User Guide · Alerting

Automatically record and fire alerts when metrics go wrong.

---

Capabilities

Capability	Description
Threshold alerts	Fire when error rate, latency, throughput, etc. cross the line
Change detection	Catch sudden metric shifts
Scheduled evaluation	Runs every minute, looking back 5 minutes
Event records	Track trigger, recovery, handling (auto-resolved when metrics recover)
AI analysis	Ask for root cause directly from alert details

Evaluation mechanics: Architecture · Alerting.

---

Menu Paths

Feature	Path
Detection rules	Configuration → Alert Config
Alert list	Alert Center → Alert List

---

Workflow

1. Create a Detection Rule

Configuration → Alert Config → New Rule

Configurable fields:

• Scope: service or instance
• Metrics: error rate, avg latency, P99 latency, request count, etc.
• Condition: threshold (above/below) or change detection
• Severity: Info / Warning / Critical
• Evaluation: follows platform default (every minute)

2. View and Handle Alerts

Alert Center → Alert List

Filter by service, severity, status. Click an alert for details:

• Abnormal metric trends
• Related traces and logs
• (Optional) AI root cause analysis, or Alert Center → Manual Root Cause Analysis for a time-range investigation
• Handling log

Alerts auto-resolve when metrics recover.

Configuration Example

Example: fire when order-service error rate stays above 5% for 5 minutes. Create it under Configuration → Alert Config → New Rule:

Field	Value	Meaning
Rule name	order-service error rate too high	How the row is labeled in the alert list
Scope	order-service	Service (or an instance) to evaluate
Metric	Error rate (error_rate / service.error.pct)	Percent, not a 0–1 fraction
Condition	Threshold, greater than (gt)	Or less-than / change detection
Threshold	5	5%
Lookback	300 seconds	Each run uses the last 5 minutes; the job itself runs every minute
Severity	Critical (critical)	Info / Warning also exist
Enabled	yes	Disabled rules are not evaluated

Equivalent YAML:

ruleName: order-service error rate too high
enabled: true
service: order-service
metric: error_rate
detectionWay: threshold
comparator: gt
threshold: 5
period: 300          # seconds, last 5 minutes
level: critical

Matching evaluation JSON (the block stored in queryJson):

{
  "1": {
    "way": "threshold",
    "period": 300,
    "view_unit": "%",
    "thresholds": { "critical": 5 },
    "A": { "metric": "service.error.pct", "from": [] }
  }
}

After you save and enable it, evaluation checks the last 5 minutes every minute. When the rate is above 5%, a row shows up under Alert Center → Alert List, with a description like "error rate 12% exceeded threshold 5%", status open. Open it for metric trend, related traces and logs. When the metric recovers the row is marked resolved. Trigger records for that alert sit in the event list on the detail page.

---

Working with AI

From alert details or AI Platform:

"order-service error rate alert — help me analyze the cause"

AI queries metrics, traces, and topology automatically. For Agent integration, use MCP tool queryServiceAlarms — see Agent Integration.

---

FAQ

Symptom	Action
No alerts after creating rules	Ensure services have metrics; evaluation runs every minute; verify rule scope (see Docker / K8s ops troubleshooting)
No alerts after Demo install	Create and enable a detection rule first; install demo app for traffic; wait 1–2 evaluation cycles
Too many alerts	Tune thresholds or narrow the monitoring scope

Alert Notification Channel (Webhook)

DataBuff provides a Webhook notification channel to push real-time system alerts and alarms to your custom HTTP endpoints. When an alarm event is triggered, the system automatically sends an HTTP POST request containing alert details in JSON format.

Configuration Parameters

To set up the alert notification channel, the following parameters are used within the configuration map:

Parameter Key	Type	Description	Default
webhookUrl	String	The target HTTP/HTTPS URL where the JSON alert payload will be sent.	"" (Empty)
enabled	Boolean	Toggles the notification channel system. Set to true to activate.	false

Webhook Payload Format

The notification system transmits payloads with the header Content-Type: application/json. The timeout for connection is configured at 3 seconds, with a maximum request timeout of 5 seconds.

Supported Properties

The JSON payload contains the following alert fields:

• alarmId (String): The unique identifier of the triggered alarm.
• service (String): The name of the service or component generating the alert.
• status (String): The current state of the alarm (e.g., triggered, resolved).
• message (String): A detailed text description of the alarm event.

JSON Example

Below is an example of the JSON payload sent by the DataBuff system to your webhook endpoint:

{
  "alarmId": "ALARM-2026-0091",
  "service": "auth-service-vm",
  "status": "CRITICAL",
  "message": "Memory usage exceeded 92% on instance node-01."
}