On Thu, 28 Aug 2008 15:18:12 +0100 Tim Chown tjc@ecs.soton.ac.uk wrote:
b1-l1-cat1 may have indexed one of its temperature sensors as 1 during the initial import into NAV, and then changed its mind at a later time. That would account for the problem you're having.
Thanks for the explanation. What then is the recommended way to suppress errors related to this OID? NAV kindly generates email alerts for errors when querying devices, we just have a few too many related to this OID :)
There is no recommended way, really. Cricket is a noisy fellow, complaining about every little thing that annoys it, and since it normally runs every five minutes, it annoys the heck out of many a sysadmin during the course of a day.
Most installations I've run into either direct cron-mail from Cricket into /dev/null, or put it into a mailbox they check less often than their inbox. It's output is not all terribly useful.
Is there a recommended way to configure NAV to not poll our 3750 stacks for temp data?
You could re-profile them and see whether NAV notices that they don't support that OID anymore.
As each SNMP-enabled device is entered into NAV, getDeviceData will make a profile of which OIDs it responds to. This profile is available in the report system: Find a device in the "All IP Devices" report, click on the number in the SNMP column (if the column is empty, it means that no OIDs exist in the profile, or the device has not yet been profiled). If NAV thinks the device responds to the offending temperature OID, it will be listed there.
A device will normally only be re-profiled if its software version changes, or NAV detects it has been replaced (i.e. serial number has changed). You can manually trigger a re-profiling of a device:
First go to Edit Database, edit the device and click the Update-button without making any actual changes. This step invalidates the OID profile.
Then look up the device in IP Device Center and click the "Refresh" link to trigger getDeviceData to start polling the device immediately. gDD will see the OID profile has been invalidated and will start re-profiling (this part of gDD is called the OID tester, or OID_TEST in the logs).
If you wish to re-profile a batch of devices, you have to tinker with a little SQL.
I see there are config files under Cricket for generic routers and switches with this OID, i.e.:
/etc/nav/cricket-config/routers/Defaults /etc/nav/cricket-config/switches/Defaults
And also some reference in
/etc/nav/cricketoids.txt /etc/nav/cricket-config/config.db
It looks like Cricket generates the Defaults file and the config.db each night, while cricketoids.txt is static, but it's not clear to us where those nightly builds are driven from (i.e. where we could remove/suppress the temp entry).
What happens is this: NAV runs a nightly job (makecricketconfig.pl) which will generate/update the Cricket configuration files from scratch, based on the contents of the NAV database. The device OID profiles are what mainly defines which OIDs are configured to be collected by Cricket. The Defaults files you refer to are the config files updated by NAV.
Cricket compiles all the textual config information from the directory tree below /etc/nav/cricket-config/ into a more efficient binary format and stores this in /etc/nav/cricket-config/config.db . The compilation process happens automatically each time a config file is changed manually or by NAV.
The file /etc/nav/cricketoids.txt, OTOH, was obsoleted several years ago, it serves no function. But thanks to you pointing out it still exist, we've removed it from the next release.
A week ago I knew far less about OIDs and I think I was better for it :)
Welcome to the wonderful world of SNMP ;)