I also like enabling blackholes with high print_amount settings anyway, so that my journald logs show some progress occasionally.
I like this idea, but it overlaps somewhat with observing Vector in general. When Vector supplies it's own "internal" metrics source the user could then build a pipeline to visualize that data however they wish. In addition, we could provide a light-weight Vector sub-command on the CLI that could use this data to provide insight into a running Vector instance. That said, this still doesn't entirely cover the use case quoted above, which is basically a "heartbeat" within the logs themselves.
What I'm wondering is if we should consider canoncial log lines for each component that could be printed at a configurable rate. This could include any information it wants, such as the number of successful events processed, number of failures, timing information, and more. But how would this overlap with our own internal metrics, if at all?
Before beginning work we should decide this is worth doing and formulate a spec that we all agree on. This should take into consideration upcoming observability work.
jszwedko
commented
2 years ago
This is a follow up to https://github.com/timberio/vector/pull/1237. Specifically this quote:
I like this idea, but it overlaps somewhat with observing Vector in general. When Vector supplies it's own "internal" metrics source the user could then build a pipeline to visualize that data however they wish. In addition, we could provide a light-weight Vector sub-command on the CLI that could use this data to provide insight into a running Vector instance. That said, this still doesn't entirely cover the use case quoted above, which is basically a "heartbeat" within the logs themselves.
What I'm wondering is if we should consider canoncial log lines for each component that could be printed at a configurable rate. This could include any information it wants, such as the number of successful events processed, number of failures, timing information, and more. But how would this overlap with our own internal metrics, if at all?
Before beginning work we should decide this is worth doing and formulate a spec that we all agree on. This should take into consideration upcoming observability work.