Just a follow-up to this earlier question I had posed. My prior solution was incorrect. I have discovered a way in SQL to ignore subsequent HARD recoveries into an "OK" state that follow any SOFT non-OK states. The PostgreSQL query (on the icinga_statehistory table) is as follows:
state_type == 1 AND (last_hard_state != 0 OR state != last_state) This will exclude repetitive HARD OK states that follow the first recovery into an OK state. Jude George > Icinga2 seems to have an unbalanced way of treating HARD and SOFT states. > > I am using a max_checks value of 3 for a service. Let's say that a service > goes > into a SOFT Warning or Critical state (i.e. the problem occurs for less than 3 > checks in a row, in my case). Then the service recovers. It will first go > into a > SOFT OK state, then into a HARD OK state. This occurs even though it never > entered a HARD Warning or Critical state. > > My service frequently goes into a SOFT non-OK state, but it almost never > goes into a HARD non-OK state, because the problem rarely occurs 3 times in > succession. This is by design. However, if it does, there's a real problem, > and > that's what I want the HARD state to show - the real problem, and then the > real recovery from that problem. > > To my end-user, I only want to show the HARD state transitions. So the > result is that when I show a SQL query for all of the HARD state transitions > (by > searching in icinga_servicechecks table for state_type = 1, which is HARD > states), I see all of these HARD recovery "OK" states, even though there was > never a HARD non-OK state. > [etc. etc.] _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
