Live data from Hacker News

Graphiti: An Alternate Frontend for Graphite

dev.paperlesspost.com

1–10 of 21 posts

Re: Graphiti: An Alternate Frontend for Graphite

#2
Graphite is a great tool for quickly seeing what is going on. Generating the graphs was always a bit of a pain point for it. I must say, this is an amazing contribution. Thanks so much.

(I'm the author of http://jmxtrans.googlecode.com which allows you to very easily tie together Graphite & Java Management Extensions (JMX) for monitoring all of your JVM's.)

Re: Graphiti: An Alternate Frontend for Graphite

#4
As this post recognizes, there are a lot of components bundled under the name Graphite:

* There's whisper, the file format carbon uses to store time-series data.

* There's carbon, the daemons that accept data over the network, combines them, and writes them to whisper files.

* There's graphite, a django application that can read data from carbon files or RRD files. Graphite features several user interfaces of its own as well as an API to render the data as graphs or as numerical values.

What I find most interesting is graphite's API's potential as an intermediary service between your metrics storage (whether its RRD, whisper, or some other format that you add support for) and your applications that need to consume those metrics (e.g. your monitoring system, your dashboards).

Re: Graphiti: An Alternate Frontend for Graphite

#7

Why would I want to use graphite, a python based graphing solution to say rrdtool?

Not sure why you got voted down, so I'll vote you back up and answer your totally valid question.

rrdtool is fine if you know your schema in advance, but that is somewhat of a hinderance because you don't always know it or want to have to define it.

Graphite is great because it listens on a port an accepts data in a simple unstructured format. The format is: key : value (long) : timestamp

Where key can be in dot notation so that you can have your data in a 'tree' like structure. This is a made up example: "ehcache.activemq.joins" or "ehcache.activemq.quits". The dashboard can then give you a nice tree to navigate through your data so that you can pin down specific areas that you'd like to graph. It also allows you to easily mix and match areas as overlays.

Hope that explains things.

Re: Graphiti: An Alternate Frontend for Graphite

#8
post #5

I've been working on a less-configurable sort of graphite dashboard for use as an ambient display- https://github.com/potch/statsdash . Looks great on a tablet.

Another alternate graphite frontend worth following is Gdash. I like that its dashboard and graph configuration is done through YAML files.

http://www.devco.net/archives/2011/10/08/gdash-graphite-dash....

Re: Graphiti: An Alternate Frontend for Graphite

#10

Why would I want to use graphite, a python based graphing solution to say rrdtool?

Well, you can use graphite as a frontend to your RRD files if you like. I'm using it to view data gathered by collectd and am planning to throw some RRD files generated by jmxtrans at it soon.

If you were writing a tool that recorded time-series data, there's some explanation of why you might choose whisper over rrdtool at http://graphite.wikidot.com/whisper. I don't know of any other projects thats use whisper directly, though, and the creator of whisper is working on a replacement for it named ceres (http://graphite.wikidot.com/roadmap#toc0). The primary appeal is of the carbon daemon, which lets you send data to it over a super-simple protocol and takes care of persisting it for you.

Post reply on HN