Change values in graphs

[komodo]

Hi

I have one problem with graphs. When i look at the page Views there are ping graphs for some hosts, but there are some strange values, like "Last 258.6m". What is it ? I need there values in ms for ping, but it seems that there is real value x 1000 and with "m" at the end.
Is there any chance to change this ?

Thank you

[ttsig]

I have noticed the same thing. It makes the graphs less than impressive and that was the primary reason I was interested in Centreon. We see the same thing for the "load average" graphs from Linux host. A load of .14 is shown as 140m.

The "m" appears to stand for milli so my guess is that you seeing .2586ms ping times and Centreon is displaying graphs as 258.6 milli-milliseconds, which makes very little sense it all.

There really needs to be a way to tell the graph template how to present the information in a reasonable way. It appears the graph templates in their current form simply don't let you define this and use the "rrdtool" defaults, which I think tries to turn fractional values into whole numbers, but I'll admit I haven't looked at the code yet.

If I'm wrong, and there is an easy way to make the graphs show reasonable numerical values I'd love to know it, however, I've noticed that even the screenshots one the website appear to show this same behaviour.

Thanks,
Tom

[komodo]

Hi, so i had tested some things about graphs, and with advice from some guy at irc ot looks that these values ar dependent from check plugin results. So i have changed ping plugin from centreon_check_ping to check_fping. But i have had delete entries from metrics table in centreonds db and purge ods db.
Then graphs are build again and they look much better.

[ttsig]

Well, I don't see how it can be based solely on the plugin results. I've been using the load average plugin and the data returned by that plugin is correct. If I get back a load of .14, the RRD contains the correct data but the graph displays 140m which makes no sense as a load average. If the load is over 1 it seems OK.

In looking at the code the reason for this is that the tool is building it's RRD graph template and using "%s" in the GPRINT command. The %s command tells rrdgraph to use SI Magnitude values in the output as shown here http://www.vias.org/encyclopedia/unit_prefixes.html. Because of this 1000 is "k" and 1000000 is "M" and .1402 is "140.2m". This is good for graphing things like network traffic, but no so great for things like load average or latency.

The only way that I can see to fix this properly is to add an additional option to the Curve templates to define if you want "SI Magnitude Scaling" of the value. I made a quick modification to add a "Automatically Scale Value" checkbox, an new column to the database (ds_scaling), and changed the generateODSImage.php file to use this flag and now my graphs have reasonable looking data.

This would be a really nice enhancement.

[DonKiShoot]

Maybe you could share your work with us and maybe open a bugtrack for developpers to integrate your work if they guess.

PS: Sorry for my bad english ;-)

[komodo]

Well, I don't see how it can be based solely on the plugin results. I've been using the load average plugin and the data returned by that plugin is correct. If I get back a load of .14, the RRD contains the correct data but the graph displays 140m which makes no sense as a load average. If the load is over 1 it seems OK.

In looking at the code the reason for this is that the tool is building it's RRD graph template and using "%s" in the GPRINT command. The %s command tells rrdgraph to use SI Magnitude values in the output as shown here http://www.vias.org/encyclopedia/unit_prefixes.html. Because of this 1000 is "k" and 1000000 is "M" and .1402 is "140.2m". This is good for graphing things like network traffic, but no so great for things like load average or latency.

The only way that I can see to fix this properly is to add an additional option to the Curve templates to define if you want "SI Magnitude Scaling" of the value. I made a quick modification to add a "Automatically Scale Value" checkbox, an new column to the database (ds_scaling), and changed the generateODSImage.php file to use this flag and now my graphs have reasonable looking data.

This would be a really nice enhancement.

Great work :-) So it would be good to post this to developers like DonKiShoot said.

[ttsig]

I had considered opening a bug, however, I found the bug system confusing as the majority of the bugs appear to be in French and I only speak English.

I've noticed that this issue has come up several times in the forums so obviously this is an issue for other users so I'll go ahead an open the bug and post my patches. I'm sure they'll need cleanup to be accepted, but perhaps they'll at least give them an idea.

[ryker]

What's really confusing is there seems to be 2 bug trackers. If you click on the 'bugs' link at the top of this page, that brings you to a flyspray bug tracker. It used to only be for Oreon, but now I see that they seemed to have added Centreon 2 in the versions list.
...and if you click on the 'Trac' link above, it brings you to the trac page. Click on 'view tickets' and then 'active tickets'. You'll see that is pretty active.
I've submitted bugs for Centreon when it was in beta on both sites. The bug on the flyspray tracker seemed to be ignored, while the bugs submitted on the trac page weren't.
I would suggest using the trac page to submit the bug.
I'm very much anxiously awaiting this to be included in the next release of Centreon. My boss is as well. :)

[DonKiShoot]

Yes flyspray seems to be dead for a while.
Centreon team should delete all link to flyspray, it's confusing.

[ttsig]

OK, I have opened bug 364 (http://trac.centreon.com/ticket/364) in Trac and within the bug I have posted a patch with my version of a "quick fix", a simple option that allows you to enable or disable scaling on a per-graph basis.

I'm not much of a PHP coder and I'm sure my patch would need some work to be accepted in to the actual code, however, it works for me, and I think this is an important fix as without this, many graphs make no sense at all.