PingPlotter

Overview

This document provides a complete guide to integrating PingPlotter with Callgoose SQIBS using PingPlotter’s Execute REST Call alert action. Because PingPlotter handles alert states individually, we will configure two separate alert actions: one to open an incident when network issues begin, and another to resolve it when stability returns.

Prerequisites

• A PingPlotter Desktop or Cloud account.
• A Callgoose SQIBS API token with required permissions.
• A configured Callgoose webhook endpoint to receive POST requests.

1. Obtain Callgoose API Credentials

• Generate an API token inside Callgoose SQIBS.
• Copy the Callgoose webhook endpoint provided inside your workspace.
• Note: Keep this URL handy, as you will use it for both the Trigger and Resolve actions in PingPlotter.

2. Configure PingPlotter Alert Actions

In PingPlotter, you must create the alert logic first, and then add the specific REST actions.

2.1 Create the Alert Condition

• Open PingPlotter and select the target you wish to monitor.
• Go to Alerts and create a New Alert.
• Define your conditions (e.g., Latency > 200ms for 10 samples).

2.2 Add the "Trigger" Action (Creates Incident)

This action sends a signal to Callgoose when the problem starts.

• In the Alert Editor, find Event 1.
• Set the Event type to: When conditions start.
• Action Type: Select Execute REST Call.
• Method: POST
• Address: Paste your Callgoose Webhook URL.
• Content Type: application/json
• Body: Paste the Trigger JSON below.

2.2.1 Trigger JSON Template

JSON

{
  "source": "pingplotter",
  "event_state": "Started",
  "alert_name": "{{AlertName}}",
  "description": "Alert triggered for target: {{Host.HostName}}. Check PingPlotter for detailed metrics.",
  "agent": "{{AgentName}}",
  "target": "{{Host.HostName}}",
  "start_time": "{{UtcNow}}"
}

2.3 Add the "Resolve" Action (Closes Incident)

This action sends a signal to Callgoose when the problem ends.

1. Click Add Action (or create Event 2).
2. Set the Event type to: When conditions end.
3. Action Type: Select Execute REST Call.
4. Method: POST
5. Address: Paste your Callgoose Webhook URL.
6. Content Type: application/json
7. Body: Paste the Resolve JSON below.

2.3.1 Resolve JSON Template

JSON

{
  "source": "pingplotter",
  "event_state": "Ended",
  "alert_name": "{{AlertName}}",
  "description": "Target {{Host.HostName}} has returned to normal levels.",
  "agent": "{{AgentName}}",
  "target": "{{Host.HostName}}",
  "end_time": "{{UtcNow}}"
}

3. Example Payloads Sent to Callgoose

Use these examples to verify what data Callgoose receives after PingPlotter processes the variables. This is crucial for setting up your API Filters correctly.

3.1 Trigger Example (Alert Started)

Sent when the alert condition is met.

{
  "source": "pingplotter",
  "event_state": "Started",
  "alert_name": "High Latency to Google",
  "description": "Alert triggered for target: 8.8.8.8. Check PingPlotter for detailed metrics.",
  "agent": "Bangalore-HQ-Agent",
  "target": "8.8.8.8",
  "start_time": "2025-12-04T09:15:00Z"
}

3.2 Resolve Example (Alert Ended)

Sent when the target returns to normal.

{
  "source": "pingplotter",
  "event_state": "Ended",
  "alert_name": "High Latency to Google",
  "description": "Target 8.8.8.8 has returned to normal levels.",
  "agent": "Bangalore-HQ-Agent",
  "target": "8.8.8.8",
  "end_time": "2025-12-04T09:25:30Z"
}

4. Configure Callgoose API Filters

Now that PingPlotter is sending two distinct payloads, configure Callgoose to interpret them.

4.1 Trigger Filter (Create Incident)

• Payload JSON Key: "event_state"
• Key Value Contains: Started
• Incident Mapping Field: "target" (matches the {{Host.HostName}})
• Incident Title: "alert_name"
• Incident Description: "description"

4.2 Resolve Filter (Auto-Resolve Incident)

• Payload JSON Key: "event_state"
• Key Value Contains: Ended
• Incident Mapping Field: "target" (Must match the Trigger mapping field exactly to close the correct incident)

Refer to the API Filter Instructions and FAQ for more details.

5. Verification and Testing

• Force a Trigger: Temporarily lower your PingPlotter latency threshold (e.g., to 1ms) so the alert fires immediately.
• Check Callgoose: Verify a new incident is created with the status "Started" and the correct Target Name (e.g., "8.8.8.8").
• Force a Resolve: Set the threshold back to normal (e.g., 200ms).
• Check Callgoose: Verify the incident status changes to "Resolved" automatically.

6. Troubleshooting

• Incident Created but not Resolved
• Cause: The Mapping Field differs between the Trigger and Resolve filters.
• Fix: Ensure both filters map using the exact same field (e.g., target).
• Variable Tags visible in Incident (e.g., {{AlertName}})
• Cause: A typo in the variable syntax.
• Fix: Ensure you are using {{AlertName}} (no dot) and {{Host.HostName}}.
• "400 Bad Request" Error
• Cause: Invalid JSON format.
• Fix: Ensure there are no trailing commas in the JSON body and that all quotes are standard double quotes ("), not "curly" quotes.

7. Conclusion

Integrating PingPlotter with Callgoose SQIBS creates a robust, automated feedback loop for network performance monitoring. By configuring separate Start and End events, you ensure that Callgoose accurately reflects the real-time state of your endpoints—automatically opening incidents when latency spikes and closing them when stability is restored. This setup minimizes alert fatigue and accelerates response times for critical network outages.

For further customization or advanced use cases, refer to:

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