Collector logging #1783
Collector logging #1783
Conversation
|
@ajssmith wanted to get your take on this approach before cleaning it up a bit. I'm still on the fence about the "flow-logging-profile" flag. Background: In skupper v1 the volume of logs coming from a collector handling a lot of vanflow records could be a problem. In v2 I dropped flow logging to avoid the issue. For the most part I have not missed them - I have been leaning more on some of the new internal metrics the collector publishes, but there's been a time or two I wish I had them. Starting out on the problem, I went with a fully user configurable per-record-type-regex-matching sampling but found that was too much to configure as a user. I've since moved to offering "profiles" with different sampling strategies set at somewhat arbitrary levels. Thoughts on this approach? Other suggestions? EDIT Went forward with cleaning out some of the original cruft. Considering this fully ready for review! |
c-kruse
force-pushed
the
collector-logging
branch
from
194eb8d to
f03e868
Compare
|
|
||
| var ( | ||
| // loggingProfileMinimal logs 1 vanflow event per second (with bursts up to 32) | ||
| // reduces Link Record noise to 1 every ~20s. |
There was a problem hiding this comment.
@ted-ross thought you may find this interesting. I know you've mentioned link record noise before.
I felt I had to suppress logging for LinkRecord messages in particular due to the constant churn of octets/octet rates. When under load, I think Connector and Listener records were also observed to be particularly busy.
Signed-off-by: Christian Kruse <[email protected]>
Implements several "profiles" to control the quantity of vanflow record logging the collector does. Defaults to none. Signed-off-by: Christian Kruse <[email protected]>
c-kruse
force-pushed
the
collector-logging
branch
from
f03e868 to
16dcffd
Compare
|
Thanks for this. Agree that having a way to control the logging of flow-events is needed. While there are other, it seems that he primary use case for generating flow logs it to satisfy audit requirements or to support debug activities related to communications across the van. Having the ability to dynamically turn on/off flow logging would be sufficient. If user needs the logs for audit purposes, the sampling feature would likely not be used. The question is whether sampling would be useful for debugging or simply turning logs on/off for a period of time would be ok. It has been suggested by a number of users that long term, the granularity of flow logging should be at the routing key level (e.g. generate flow logs for service a but not for service b). |
|
Closing for now! There's a few nuances I think we should probably tackle here. |
flow-logging-profileflag to allow opt-in for the logging of vanflow records with some coarse control over the volume of log events though sampling.