Good data, graph functional, zero values drawn

[Harmon20]

I’ve got a handful of graphs that are appear functional but are not drawing the values they represent. They are drawing, just not the values fetched.

Everything appears to be functioning normally. No errors, no missing elements. The problem is that even though there is non-zero data being represented by the graph and successfully being fetched, the graph is drawing 0 values in the graph. See image below.

Other graphs on the same device, such as the current on the individual modules that this graph should show the aggregate of, display and draw as expected.

This malfunctioning graph on other devices of the same type and manufacturer are broken in the same way - data appears good, graph appears to be functioning normally, but the data being drawn is of 0 value rather than the actual values being fetched.

Graphs of the same sensor (“Current”) on other device types and manufacturers draw successfully. This would implicate the mfr specific aspects of the Librenms system, presumably bad MIBs, but the data is being polled, received, and accumulated properly and is showing in the legend as expected. It appears that it is not something with data gathering, processing, or storage but something breaking in the drawing of the data, and graphing of good data should be sensor/mfr agnostic. Data is data.

Any ideas where the disconnect could possibly be?

The graph, showing a good rrd command and good data, but drawing of zero value:

The data from a fetch for the same time period and same file mentioned in the graph command: fetch-values.txt

Validation:

librenms@libre2:~$ date
Fri 24 Jan 2025 11:08:43 AM CST
librenms@libre2:~$ ./validate.php
===========================================
Component | Version
--------- | -------
LibreNMS  | 25.1.0-39-gef4b422f7 (2025-01-24T08:58:59-06:00)
DB Schema | 2025_01_22_194342_drop_storage_deleted (312)
PHP       | 8.3.14
Python    | 3.8.10
Database  | MariaDB 10.3.39-MariaDB-0ubuntu0.20.04.2
RRDTool   | 1.7.2
SNMP      | 5.8
===========================================

[OK]    Composer Version: 2.8.4
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[OK]    Database connection successful
[OK]    Database Schema is current
[OK]    SQL Server meets minimum requirements
[OK]    lower_case_table_names is enabled
[OK]    MySQL engine is optimal
[OK]    Database and column collations are correct
[OK]    Database schema correct
[OK]    MySQL and PHP time match
[OK]    Active pollers found
[OK]    Dispatcher Service not detected
[OK]    Locks are functional
[OK]    Python poller wrapper is polling
[OK]    Redis is unavailable
[OK]    rrd_dir is writable
[OK]    rrdtool version ok
librenms@libre2:~$

[Harmon20]

I’m a dummy.

Thinking through the issue - the scale of the graph due to the threshold, the scientific notation on the values - I suddenly thought about that drawing of zero being a matter of scale on the graph. Maybe it wasn’t zero, maybe the scale was so far off that it just looks that way.

The sensor thresholds were set to 80000 and 70000, the presumption being, based on the existing data and settings, that these thresholds are in mA and not A. This would seem to comport with the graph being drawn - the threshold of 80000 draws a threshold line at 80.0A.

So I went into the thresholds and set them to 80 and 70.

The threshold lines on the graph were drawn in exactly the same place on the graph. I had changed the threshold values by an order of magnitude and they didn’t change on the graph.

However, the graph drawing scale had changed. Now it was obvious that the graph wasn’t drawing a zero line. It was drawing the non-zero values but they were squished to nothing in the graph scale. See the new graph for the same parameters, below.

So the graph was being drawn accurately - non-zero values being drawn and the thresholds drawn in the proper place using the requisite relative scale. However, the Y axis labeling was where the malfunction actually existed. The axis was labeling the thresholds as being at 70A and 80A when it was actually 70kA and 80kA. (Or 70,000A and 80,000A)

So there is an issue, just not the one that I thought.