Alerts (Incidents) and Events (REST)

GET Alerts

Lists all alerts, fitting the filter criteria.

If no start and end date is specified, a default time frame of three days is selected.

GET AppMon 2017 May
https://<server>:8021/api/v2/alert


AppMon 2018 February
https://<server>:8021/api/v3/alerts
produces application/json

POST Alerts

Creates an alert (incident) for the specified System Profile and Incident Rule.

If the request does not contain a start and end date, the current server time will be used.

The default severity is informational and the default state is Created.

Alerts with informational severity are automatically set to the Confirmed state. You can set such alerts to other states with a subsequent update.

It is possible to specify the start date and leave the end date unset. The end date can then be provided later with an update.

At least three JSON properties: systemprofile, incidentrule, and message must specified.

POST AppMon 2017 May
https://<server>:8021/api/v2/alerts


AppMon 2018 February
https://<server>:8021/api/v3/alets
consumes application/json

PUT Alert

Updates an existing alert. You can user the GET Alert request first, then modify the required parameters of its response, or you can send several requests, modifying one property at time.

PUT AppMon 2017 May
https://<server>:8021/api/v2/alerts/<alert>


AppMon 2018 February
https://<server>:8021/api/v3/alerts/<alert>
consumes application/json

GET Alert

Inquires information about specified alert.

GET AppMon 2017 May
https://<server>:8021/api/v2/alerts/<alert>


AppMon 2018 February
https://<server>:8021/api/v3/alerts/<alert>
produces application/json

DELETE Alert

Deletes the specified alert.

DELETE AppMon 2017 May
https://<server>:8021/api/v2/alerts/<alert>


AppMon 2018 February
https://<server>:8021/api/v3/alerts/<alert>

GET Alert suppressions

Lists all existing alert suppressions (incident downtimes).

The response can optionally be filtered by a System Profile, an Incident Rule, or a combination of both.

GET AppMon 2017 May
https://<server>:8021/api/v2/alertsuppression


AppMon 2018 February
https://<server>:8021/api/v3/alertsuppression
produces application/json

PUT Alert suppression

Creates incident downtime with specified parameters. In such an incident downtime already exists, it will be overwritten.

You can either create a one-time suppression by setting the JSON property 'once' to 'true', or create a repeatedly scheduled suppression by providing either a Quartz cron expression or a reference to business hours defined in the self-monitoring System Profile.

Referencing business hours means the alert suppression will be active outside the defined business hours. Setting a duration will have no effect if business hours are referenced.

You can create a global alert suppression, which affects all existing and future System Profiles and Incident rules, by leaving System Profiles and Incident rules unspecified.

PUT AppMon 2017 May
https://<server>:8021/api/v2/alertsuppression/<suppression>


AppMon 2018 February
https://<server>:8021/api/v3/alertsuppression/<suppression>
consumes application/json

GET Alert suppression

Inquires information about the specified incident downtime.

GET AppMon 2017 May
https://<server>:8021/api/v2/alertsuppression/<suppression>


AppMon 2018 February
https://<server>:8021/api/v3/alertsuppression/<suppression>
consumes application/json

DELETE Alert suppression

Deletes the specified incident downtime.

DELETE AppMon 2017 May
https://<server>:8021/api/v2/alertsuppression/<suppression>


AppMon 2018 February
https://<server>:8021/api/v3/alertsuppression/<suppression>

POST Deployment event

Creates a deployment event for the specified System Profile.

If the request does not contain a start and end date, the current server time will be used.

The default severity is informational and the default state is Created. Events with a severity of informational are automatically set to state Confirmed. You can set such events to other states with a subsequent update.

It is possible to specify the start date and leave the end date unset, the end date can then be provided later with an update.

The systemprofile and message properties are must, the rest is optional.

You can find the ID of the new event in the location header.

POST AppMon 2017 May
https://<server>:8021/api/v2/events/Deployment


AppMon 2018 February
https://<server>:8021/api/v3/events/Deployment
consumes application/json

PUT Deployment event

Updates an existing deployment event. You can user the GET Alert request first, then modify the required parameters of its response, or you can send several requests, modifying one property at time.

PUT AppMon 2017 May
https://<server>:8021/api/v2/events/Deployment/<deploymentEvent>


AppMon 2018 February
https://<server>:8021/api/v3/events/Deployment/<deploymentEvent>
consumes application/json

GET Deployment event

Inquires information about specified deployment event.

GET AppMon 2017 May
https://<server>:8021/api/v2/events/Deployment/<deploymentEvent>


AppMon 2018 February
https://<server>:8021/api/v3/events/Deployment/<deploymentEvent>
consumes application/json

DELETE Deployment event

Deletes the specified deployment event.

DELETE AppMon 2017 May
https://<server>:8021/api/v2/events/Deployment/<deploymentEvent>


AppMon 2018 February
https://<server>:8021/api/v3/events/Deployment/<deploymentEvent>