Send notifications to the Qisutu ticket system¶

Monitoring operates independently. For ticket integration, the appropriate Monitoring add-on must be installed separately in the Qisutu ticket system. It is not part of the monitoring package. The add-on must support connections of type Qisutu Monitoring and the associated event address.

Prepare the connection in Qisutu¶

In the Qisutu ticket system, open Administration → Monitoring.
Create a connection of type Qisutu Monitoring there.
Use the complete connection address and access key displayed by this connection.

The settings for ticket creation and processing are in the Qisutu add-on. No queue, ticket customer, SLA or CI association for ticket creation is selected in Qisutu Monitoring. Use the configuration of the separate add-on for this.

Store the connection in monitoring¶

Open Notifications → Qisutu ticket system.
Enable Send notifications to Qisutu.
Paste the complete HTTPS address into Connection address from the add-on. Copy the displayed event address; the ticket system’s general home address is not sufficient. The address ends in /v1/addons/qisutu.monitoring/events/ and the ID of the respective connection.
Enter the corresponding key in Access key. The key must belong to this exact Qisutu connection.
If Qisutu uses a certificate from an internal CA, add its PEM certificate under Custom CA certificate.
Click Test Qisutu connection.
After a successful test, click Save notification settings.

The test does not create a ticket. It checks whether Qisutu is reachable, the access key is valid, the connection is active and the system type matches Qisutu Monitoring. Ticket processing must then be checked using an actual state change.

Leaving the access key empty when editing retains a previously saved key. To delete it, enable Remove saved access key and save. A new key replaces the previous one when saving.

What is transmitted to Qisutu?¶

When a problem occurs, monitoring sends an event of type problem; after successful restoration, it sends an event of type recovery. The data transmitted includes the device name, check name, summary, details, time, severity and a persistent ID for the check. This allows the add-on to associate related events. The same ongoing problem is not sent again at every check interval.

Monitoring state	Transmitted event type	Severity
Outage, Critical, Check error	`problem`	`critical`
Warning, Missing measurements	`problem`	`warning`
Recovered	`recovery`	`info`

The Qisutu add-on determines automatic ticket creation, any suppression rules and recovery processing. Successful transmission means that the add-on has accepted the event. It does not necessarily mean a new ticket was created: The add-on may also ignore or suppress an event according to its own rules.