Motadata

Overview

This document provides a detailed guide to integrating Motadata 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 alerts generated from Motadata (NMS, AIOps, or ServiceOps). The guide includes steps for configuring Webhook/HTTP Request notifications in Motadata, defining JSON payloads, creating API filters in Callgoose SQIBS, and troubleshooting.

Prerequisites

• Motadata Account
• Access to Motadata NMS / AIOps / ServiceOps with Administrator privileges to configure Alert Actions, Webhooks, or Workflow Automations.
• Callgoose SQIBS Account
• Permissions to create API filters, manage services, and access API logs.
• Webhook/API Endpoint
• Generated in Callgoose SQIBS.
• API Token
• Created in 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

Follow the document How to Create API Token in Callgoose SQIBS.

Copy the generated token for later use.

1.2 Find the API Endpoint

Refer to Callgoose SQIBS API Endpoint Documentation.

Your endpoint will follow the format:

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

Note:

Ensure the from parameter is set to Motadata to easily identify logs in Callgoose.

2. Configuring Motadata to Send Alerts

Motadata supports outbound alert delivery through Webhook Alert (NMS) or Send HTTP Request actions (AIOps / ServiceOps). You will configure Motadata to POST JSON payloads directly to Callgoose SQIBS.

2.1 Access Motadata

• Log in to your Motadata platform (NMS / AIOps / ServiceOps).
• Ensure you have Administrator permissions to modify Alert Actions or Automation Workflows.

2.2 Create a Webhook / HTTP Request Notification

The steps are the same for both NMS (Webhook Alert) and ServiceOps/AIOps (Send HTTP Request).

Steps

1. Go to:

• NMS: Settings → Actions → Webhook Alert
• AIOps/ServiceOps: Automation → Workflow → Add Action → Send HTTP Request

1. Click Create New.
2. Configure the Webhook / Request:

• Name: Callgoose SQIBS Integration
• Type: Webhook / HTTP Request
• Method: POST
• URL: Your Callgoose Endpoint (from Step 1.2)
• Content-Type: application/json
• Authentication:
• Not required unless your Callgoose endpoint uses headers.

2.3 Define the JSON Payload Template

Motadata allows custom payload templates (variable fields differ per product).

Paste the following recommended JSON structure into the Body/Template field.

{
  "status": "${ALERT_STATUS}",
  "incident_key": "${DEVICE}-${RULE_NAME}",
  "rule_name": "${RULE_NAME}",
  "severity": "${SEVERITY}",
  "device": "${DEVICE}",
  "description": "Value: ${METRIC_VALUE}. Threshold: ${THRESHOLD}.",
  "url": "${ALERT_URL}",
  "timestamp": "${EVENT_TIME}"
}

2.4 Attach Notification to a Rule / Monitor

For NMS

• Navigate to Monitors / Alerts.
• Choose an existing Rule or create a new one.
• Scroll to Notifications / Actions.
• Select the Callgoose SQIBS Integration notification.
• Save the rule.

For AIOps / ServiceOps

• Open an Automation Workflow.
• Add an Action → Send HTTP Request.
• Attach the Callgoose Notification.
• Save the workflow.

2.5 Test the Webhook

• From the notification page, click Test (if available).
• Or trigger an alert manually by temporarily altering thresholds.
• Verify Callgoose receives the test alert in API Logs.

3. Example JSON Payloads From Motadata

Below examples show how payloads appear when sent to Callgoose SQIBS.

3.1 Triggered Alert Payload

{
  "status": "critical",
  "incident_key": "Server01-HighCPU",
  "rule_name": "HighCPU",
  "severity": "critical",
  "device": "Server01",
  "description": "Value: 95%. Threshold: 90%.",
  "url": "https://motadata.local/alerts/12345",
  "timestamp": "2025-01-10T12:30:00Z"
}

3.2 Resolved Alert Payload

{
  "status": "ok",
  "incident_key": "Server01-HighCPU",
  "rule_name": "HighCPU",
  "severity": "info",
  "device": "Server01",
  "description": "Value: 45%. Threshold: 90%.",
  "url": "https://motadata.local/alerts/12345",
  "timestamp": "2025-01-10T12:45:00Z"
}

4. Configuring Callgoose SQIBS

4.1 Create API Filters

API filters map incoming Motadata alert JSON fields to Callgoose incident fields.

4.1.1 Trigger Filter (For Creating Incidents)

• Payload JSON Key: status
• Key Value Contains: critical, warning, major (depending on Motadata setup)
• Map Incident With: incident_key
• Incident Title: rule_name
• Incident Description: description(or leave empty to receive full payload as description )

4.1.2 Resolve Filter (For Resolving Incidents)

• Payload JSON Key: status
• Key Value Contains: ok, cleared
• Incident Mapped With: incident_key

5. Testing & Validation

5.1 Triggering Alerts

• Lower the threshold in Motadata (e.g., reduce CPU threshold).
• Motadata sends a critical/major alert.
• A new incident should appear in Callgoose SQIBS.

5.2 Resolving Alerts

• Restore normal threshold or stop load.
• Motadata sends an ok status alert.
• The existing incident auto-resolves.

6. Debugging & Troubleshooting

Common Checks

• Enable Debug mode on the API token in Callgoose.
• Review API Logs in SQIBS.
• Check Motadata notification logs to verify:
• Payload was sent
• Correct URL used
• 200 OK received

7. Security Considerations

• Keep the API token private.
• Only use HTTPS endpoints.
• Rotate API tokens periodically.

8. Conclusion

By following this guide, you can integrate Motadata with Callgoose SQIBS for seamless incident creation, updates, and automated resolution. This ensures real-time visibility and proactive Incident Management across your monitoring and operations ecosystem.

For additional reference:

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