Distributed Argus Redundancy Protocol

DARP is an advanced feature. If you are just starting out with argus, it is recommended that you skip this section.

For increased reliability, some people may want to have multiple Argus servers monitoring their network. There are several reasons you may want to do this, and Argus DARP has several modes of operation:

none: no redundancy, this is what you do now.
failover: the master Argus server monitors things, a slave server sits idle and monitors the master. when the slave detects the master has failed, the slave takes over and monitors things
distributed: a number of slaves each monitor the same or different things. the master gathers the results from the slaves, and determines the overall status of the things being monitored.
redundant: both the master and slave monitor things.

Mix-and-match, combinations, and variations on the above are also possible

Configuring

Each Argus server participating in DARP must be given a unique name (or tag) to identify it to the other servers. You can use the hostname of the server, or you can pick other names. In the examples below we will use 'master1', 'slave1', and 'slave2'.

	darp_mode:	failover

	DARP "myname" {

		# ...

	}

The Master

The must be exactly one Argus DARP master. The master must be told who the slaves are:

	DARP "master1" {
	    # parameters common to all
	    # slaves can appear up here

	    slave "slave1" {
		hostname:	10.1.2.3
		secret:		secret-password
	    }
	    slave "slave2" {
		hostname:	10.2.3.4
		secret:		dont-tell
	    }
	}

The master can also monitor the status of its slave connections as normal Service monitors:

	Group "Darp Slaves" {

	    Service DARP/WATCH/slave1
	    Service DARP/WATCH/slave2
	}

The Slaves

There can be any number of slaves. Each must be told how to find and authenticate with its master:

	DARP "slave1" {

	    master "master0" {
		hostname:	10.0.0.2
		secret:		secret-password
		# any other parameter valid for a
		# 'Service TCP' can appear here
	    }
	}

For security reasons, the master requires that the slaves connect from the specified IP address and "login" with the specified name and secret. Be careful that the master and slave are configured with matching values.

Upon startup, the slaves will fetch the configuration from the master, so the slave's config file should not specify any Groups or Services. It may specify global level data, and notification Methods.

If the master has 'Service DARP/WATCH' or 'Service Self' monitors configured, these cannot be DARPed, and will not be fetched by the slaves.
Because that would just be silly.