Nagiosgraph: JavaScript is disabled. nagiosgraph.js is not

[mksmr]

I had already seen that - looks like it doesn't apply, but thanks a lot anyway. If things like these can happen without creating an error message I'd consider it a serious bug.

[dwhitfield]

If you believe the bug is in RRD Tool, then you can file a bug report at https://github.com/oetiker/rrdtool-1.x/issues/new.

If you believe the bug is in Nagios Core, then you can file the bug report at https://github.com/NagiosEnterprises/na ... issues/new.

Please let us know if you need help figuring out where the bug lies. Thanks!

[mksmr]

The problem is finally found, and reproducable. A rrd file with a malformed name causes it, as indicated in this thread.

Nagiosgraph generates rrd databases, using the pattern $yourservicedescription___$perfdatalabel to name them. A service named PING, i. e., returns perfdata with the label "rta" and a value, and "pl" and a value. Consequently, two files named PING___rta.rrd and PING___pl.rrd are created.

For reasons I haven't worked out yet, one of my checks returned the value NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."exq", and consequently a file named <$myservicedescription>___NET-SNMP-EXTEND-MIB%3A%3AnsExtendOutput1Line.%22exq%22.rrd was created. It's the name of the file, not its contents, that causes nagiosgraph.js to drop out without any message (apart from stopping to work properly and displaying the infamous "JavaScript is disabled..." bar).

Removing the check and restarting nagios does not help - as long as the file is present, the js component malfunctions. It can be fixed by simply removing it, but it will be re-created with the next run.

By adding a label statement to the check command like -l anylabel I'm getting a file named <$myservicedescription>___anylabel.rrd. It has the same content, but a different name. The problem does not show up then.

Generally, nagiosgraph does a good job in replacing/masking non-standard characters (blanks, slashes, backslashes, non-7bit-ascii symbols). I figure it's the ", masked by %22, that knocks the js component out.

The problem can be circumvented by always labeling check results to make sure that no weird symbols/characters end up in the rrd filenames.

As stated before, I have never seen any error messages or suspicious log entries - nagiosgraph.js just silently malfunctions. I am not aware of any documentation (nagiosgraph in general isn't very well documented and seems to be dormant, the latest version dating back to mid-2015) that explains file naming.

So - use sensible labels, don't go with the default.

I stumbled over the solution (I had almost given up on it) while setting up a new machine and copying the checkfiles one after the other from the old to the new machine. Even in a medium-sized environment, your rrd files quickly add up to a thousand and more, probably containing loads of %20s in their names. Good luck on finding that when you don't even know where to begin.

And another thing: the mere presence of the file causes the problem, even when you have no window open that would display/call it, and no active check that adds to it. I take it that the whole rrd tree is constantly parsed - it shall be interesting to watch the load as the databases grow in size and number. Again - no docu how this thing actually works, unless you're a Java programmer...

Anyway - thanks a lot for everybody's time and patience, especially in light of the fact that this isn't even an actual nagios problem.

[dwhitfield]

Thank you so much for the detail! That will be useful if others have this issue.

For those of you that thought tldr, here you go:

So - use sensible labels, don't go with the default.

@mksmr, are we ready to lock this up?

[mksmr]

@mksmr, are we ready to lock this up?

It might make sense to leave it open for a bit more, in case somebody wants to comment on it. After all it isn't really fixed (only the programmers could do that), it's just a workaround. There might be other issues that just haven't been found yet. But then, this applies to every bit of software.

N. b.: this suggests that it's actually the " or it's substitute (%22) that causes the problem.

[dwhitfield]

Fair enough, but comments probably need to be directed at nagiosgraph to be the most useful. Still, having it two places is not the end of the world.

[mksmr]

The nagiosgraph page on sourceforge.net isn't exactly a busy place. I couldn't even tell if the project is still active. The latest nagiosgraph release is 2.5 years old, and I haven't seen dev/admin postings recently.

[dwhitfield]

The nagiosgraph page on sourceforge.net isn't exactly a busy place. I couldn't even tell if the project is still active. The latest nagiosgraph release is 2.5 years old, and I haven't seen dev/admin postings recently.

Precisely why it is difficult to work with as the OSes and Nagios move forward without them! Sourceforge has been good for us, but it's obviously just not as popular in general as it once was.

PNP says updated today at https://docs.pnp4nagios.org/pnp-0.6/dwnld but their sourceforge is dead too. There's https://github.com/lingej/pnp4nagios though, which had a commit in April.

https://www.nagios.com/roadmaps/ says there will be reporting enhancements coming to Core in April. I don't see anything specifically about graphing, but the 5 roadmap is going to be breaking Core up into smaller components, which will hopefully make it easier for outside contribution.

[JimKeating]

Fixed the problem by cleaning out old files in the "/usr/local/nagiosgraph/var/rrd" folder. I had to go through all the folders and check the dates of the files. Any that had not been updated in the last few hours I deleted. I also deleted all the old folders from devices that had been removed or renamed. This also fixed the problem of the pull down menus not working on the page.
Best Wishes for fixing this most annoying problem!

[dwhitfield]

@JimKeating

Thanks so much for the contribution!