Dispatch Alerts to a Webhook
Anomify can dispatch alerts to a webhook.
Your webhook endpoint must:
- Accept a header of x-api-key with the key you provide us with to authenticate requests
- Accept a POST with a JSON payload with the event data
Every alert can consist of 3 individual POSTs.
- The initial event json
- An event update once all the correlations analysis is complete
- A final event update that will include all previous info, any subsequent info and the
end_timestamp
value
Initial event json
{
"data": {
"anomaly": {
"anomalyScore": 0.7,
"id": "256828",
"metric": "web-server-1.mysql.counters.handlerRead_rnd",
"timestamp": 1599563224,
"value": 143.544444
}
},
"status": {}
}
Note
The id
elements are always passed as strings, not integers.
The id
is typed as a string because it is also typed as a string in other responses, such as the 'possible related anomalies' element.
Since these elements are JSON objects, the id
serves as the key of the JSON element, and therefore it must be typed as a string. That's why all id
objects are strings.
An event update will be posted a few minutes later once all the correlations analysis has been completed with the same id
.
{
"data": {
"anomaly": {
"anomalyScore": 0.7,
"cross correlations": {
"web-server-1.cpu0.iowait": {
"coefficient": 0.95752,
"shifted": 0,
"shifted_coefficient": 0.95752
},
"web-server-1.mysql.counters.handlerRead_first": {
"coefficient": 0.93422,
"shifted": 0,
"shifted_coefficient": 0.93422
},
"web-server-1.mysql.counters.handlerRead_key": {
"coefficient": 0.9997,
"shifted": 0,
"shifted_coefficient": 0.9997
},
"web-server-1.mysql.counters.handlerRead_next": {
"coefficient": 0.99738,
"shifted": 0,
"shifted_coefficient": 0.99738
},
"web-server-1.mysql.general.selectRange": {
"coefficient": 0.97342,
"shifted": 0,
"shifted_coefficient": 0.97342
},
"web-server-1.procs_running": {
"coefficient": 0.9486,
"shifted": 0,
"shifted_coefficient": 0.9486
},
"web-server-1.total.iowait": {
"coefficient": 0.97975,
"shifted": 0,
"shifted_coefficient": 0.97975
},
"mail-server-1.cpu0.nice": {
"coefficient": 0.99993,
"shifted": 0,
"shifted_coefficient": 0.99993
}
},
"id": "256828",
"metric": "web-server-1.mysql.counters.handlerRead_rnd",
"possible related anomalies": {
"256826": {
"metric": "web-server-1.mysql.counters.handlerRead_key",
"timestamp": 1599563164
},
"256827": {
"metric": "web-server-1.mysql.general.selectRange",
"timestamp": 1599563224
}
},
"possible related matches": {
"169560": {
"timestamp": 1599563230,
"fp id": 8821,
"layer id": "None",
"metric": "web-server-2.mariadb.localhost:3306.mysql.bytes_sent"
},
"169561": {
"timestamp": 1599563235,
"fp id": 8555,
"layer id": "None",
"metric": "web-server-2.mariadb.localhost:3306.mysql.handler_read_next"
}
},
"timestamp": 1599563224,
"value": 143.544444
}
},
"status": {}
}
Later a final event update will be POSTED that will include all previous info, any subsequent info and the end_timestamp
value, which is the end of the anomalous period.
{
"data": {
"anomaly": {
"anomalyScore": 0.7,
"cross correlations": {
...
...
},
"end_timestamp": 1599563860,
"id": "256828",
"metric": "web-server-1.mysql.counters.handlerRead_rnd",
"possible related anomalies": {
...
...
},
"possible related matches": {
...
...
},
"timestamp": 1599563224,
"value": 143.544444
}
},
"status": {}
}