4

I wanted to attach a comment to a system that is being monitored with Nagios. I prefer using check_mk as GUI. Now I stumbled across this: I can set a comment as sticky and/or persistent.

So I asked our Nagios-admin what the difference between sticky and persistent would be.

It turned out, that he did not know about "sticky" - this has to be something check_mk-specific.

After a Google and a review of check_mk documents I could not find anything about that topic.

So: What is the difference between sticky and persistent for Nagios-service-comments?

Update: Here is a screenshot - check_mk quicksearch for a specific server, then select the hamer-symbol. Then this will show up:

Screenshot

The question is about the Acknowledge-Box: sticky vs. persistent

  • In the Multisite GUI, how do you add a new comment to the service? If I go to "Service problems", then choose a service and click on "Comments" button, there is no textbox to enter the comment, only table header: Author, Comment text, Time, E.Type. On the other side, in the old Nagios GUI, I only familiar with sticky and persistent comment when acknowledging a service problem: "Sticky Acknowledgement", "Send Notification", "Persistent Comment". Is this what you are talking about? – quanta Jul 4 '13 at 8:00
  • @quanta I updated my question with a screenshot. – Nils Jul 4 '13 at 12:09
6

I'll answer with some gritty details. Jenny D is to the point but I'd like to be more precise about "no further alarms".

Normally, Nagios will notifiy you on each status change:

  1. So if your service becomes "WARN", you get a notification.
  2. You acknoweledge the service now, and will not get another (i.e. perioditc) notification as long as the service stays in the "WARN" state.
  3. If it traverses to "CRIT", you get a notification.
  4. If it goes back to "WARN", you get a notification.
  5. If it then goes to "OK", you get a recovery notification.
  6. After that, acknowledgment is expired since it becomes "OK"

In the sticky scenario, the will be no notifications about traversals between problem states:

  1. So if your service becomes "WARN", you get a notification.
  2. You acknoweledge the service now with the sticky option set.
  3. If it traverses to "CRIT", you get no notification.
  4. If it goes back to "WARN", you get no notification.
  5. If it then goes to "OK", you get a recovery notification.
  6. After that, the sticky setting is removed since it's a property of the acknowledgment - expired since it becomes "OK"

In human terms:

Not setting the sticky option means: I'm working on the issue, but this will take a while, for example, while it's just a WARN I'm not authorized to map a new disk. If suddenly stuff escalates and the filesystem fills to CRIT, I need to know since then we move from proactive maintenance to an emergency fix.

The sticky option allows you to chose some other way of doing it. I'm working on the issue and will keep an eye on it while I work. During my work, it can worsen temporarly until I'm DONE and then it'll be fine

FYI: If you use the persistent comment option, the acknowledgement will be gone, but the text you entered will remain

3

The question is about the Acknowledge-Box: sticky vs. persistent

OK, they are what I have described in the above comment. Take a look at this for more details:

  • If the "sticky" option is set to one (1), the acknowledgement will remain until the host returns to an UP state. Otherwise the acknowledgement will automatically be removed when the host changes state.

  • If the "persistent" option is set to one (1), the comment associated with the acknowledgement will survive across restarts of the Nagios process. If not, the comment will be deleted the next time Nagios restarts.

  • But persistent will not survive the up-state either? – Nils Jul 6 '13 at 19:45
2

The "sticky" here means a "sticky acknowledgement" = there will be no further alarms until this issue has been resolved. In other words, the fact that you've acknowledged it will stick to the fault even if the same fault keeps generating alarms. (Of course, this lasts until the current problem has been resolved and the issue stops generating alarms - the next time that it fails, it will again generate alarms.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.