Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prometheus: An open-source service monitoring system and time series database

prometheus.io

Post reply on HN
Print view View original

21–30 of 122 posts

Re: Prometheus: An open-source service monitoring system and time series database

#21

Post by bbrazil »

e12e wrote: post #19

So... how does this compare to http://riemann.io/ ? I just re-discovered riemann... and was thinking of pairing it with logstash and have a go. It would seem prometheus does something... similar?

From my look at Riemann, it seems more aimed as an event monitoring system than a time-series monitoring system. You can (and many do) use Riemann as time-series monitoring system, my understanding is that Prometheus is a bit better for multi-dimensional labels.

I could see Riemann being used as an alert manager on top of Prometheus, handling all the logic around de-duping of alerts and notification. Prometheus's own alert manager is considered experimental.

Re: Prometheus: An open-source service monitoring system and time series database

#22

Post by [deleted] »

lifeisstillgood wrote: post #20
[deleted] wrote: post #18

Earlier quoted context omitted.

[deleted]

What on earth? Google imposes non disclosure on ex-employees to mention by name in-house monitoring systems? (Presumably Borg-monitor?) That strikes me as a bit paranoid, not letting the name of a monitoring system be revealed. Am I missing something?

[deleted]

Re: Prometheus: An open-source service monitoring system and time series database

#24

Post by bbrazil »

corford wrote: post #23

This looks great! Is an official Python client library on the roadmap?

Yes, I've got something working at the moment. It needs cleanup, docs, unittests etc.

If you want to help out, it's up at https://github.com/brian-brazil/client_python

Re: Prometheus: An open-source service monitoring system and time series database

#25

Post by clarkevans »

We've been looking for something like this, unfortunately the "pull" model won't work for us. We really need a push model so that our statistics server doesn't need access to every single producer. I see the pushgateway, but it seems deliberately not a centralized storage.

I wonder what InfluxDB means by "distributed", that is, if I could use it to implement a push (where distributed agents push to a centralized metric server) model.

Re: Prometheus: An open-source service monitoring system and time series database

#26

Post by bbrazil »

clarkevans wrote: post #25

We've been looking for something like this, unfortunately the "pull" model won't work for us. We really need a push model so that our statistics server doesn't need access to every single producer. I see the pushgateway, but it seems deliberately not a centralized storage. I wonder what InfluxDB means by "distributed", that is, if I could use it to implement a push (where distributed agents push to a centralized metr…

(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.

Re: Prometheus: An open-source service monitoring system and time series database

#27

Post by clarkevans »

bbrazil wrote: post #26
clarkevans wrote: post #25

We've been looking for something like this, unfortunately the "pull" model won't work for us. We really need a push model so that our statistics server doesn't need access to every single producer. I see the pushgateway, but it seems deliberately not a centralized storage. I wonder what InfluxDB means by "distributed", that is, if I could use it to implement a push (where distributed agents push to a centralized metr…

(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 s…

Each 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.

Re: Prometheus: An open-source service monitoring system and time series database

#28

Post by Rapzid »

clarkevans wrote: post #25

We've been looking for something like this, unfortunately the "pull" model won't work for us. We really need a push model so that our statistics server doesn't need access to every single producer. I see the pushgateway, but it seems deliberately not a centralized storage. I wonder what InfluxDB means by "distributed", that is, if I could use it to implement a push (where distributed agents push to a centralized metr…

Same here; need push for integration. It appears that Prometheus favours pull to a fault. To me it makes sense to have a push/message infrastructure that you can then write scrapers for to your hearts content. InfluxDB has push, but I read that it uses 12X the storage due to storing metadata with each metric; Yikes!

Re: Prometheus: An open-source service monitoring system and time series database

#29

Post by bbrazil »

clarkevans wrote: post #27
bbrazil wrote: post #26

Earlier quoted context omitted.

(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 s…

Each 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 securit…

That'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 looks at other bits of the push vs. pull question.

Re: Prometheus: An open-source service monitoring system and time series database

#30

Post by clarkevans »

Rapzid wrote: post #28
clarkevans wrote: post #25

We've been looking for something like this, unfortunately the "pull" model won't work for us. We really need a push model so that our statistics server doesn't need access to every single producer. I see the pushgateway, but it seems deliberately not a centralized storage. I wonder what InfluxDB means by "distributed", that is, if I could use it to implement a push (where distributed agents push to a centralized metr…

Same here; need push for integration. It appears that Prometheus favours pull to a fault. To me it makes sense to have a push/message infrastructure that you can then write scrapers for to your hearts content. InfluxDB has push, but I read that it uses 12X the storage due to storing metadata with each metric; Yikes!

What do you use for push-oriented time-series metrics? We are thinking of using LogStash (it has a go client). Unfortunately, as I understand, it's not time-series oriented.
Post reply on HN