search

shinken-monitoring / mod-webui

Shinken Web User Interface
GNU Affero General Public License v3.0
79 stars 71 forks source link

Add a performance data tab in element view #274

Closed mohierf closed 9 years ago

mohierf commented 9 years ago

Add a performance data tab in the element view to display all the available metrics for all services of an host. Links to a Graphite graph for each metric ...

mohierf commented 9 years ago

In host view, creates a table containing all the metrics of all host services. For each metric, displays : value, warn, crit, min, max and UOM, and then includes a perfometer that displays a Graph for the metric.

image

Simage commented 9 years ago

@mohierf. Is this not just a modified graphs tab with a slightly different interface??

mohierf commented 9 years ago

The idea was to have all the known metrics of an host/service in a single tab ...

For an host element, the graphs tab displays the graphs for the host check perfdata if they exist.

Simage commented 9 years ago

Obviously my mind doesn't work so well after midnight, I see the difference now.

I blame age, apparently I'm not as young as I used to be

mohierf commented 9 years ago

:-)

naparuba commented 9 years ago

Cool!!! :D

On Fri, Jul 31, 2015 at 9:32 AM, Frédéric MOHIER notifications@github.com wrote:

:-)

— Reply to this email directly or view it on GitHub https://github.com/shinken-monitoring/mod-webui/issues/274#issuecomment-126592653 .

mohierf commented 9 years ago

This view raised a problem in Shinken when you do not always receive the same perfdata in the hosts/services checks ... only the last received perfdata/metrics are stored in Shinken objects !

Let me explain with an example :

Only the metric counter2 is known by Shinken whereas counter1 is a metric that should be available for the service ... it may be interesting that all the metrics received in the perfdata are stored with the service and not only the last one !

I will open an issue in Shinken for this feature ...

maethor commented 9 years ago

Actually, I don't know about Graphite but if you have a service doing that with PNP4Nagios, I will break your graphs.

naparuba commented 9 years ago

It's not to the core to manage perfdata. It's out of it's scope.

What I did in enterprise is just to query graphite to have all metrics for a service. Simple and efficient ^^

On Fri, Jul 31, 2015 at 11:29 AM, Guillaume Subiron < notifications@github.com> wrote:

Actually, I don't know about Graphite but if you have a service doing that with PNP4Nagios, I will break your graphs.

— Reply to this email directly or view it on GitHub https://github.com/shinken-monitoring/mod-webui/issues/274#issuecomment-126621655 .

mohierf commented 9 years ago

Ok, if core do not manage perfdata, we should remove the perfdata.py from Shinken core ;-)

And for sure, we may request all metrics in Graphite but what about PNP ... is it possible ? Not sure it is ...

1/ We may choose to build a WebUI only with Graphite metrics ... :/P 2/ An extra module should manage and store a simple dictionnary for each host/service to keep all the metrics 3/ Metrics list is requested from Graphite and/or PNP 4/ we should leave this tab as is ...

I prefer the second option :-)

mohierf commented 9 years ago

@maethor: what is the problem with PNP and different metrics in perfdata ?

maethor commented 9 years ago

RRD doesn't manage the case you describe. If you loose a variable in a perfdata, the RRD database for this perfdata « breaks » and is not readable anymore, because she doesn't match the new xml schema.

To answer your previous comment, I don't know if we can retrieve the list of metrics from PNP.

mohierf commented 9 years ago

Tell me if I am wrong ... With RRD, you must specify all the metrics that you may store for a service. Let's say : counter1, counter2 and counter3

I a service check contains only counter1, it does not break ? It only stores the received value ... And if next check sends values for counter2 and counter3, it is also ok ?

maethor commented 9 years ago

You are wrong :)

I don't know the internals, but RRD init the DB with the first perfdata it receives. So if the first perfdata contains "counter1", "counter2" and "counter3", the DB is init with this "fields". Then, if the perfdata schema changes, the RRD database will break.

But again, I don't know the internals. Maybe I should look at npcdmod (the equivalent of mod-graphite), because it may not be a RRD bug but a npcdmod's one.

mohierf commented 9 years ago

Too bad ... :/P

naparuba commented 9 years ago

That's in misc (or at least should be) because of common parsing between modules. But Remeber that shinken is a monitoring tool, not a metrology one and will stay like this :)

If I'm not wrong pnp is able to be queried like graphite, to have all metrics. But it's very very long since I try it, so I don't really remember ^^

For the module that look/store metric names, maybe with a redis server? But it's anoter module, so harder to setup etcetc. Ask the metrology part/module to query the metrics and then display it it not a big deal, and is easier I think.

On Fri, Jul 31, 2015 at 1:13 PM, Frédéric MOHIER notifications@github.com wrote:

Too bad ... :/P

— Reply to this email directly or view it on GitHub https://github.com/shinken-monitoring/mod-webui/issues/274#issuecomment-126657039 .

Simage commented 9 years ago

you do not always receive the same perfdata in the hosts/services checks ... only the last received perfdata/metrics are stored in Shinken objects !

Is this a problem? The purpose of the perfdata module is to display the current perfdata. Display of historic data is managed by the graphing module. Theoretically, if the set of metrics you receive changes, that change potentially contains meaning, by hiding that change and showing the full set of all metrics ever recieved that meaning is lost from the data.

Graphite and pnp shouldn't care because missing metrics should receive a null value and new metrics should create a new database for that metric. Not 100% certain about PNP but I know graphite works this way

mohierf commented 9 years ago

My concern is not the changing metrics ... but to get a view of all the metrics for a check. If all metrics are not always sent in the perfdata, you only see the last sent metrics ...

I copy the comment I wrote this morning with an example : 

Let me explain with an example : 
- you receive a service check with perfdata containing **counter1=1**
- you receive a new check for the same service with perfdata containing **counter2=1**

Only the metric counter2 is known by Shinken whereas **counter1** is a metric that should be available for the service ... it may be interesting that all the metrics received in the perfdata are stored with the service and not only the last one !
mohierf commented 9 years ago

@naparuba : sure, Shinken is not a metrology tool ... but I find it interesting to allow the monitoring user to see the last value of all the received metrics and not only the last perfdata.

I will open a WebUI issue with this feature ... for future enhancement

mohierf commented 9 years ago

Closing ... going on #285