Trouble setting up data query - .rrd file not being created

[mcuelenaere]

Experiencing the same problems here.

Some possible helpful data: I'm trying to get a custom-written "Get Script Server Data" working.
At first, I couldn't get the script working in Cacti, yet it works via CLI. After some debugging and spending quite some time on it I found out that because the script was launched as a new PHP process on the server, it inherited the environment variables from its parent, ie HTTP_ACCEPT_ENCODING etc.
This made PHP think it was dealing with an HTTP server and thus outputted gzip'ed data. After modifying exec_into_array() in lib/functions.php to use proc_open() (giving it a cleaned environment), the script started working.

Now I'm stuck on this problem, the RRDTool database doesn't seem to get created; even after manually creating it it doesn't seem to get populated with data. I added some debug statements to the server data script and it seems the script doesn't get called from spine (works though when querying for indexes in host.php).

Any help tracking down this problem would be appreciated.

[gandalf]

How did you create the related graph?
R.

[mcuelenaere]

How did you create the related graph?
R.

With "related" graph I'm guessing you want to know how I created the graphs?

Devices->[device]->Create Graphs for this Host->Data Query[..]->Create

One thing that's odd, is that the corresponding rows in the Data Query table aren't grayed out when I've created the graphs, even though the graphs and data sources are created.

[gandalf]

Then, there's definitively sth going wrong here. In most cases, this is an issue with the index being wrong (thus greying out does not match the correct index). That's all I can do from remote without access
R.

[gunzl1ng3r]

Hi, I got the same problem, that the rrd-Files are not created and the Data Sources lack essential data.

I attached screenshots of everything, that might help identify the problem:
They're all packed up in the attachment:

data_query_problem.zip

(594.06 KiB) Downloaded 129 times

The SNMP-Query: Query_01.jpg
The verbose output of the query: Device_01.jpg
A picture of the items not being grayed out after creation: Device_02.jpg
A picture of the DataSource lacking the information from the DataQuery: DS_01.jpg
The general configuration of the Data Query in Cacti: DQ_01.jpg
The association between Data Query, Data Template and Graph: DS_02.jpg
The configuration of the DataTemplate: DT_01.jpg
The configuration of the Graph: GT_01.jpg
...and how the Graph items are associated with the Data Source: GT_02.jpg

I already tried running Cacti-Log at DEBUG Level, however, I did not see anything suspicious...
Cacti-Version is 0.8.7g

Is there any other intel I should provide?

[gandalf]

IMHO, there's no need for a REGEXP in that xml file. And then, we need output of an snmpwalk against the table's base OID
R.

[gunzl1ng3r]

Here's the snmpwalk on the oid of the table.

Reason for the REGEXP is the obvious missing of .1.3.6.1.4.1.3417.2.11.2.4.1.1 in this output...
I attached the BLUECOAT-SG-PROXY-MIB.yml in which the sgProxyCPUTable is defined.
There it states for .1.3.6.1.4.1.3417.2.11.2.4.1.1 (sgProxyCpuCoreIndex) -> not-accessible...
So, due to me not being able to directly access the list of cores I thought the only way around would be to parse the OID of on of the other entries...

Code: Select all

snmpwalk -v2c -cnagios sg10 .1.3.6.1.4.1.3417.2.11.2.4.1 -On
.1.3.6.1.4.1.3417.2.11.2.4.1.2.1 = Counter64: 5183123652
.1.3.6.1.4.1.3417.2.11.2.4.1.2.2 = Counter64: 5183123652
.1.3.6.1.4.1.3417.2.11.2.4.1.2.3 = Counter64: 5183123652
.1.3.6.1.4.1.3417.2.11.2.4.1.2.4 = Counter64: 5183123653
.1.3.6.1.4.1.3417.2.11.2.4.1.3.1 = Counter64: 153982115
.1.3.6.1.4.1.3417.2.11.2.4.1.3.2 = Counter64: 134099275
.1.3.6.1.4.1.3417.2.11.2.4.1.3.3 = Counter64: 134162407
.1.3.6.1.4.1.3417.2.11.2.4.1.3.4 = Counter64: 100307734
.1.3.6.1.4.1.3417.2.11.2.4.1.4.1 = Counter64: 5029141537
.1.3.6.1.4.1.3417.2.11.2.4.1.4.2 = Counter64: 5049024377
.1.3.6.1.4.1.3417.2.11.2.4.1.4.3 = Counter64: 5048961245
.1.3.6.1.4.1.3417.2.11.2.4.1.4.4 = Counter64: 5082815919
.1.3.6.1.4.1.3417.2.11.2.4.1.5.1 = Counter64: 82574
.1.3.6.1.4.1.3417.2.11.2.4.1.5.2 = Counter64: 82574
.1.3.6.1.4.1.3417.2.11.2.4.1.5.3 = Counter64: 82574
.1.3.6.1.4.1.3417.2.11.2.4.1.5.4 = Counter64: 82575
.1.3.6.1.4.1.3417.2.11.2.4.1.6.1 = Counter64: 11952
.1.3.6.1.4.1.3417.2.11.2.4.1.6.2 = Counter64: 9859
.1.3.6.1.4.1.3417.2.11.2.4.1.6.3 = Counter64: 9792
.1.3.6.1.4.1.3417.2.11.2.4.1.6.4 = Counter64: 8144
.1.3.6.1.4.1.3417.2.11.2.4.1.7.1 = Counter64: 70622
.1.3.6.1.4.1.3417.2.11.2.4.1.7.2 = Counter64: 72715
.1.3.6.1.4.1.3417.2.11.2.4.1.7.3 = Counter64: 72782
.1.3.6.1.4.1.3417.2.11.2.4.1.7.4 = Counter64: 74431
.1.3.6.1.4.1.3417.2.11.2.4.1.8.1 = Gauge32: 15
.1.3.6.1.4.1.3417.2.11.2.4.1.8.2 = Gauge32: 12
.1.3.6.1.4.1.3417.2.11.2.4.1.8.3 = Gauge32: 12
.1.3.6.1.4.1.3417.2.11.2.4.1.8.4 = Gauge32: 10
.1.3.6.1.4.1.3417.2.11.2.4.1.9.1 = Gauge32: 85
.1.3.6.1.4.1.3417.2.11.2.4.1.9.2 = Gauge32: 88
.1.3.6.1.4.1.3417.2.11.2.4.1.9.3 = Gauge32: 88
.1.3.6.1.4.1.3417.2.11.2.4.1.9.4 = Gauge32: 90

[gandalf]

Here's the snmpwalk on the oid of the table.

Reason for the REGEXP is the obvious missing of .1.3.6.1.4.1.3417.2.11.2.4.1.1 in this output...
I attached the BLUECOAT-SG-PROXY-MIB.yml in which the sgProxyCPUTable is defined.
There it states for .1.3.6.1.4.1.3417.2.11.2.4.1.1 (sgProxyCpuCoreIndex) -> not-accessible...
So, due to me not being able to directly access the list of cores I thought the only way around would be to parse the OID of on of the other entries...

That index would help, but is not required. In fact, you may use .1.3.6.1.4.1.3417.2.11.2.4.1.2 twice, once as an <Index> field in the XML, <direction> input and as an output field as well. As this is a permanently changing number, it makes not much sense as an index of a data query, I must admit that. We should of course prefer some string (aka: constant results), but that does not need to be at .1.3.6.1.4.1.3417.2.11.2.4.1.1. It may even be part of a completely different table as long as both tables have some index count (example: snmp tables for interface traffic (base) and related table for highspeed interface traffic).
R.

[gunzl1ng3r]

That index would help, but is not required. In fact, you may use .1.3.6.1.4.1.3417.2.11.2.4.1.2 twice, once as an <Index> field in the XML, <direction> input and as an output field as well. As this is a permanently changing number, it makes not much sense as an index of a data query, I must admit that. We should of course prefer some string (aka: constant results), but that does not need to be at .1.3.6.1.4.1.3417.2.11.2.4.1.1. It may even be part of a completely different table as long as both tables have some index count (example: snmp tables for interface traffic (base) and related table for highspeed interface traffic).
R.

Unfortuanetely there is no related table... in fact even an unlimited snmpwalk could not find something that might work... there has to be a reason, why Cacti behaves this strange...

[noname]

I think the "<index_order>" in your XML should be as following:

<index_order>sgProxyCpuCoreIndex</index_order>

[gunzl1ng3r]

I think the "<index_order>" in your XML should be as following:

<index_order>sgProxyCpuCoreIndex</index_order>

You sir, are my hero!

Can't believe it was a simple mistake like this... but now it's working absolutely fine.

THANK YOU VERY MUCH!

[gandalf]

I think the "<index_order>" in your XML should be as following:

<index_order>sgProxyCpuCoreIndex</index_order>

Me == blind
R