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
I would like to discuss the advantages of aggregating metrics directly on the application side. As someone who has limited experience with metric systems, the reasons for preferring this method over using a push gateway in Prometheus are not entirely clear to me. One apparent advantage of the push gateway is the absence of a need for additional dependencies like Redis. I would appreciate any clarification on this matter.
The text was updated successfully, but these errors were encountered:
By using a push gateway, you lose the health monitoring provided by the up metric (application-side metrics built by this lib will give you an automatic up=1|0 metric which you can use to monitor if the target/remote server is up or not; you don't get this with the push gateway)
By using a push gateway, you introduce a single point of failure and potential bottleneck (your application needs to always be pushing data to a single instance of the push gateway, and if the push gateway fails or becomes overloaded, you will lose metrics)
RE: "apparent advantage of the push gateway is the absence of a need for additional dependencies"
Aren't you just trading one dependency, for another? You're trading a dependency on Redis, for a dependency on the PushGateway instead.
Good day,
I would like to discuss the advantages of aggregating metrics directly on the application side. As someone who has limited experience with metric systems, the reasons for preferring this method over using a push gateway in Prometheus are not entirely clear to me. One apparent advantage of the push gateway is the absence of a need for additional dependencies like Redis. I would appreciate any clarification on this matter.
The text was updated successfully, but these errors were encountered: