Runtime Macros "last_problem_start_time" - alternative to "problem_id"

[xam-stephan]

Is it possible to extend the macros with "last_problem_start_time"= to get a unique error ID/[Host|Service]?

As an alternative to (Icinga1) "problem_id" for Icinga2, because 'simple non-globally unique' does not work when having a native cluster stack (https://github.com/Icinga/icinga2/issues/2188)

unique-id/string/value (for external tools) = $host.name$[+$service.name$]+$[host|service].last_problem_start_time$

Background: we use the (Icinga1) problem_id to create, update and solve tickets.

[dnsmichi]

last_hard_state_change and last_hard_state isn't sufficient?

[xam-stephan]

With the current macros I see no possibility. I'm looking for a macro that can help you establish a relationship between the problem(s) and the recovery.

[dnsmichi]

Can you add a concrete example where this is required (including code snippets on the application end) and why my proposal won't work here?

[xam-stephan]

During the problem, last_state_ok is equal = ok But during recovery the value is immediately reset

################################################## Host=icinga2-test Service=ping4 Output=test last_hard_state_change=1491986302 last_hard_state=1 state=WARNING last_state_ok=1491986275 ################################################## Host=icinga2-test Service=ping4 Output=test last_hard_state_change=1491986307 last_hard_state=2 state=CRITICAL last_state_ok=1491986275 ################################################## Host=icinga2-test Service=ping4 Output=test last_hard_state_change=1491986312 last_hard_state=0 state=OK last_state_ok=1491986312 ##################################################

Director Test Notification Plugin Command: /etc/icinga2/scripts/test-service-notification.pl -H $host.name$ -O $service.output$ -S $service.name$ -c $service.last_hard_state_change$ -i $service-state_id$ -l $service.last_hard_state$ -o $service.last_state_ok$ -p $service.perfdata$ -s $service.state$

-------- test script ------------

!/usr/bin/perl -w

use Getopt::Long; my $file = "/home/icinga2/alerts.txt"; my ($opt_H, $opt_S, $opt_O, $opt_c, $opt_l, $opt_s, $opt_o, $opt_i); Getopt::Long::Configure('bundling'); GetOptions ( "H=s" => \$opt_H, "host=s" => \$opt_H, "S=s" => \$opt_S, "service=s" => \$opt_S, "O=s" => \$opt_O, "output=s" => \$opt_O, "c=s" => \$opt_c, "last_hard_state_change=s" => \$opt_c, "l=s" => \$opt_l, "last_hard_state=s" => \$opt_l, "s=s" => \$opt_s, "state=s" => \$opt_s, "i=i" => \$opt_i, "state_id=i" => \$opt_i, "o=s" => \$opt_o, "last_state_ok=s" => \$opt_o, );

if (open(OUT,">>$file")) { print OUT "#"x50,"\n"; if (defined($opt_H)) { print OUT "Host=".$opt_H."\n"; } if (defined($opt_S)) { print OUT "Service=".$opt_S."\n"; } if (defined($opt_O)) { print OUT "Output=".$opt_O."\n"; } if (defined($opt_c)) { print OUT "last_hard_state_change=".$opt_c."\n"; } if (defined($opt_l)) { print OUT "last_hard_state=".$opt_l."\n"; } if (defined($opt_s)) { print OUT "state=".$opt_s."\n"; } if (defined($opt_i)) { print OUT "state_id=".$opt_i."\n"; } if (defined($opt_o)) { print OUT "last_state_ok=".$opt_o."\n"; } close OUT; }

[dnsmichi]

$notification.last_problem_notification$ already exists.

[pboguslawski]

Hi,

Consider implementing runtime macro notification.id (unique ID generated compatible to Message-ID in e-mail messages) and macro notification.references (empty/absent for first problem notification and equal to notification.id of first problem notification for all next notifications from the same problem).

This will allow one to add extra headers in e-mails like:

message="Message-ID: ${NOTIFICATIONID}\n" if [ -n "${NOTIFICATIONREFERENCES}" ]; then message="${message}References: ${NOTIFICATIONREFERENCES}\n"

to have e-mails from same problem automagically ordered in separate threads in e-mail clients/smart ticketing systems like OTRS.

Lack of unique problem-id in runtime notification macros (like in Icinga1) causes "mess" in receiving system now (i.e. tons of separate tickets which user must merge manually if want to keep history of same problem in same ticket).

Regards, Pawel

[infinity0]

This is what stopped me migrating from icinga 1 to icinga 2 years ago, and I see it still hasn't been resolved despite icinga 1 being deprecated now. I am wondering, what is the difficulty here, since the feature was in both nagios and icinga 1?

[N-o-X]

This is not something we will implement in the near feature. We'll keep this in mind for when we start work on the Notification Manager (NoMa 2).