Introduction

The current state of services and hosts is determined by two components: the status of the service or host (i.e. OK, WARNING, UP, DOWN, etc.) and the type of state it is in. There are two state types in Nagios - "soft" states and "hard" states. State types are a crucial part of Nagios' monitoring logic. They are used to determine when event handlers are executed and when notifications are sent out.

Service and Host Check Retries

In order to prevent false alarms, Nagios allows you to define how many times a service or host check will be retried before the service or host is considered to have a real problem. The maximum number of retries before a service or host check is considered to have a real problem is controlled by the <max_check)attempts> option in the service and host definitions, respectively. Depending on what attempt a service or host check is currently on determines what type of state it is is. There are a few exceptions to this in the service monitoring logic, but we'll ignore those for now. Let's take a look at the different service state types...

Soft States

Soft states occur for services and hosts in the following situations...

• When a service or host check results in a non-OK state and it has not yet been (re)checked the number of times specified by the <max_check_attempts> option in the service or host definition. Let's call this a soft error state...
• When a service or host recovers from a soft error state. This is considered to be a soft recovery.

Soft State Events

What happens when a service or host is in a soft error state or experiences a soft recovery?

• The soft error or recovery is logged if you enabled the log_service_retries or log_host_retries options in the main configuration file.
• Event handlers are executed (if you defined any) to handle the soft error or recovery for the service or host. (Before any event handler is executed, the $HOSTSTATETYPE$ or $SERVICESTATETYPE$ macro is set to "SOFT").
• Nagios does not send out notifications to any contacts because there is (or was) no "real" problem with the service or host.

As can be seen, the only important thing that really happens during a soft state is the execution of event handlers. Using event handlers can be particularly useful if you want to try and proactively fix a problem before it turns into a hard state. More information on event handlers can be found here.

Hard States

Hard states occur for services in the following situations (hard host states are discussed later)...

• When a service check results in a non-OK state and it has been (re)checked the number of times specified by the <max_check_attempts> option in the service definition. This is a hard error state.
• When a service recovers from a hard error state. This is considered to be a hard recovery.
• When a service check results in a non-OK state and its corresponding host is either DOWN or UNREACHABLE. This is an exception to the general monitoring logic, but makes perfect sense. If the host isn't up why should we try and recheck the service?

Hard states occur for hosts in the following situations...

• When a host check results in a non-OK state and it has been (re)checked the number of times specified by the <max_check_attempts> option in the host definition. This is a hard error state.
• When a host recovers from a hard error state. This is considered to be a hard recovery.

Hard State Changes

Before I discuss what happens when a host or service is in a hard state, you need to know about hard state changes. Hard state changes occur when a service or host...

• changes from a hard OK state to a hard non-OK state
• changes from a hard non-OK state to a hard OK-state
• changes from a hard non-OK state of some kind to a hard non-OK state of another kind (i.e. from a hard WARNING state to a hard UNKNOWN state)

Hard State Events

What happens when a service or host is in a hard error state or experiences a hard recovery? Well, that depends on whether or not a hard state change (as described above) has occurred.

If a hard state change has occurred and the service or host is in a non-OK state the following things will occur..

• The hard service or host problem is logged.
• Event handlers are executed (if you defined any) to handle the hard problem for the service or host. (Before any event handler is executed, the $HOSTSTATETYPE$ or $SERVICESTATETYPE$ macro is set to "HARD").
• Contacts will be notified of the service or host problem (if the notification logic allows it).

If a hard state change has occurred and the service or host is in an OK state the following things will occur..

• The hard service or host recovery is logged.
• Event handlers are executed (if you defined any) to handle the hard recovery for the service or host. (Before any event handler is executed, the $HOSTSTATETYPE$ or $SERVICESTATETYPE$ macro is set to "HARD").
• Contacts will be notified of the service or host recovery (if the notification logic allows it).

If a hard state change has NOT occurred and the service or host is in a non-OK state the following things will occur..

• Contacts will be re-notified of the service or host problem (if the notification logic allows it).

If a hard state change has NOT occurred and the service or host is in an OK state nothing happens. This is because the service or host is in an OK state and was the last time it was checked as well.