Alert ID expanding from template placeholder

Help
1

Hello!

I was working on adding alert acknowledgement option from transport messages, so that we could acknowledge them without going to the web interface.
There is a simple API ack_alert request in the script, which only requires alert_id to be passed. I thought that maybe one of the template placeholders could be expanded to the alert id and then easily passed to API call, so added both %id and %uid to the template to see what is required. But it seems that both placeholders expand to values from alert_log table.

Last PROBLEM alert contents for ids:

Timestamp: 2018-06-20 14:35:12
Faults:
#1: sensor_id => 7051; sensor_oid => .1.3.6.1.4.1.11.2.14.11.5.1.82.1.1.1.1.13.49; sensor_descr => 49 Port Bias Current; 
Sensor: 0.016116
Previous Measurement: 
Limit: 0 / 0.01
Alert ID: 
Alert UID: 213154
ACK URL: https://librenms/test.php?id=213154

Note that %id is not expanded at all in problem alert.
It will be expanded with recovery event, but will not be the same as %uid, however from the same table.

Alert rule template:

Last IDs from alerts at about the same time (alert delay is 5m, so there is a threshold):

select id from alerts order by id desc limit 10;
+-------+
| id    |
+-------+
| 37293 |
| 37292 |
| 37291 |
| 37290 |
| 37289 |
| 37288 |
| 37287 |
| 37286 |
| 37285 |
| 37284 |
+-------+

Last IDs from alert_log at about the same time (alert delay is 5m, so there is a threshold):

select id from alert_log order by id desc limit 10;
+--------+
| id     |
+--------+
| 213155 |
| 213154 |
| 213153 |
| 213152 |
| 213151 |
| 213150 |
| 213149 |
| 213148 |
| 213147 |
| 213146 |
+--------+

Can somebody please approve if this is expected behavior or a bug? In the latter case, can somebody point out which code block should be reviewed for fix (if it is something simple, I can try fixing this myself)?

./validate.php output:

====================================
Component | Version
--------- | -------
LibreNMS  | 1.40-23-g68a6766
DB Schema | 252
PHP       | 5.6.30-0+deb8u1
MySQL     | 5.7.20
RRDTool   | 1.6.0
SNMP      | NET-SNMP 5.7.2.1
====================================

[OK]    Composer Version: 1.6.5
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[FAIL]  Database: extra table (plugin_config_rules)
[FAIL]  We have detected that your database schema may be wrong, please report the following to us on IRC or the community site (https://t.libren.ms/5gscd):
        [FIX] Run the following SQL statements to fix.
        SQL Statements:
         DROP TABLE `plugin_config_rules`;
[WARN]  Some devices have not been polled in the last 5 minutes. You may have performance issues.
        [FIX] Check your poll log and see: http://docs.librenms.org/Support/Performance/
        Devices:
         <device list>
[FAIL]  Some devices have not completed their polling run in 5 minutes, this will create gaps in data.
        [FIX] Check your poll log and see: http://docs.librenms.org/Support/Performance/
        Devices:
         <device list>
[FAIL]  We have found some files that are owned by a different user than librenms, this will stop you updating automatically and / or rrd files being updated causing graphs to fail.
        [FIX] chown -R librenms:librenms /opt/librenms
        Files:
         /opt/librenms/html/test.php
2

After Laravel Blade implementation alert->id is expanding to “id is not a valid data name” string.

3

Same applies for $alert->rule, it is not expanded at all with version 1.42.01-75-ge9ff8c4.

If it is impossible to tell if it expected behavior or not, maybe somebody has actually succeeded acknowledging an issue without directly accessing web interface, via some other means? Or have an idea how this can be done?

In order to ack a correct alert, it is needed to get a combination of alert and device identifiers. Alert rule name is expanded alright, but unfortunately all of them contain whitespaces in the naming fields, thus breaking the URL as per example above. Maybe it is possible to get alert id via SQL, knowing the timestamp - but there may be occasions, when multiple alerts fire off at the same second, so it is not a bulletproof approach either…

4

Alright, finally there is some progress. It is not documented, but placeholder $alert->rule_id indeed is expanded to the correct rule id.
Before I make adjustments to the documentation, @laf or @murrant, can you please approve this is documentation bug or there is some work in progress in this area?

1 Like
5

It’s no real bug, the known available params are documented. Just add more to them if they are missing.

uid is the one you want btw for a unique ID that spans the life of an alert.

6

Thank you, sent the docs update request.

In case anybody is interested in alert ACKing from notification, here is how I ended up doing this: https://gist.github.com/angryp/d5cdb8d912b0315b9627b08630523143

2 Likes