Icinga 2 Object Types of an service

Icinga 2
1

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
2

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

3

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.