discovery.php is Observium's discovery process. It scans devices and populates the database with ports and other entities that require polling. The discovery process should be run automatical periodically via cron, but can also be run manually for debugging and development purposes.
The discovery process should be run once or twice per day on usual installations. It usually takes longer to run than the poller since it queries devices using a more prospective method than the poller.
13 */12 * * * root cd /opt/observium && ./discovery.php -h all >> /dev/null 2>&1
discovery.php [-dquV] [-i instances] [-n number] [-m module] [-h device]
||Discover a single device by device_id|
||Discover devices matching the hostname wildcard|
||Discover all odd numbered devices|
||Discover all even numbered devices|
||Discover all devices|
||Discover all new devices which have never been discovered|
||Discover as instance
||Upgrade DB Schema, used during update procedure|
||Show globally enabled/disabled modules and exit|
||Show version and exit|
||Enable debugging output|
||More verbose debugging output|
||Specify discovery module(s) (separated by commas) to be run|
Most manual usage of the discovery script will be for debugging or development purposes. For example, to check if a device is returning any useful data to a particular discovery module.
For example, to debug the
storage module on the device
storage-server.company.com you could use this :
./discovery.php -h storage-server.company.com -m storage -dd
You can run multiple modules using the
-m option, this is useful when debugging unix-agent and application modules, which require both to be run :
./discovery.php -h srv01.company.com -m unix-agent,applications -dd
Example debugging output¶
Debugging output will usually include the full command line of any SNMP commands run, along with the data returned by the device and some output indicating how we process the data and whatever SQL changes we make based on the data returned.
This example output from the mempools module shows part of this process
The example below illustrates what happens when a module doesn't find any entries in a specific MIB. In this instance the device repoorts that there are no entries in the dskEntry table in UCD-SNMP-MIB.