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