Smokeping_probes_basefork - Man Page
Yet Another Base Class for implementing SmokePing Probes
Like Smokeping::probes::basevars, but supports the probe-specific property `forks' to determine how many processes should be run concurrently. The targets are pinged one at a time, and the number of pings sent can vary between targets.
*** Probes *** +basefork forks = 5 offset = 50% step = 300 timeout = 15 # The following variables can be overridden in each target section /^influx_.+/ = influx_location = In the basement pings = 5 # [...] *** Targets *** probe = basefork # if this should be the default probe # [...] + mytarget # probe = basefork # if the default probe is something else host = my.host /^influx_.+/ = influx_location = In the basement pings = 5
Not all pinger programs support testing multiple hosts in a single go like fping(1). If the measurement takes long enough, there may be not enough time perform all the tests in the time available. For example, if the test takes 30 seconds, measuring ten hosts already fills up the SmokePing default five minute step.
Thus, it may be necessary to do some of the tests concurrently. This module defines the ping method that forks the requested number of concurrent processes and calls the pingone method that derived classes must provide.
The pingone method is called with one argument: a hash containing the target that is to be measured. The contents of the hash are described in Smokeping::probes::basevars(3pm).
The number of concurrent processes is determined by the probe-specific variable `forks' and is 5 by default. If there are more targets than this value, another round of forks is done after the first processes are finished. This continues until all the targets have been tested.
The timeout in which each child has to finish is set to 5 seconds multiplied by the maximum number of 'pings' of the targets. You can set the base timeout differently if you want to, using the timeout property of the probe in the master config file (this again will be multiplied by the maximum number of pings). The probe itself can also provide another default value if desired by modifying the _default value of the timeout variable.
If the child isn't finished when the timeout occurs, it will be killed along with any processes it has started.
The number of pings sent can be specified in the target-specific variable 'pings'.
Supported probe-specific variables:
Run this many concurrent processes at maximum
Example value: 5
Default value: 5
If you run many probes concurrently you may want to prevent them from hitting your network all at the same time. Using the probe-specific offset parameter you can change the point in time when each probe will be run. Offset is specified in % of total interval, or alternatively as 'random', and the offset from the 'General' section is used if nothing is specified here. Note that this does NOT influence the rrds itself, it is just a matter of when data acquisition is initiated. (This variable is only applicable if the variable 'concurrentprobes' is set in the 'General' section.)
Example value: 50%
Duration of the base interval that this probe should use, if different from the one specified in the 'Database' section. Note that the step in the RRD files is fixed when they are originally generated, and if you change the step parameter afterwards, you'll have to delete the old RRD files or somehow convert them. (This variable is only applicable if the variable 'concurrentprobes' is set in the 'General' section.)
Example value: 300
How long a single 'ping' takes at maximum
Example value: 15
Default value: 5
Supported target-specific variables:
This is a tag that will be sent to influxdb and has no impact on the probe measurement. The tag name will be sent without the "influx_" prefix, which will be replaced with "tag_" instead. Tags can be used for filtering.
Example value: influx_location = In the basement
How many pings should be sent to each target, if different from the global value specified in the Database section. Note that the number of pings in the RRD files is fixed when they are originally generated, and if you change this parameter afterwards, you'll have to delete the old RRD files or somehow convert them.
Example value: 5
Niko Tyni <email@example.com>