Xitoring

Overview

This document provides a detailed guide to integrating Xitoring with Callgoose SQIBS for real-time Incident Management, Incident Auto Remediation, and Event-Driven Automation.

This integration enables automatic creation, updating, and resolution of incidents in Callgoose SQIBS based on alert notifications generated in Xitoring. The guide covers configuring Xitoring’s Webhook Notification Role, understanding its JSON payload structure, creating API Filters in Callgoose SQIBS, testing the integration, and troubleshooting.

Prerequisites

• Xitoring Account: Access with permissions to manage Notification Roles and assign them to servers or checks.
• Callgoose SQIBS Account: Permissions to create API filters and manage integration endpoints.
• Webhook/API Endpoint: Generated in Callgoose SQIBS.
• API Token: From Callgoose SQIBS.

1. Obtain API Token and Endpoint Details

To integrate with Callgoose SQIBS, first obtain an API token and endpoint URL.

1.1 Generate an API Token

Create an API token inside Callgoose SQIBS. Store the token securely. It will be used as part of the webhook URL.

1.2 Find the API Endpoint

Your Callgoose SQIBS API endpoint will follow the pattern:

https://****.callgoose.com/v1/process?from=Xitoring&token=xxxx

Ensure the from parameter is set to Xitoring to easily identify events in logs.

2. Configuring Xitoring to Send Alerts

Xitoring uses Notification Roles to send webhook notifications when an alert is triggered. You will configure such a role to POST JSON payloads to the Callgoose endpoint.

2.1 Access Xitoring

Log in to your Xitoring dashboard with appropriate administrative permissions.

2.2 Create a Webhook Notification Role

Inside Xitoring:

• Navigate to Notification Roles.
• Click Create Notification Role or edit an existing one.
• Set Notification Method to Webhook.
• In the Webhook URL field, enter your Callgoose endpoint:

https://****.callgoose.com/v1/process?from=Xitoring&token=xxxx

• Select the Notification Role recipients and applicable servers or checks.
• Click Send Test Notification to verify connectivity.
• Save the role.

2.3 Xitoring Webhook Delivery Behavior

Xitoring sends a JSON body via POST for each alert event. This payload contains information about the affected check, its numeric type, status, values, timestamps, and human-readable type.

When an alert recovers, a new payload is sent with the updated status representing the recovered state.

3. Example JSON Payloads From Xitoring

The following payload structures are taken directly from Xitoring’s webhook format.

3.1 Triggered Alert Payload

{
 "id": 132,
 "group": "server",
 "sub_group": "service",
 "server_id": 55,
 "check_id": 335,
 "label": "Mysql",
 "name": "Mysql",
 "type": 33,
 "type_human_readable": "MySQL",
 "unit": "%",
 "value": 50.55,
 "status": 2,
 "incident_time": "2023-09-12 06:14:25"
}

3.2 Resolved Alert Payload

{
 "id": 132,
 "group": "server",
 "sub_group": "service",
 "server_id": 55,
 "check_id": 335,
 "label": "Mysql",
 "name": "Mysql",
 "type": 33,
 "type_human_readable": "MySQL",
 "unit": "%",
 "value": 10.20,
 "status": 0,
 "incident_time": "2023-09-12 06:20:10"
}

• Status Mapping (per Xitoring documentation)
• 0 = OK
• 1 = WARNING
• 2 = CRITICAL
• 3 = UNKNOWN

These values will be used for filter matching in Callgoose.

4. Configuring Callgoose SQIBS

4.1 Create API Filters

API Filters transform incoming Xitoring webhook payloads into incidents. Two filters are required: Trigger and Resolve.

4.1.1 Trigger Filter (For Creating Incidents)

• Payload JSON Key: "status"
• Key Value Contains: [1, 2, 3] (WARNING, CRITICAL, UNKNOWN)
• Map Incident With: "check_id"
• Incident Title: "name"
• Incident Description: Leave empty to include entire payload.

This ensures alerts from the same check are grouped consistently.

4.1.2 Resolve Filter (For Resolving Incidents)

• Payload JSON Key: "status"
• Key Value Contains: [0]
• Incident Mapped With: "check_id"

This ensures that recovery events close the correct incident. Refer to the API Filter Instructions and FAQ for more details.

5. Testing & Validation

5.1 Triggering Alerts in Xitoring

• Adjust a monitored service or threshold to force a WARNING/CRITICAL condition, or use Send Test Notification.
• Confirm that:
• Xitoring logs show a successful webhook delivery.
• Callgoose API logs display the incoming JSON payload.
• A new incident is created automatically.

5.2 Resolving Alerts

• Restore the original condition or metric.
• Xitoring will send a payload with status = 0.
• Confirm that the associated incident in Callgoose resolves automatically.

6. Debugging & Troubleshooting

Common issues and corrective actions:

• No incident created
• Incorrect webhook URL
• Trigger filter not matching status values
• API token missing or invalid
• Payload structure mismatch in filter settings
• Incident not resolving
• Resolve filter expects status 0 but payload differs
• check_id mismatch between Trigger and Resolve events
• Malformed JSON
• Rare in Xitoring, but ensure Callgoose logs show valid JSON
• Authentication errors
• Token mismatch or malformed query parameter

7. Security Considerations

• Keep your Callgoose API token confidential.
• Always use HTTPS endpoints.
• Rotate API tokens periodically.
• Restrict webhook sources if possible.

8. Conclusion

By completing the steps above, you can integrate Xitoring with Callgoose SQIBS for seamless incident creation, event-driven workflows, and automated resolution. This allows Operations and DevOps teams to maintain real-time observability and rapid response capabilities.

For additional customization or advanced use cases, refer to the documentation of both Xitoring and Callgoose SQIBS.

For further customization or advanced use cases, refer to the official documentation for both Xitoring and Callgoose SQIBS:

• Xitoring Documentation
• Callgoose SQIBS API Token Documentation
• Callgoose SQIBS API Endpoint Documentation
• API Filter Instructions and FAQ
• How to Send API