| Service Check #: | Service State: | Service Check Output: |
| x | OK | RAID array optimal |
| x+1 | OK | RAID array optimal |
| x+2 | WARNING | RAID array degraded (1 drive bad, 1 hot spare rebuilding) |
| x+3 | CRITICAL | RAID array degraded (2 drives bad, 1 host spare online, 1 hot spare rebuilding) |
| x+4 | CRIICAL | RAID array degraded (3 drives bad, 2 hot spares online) |
| x+4 | CRITICAL | RAID array degraded (3 drives bad, 2 hot spares online) |
| x+5 | CRITICAL | RAID array failed |
| x+6 | CRITICAL | RAID array failed |
| x+7 | CRITICAL | RAID array failed |
Given this sequence of checks, you would normally only see two log entries for this catastrophe. The first one would occur at service check x+2 when the service changed from an OK state to a WARNING state. The second log entry would occur at service check x+3 when the service changed from a WARNING state to a CRITICAL state.
-For whatever reason, you may like to have the complete history of this catasrophe in your log files. Perhaps to help explain to your manager how quickly the situation got out of control, perhaps just to laugh at over a couple of drinks at the local pub, whatever... +For whatever reason, you may like to have the complete history of this catastrophe in your log files. Perhaps to help explain to your manager how quickly the situation got out of control, perhaps just to laugh at over a couple of drinks at the local pub, whatever...
@@ -93,6 +89,13 @@ You can enable state stalking for hosts and services by using the stalking_options directive in host and service definitions.
++How Does This Differ From Volatile Services? +
+ ++Volatile services are similar, but will cause notifications and event handlers to run. Stalking is purely for logging purposes. +
Caveats @@ -103,7 +106,7 @@
-As a general rule, I would suggest that you not enable stalking for hosts and services without thinking things through. Still, its there if you need and want it. +As a general rule, I would suggest that you not enable stalking for hosts and services without thinking things through. Still, it's there if you need and want it.
diff -ur nagios-2.5.original/html/docs/volatileservices.html nagios-2.5/html/docs/volatileservices.html --- nagios-2.5.original/html/docs/volatileservices.html 2005-12-14 16:51:03.000000000 +0000 +++ nagios-2.5/html/docs/volatileservices.html 2006-09-13 20:33:51.796444734 +0100 @@ -15,11 +15,9 @@ -
What's So Special About Volatile Services? @@ -54,19 +50,21 @@ Volatile services differ from "normal" services in three important ways. Each time they are checked when they are in a hard non-OK state, and the check returns a non-OK state (i.e. no state change has occurred)...
-
These events normally only occur for services when they are in a non-OK state and a hard state change has just occurred. In other words, they only happen the first time that a service goes into a non-OK state. If future checks of the service result in the same non-OK state, no hard state change occurs and none of the events mentioned take place again.
+If you are only interested in logging, consider using stalking options instead. +
+ +The Power Of Two
@@ -82,33 +80,27 @@ In Nagios: -
In PortSentry:
-
Create a shell script in the /usr/local/nagios/libexec/eventhandlers directory named submit_check_result. The contents of the shell script should be something similiar to the following...
-
-
#!/bin/sh
@@ -128,8 +120,6 @@
# append the command to the end of the command file
`$echocmd $cmdline >> $CommandFile`
-
-
Note that if you are running PortSentry as root, you will have to make additions to the script to reset file ownership and permissions so that Nagios and the CGIs can read/modify the command file. Details on permissions/ownership of the command file can be found here. @@ -139,14 +129,12 @@ So what happens when PortSentry detects a port scan on the machine?
-