The alert id isn’t the same as the alert id. No attempt is even made to explain the different IDs:

Yeah. The LMx# ID is tied to the specific device datasource instance that is alerting. So an alert for Server01’s C: drive free space will always have the same LMx# alert id each time. Even for alerts that occur years apart. The 3rd letter will depends on the alert type. D=device, S=website, A=Collector, etc.The DS# ID is tied to the specific situation and time. So for example a warning alert that occurred at 1am. This ID changes although if the alert situation changes, for example if the alert changing from warning to error then the ID changes. I think because the system kinda clears the warning and then alerts and error, but will pass previous alert state.I guessing this is because it’s useful for the GUI show alerts the way it does. It does mean that neither ID is useful for linking to tickets. The LMx# id is too long-term and the DS# is too short. You kinda have to either let LM to the tracking via ##EXTERNALTICKETID## or setup the ticketing/integration system o have complex logic to track alerts and keep it’s own state of each alert and it’s ticket.

Does this frustrate anyone else? | LogicMonitor

Mike_Moniz
Professor
2 years ago
Yeah. The LMx# ID is tied to the specific device datasource instance that is alerting. So an alert for Server01’s C: drive free space will always have the same LMx# alert id each time. Even for alerts that occur years apart. The 3rd letter will depends on the alert type. D=device, S=website, A=Collector, etc.
The DS# ID is tied to the specific situation and time. So for example a warning alert that occurred at 1am. This ID changes although if the alert situation changes, for example if the alert changing from warning to error then the ID changes. I think because the system kinda clears the warning and then alerts and error, but will pass previous alert state.
I guessing this is because it’s useful for the GUI show alerts the way it does. It does mean that neither ID is useful for linking to tickets. The LMx# id is too long-term and the DS# is too short. You kinda have to either let LM to the tracking via ##EXTERNALTICKETID## or setup the ticketing/integration system o have complex logic to track alerts and keep it’s own state of each alert and it’s ticket.
Patrick_Friar
LM Champion
2 years ago
@Mike Moniz the unique DS# is more useful internally than externally as it can be referenced in our backend logs when investigating issues with specific alerts, the associated LMD can be checked to verify during these searches as well as in alert frequency reporting, etc.

While I don’t have any hard data on the design I would think that using LM-generated IDs in ticketing systems might lead to some very sporadic behavior and ultimately cause more of a headache, hence allowing the ticketing systems to follow their own ID schema.
Anonymous
2 years ago
Yeah, I knew about the differences. Just two frustrations: 1) if there’s a different ID for the recurrence, why can’t there be a recurrence count and bundling of alerts by the LMx ID (and alerting based on recurrence count). 2) Did you know that the tokens are swapped? ##ALERTID## has the DS alert number and ##INTERNALID## has the LMx ID?
Where’s the documentation on this?
Mike_Moniz
Professor
2 years ago
I understand. The issue is that you need to be able to map alerts to tickets, and tickets to alerts. Generally you do that by some sort of mapping. For example alert 873 = ticket 235. But LM doesn’t have an alert id that you can map. The ticketing system has to rely on LM keeping it informed on alert changes (which it does not always do, but much better than before) or separately tracking alert states.
Just imagine how much work LM would need to do if the ticket number changes every time its state changes. If the ticket number changes ween the ticket is open, pending, waiting for customer, etc. I once spent over a month working with a 3rd party integration/glue product to implement logic to deal with this. But it is doable and if possible best to try to use ##EXTERNALTICKETID## when possible.
Anonymous
2 years ago
We actually don’t pass directly to our ticketing system, so the external ticketid token is basically useless. If we could use the API to come back in and set the externalticketid on an alert, that would be awesome. As it is, we currently just modify the note on the alert to contain the real external ticket id.
David_Bond
Professor
2 years ago
@Stuart Weenig
Both are important.
The LMD number (or LME, or LMS etc. depending on the alert type) is what we (Panoramic Data Limited) calls the “Problem Signature” and relates to the INSTANCE/DATAPOINT tuple. For example “Downlink throughput on Bandwidth Router 5’s GE1/0 interface”.
This can reliably be used as the identifier for the Incident. That way, if the bandwidth keeps spiking, you don’t keep opening new tickets, you just update the old one.
The DS (etc.) id is unique to the alert NOTIFICATION and will not be repeated. This can be used to tag the Comment that you add to the ticket, each time you get a bandwidth spike.
LogicMonitor’s built in “Integrations” are useless for this, of course - they just keep spamming incidents into the ITSM without a care in the world.
<Incoming advert>
Our AlertMagic system fixes all this - just point it at your ServiceNow / AutoTask / Cherwell / Dynamics etc. system and it does the rest.
If you’re interested, give me a yell via Linked In or fill in some details here: https://alert.magicsuite.net/
David
Anonymous
2 years ago
Yep, we’ve understood that for a while. One frustrating thing is that LM obviously knows how to bundle alerts together, as evidenced by the IDs involved. However, for years they haven’t had the ability to come out with an occurrence count per alert or used occurrence count to dictate opening/clearing of alerts.
David_Bond
Professor
2 years ago
Hi @Stuart Weenig,
You absolutely can. It’s achieved using the new UIv4 Alert Graph. Admittedly it’s buried, but looks like this in the UI:
You can hit the following URL:
https://panoramicdata.logicmonitor.com/santaba/rest/alert/alerts/DS26996359/history?fields=alertCount&start=1685228400&end=1687883190&_=1687883190864
… to get a history with a response like follows:
{
"alertCount" : 142
}
OR omit the fields constraint like this:
https://panoramicdata.logicmonitor.com/santaba/rest/alert/alerts/DS26996359/history?start=1685228400&end=1687883190&_=168788319086
to get a response like this:
{
"alertCount": 142,
"histogram": {
"datapoint": [
"warn",
"error",
"critical"
],
"timestamps": [
1685232000,
1685318400,
1685404800,
1685491200,
1685577600,
1685664000,
1685750400,
1685836800,
1685923200,
1686009600,
1686096000,
1686182400,
1686268800,
1686355200,
1686441600,
1686528000,
1686614400,
1686700800,
1686787200,
1686873600,
1686960000,
1687046400,
1687132800,
1687219200,
1687305600,
1687392000,
1687478400,
1687564800,
1687651200,
1687737600,
1687824000
],
"values": [
[
2,
0,
0
],
[
7,
0,
0
],
[
7,
0,
0
],
[
7,
0,
0
],
[
6,
0,
0
],
[
3,
0,
0
],
[
3,
0,
0
],
[
5,
0,
0
],
[
4,
0,
0
],
[
2,
0,
0
],
[
3,
0,
0
],
[
6,
0,
0
],
[
2,
0,
0
],
[
6,
0,
0
],
[
2,
0,
0
],
[
4,
0,
0
],
[
4,
0,
0
],
[
6,
0,
0
],
[
3,
0,
0
],
[
6,
0,
0
],
[
4,
0,
0
],
[
2,
0,
0
],
[
4,
0,
0
],
[
5,
0,
0
],
[
4,
0,
0
],
[
6,
0,
0
],
[
6,
0,
0
],
[
5,
0,
0
],
[
6,
0,
0
],
[
7,
0,
0
],
[
5,
0,
0
]
]
},
"type": "instance"
}
David_Bond
Professor
2 years ago
@Stuart Weenig I posted a reply but it’s being “moderated”, whatever that means (presumably because it contained pictures).
Anyway, the gist of the post was that there IS a way to achieve this via the new santaba endpoints for Alert history (the graphs against alerts shown buried somewhere in the new Resources v4 UI):
https://panoramicdata.logicmonitor.com/santaba/rest/alert/alerts/DS26996359/history?start=1685228400&end=1687883190&_=168788319086

and

https://panoramicdata.logicmonitor.com/santaba/rest/alert/alerts/DS26996359/history?fields=alertCount&start=1685228400&end=1687883190&_=1687883190864
This provides results in the following form (which includes an alert total):
{
"alertCount": 142,
"histogram": {
"datapoint": [
"warn",
"error",
"critical"
],
"timestamps": [
1685232000,
1685318400,
1685404800,
1685491200,
1685577600,
1685664000,
1685750400,
1685836800,
1685923200,
1686009600,
1686096000,
1686182400,
1686268800,
1686355200,
1686441600,
1686528000,
1686614400,
1686700800,
1686787200,
1686873600,
1686960000,
1687046400,
1687132800,
1687219200,
1687305600,
1687392000,
1687478400,
1687564800,
1687651200,
1687737600,
1687824000
],
"values": [
[
2,
0,
0
],
[
7,
0,
0
],
[
7,
0,
0
],
[
7,
0,
0
],
[
6,
0,
0
],
[
3,
0,
0
],
[
3,
0,
0
],
[
5,
0,
0
],
[
4,
0,
0
],
[
2,
0,
0
],
[
3,
0,
0
],
[
6,
0,
0
],
[
2,
0,
0
],
[
6,
0,
0
],
[
2,
0,
0
],
[
4,
0,
0
],
[
4,
0,
0
],
[
6,
0,
0
],
[
3,
0,
0
],
[
6,
0,
0
],
[
4,
0,
0
],
[
2,
0,
0
],
[
4,
0,
0
],
[
5,
0,
0
],
[
4,
0,
0
],
[
6,
0,
0
],
[
6,
0,
0
],
[
5,
0,
0
],
[
6,
0,
0
],
[
7,
0,
0
],
[
5,
0,
0
]
]
},
"type": "instance"
}