Troubleshooting

At some point you may wonder why Argus thinks something is down or up (perhaps you tested it manually and you disagree), or why argus is doing such-and-such instead of other-such.

The debugging page contains all sorts of information about the object in question, some of which may be useful for a tech to troubleshoot issues (but beware, this is no place for a PHB).

The meaning of some of the information will be obvious from its name or from reading the configuration documentation, some won't be obvious. Running argusd -E will generate some documentation on the various parameters. Or find an auto-generated list here. In particular, you may find such things as: time of the last test, time of the next test, the reason a test failed, and the values argus is using for every configurable parameter.

Access to this information is controlled by 'acl_about'. To minimize confusion of management and/or end-users, it is recommended that access only be given to technical staff capable of understanding this information.

Logging

Argus will log various errors to its log file, located in the data directory, or via the web page.

Argus will log even more things to syslog, if syslog is enabled in the config file. If you haven't enabled syslog, you can also get the detailed logs using argusctl:

	argusctl -k console

The cgi program will log various errors to where ever your web server logs such things, typically a file called 'error_log'.

Service Debugging

For detailed, real-time 'what is happening' info, you can set the debugging flag on a service, this will send all sorts of data to syslog:

	Service UDP/SNMP {
		hostname:	cisco-1.example.com
		community:	qwerty
		oid:		.1.3.6.1.4.1.9.9.13.1.3.1.3.1
		maxvalue:	27
		debug:		yes
	}

You can also toggle the debugging flag at run-time using argusctl:

argusctl setparam param=debug value=1 object=Top:Servers:Ping_10.0.0.4
argusctl setparam param=debug value=0 object=Top:Servers:Ping_10.0.0.4