3 ms·
(One of the Prometheus authors here) My understanding is that InfluxDB will work for your use case, as it's all push. > I see the pushgateway, but it seems de
by bbrazil 12y ago
(One of the Prometheus authors here)
My understanding is that InfluxDB will work for your use case, as it's all push.
> I see the pushgateway, but it seems deliberately not a centralized storage.
Yeah, the primary use case for the pushgateway is service-level metrics for batch jobs.
May I ask why accessing your producers is a problem? I know for Storm I was considering writing a plugin that'd hook into it's metrics system, that'd push to the pushgateway and Prometheus would then scrape. Not my preferred way of doing things, but some distributed processing systems need that approach when work assigment is dynamic and opaque across slaves.
- clarkevans 12y agoEach node in our network has it's own access control permissions and organizational owner. It's easy enough to provide a centralized service with an end-point to push statistics from each node. In this case, organizational participation is "distributed". A pull model, while technically distributed, is organizationally centralized: I have to get each node's owner to grant me direct access. Politically, and for security reasons, that's not going to happen.
- bbrazil 12y agoThat'd be a challenge alright. One thing to consider is having each owner run their own Prometheus so that they can take advantage of all it's features, though it's a harder sell than "just push over here". http://www.boxever.com/push-vs-pull-for-monitoring http://www.boxever.com/push-vs-pull-for-monitoring looks at other bits of the push vs. pull question.
- hartror 12y agoThis is a common problem that you describe.