ipdevpoll is the main SNMP collection engine of NAV. Its work is divided into jobs, which runs a series of collection plugins for each IP device at set intervals. These jobs are fully user-configurable.
usage: ipdevpolld [-h] [--version] [-f] [-s] [-j] [-p] [-J JOBNAME] [-n NETBOX] [-m [WORKERS]] [-M JOBS] [-P] [--capture-vars] [-c] [--threadpoolsize COUNT] [--worker] optional arguments: -h, --help show this help message and exit --version show program's version number and exit -f, --foreground run in foreground instead of daemonizing -s, --log-stderr log to stderr instead of log file -j, --list-jobs print a list of configured jobs and exit -p, --list-plugins load and print a list of configured plugins -J JOBNAME run only JOBNAME jobs in this process -n NETBOX, --netbox NETBOX Run JOBNAME once for NETBOX. Also implies -f and -s options. -m [WORKERS], --multiprocess [WORKERS] Run ipdevpoll in a multiprocess setup. If WORKERS is not set it will default to number of cpus in the system -M JOBS, --max-jobs-per-worker JOBS Restart worker processes after completing JOBS jobs. (Default: Don't restart) -P, --pidlog Include process ID in every log line --capture-vars Capture and print locals and globals in tracebacks when debug logging -c, --clean cleans/purges old job log entries from the database and then exits --threadpoolsize COUNT the number of database worker threads, and thus db connections, to use in this process --worker Used internally when lauching worker processes This program runs SNMP polling jobs for IP devices monitored by NAV
Manually running a job for a given netbox¶
Unscheduled runs of jobs can be run against any NAV-monitored device from the
command line. To run the
inventory job for the switch
ipdevpolld -J inventory -n some-sw
-n argument can be given as a prefix of a device’s sysname, or as an
IP address (the device still needs to be registered in NAV).
ipdevpoll is configured in
ipdevpoll.conf. This is an “ini”-style
configuration file with multiple sections.
Where to put log messages. If this starts with
.it will be interpreted literally. Otherwise, the file will be created in the NAV log directory.
The maximum number of concurrent jobs within a single ipdevpoll process. It may be necessary to adjust this if you keep running out of available file descriptors
This section is used to change the SNMP polling parameters from their defaults.
The initial timeout value for a request, given as a number of seconds. All requests will be retried up to three times, with an exponential increase in the timeout value. The default is 1.5 seconds.
How many values to ask for in each SNMP GETBULK request, 10 being the default.
Used to list all the plugins to load into an ipdevpoll process, and assign
them short aliases. Plugins are loaded from the built-in
nav.ipdevpoll.plugins package unless a fully qualified class name is
supplied as a value. To load your homebrew plugin class
homebrew.foo module, add:
foo = homebrew.foo.Foo
To load the built-in
snmpcheck plugin from the
nav.ipdevpoll.plugins package, all that is needed is:
A list of IPv4 and/or IPv6 prefixes that should never be inserted into the database, even if they are collected from a device’s interfaces.
Allows you to specify the devices that WILL be handled by this instance of ipdevpoll using a space separated list of group ids.
Allows you to specify the devices that WON’T be handled by this instance of ipdevpoll using a space separated list of group ids.
Any section whose name starts with the
job_ prefix defines a new job
configuration. The following settings can be configured for jobs:
How often the job should be scheduled for each device. Values can be given a unit suffix of
hto indicate seconds, minutes or hours.
A sequence of plugins to run in this job. Given as a space-separated list of names as configured in the global
An internal per-process limit on how many concurrent jobs of this type can run at any given time.
ipdevpoll runs all polling tasks asynchronously in a single thread. Threads
are reserved for synchronous communication with the PostgreSQL database
backend. Even on a multi-core server, this means all of ipdevpoll’s work is
limited to a single core. Once ipdevpoll’s workload grows beyond what a single
core can handle, ipdevpoll can optionally run in a multiprocess mode, using
In multiprocess mode, ipdevpoll spawns a number of worker processes, while the master process becomes a simple job scheduler, distributing the actual jobs to the individual workers.
ipdevpoll’s default number of workers processes and threads aren’t
necessarily sane for multiprocess usage. Unless a number of workers is
supplied to the
--multiprocess option, it will spawn a number of
workers corresponding to the number of cores it detects on your system. The
default number of database threads in ipdevpoll’s threadpool is 10 per process,
which means each worker process will create 10 individual connections to
These numbers multiply fast, and can end up easily saturating PostgreSQL’s
default pool of 100 available connections, causing other NAV processes to
be unable to connect to the database. When enabling multiprocess mode, you
should really tune down the threadpool size by adding the
Another good thing about the multiprocess mode is that you can limit the
number of jobs any worker process will run before it is killed and respawned.
This may provide additional protection against unintended resource leaks. See
You can make sure ipdevpoll always runs in multiprocess mode by altering the
command option in the
ipdevpoll entry of the configuration file