Please add an argument to handle UNKNOWN as WARNING or CRITICAL
Closed this issue · 5 comments
Hello,
we need a way to handle UNKNOWN in a different way, because in our usecase unknown hints to an error.
Is it possible to add an argument to specify the exitcode for UNKNOWN?
Hi, can you please elaborate?
Given that something not-OK is detected, how can this not be handled with Icinga itself?
Example: a notification can be send given any status change: https://icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/#notification-filters-by-state-and-type
Thank you for the fast response and your hint to the Icinga docs. Unfortunately this won't help us. We have a huge environment with 20k+ hosts and we are unable to completely eliminate every occurance of an 'unknown'.
In icinga we use only 2 notification definitions, which are globally used. Here we alert only 'ok', 'warning' and 'critical',because the majority of those 'unknown' events is not helpful for our users.
In the case of check_http_json our developers want also alerts if their microservices go 'unknown'. The check is very important here.
Therefore I was hoping for an mitigation-argument, because I don't want to fiddle with the unknown exit code in the check anymore and want to move to the official repo.
I also want to thank you for the continued support for this check. It's much appreciated 👍🏻
Just so that I understand correctly, whats needed is UNKNOWN notifications only for check_http_json not all other services. Right?
If so, I would add another Icinga notification just for that Service. Example:
template Notification "http-json-custom-notification" {
command = "mail-service-notification"
states = [ Warning, Critical, Unknown ]
types = [ Problem, Acknowledgement, Recovery ]
period = "24x7"
}
apply Notification "http-json-custom-notification" to Service {
assign where service.name == "check-http-json"
}
Yes, this could solve the problem. Thanks for your time.
@K0nne No worries 👍 Glad I could help.