support carbonapi

[tbauriedel]

This PR not only adds support for carbonapi, it supports graphite-api which implements API version 0.9.8 and carbonapi which implements the necessary endpoints of API version 1.11.7 (and not metrics/expand).

Endpoint Documentation:

• graphite-web
• graphite-api
• carbonapi

I have tested it with the latest available graphite-api and carbonapi v0.16.0

Possible solution for #300

Feedback welcome!

CC @dgoetz

[widhalmt]

Tested it in my environment as well. Works flawlessly so far. THANK YOU!

[citfs]

It also works perfectly in our environment. Thank you very much.

[nilmerg]

Just to be sure, this keeps 100% compatibility with how it worked before?

[tbauriedel]

We use another API endpoint now. The return of the API is a little bit different, which is why the data is stored slightly differently into the results.

Based on the API endpoint documentations that will work with all possible components.
As mentioned: It is only tested on graphite-api and carbonapi. I had no graphite-web to test it there also. Based on the documentation it should work there also.

Besides of that it works how it worked before.

Long story short: It was possible for me and others to switch from graphite-api to carbonapoi without changing anything on the module. Drop-in replacement.

[tbauriedel]

While working on another topic for the module I have found a difference that will break the current behaviour.

The changes merge graphs with placeholders into one * and only one graph is rendered. (Also in the graphite-api) I'll take another look at the whole thing in detail and try to adapt it accordingly.

Please wait for that before merging!

Before: After:

[tbauriedel]

To solve the problem mentioned above, deep changes to the module are necessary, which would significantly change the behaviour. In order to provide clear compatibility with all versions, support for the different API versions must be built. Due to the depth and complexity of the module at this point, these changes currently exceed my possible time frame, which is why I am dependent on the support of Icinga.

If you (Icinga) are interested in supporting the current stack around Graphite, I would be happy to provide further information on which steps would need to be adapted from the Graphite / CarbonApi perspective.

[RincewindsHat]

ref NC/843420

[nilmerg]

The current stance seems to that graphite is dead. If you want to support the carbon-api, feel free to continue and propose a change dropping the old backend support.

[tbauriedel]

Just my two cents:

I have seen quite a few Icinga 2 environments. After Grafana, Graphite is still the tool of choice to have graphs when using Icinga 2. Graphite allows you to create graphs without much effort and without having to set up a complete 'visualisation environment'. Likewise, the complete Icinga 2 stack does not yet offer a usable alternative for graphs, which is why Graphite is still used here.
In many environments there is no Grafana or similar alongside Icinga Monitoring. Graphite is still often seen here.

So I cant agree that Graphite in combination with Icinga 2 is dead.

[martialblog]

Jello,

Maybe we are holding this thing upside down. Meaning, instead of this module supporting go-carbon, or more specific carbonapi, maybe carbonapi should a) implement the metrics/expand endpoint and b) it should be compatible with the original flavor Graphite.

There's already an issue for that https://github.com/go-graphite/carbonapi/issues/245

[martialblog]

carbonapi v0.16.1 implements the /metrics/expand, however I found some issues which I addressed here: https://github.com/go-graphite/carbonapi/pull/865

Been testing the main branch of the icingaweb2-module-graphite with carbonapi v0.17.0+myfixes - no issues so far

[nilmerg]

Glad to hear! For me this is then obsolete.