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

Show HN: Pup, real-time app metrics with Statsd

datadoghq.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Show HN: Pup, real-time app metrics with Statsd

#11

Post by olidb2 »

axx wrote: post #8

Am i understanding this right: this is a kick in the butt for services like NewRelic? Does this always need to run on the same server as the Application? Or is it possible to run it on a different server and push the data to it? disclaimer: i have no experience with statsd/graphite etc.

So: - It doesn't need to run on the same server as the application, and you can have any number of apps reporting to it. The only limitation here is that apps communicate with Pup in UDP.

- Our goal with pup was to make it super-easy to see app metrics. It is therefore much narrower in scope than services like New Relic or projects like Graphite. It's open-source, though, and you can take it anywhere you want.

- We ourselves operate a service that can consume data from Pup and other sources, and provides metrics + events aggregation and correlation, fancy graphing, alerting, etc.. You can check-it out at http://datadoghq.com

Re: Show HN: Pup, real-time app metrics with Statsd

#13

Post by sciurus »

brokentone wrote: post #7

Excellent project! If I understand this right, it's an addition/replacement for StatsD that adds the graphing normally done in Graphite. I've tried to get the whole Graphite/StatsD stack setup before, and I could never get Graphite together quite right.

Somewhat off-topic, but what value is there in using statsd rather than talking to carbon, the graphite backend, directly? Statsd receives metrics over udp; carbon-cache can receive them over tcp, udp, or amqp. Statsd aggregates metrics and flushed them a set intervals; if you want this, carbon-aggregator can do it.

http://graphite.readthedocs.org/en/0.9.10/carbon-daemons.htm...

Re: Show HN: Pup, real-time app metrics with Statsd

#15

Post by olidb2 »

amix wrote: post #12

This seems to be basically a collector that sends data to Datalog (a NON open-source service that costs $15/host/month). I recommend setting up Grahite+statsd (it's truly amazing and open-source realtime metrics setup).

This was developed for Datadog, yes. But Pup works fully stand-alone and is completely open-source - so you can take whatever you want / need from it.

Pup has a narrower scope than Graphite (which we also use and love), but optimizes for shortest time to app metrics viz.

(Oh and Datadog itself is all free up to 5 hosts - but remains completely optional)

Re: Show HN: Pup, real-time app metrics with Statsd

#17

Post by achompas »

olidb2 wrote: post #15
amix wrote: post #12

This seems to be basically a collector that sends data to Datalog (a NON open-source service that costs $15/host/month). I recommend setting up Grahite+statsd (it's truly amazing and open-source realtime metrics setup).

This was developed for Datadog, yes. But Pup works fully stand-alone and is completely open-source - so you can take whatever you want / need from it. Pup has a narrower scope than Graphite (which we also use and love), but optimizes for shortest time to app metrics viz. (Oh and Datadog itself is all free up to 5 hosts - but remains completely optional)

> but optimizes for shortest time to app metrics viz.

I'm not sure I understand what "shortest time to app metrics viz" means. Are you referring to the time Pup takes to create charts? Or the lowest time frequency (minutes, seconds etc.) it can handle?

Graphite defaults to reporting at 1-minute intervals, and can report at a finer granularity (1 sec. intervals) if you tweak a few settings and set up a cluster. I'm just wondering how Pup differs in this respect.

Re: Show HN: Pup, real-time app metrics with Statsd

#20

Post by achompas »

sciurus wrote: post #13
brokentone wrote: post #7

Excellent project! If I understand this right, it's an addition/replacement for StatsD that adds the graphing normally done in Graphite. I've tried to get the whole Graphite/StatsD stack setup before, and I could never get Graphite together quite right.

Somewhat off-topic, but what value is there in using statsd rather than talking to carbon, the graphite backend, directly? Statsd receives metrics over udp; carbon-cache can receive them over tcp, udp, or amqp. Statsd aggregates metrics and flushed them a set intervals; if you want this, carbon-aggregator can do it. http://graphite.readthedocs.org/en/0.9.10/carbon-daemons.htm...

Other, more experienced people can speak to this, but I'd argue that statsd has a useful ontology for classifying metrics based on what you want them to track.

If you're watching a number go up, use a statsd.Counter. Want to track request arrival rates? Use statsd.Gauges. Want to record times for request fulfillment? Use statsd.Timers.

Statsd isn't necessarily better or worse than carbon-cache via UDP, but it provides a handy solution for the above use cases.

Post reply on HN