WARNING: You have 1 Devices with bad SNMP Indexes

[hbgd420]

version:1.2.4 CentOS7.4

View the log to get the message: WARNING: You have 1 Devices with bad SNMP Indexes. Devices: Device[H3C-12510F] totalling 13 Data Sources. Please Either Re-Index, Delete or Disable these Data Sources.

2019/08/15 10:06:12 - SPINE: Poller[Main Poller] Device[H3C-12510F] ERROR: Problems parsing Multi SNMP OID! (oid: .1.3.6.1.2.1.31.1.1.1.10.), Set MAX_OIDS to 1 for this host to isolate bad OID
2019/08/15 10:06:12 - SPINE: Poller[Main Poller] Device[H3C-12510F] ERROR: Problems parsing Multi SNMP OID! (oid: .1.3.6.1.2.1.31.1.1.1.6.), Set MAX_OIDS to 1 for this host to isolate bad OID
2019/08/15 10:06:12 - SPINE: Poller[Main Poller] Device[H3C-12510F] ERROR: Problems parsing Multi SNMP OID! (oid: .1.3.6.1.2.1.31.1.1.1.10.), Set MAX_OIDS to 1 for this host to isolate bad OID
2019/08/15 10:06:12 - SPINE: Poller[Main Poller] Device[H3C-12510F] ERROR: Problems parsing Multi SNMP OID! (oid: .1.3.6.1.2.1.31.1.1.1.6.), Set MAX_OIDS to 1 for this host to isolate bad OID
2019/08/15 10:06:12 - SPINE: Poller[Main Poller] Device[H3C-12510F] ERROR: Problems parsing Multi SNMP OID! (oid: .1.3.6.1.2.1.31.1.1.1.10.), Set MAX_OIDS to 1 for this host to isolate bad OID
2019/08/15 10:06:12 - SPINE: Poller[Main Poller] Device[H3C-12510F] ERROR: Problems parsing Multi SNMP OID! (oid: .1.3.6.1.2.1.31.1.1.1.6.), Set MAX_OIDS to 1 for this host to isolate bad OID
2019/08/15 10:06:12 - SPINE: Poller[Main Poller] Device[H3C-12510F] ERROR: Problems parsing Multi SNMP OID! (oid: .1.3.6.1.2.1.31.1.1.1.10.), Set MAX_OIDS to 1 for this host to isolate bad OID

The prompt tells me that I can rebuild the index, but how do I do this? thank you very much

[hbgd420]

The only thing I can do now is to delete the graphic and recreate it. Is there any other solution?

[hbgd420]

I already know the cause of the problem, but I don't know when it will happen.
This problem is caused by the empty snmp_index field in the table `data_local` and the table `graph_local` table. I don't know why it is empty.
My solution is to manually fill the snmp_index field in the two tables, the value of the snmp_index field is derived from：

360截图16720330579747.jpg (49.72 KiB) Viewed 3055 times

[freakenfurter]

Hi,
sadly, this is a bug by the database migration script.
So, if you don't have the old database running, you have to create a new graph for the device.
I'm in the fortunate position to have the old instance running, therefore i'm writing a script to analyze the old database and fill in the missing values where the snmp_query_id=1.
E.g:
Old database (0.8.8c)

Code: Select all

select * from graph_local where host_id='1569' and snmp_query_id=1;
+-------+-------------------+---------+---------------+------------+
| id    | graph_template_id | host_id | snmp_query_id | snmp_index |
+-------+-------------------+---------+---------------+------------+
| 49133 |                 2 |    1569 |             1 | 10001      |
| 49142 |                 2 |    1569 |             1 | 10010      |
| 49141 |                 2 |    1569 |             1 | 10009      |
| 49140 |                 2 |    1569 |             1 | 10008      |
| 49139 |                 2 |    1569 |             1 | 10007      |
| 49138 |                 2 |    1569 |             1 | 10006      |
| 49137 |                 2 |    1569 |             1 | 10005      |
| 49136 |                 2 |    1569 |             1 | 10004      |
| 49135 |                 2 |    1569 |             1 | 10003      |
| 49134 |                 2 |    1569 |             1 | 10002      |
+-------+-------------------+---------+---------------+------------+

New database (1.2.6)

Code: Select all

select * from graph_local where host_id='1569' and snmp_query_id=1;
+-------+-------------------+---------+---------------+---------------------+------------+
| id    | graph_template_id | host_id | snmp_query_id | snmp_query_graph_id | snmp_index |
+-------+-------------------+---------+---------------+---------------------+------------+
| 49133 |                 2 |    1569 |             1 |                  14 |            |
| 49142 |                 2 |    1569 |             1 |                  14 |            |
| 49141 |                 2 |    1569 |             1 |                  14 | 10009      |
| 49140 |                 2 |    1569 |             1 |                  14 |            |
| 49139 |                 2 |    1569 |             1 |                  14 |            |
| 49138 |                 2 |    1569 |             1 |                  14 | 10006      |
| 49137 |                 2 |    1569 |             1 |                  14 | 10005      |
| 49136 |                 2 |    1569 |             1 |                  14 | 10004      |
| 49135 |                 2 |    1569 |             1 |                  14 |            |
| 49134 |                 2 |    1569 |             1 |                  14 |            |
+-------+-------------------+---------+---------------+---------------------+------------+

My script will connect to the old db using the hostid of the erroneous graph and fill the missing indexes.

Rgds.
Franz

[netniV]

Not always, if you know the correct index for the data source, you can update the datasource with the new index.

[Osiris]

This is due to a re-index and the query missing one of the previous indexes. There is an option under data sources to allow you to search for orphans. These are the broken data source. Once you find it, tell us about the graph template.

If these indexes come and go, I think we have to look into an xml setting to not generate this error.

[Osiris]

Cacti still remembers the old indexes, it clears them here to make them easy to track.

We really need to know why the indexes disappeared, and if this is natural, and if the indexes will reappear on there own.

If that is the behavior, there may already be a setting to not use this protection method.