Icinga 2 Object Types of an service

TheCry · March 10, 2023, 7:01am

Good morning all,
I am currently trying to optimize our call script a bit.
Here I use the Icinga 2
Object Types https://icinga.com/docs/icinga-2/latest/doc/09-object-types/:

state and last_state

According to the documentation a number should be output here.
The current state (0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN)

At least that’s how I understand it. But the output is not the integer but OK, WARNING…

What does the object last_state output? If I have a service check 1/1 the last_state is always OK, but if I have a service 1/3 the last_state seems to be the softstate.
Therefore I wanted to change to the object last_hard_state.

With the Object last_hard_state it is different. Here the integer is output. Only what surprises me, that always 2 (CRITICAL) is output, although the service stood before in the hard state OK.
Am I misunderstanding this now or is it a bug?

Icinga DB Web version (System - About): 1.0.2
Icinga Web 2 version (System - About):2.11.4
Web browser: Chrome 110.0.5481.100
Icinga 2 version (icinga2 --version): r2.13.7-1
Icinga DB version (icingadb --version): v1.1.0
PHP version used (php --version): 7.4
Server operating system and version: Debian 10

Al2Klimov · March 23, 2023, 5:22pm

Hello Sascha!

Please provide the sequence of state changes in question -i.e. the history- so we can explain when which state is the last hard one and why.

Best,
A/K

TheCry · March 24, 2023, 6:16am

Thanks for your Reply…
I have 2 services here… An active and a passive check. The passive check we use for traps.
Here is the active check:

Zustands-Änderung (Hard)
 CommunicationMrg_Alarme
auf
 hostname.tld (AvayaCommunication Manager)
am Feb 15
WARNING: WARNING-Alarms: 8 - MINOR-Alarms: 0 - MAJOR-Alarms: 0
[1] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[2] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[3] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[4] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[5] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[6] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[7] - Alarm => Alarmport: 01, MaintName: AESV-SES, Date: 15.02 - 06:46 Uhr
[8] - Alarm => Alarmport: 01, MaintName: AESV-SES, Date: 15.02 - 06:46 Uhr


Zustands-Änderung (Soft)
 CommunicationMrg_Alarme
auf
 hostname.tld (AvayaCommunication Manager)
am Feb 15
WARNING: WARNING-Alarms: 8 - MINOR-Alarms: 0 - MAJOR-Alarms: 0
[1] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[2] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[3] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[4] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[5] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[6] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[7] - Alarm => Alarmport: 01, MaintName: AESV-SES, Date: 15.02 - 06:46 Uhr
[8] - Alarm => Alarmport: 01, MaintName: AESV-SES, Date: 15.02 - 06:46 Uhr


Zustands-Änderung (Soft)
 CommunicationMrg_Alarme
auf
 hostname.tld (AvayaCommunication Manager)
am Feb 15
WARNING: WARNING-Alarms: 8 - MINOR-Alarms: 0 - MAJOR-Alarms: 0
[1] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[2] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[3] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[4] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[5] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[6] - Alarm => Alarmport: 1, MaintName: ADJ-IP, Date: 15.02 - 06:46 Uhr
[7] - Alarm => Alarmport: 01, MaintName: AESV-SES, Date: 15.02 - 06:46 Uhr
[8] - Alarm => Alarmport: 01, MaintName: AESV-SES, Date: 15.02 - 06:46 Uhr


Service hat sich erholt
CommunicationMrg_Alarme
auf
 hostname.tld (AvayaCommunication Manager)
am Feb 1
OK: No Communicationmanager-Alarms with level *WARNING, MINOR, MAJOR*.
Service hat sich erholt
 CommunicationMrg_Alarme
auf
 hostname.tld (AvayaCommunication Manager)
am Feb 1
OK: No Communicationmanager-Alarms with level *WARNING, MINOR, MAJOR*.

And here the passive check:

Zustands-Änderung (Hard)
 ALARM_IC_CONNECT_FAIL
auf
 hostname.tld (Sentinel - 111.111.111.111)
am Mar 23 23:10
CRITICAL - NICE: Interactions Center failed to connect to <remote Component type> <remote component name> (TrapEvent: niceSentinelAlarmICConnectFail - niceSentinelAlarmServiceEffect: High Risk Of Recording Loss - niceSentinelAlarmUpdateTime: No data available - niceSentinelAlarmTraps: 1109 - niceSentinelAlarmDescription: Interactions Center failed to connect to Logger - niceSentinelAlarmClearTime: 010101000000 - niceSentinelAlarmComponentType: usqn3pwicn2.sd01.unicreditgroup.eu - ic cluster - niceSentinelAlarmComponentLocation: 230323231015 - niceSentinelAlarmOperation: 1 - niceSentinelAlarmSeverity: 3 - niceSentinelAlarmAckTime: 010101000000 - niceSentinelAlarmAdditionalInfoLink: No data available - niceSentinelAlarmComponentDNS: UniCredit Production - Master Site  - niceSentinelAlarmClearingMethod: Interactions Center - niceSentinelAlarmAdditionalInfo: Additional Info: {Board=}, {Internal Component=Interactions Center}{Other=} - niceSentinelAlarmComponentIP: usqn3pwicn2.sd01.unicreditgroup.eu - niceSentinelAlarmOpenTime: 230323231024 - niceSentinelAlarmMetricName: No data available - niceSentinelAlarmMetricValue: No data available - niceSentinelAlarmVersion: 6.3 - niceSentinelAlarmDisplayName: 123.123.123)

Zustands-Änderung (Hard)
 ALARM_IC_CONNECT_FAIL
auf
 hostname.tld (Sentinel - 111.111.111.111)
am Mar 23 22:22
CRITICAL - NICE: Interactions Center failed to connect to <remote Component type> <remote component name> (TrapEvent: niceSentinelAlarmICConnectFail - niceSentinelAlarmDisplayName: 123.123.123 - niceSentinelAlarmMetricValue: No data available - niceSentinelAlarmVersion: 6.3 - niceSentinelAlarmUpdateTime: No data available - niceSentinelAlarmComponentIP: usqn3pwicn2.sd01.unicreditgroup.eu - niceSentinelAlarmMetricName: No data available - niceSentinelAlarmClearTime: 010101000000 - niceSentinelAlarmDescription: Interactions Center failed to connect to Logger - niceSentinelAlarmComponentLocation: 230323222153 - niceSentinelAlarmAdditionalInfoLink: No data available - niceSentinelAlarmServiceEffect: High Risk Of Recording Loss - niceSentinelAlarmComponentDNS: UniCredit Production - Master Site  - niceSentinelAlarmTraps: 1109 - niceSentinelAlarmAdditionalInfo: Additional Info: {Board=}, {Internal Component=Interactions Center}{Other=} - niceSentinelAlarmAckTime: 010101000000 - niceSentinelAlarmOperation: 1 - niceSentinelAlarmClearingMethod: Interactions Center - niceSentinelAlarmComponentType: usqn3pwicn2.sd01.unicreditgroup.eu - ic cluster - niceSentinelAlarmSeverity: 3 - niceSentinelAlarmOpenTime: 230323222159)

Service hat sich erholt
 ALARM_IC_CONNECT_FAIL
auf
 hostname.tld (Sentinel - 111.111.111.111)
vor 2d 0h
ok

I have to say that we have set Volatile = true for the passive check to see all further traps in the history. If I set this to false we only see the first trap that changes the status.
I described the problem a long time ago here: Notifications for passive services

With the passive check I have tried several things. The problem is exactly as I described it in the ticket.

github.com/Icinga/icinga2

ICINGA service object output is not correct

opened 07:11AM - 13 Mar 23 UTC

TheCry

## Describe the bug Good morning all, I am currently trying to optimize our …call script. For this I use the objects from ICINGA Object Types https://icinga.com/docs/icinga-2/latest/doc/09-object-types/#service state, last_state and last_hard_state According to the documentation a number should be output here. The current state (0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN) At least that's how I understand it. With "state/last_state" no integer but OK, WARNING, CRITICAL, UNKNOWN is output. Now I wanted to work with the object "last_hard_state". Here I noticed that integers are output. With a CRITICAL I receive accordingly a 2. But the object last_hard_state always returns only CRITICAL. For a service that should immediately issue an alarm when it changes from OK to CRITICAL (1/1), the object last_hard_state contains the value CRITICAL although the service was previously in the hard state OK. ## Expected behavior If a service is in HARD state OK the object last_hard_state should output OK when the service changes to a new HARD state. Only when the service comes to a new hard state, the object last_hard_state in the previous hard state may change. The objects state, last_state and last_hard_state should all have the same output. Either integer or alphanumeric ## Your Environment Icinga DB Web version (System - About): 1.0.2 Icinga Web 2 version (System - About):2.11.4 Web browser: Chrome 110.0.5481.100 Icinga 2 version (icinga2 --version): r2.13.7-1 Icinga DB version (icingadb --version): v1.1.0 PHP version used (php --version): 7.4 Server operating system and version: Debian 10