Unique identifier for notifications

[nook24]

Hi,

I'm looking for an method to have an unique identifier for a notification that got sent to multiple contacts.

Unfortunately the macros $HOSTNOTIFICATIONID$ and $SERVICENOTIFICATIONID$ depend on the retention.dat and are therefore not really unique.

My next idea was to concat $HOSTNAME$ + $SERVICEDESC$ + $TIMET$ to get a unique id. I checked the Naemon source code and for me it looks like that the value of $TIMET$ get calculated when the command line of the notification script gets assembled. So the value of $TIMET$ could be 12:00:00 for one contact and 12:00:01 for the second contact.

My suggestion would be, to add a new UUID macro to the notification logic. Same as: https://github.com/naemon/naemon-core/blob/6d3ec3405d1c14129f59eb42e7f059ada7045351/src/naemon/notifications.c#L1362

Like so:

nm_asprintf(&mac.x[MACRO_HOSTNOTIFICATIONUUID], "%s", get_uuid_v4()); 

This would ensure that all notifications would have an unique identifier. Before I start implementing this and send over a pull request I wanted to ask if this is a change you would merge into the core or not. I would probably make use of uuid/uuid.h. So this would add in a new dependency.

[sni]

tbh, i am not a big fan of adding a new dependency to solely solve a single very specific detail. Naemon uses a notification id internally already which is unique, even over restarts. As you noticed already, state is stored in the retention.dat file. If you really need a global unique id, you could create a uuid and create a lookup map from the internal notification id to your uuid. I assume you want to use it in your statusengine neb module?

[nook24]

I admit that my request is an edge case. For me it would be good if I could use some INSERT ... ON DUPLICATE KEY UPDATE syntax inside of my notification scripts. The issue with the current notification_id is, that in case of a rollback of the System (ZFS replication, or VM snapshots for example) it could happen that I end up with an wrong / old notification_id which was already used before that rollback happened. But tbh it's more likely that Naemon crashes and the retention.dat is old and I end up with duplicate notification_id's.

I understand why you try to keep Naemon as free of dependencies as possible. An dependency free version which would be still unique enough would be something like this:

#include <time.h>
#include <stdlib.h>
#include <stdio.h>

int main() {

    int i;
    int notification_id = 1;    // svc->current_notification_id

    srand(time(NULL));

    for (i = 0; i < 10; ++i) {
        int r = rand();
        printf("%d-%d-%d\n", notification_id, r, (int)time(NULL));
    }
}

/* Output:
1-335965681-1623135328
1-852319791-1623135328
1-1814191106-1623135328
1-1084834684-1623135328
1-1320047683-1623135328
1-1646583020-1623135328
1-200194969-1623135328
1-199793549-1623135328
1-1584433471-1623135328
1-563424688-1623135328
*/

It would make sure that all running instances of an notification script would know the same unique id without relying on the retention.dat

This could also used to deduplicate alerts.

I assume you want to use it in your statusengine neb module?

Unfortunately not, otherwise I would add this directly to the broker.