best idea to importing rrd into graphite

This forum was archived to /woltlab and is now in read-only mode.
  • Hi,


    I would like to ask your opinion and help:
    What is the best way to import rrd databases into graphite?
    (I plan to change nagios + pnp4nagios to icinga2 with graphite + grafana but I do not want to loose my performance data) of course gaps are not an issue.... )


    Thanks,


    klajosh

  • Rumors tell this is a pain. Rather archive the rrd storage and start fresh. Or continue to use PNP for half a year in parallel with Graphite and then stop it.

  • thanks! this would have been my second idea... and now the question is how I can feed 2 graphing solution with 1 performance data query?
    can you help me with this?

  • What exactly do you mean by "querying"? Is it about feeding that from Icinga 2 to the various backends, or is it a presentation layer question?

  • feeding from icinga2 to various backends. I have already read that more than one action urls can be added to services and hosts.
    so the idea then would be to feed:
    pnp4nagios backend (rrd databases)
    graphite backend (carbon)


    how can I do that?

  • Simple. You'll setup PNP and Graphite as readers.


    • PNP with NPCD als Perfdata-File-Collector and icinga2 feature enable command (as per the documentation)
    • Graphite Carbon Cache listening on tcp/2003 and icinga2 feature enable graphite (as per the documentation)

    If you require more than one perfdatawriter, or multiple graphite carbon cache writers, edit the configuration files and add multiple config objects with different settings.

  • ooki. this works as the documentation says. now I have 2 graphing solution. this is very good.
    just for curiosity how does it work? I mean the check runs, gets the performance data. Then
    what happens with the performance data? Because as I know pnp4nagios gets it and then stores in rrd then deletes it.
    But now as I see graphite also keeps updating. What kind of magic does icinga2 do? :)

  • Hm. Where to start so it does not get too technical ... Imagine that there is a pool of workers (threads) which watch out for tasks. Such a task could be a scheduled check execution. Icinga 2 fires the check, but does not wait for it (another local worker takes over, or it is fired over the cluster to another node for execution).


    Then there is a worker which waits for new checkresults (from a local check or as cluster event, or even sent in via API or Command Pipe, all their own workers). It does some state change and notification calculation and then signals all registered handlers - hey, a new checkresult is here (OnNewCheckResult, boost signal in the code).


    One thing which also happens - when the checkresult is received, there is a dedicated PerfdataValue class which parses the perfdata string into an actual object with attributes (value, etc.). It is described over here, since you can query it through the API.



    There's a lot of them, and for features each object handles such. So if you have 2 GraphiteWriter objects, both will get the signal. In your scenario both PerfdataWriter and GraphiteWriter receive the signal with the checkresult and the current checkable object.


    The thing which happens in PerfdataWriter - it will replace the runtime macros with the received information (check result output, PerfdataValues, host name, service name) and then dump it into a rotated file. (the rotation happens in a timer which runs asynchronous).


    The GraphiteWriter does a similar thing - the format template gets replaces by actual values, metrics are escaped, and additional metadata/thresholds are added if enabled. Then the metric is pushed to the defined tcp socker where carbon cache is listening.


    And if you look into the code regions above - the API event streams listen to that signal as well. GelfWriter, OpenTsdbWriter, InfluxdbWriter (new in 2.5), even the IDO database events for historical tables. Well and the cluster replication also depends on that signal.


    So Icinga 2 isn'T just a core which checks and notifies. It feels more like sound foundation for a framework, using modern programming techniques and abstracting certain things. The GraphiteWriter code is rather short and also portable if you want to start develop your own writer.

  • :-)


    You can also see certain integrations highlighted in my talk from Icinga Camp Berlin 2017: https://www.icinga.com/2017/03…a-camp-berlin-2017-recap/

  • If you want to use InfluxDB there is a script that can convert RRDs to InfluxDB.

    I think sni knows exactly where it is hidden in OMD :) I used it for a customer, it was easy to customize to fit the environment i had.