Integrations
pgDash
Overview
This document provides a guide to integrating pgDash with Callgoose SQIBS. This integration allows pgDash to POST alert events to Callgoose via webhook. Callgoose API Filters will then ingest these fixed payloads to automatically create and resolve incidents.
Prerequisites
- pgDash: Admin access to configure Integrations and Alert Rules.
- Callgoose SQIBS: Permission to create API Tokens and API Filters.
- Connectivity: Ensure pgDash servers can make outbound HTTPS POST requests to the Callgoose API endpoint.
1. Obtain API Token and Endpoint
1.1 Generate an API Token
- Log in to Callgoose SQIBS.
- Generate a new API Token.
- Store this token securely.
1.2 Construct the Webhook URL
Your Endpoint URL will typically look like this: https://****.callgoose.com/v1/process?from=FromValue&token=xxxx
Find your endpoint here Api Endpoint.
Note: If you cannot pass the token in the URL, you will need to add it as a header in pgDash.
2. Configuring pgDash
2.1 Create the Webhook Integration
- Log in to pgDash and navigate to Alerting or Integrations.
- Select Add Integration > Webhook.
- Name: Enter Callgoose SQIBS.
- URL: Enter the Callgoose Webhook URL from Section 1.2.
- Headers (Optional): If token is not in the URL, add header Authorization: Bearer <TOKEN>.
- Save the integration.
2.2 Attach to Alert Rules
- Go to Alert Rules.
- Edit a rule (e.g., High Replication Lag).
- In Notification Channels, select the "Callgoose SQIBS" webhook.
- Save the rule.
3. Standard pgDash Webhook Payloads
pgDash sends a fixed JSON structure. Your Callgoose filters must match these fields.
3.1 Trigger Event Example
{
"type": "alert",
"action": "trigger",
"text": "Replication Lag is high on host-01",
"alert_rule": { "id": 12345, "name": "High Replication Lag" },
"server": { "name": "prod-db-01" }
}
3.2 Resolve Event Example
{
"type": "alert",
"action": "resolve",
"text": "Replication Lag is back to normal",
"alert_rule": { "id": 12345, "name": "High Replication Lag" }
}
4. Configuring Callgoose SQIBS Filters
Map the pgDash fields to Callgoose attributes to handle incident lifecycle.
4.1 Trigger Filter
- Payload JSON Key: "action"
- Key Value Contains: trigger
- Map Incident With: "alert_rule"."id" (this allows correlation between create and resolve)
- Incident Title From: "alert_rule"."name"
- Incident Description From: "text" (or leave empty to store full JSON)
4.2 Resolve Filter
- Payload JSON Key: "status"
- Key Value Contains: resolved (or OK depending on your payload)
- Incident Mapped With: "alert_rule"."id"
This ensures that incidents are resolved automatically when Mera Monitor sends a resolve event. Refer to the API Filter Instructions and FAQ for more details.
5. Testing & Validation
- Send Test: In pgDash Webhook settings, click Send Sample. Verify 200 OK in Callgoose logs.
- Trigger Alert: Simulate a threshold breach. Confirm a new incident appears in Callgoose with the correct Title and ID.
- Resolve Alert: Revert the breach. Confirm the Callgoose incident status changes to Resolved.
6. Quick Troubleshooting
- No Incident Created? Check if the Webhook URL includes the correct API Token and that the Trigger Filter matches action: trigger.
- Duplicate Incidents? Ensure Unique ID is mapped to alert_rule.id, not a timestamp.
- Not Auto-Resolving? Verify the Resolve Filter matches action: resolve and uses the same alert_rule.id as the Trigger Filter.
7. Conclusion
By following this guide, you have successfully integrated pgDash with Callgoose SQIBS. This setup ensures that critical PostgreSQL alerts—such as replication lag, high connection counts, or slow queries—are instantly converted into actionable incidents. With the automated trigger and resolve logic in place, your team can reduce manual monitoring noise and focus on resolving database issues faster.
For further customization or advanced use cases, refer to the official documentation for both pgDash and Callgoose SQIBS:
