Repository navigation
Detect when Vector is lagging #20432
|
Is there a way using which we can somehow detect by how much the vector is falling behind reading events from a particular file? Currently we want to use vector to use file source to push logs of a very critical application (Almost 0 log loss) to kafka and we want to get alerted if vector is lagging behind and is not keeping up with the load. |
Replies: 2 comments 1 reply
|
My suggestion for this would be to add a timestamp to each event as it is written to the file and then you could measure the difference between the timestamp being read and "now" (in Vector this could be done using a |
|
For your follow-up, the file source exposes an This exposes Vector's internal metrics: sources:
internal:
type: internal_metrics
scrape_interval_secs: 1
sinks:
metrics:
type: prometheus_exporter
inputs: [internal]
address: "0.0.0.0:9598"I checked this on Vector 0.60.0: the gauge reported 2 for two open files, then 3 when another matching file appeared. The count cannot prove that every file was discovered. A file can appear and disappear between discovery scans. Keep rotated files available long enough to be discovered and drained, include the relevant rotated paths, and review Jesse's timestamp approach measures the age of events that actually reach Vector. Use the application's written timestamp, with synchronized clocks; the file source's default |
For your follow-up, the file source exposes an
open_filesgauge. With the default internal-metrics namespace, it appears in Prometheus asvector_open_files, withcomponent_ididentifying the file source.This exposes Vector's internal metrics:
I checked this on Vector 0.60.0: the gauge reported 2 for two open files, then 3 when another matching file appeared.
The count cannot prove that every file was discovered. A file can appear and disappear between discovery scans. Keep rotated files available long enough to be …