graphite-dev team mailing list archive

[Francois Mikus <question198435@xxxxxxxxxxxxxxxxxxxxx>]

Question #198435 on Graphite changed:
https://answers.launchpad.net/graphite/+question/198435

Francois Mikus posted a new comment:
If I may suggest... First a bit of background. This is what is used for
the architecture of the snmp poller for the Shinken monitoring system.
The same would apply when interacting with any service or device that
can return bulk metrics.

Daemonize your poller
Do bulk requests against graphite
Cache your returned data in memory, in case you do not analyze all the data at once.(ex. memcached (You may have a scheduler)
Use a fast json library (ex. ultrajson for python)
Use python (So it could be transformed into a Shinken poller module, eh ;-)


Think of doing more analytics upfront before sending to graphite, to have more valuable metrics. See the metrics project. https://github.com/codahale/metrics or see the presentation http://pivotallabs.com/talks/139-metrics-metrics-everywhere

As for the script to do checks against graphite from Nagios... I think
what he has done is great stuff, it just may run into scalability
issues, especially if using a Nagios core.

Shinken is a much more powerful framework that could actually poll
graphite for this using an efficient daemonized poller module or act as
a listener for data coming from the sources. The sources could even send
to both graphite and Shinken.

You will be happy to note that Shinken can now drive lots of data
through its core on to graphite. It will soon include triggers to
process the raw performance data. The graphite export module is getting
better. (pickle, buffering on comm loss, bulk transfers, correct
formatting of metric names, prepending or appending data to metric
names, etc.)

Very cool stuff that may be of interest for those pushing the bounds of
monitoring.

-- 
You received this question notification because you are a member of
graphite-dev, which is an answer contact for Graphite.