You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In particular, fields like camera_fps (and related fields) report a metric that's a rate (some quantity per time). This is fundamentally hard to scrape since the consumer now needs to know the sampling rate at which this metric is updated. If the field is scraped too slowly, then the consumer may miss sudden dips or spikes in the rate.
Instead of (or in addition to) reporting a rate, I propose that we provide a monotonically increasing counter. So instead of camera_fps, it would be camera_frames, which is the total number of camera frames seen. If this data is being dumped into prometheus or influxdb, it's trivial to take the derivative to produce a more accurate rate (one that cannot miss dips and peaks).
The text was updated successfully, but these errors were encountered:
NickM-27
changed the title
api/stats: should record counts, not rates
Keep statistics of total frame count as well as average frame rate for time series databases
Sep 12, 2024
This would also be useful for alerting when a camera is offline. Right now I don't see a way from /api/stats to see if a camera stream isn't working. If the frame count was available and weren't increasing that would be one way to know.
Hi, thank you for your hard work on Frigate.
The
/api/stats
API currently exposes fields like:In particular, fields like
camera_fps
(and related fields) report a metric that's a rate (some quantity per time). This is fundamentally hard to scrape since the consumer now needs to know the sampling rate at which this metric is updated. If the field is scraped too slowly, then the consumer may miss sudden dips or spikes in the rate.Instead of (or in addition to) reporting a rate, I propose that we provide a monotonically increasing counter. So instead of
camera_fps
, it would becamera_frames
, which is the total number of camera frames seen. If this data is being dumped intoprometheus
orinfluxdb
, it's trivial to take the derivative to produce a more accurate rate (one that cannot miss dips and peaks).The text was updated successfully, but these errors were encountered: