For the problems DOWN, UNREACH, WARN, CRIT or UNKNOWN Check_MK distinguishes two possible states: unhandled and handled. A handled (acknowledged) problem indicates that the issue is known and somebody is attending to it.
If a problem has been acknowledged, then...
- ... it will be identified with a symbol,
- ... will no longer appear as unhandled in the tactical overview,
- ... and no further notifications will be sent.
2. Procedure of an acknowledgement
Problems are acknowledged via commands on the affected hosts/services. Acknowledgements can be removed in the same way.
Advice for these options:
|sticky||An acknowledgement is normally valid until the next status change. If e.g. a service has been acknowledged with a WARN status and later changes to CRIT the acknowledgement will be automatically removed. Activating sticky will retain the acknowledgement until an OK or an UP status is achieved.|
|send notification||All contacts assigned to the host/service whom are configured to be alerted for the Acknowledgement of host/service problem will be sent a notification.|
|persistent comment||With this option your commentary will not be automatically deleted if the acknowledgement disappears or is removed. Commentaries entered in this way must be manually deleted later (see the end of this chapter).|
|Expire acknowledgement after ...|
|Comment||You can include a URL like http://www.example.com in this field, which will be replaced by a clickable link.|
3. Acknowledgements in the GUI
In the Check_MK web interface there are several possibilities for displaying acknowledgements.
In all host and service views, acknowledged problems are identified by two symbols:
|This symbol marks an acknowledgement|
|Clicking on this symbol displays a list with acknowledgement commentaries.|
Via Views ➳ Other ➳ Comments you can view a list of all commentaries for hosts and services - including those created through acknowledgements. Commentaries may be deleted via commands. Deleting a commentary has no effect on logged acknowledgements.