Provided by: smokeping_2.7.3-4.1_all bug

NAME

       Smokeping::probes::Qstat - Qstat Probe for SmokePing

SYNOPSIS

        *** Probes ***

        +Qstat

        binary = /usr/bin/quakestatba # mandatory
        forks = 5
        game = nexuizs
        mininterval = 0.1
        offset = 50%
        port = 27970
        sourceaddress = 192.168.0.1
        sourceport = 9923-9943
        step = 300
        timeout = 15

        # The following variables can be overridden in each target section
        pings = 5

        # [...]

        *** Targets ***

        probe = Qstat # if this should be the default probe

        # [...]

        + mytarget
        # probe = Qstat # if the default probe is something else
        host = my.host
        pings = 5

DESCRIPTION

       Integrates Qstat as a probe into smokeping. The variable binary must point to your copy of
       the Qstat program.

       Make sure to set your pings to 10, most Quake servers seem to throttle after 10 rapid
       pings.

       Set the game parameter to one of the valid options to check a different type

VARIABLES

       Supported probe-specific variables:

       binary
           The location of your quakestat binary.

           Example value: /usr/bin/quakestatba

           This setting is mandatory.

       forks
           Run this many concurrent processes at maximum

           Example value: 5

           Default value: 5

       game
           What game type to check, from the -default flag of quakestat

           Example value: nexuizs

           Default value: q3s

       mininterval
           The minimum amount of time between sending a ping packet to the target.

           Example value: 0.1

           Default value: 0.5

       offset
           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 acqusition is initiated.  (This variable is only
           applicable if the variable 'concurrentprobes' is set in the 'General' section.)

           Example value: 50%

       port
           The game server port to check. It can also be overriden by adding :port to the host
           parameter in the Target config.

           Example value: 27970

       sourceaddress
           The quakestat "-srcip" parameter . From quakestat(1):

           Send packets using this IP address

           Example value: 192.168.0.1

       sourceport
           The quakestat "-srcport" parameter . From quakestat(1):

           Send packets from these network ports

           Example value: 9923-9943

       step
           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

       timeout
           How long a single 'ping' takes at maximum

           Example value: 15

           Default value: 5

       Supported target-specific variables:

       pings
           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

AUTHORS

       Walter Huf <hufman@gmail.com>