Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The advantages of aggregating metrics directly on the application side #145

Open
niceblex33 opened this issue Jan 10, 2024 · 2 comments
Open

Comments

@niceblex33
Copy link

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.

@consolibyte
Copy link

There's some discussion around disadvantages of the push gateway in the Prom documentation. It's worth reading:
https://prometheus.io/docs/practices/pushing/

The two ones that stand out here to me are:

  1. 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)
  2. 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.

@niceblex33
Copy link
Author

Thank you for the very detailed answer. I also did some research and already changed my mind towards its better to use pull strategy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants