I have 2 Palo Alto firewalls which dropped off the map at the same time about 25 days ago. I think it may have coincided with an Observium upgrade; but I didn't write down update particulars and I don't think Observium maintains a history?
When I run discovery with debug there is a SQL query posted (which fails) attempting to lookup the device:
SQL[SELECT * FROM `devices` WHERE `disabled` = 0 AND `hostname` LIKE 'vpn01-p.{redacted}' AND `status` = '1' AND `poller_id` = '0' ORDER BY `last_discovered_timetaken` ASC]
In this case, the query fails because "status" is actually set to 0.
So what is the "status" field for in the "devices" table and how is it set 'wrong?'
There is a "statuses" tab in the web GUI for the device's "properties", but in this case (a PAN firewall) there are 2 MIB entries for indicating the fail-over status of the device pair ("HA State" and "HA Peer State"); so I don't think they have anything to do with the "status" field in the DB.
Device status is set right at the start of the poller when it decides if the device is up or down based on whether it responds to initial ping & snmp attempts or not.
We don't run discovery on devices which are marked as down, because it wouldn't work :D
Don't confuse the massively overlapping use of "state" and "status". We don't have many words to use in this context, so the same terminology is used a lot of times for a lot of things.
adam.
Eric W. Bates (he) via observium wrote on 2024-03-19 12:56:
I have 2 Palo Alto firewalls which dropped off the map at the same time about 25 days ago. I think it may have coincided with an Observium upgrade; but I didn't write down update particulars and I don't think Observium maintains a history?
When I run discovery with debug there is a SQL query posted (which fails) attempting to lookup the device:
SQL[SELECT * FROM `devices` WHERE `disabled` = 0 AND `hostname` LIKE 'vpn01-p.{redacted}' AND `status` = '1' AND `poller_id` = '0' ORDER BY `last_discovered_timetaken` ASC]
In this case, the query fails because "status" is actually set to 0.
So what is the "status" field for in the "devices" table and how is it set 'wrong?'
There is a "statuses" tab in the web GUI for the device's "properties", but in this case (a PAN firewall) there are 2 MIB entries for indicating the fail-over status of the device pair ("HA State" and "HA Peer State"); so I don't think they have anything to do with the "status" field in the DB.
observium mailing list -- observium@lists.observium.org To unsubscribe send an email to observium-leave@lists.observium.org
Anything? We are paying for a professional license.
What is devices.status? How do I toggle it on? If I just toggle it in the SQL, what will break?
On 3/19/24 08:56, Eric W. Bates wrote:
I have 2 Palo Alto firewalls which dropped off the map at the same time about 25 days ago. I think it may have coincided with an Observium upgrade; but I didn't write down update particulars and I don't think Observium maintains a history?
When I run discovery with debug there is a SQL query posted (which fails) attempting to lookup the device:
SQL[SELECT * FROM `devices` WHERE `disabled` = 0 AND `hostname` LIKE 'vpn01-p.{redacted}' AND `status` = '1' AND `poller_id` = '0' ORDER BY `last_discovered_timetaken` ASC]
In this case, the query fails because "status" is actually set to 0.
So what is the "status" field for in the "devices" table and how is it set 'wrong?'
There is a "statuses" tab in the web GUI for the device's "properties", but in this case (a PAN firewall) there are 2 MIB entries for indicating the fail-over status of the device pair ("HA State" and "HA Peer State"); so I don't think they have anything to do with the "status" field in the DB.
Apologies. My mistake. I found your reply.
On 4/10/24 10:02, Eric W. Bates (he) wrote:
Anything? We are paying for a professional license.
What is devices.status? How do I toggle it on? If I just toggle it in the SQL, what will break?
On 3/19/24 08:56, Eric W. Bates wrote:
I have 2 Palo Alto firewalls which dropped off the map at the same time about 25 days ago. I think it may have coincided with an Observium upgrade; but I didn't write down update particulars and I don't think Observium maintains a history?
When I run discovery with debug there is a SQL query posted (which fails) attempting to lookup the device:
SQL[SELECT * FROM `devices` WHERE `disabled` = 0 AND `hostname` LIKE 'vpn01-p.{redacted}' AND `status` = '1' AND `poller_id` = '0' ORDER BY `last_discovered_timetaken` ASC]
In this case, the query fails because "status" is actually set to 0.
So what is the "status" field for in the "devices" table and how is it set 'wrong?'
There is a "statuses" tab in the web GUI for the device's "properties", but in this case (a PAN firewall) there are 2 MIB entries for indicating the fail-over status of the device pair ("HA State" and "HA Peer State"); so I don't think they have anything to do with the "status" field in the DB.
Thanks for your reply about poller.php.
The problem appears to be the -t (timeout) option given to snmpget in the poller is set to 1 second. 4 of our 6 Palos need more than one second to come up with an answer.
How do I increase that timeout value? It's set explicitly in the [CMD] so I don't think setting anything in /etc/snmp will help?
On 3/19/24 08:56, Eric W. Bates (he) wrote:
I have 2 Palo Alto firewalls which dropped off the map at the same time about 25 days ago. I think it may have coincided with an Observium upgrade; but I didn't write down update particulars and I don't think Observium maintains a history?
When I run discovery with debug there is a SQL query posted (which fails) attempting to lookup the device:
SQL[SELECT * FROM `devices` WHERE `disabled` = 0 AND `hostname` LIKE 'vpn01-p.{redacted}' AND `status` = '1' AND `poller_id` = '0' ORDER BY `last_discovered_timetaken` ASC]
In this case, the query fails because "status" is actually set to 0.
So what is the "status" field for in the "devices" table and how is it set 'wrong?'
There is a "statuses" tab in the web GUI for the device's "properties", but in this case (a PAN firewall) there are 2 MIB entries for indicating the fail-over status of the device pair ("HA State" and "HA Peer State"); so I don't think they have anything to do with the "status" field in the DB.
Found it in the device's --> properties --> snmp --> basic configuration
Thank you.
On 4/10/24 10:33, Eric W. Bates (he) wrote:
Thanks for your reply about poller.php.
The problem appears to be the -t (timeout) option given to snmpget in the poller is set to 1 second. 4 of our 6 Palos need more than one second to come up with an answer.
How do I increase that timeout value? It's set explicitly in the [CMD] so I don't think setting anything in /etc/snmp will help?
On 3/19/24 08:56, Eric W. Bates (he) wrote:
I have 2 Palo Alto firewalls which dropped off the map at the same time about 25 days ago. I think it may have coincided with an Observium upgrade; but I didn't write down update particulars and I don't think Observium maintains a history?
When I run discovery with debug there is a SQL query posted (which fails) attempting to lookup the device:
SQL[SELECT * FROM `devices` WHERE `disabled` = 0 AND `hostname` LIKE 'vpn01-p.{redacted}' AND `status` = '1' AND `poller_id` = '0' ORDER BY `last_discovered_timetaken` ASC]
In this case, the query fails because "status" is actually set to 0.
So what is the "status" field for in the "devices" table and how is it set 'wrong?'
There is a "statuses" tab in the web GUI for the device's "properties", but in this case (a PAN firewall) there are 2 MIB entries for indicating the fail-over status of the device pair ("HA State" and "HA Peer State"); so I don't think they have anything to do with the "status" field in the DB.
participants (2)
-
Adam Armstrong -
Eric W. Bates (he)