Webhooks
pgDash supports notification of alerts and change alerts via Webhooks since version 2.4.11. This document describes the technical details required to write your own Webhook to process these notifications.
General Requirements:
- Webhooks must be provided as a
httporhttpsURL. ForhttpsURLs the certificate must be valid. - Notifications are delivered as an HTTP POST request with a content type of
application/json. The User-Agent header will begin withpgDash-Webhook. The connection will be closed after a successful request. - The webhook must process the notification within 3 seconds. If it fails to send a response within this time, pgDash will wait for 5 seconds and retry the request. No more than 3 retries will be attempted. Note that retries are attempted only on timeout, not on the response's HTTP status code.
- The webhook must return a status code of 200 if it receives and processes the request.
- pgDash will discard any response body from the webhook. No response body is required.
Request Body for Alerts:
- Webhook URLs set on the "Alerts" page in pgDash will be invoked whenever there is a change in the alert status of any rule that has been set.
- Notifications are sent only when the status changes, that is, the mechanism is "edge-triggered" and not "level-triggered". In the absence of any notifications it must be assumed that the state indicated by the last-sent notification continues to persist.
- When all alerts clear, a notification is sent without any alert items (the
alertsarray described below is empty). As per the previous rule, another notification will be sent only when this state changes, that is, when an alert rule is triggered. - The request body is a JSON object with the following properties:
version- integer - the version of the JSON object's schema. Currently always 1. Note that backwards-compatible changes, like adding a new property might be done without incrementing this version number.server- string - the name of the server whose alert status has changed.reported- integer - the timestamp of the pgmetrics report which caused the change in the alert status. The timestamp is represented as the number of seconds since epoch (1 Jan 1970).alerts- array of objects - the list of warning or critical alerts, each as an object with properties as below. Note that if the alerts just cleared and the state went back to normal, this array will be empty. For each separate object that triggered a rule, there will be a separate entry in this array (example if the rule is "Table size is greater than 100 MiB" and two tables qualify, there will be two entries in this array that have the same "text" property.)type- string - one ofwarnorcritindicating a rule type of warning or critical respectively.text- string - a description of the alert rule, example "Number of backends is greater than 40", "Database size is greater than 1 GiB".value- string - the current value which triggered the rule, example "43", "1.4 GiB"objname- string - the name of the object involved in the alertobjlink- string - a URL to the object involved in the alertquery- string, optional - if this is a query-level alert, the full SQL query text
Here is an example of the request body:
1
{
2
"version": 1,
3
"server": "prod-42",
4
"reported": 1567428364,
5
"alerts": [
6
{
7
"type": "warn",
8
"text": "Number of backends is greater than 40",
9
"value": "43",
10
"objname": "inventorydb",
11
"objlink": "https://app.pgdash.io/server/prod-42/db/inventorydb"
12
},
13
{
14
"type": "warn",
15
"text": "Max time taken by query is greater than 3 minutes",
16
"value": "4m",
17
"objname": "/*\"\"*/ select *, pg_",
18
"objlink": "https://app.pgdash.io/server/prod-42/alerts",
19
"query": "/*\"\"*/ select *, pg_sleep($) from testtable"
20
},
21
{
22
"type": "crit",
23
"text": "Database size is greater than 1 GiB",
24
"value": "1.4 GiB",
25
"objname": "inventorydb",
26
"objlink": "https://app.pgdash.io/server/prod-42/db/inventorydb"
27
}
28
]
29
}
Copied!
​
Request Body for Change Alerts:
- Webhook URLs set on the "Change Alerts" page will be invoked whenever changes between consecutive reports (as set by the change alert rules) are detected by pgDash.
- Notifications are sent whenever changes are detected. Each notification is independent, and there is no "state" as for the regular alerts.
- The request body is a JSON object with the following properties:
version- integer - the version of the JSON object's schema. Currently always 1. Note that backwards-compatible changes, like adding a new property might be done without incrementing this version number.server- string - the name of the server involved.prevreport- integer - the timestamp (as seconds since epoch 1 Jan 1970) of the previous report which was the basis for the change.currreport- integer - the timestamp (as seconds since epoch 1 Jan 1970) of the current report which has changed since the previous one.changes- array of objects - the list of changes. Each entry is a JSON object with the following properties:item- string - a description of the changeprev- string, optional - the previous value, if applicablecurr- string, optional - the current value, if applicable
Here is an example of the request body:
1
{
2
"version": 1,
3
"server": "prod-42",
4
"prevreport": 1567432246,
5
"currreport": 1567432291,
6
"changes": [
7
{
8
"item": "New Table Added",
9
"curr": "inventorydb.public.dispatch201909"
10
},
11
{
12
"item": "Size of Tablespace \"pg_default\" Changed",
13
"prev": "53 GiB",
14
"curr": "54 GiB"
15
}
16
]
17
}
Copied!
Last modified 2yr ago
Copy link
Contents