什么是 告警？

告警是一个技术框架，旨在解决现代 AI 代理生态系统监控的复杂性。它通过将症状归类到根本原因下，并实施从 P0 到 P3 的严谨严重性层级，提供了防止告警疲劳的标准模式。利用 Openclaw Skills，开发人员可以超越简单的阈值监控，实现复杂的行为漂移检测和成本感知告警。

该技能通过监控死循环、静默失败和 API 使用激增，确保您的代理工作流保持稳定。它弥合了原始代理日志与可操作工程情报之间的鸿沟，确保通过高可靠性的 Webhook 模式在正确的时间通知正确的领域专家。

下载入口:https://github.com/openclaw/skills/tree/main/skills/ivangdavila/alerts

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

告警 应用场景

• 将数百个独立的 Pod 故障去重为单个服务级告警。
• 监控 AI 代理的 Token 消耗和成本，防止意外的账单激增。
• 检测 LLM 响应中的行为漂移和质量下降。
• 自动化事件升级路径，确保 P0 问题通过短信或电话送达值班工程师。
• 直接在 Slack 或 PagerDuty 通知中提供操作手册（Runbooks）的即时访问。

1. 告警被摄取并按服务或集群等逻辑标签分组，以防止通知风暴。
2. 应用严重性层级以确定通知渠道和所需的响应时间。
3. AI 特定监控器跟踪 Token 速率、关联 ID 和响应成功率。
4. 路由逻辑将事件定向到特定的专业领域（例如数据库或 API 团队），而非通用的排班表。
5. 自动化修复触发器尝试解决已知问题，同时通过 Webhook 更新状态页面。

告警 配置指南

要在您的 Openclaw Skills 环境中实施这些模式，请使用以下结构配置您的告警管理器：

# 配置分组和重复间隔
group_by: ['alertname', 'service']
repeat_interval: 5m

# 设置 Webhook 验证
export WEBHOOK_SECRET="your_hmac_secret"

确保您的代理监控逻辑包括行为基线以及为每个工作流生命周期生成的关联 ID。

告警 数据架构与分类体系

name: Alerts
description: Smart alerting patterns for AI agents - deduplication, routing, escalation, and fatigue prevention

Alert Fatigue Prevention

Group alerts by root cause, never by individual symptoms. Use labels: alertname, service, cluster - not instance IDs.

# Good: One alert for database down affecting 50 pods
group_by: ['alertname', 'service']
# Bad: 50 individual alerts for each failed pod

Implement severity hierarchy: P0 (pages immediately) > P1 (within 15min) > P2 (business hours) > P3 (weekly review). P0: Service completely down, data loss, security breach. P1: Degraded performance, partial outage, high error rates.

Set cooldown periods to prevent alert spam. Minimum 5 minutes between identical alerts, 30 minutes for cost alerts.

repeat_interval: 5m  # For critical alerts
repeat_interval: 30m # For cost/performance alerts

Use inhibition rules to suppress symptoms when root cause fires. If "Database Unreachable" fires, silence all "API High Latency" alerts from same cluster.

AI Agent Monitoring Patterns

Monitor token/API usage with exponential alerting thresholds. Alert at 2x, 5x, 10x normal usage - costs can spiral quickly. Track: tokens per minute, cost per request, API rate limits approached.

Set behavioral drift alerts on response quality degradation. Compare current outputs to baseline with sample prompts every hour. Alert when success rate drops below 85% or response time exceeds 2x baseline.

Monitor for infinite loops in multi-agent workflows. Alert if same prompt sent >3 times in 5 minutes or agent hasn't responded in 10 minutes. Include correlation IDs to trace conversation chains.

Track silent failures through downstream metrics. Monitor: tasks completed vs started, user satisfaction scores, retry attempts. These catch errors that don't throw exceptions.

Routing and Escalation Rules

Route by expertise domain, not arbitrary on-call schedules. Database alerts → DB team, API alerts → backend team, cost alerts → platform team. Only escalate to managers for P0 incidents lasting >30 minutes.

Use progressive escalation with increasing urgency. P1 alerts: Slack notification → 5min wait → SMS → 10min wait → phone call. Include runbook links in every alert for faster resolution.

Set context-aware routing based on time and impact. Business hours: Route to primary team. Off-hours: Route to on-call only for P0/P1. If >100 users affected: Immediately escalate regardless of severity.

Webhook Reliability Patterns

Always include correlation IDs for alert lifecycle management. Generate UUID for each incident, use it to create/update/resolve alerts. Essential for bi-directional integrations with PagerDuty/Slack.

Implement exponential backoff for webhook failures. Retry after 1s, 2s, 4s, 8s, 16s, then mark failed and escalate. Log webhook response codes/times for debugging delivery issues.

Use webhook verification to prevent spoofing. Validate signatures using HMAC-SHA256 with shared secret. Always check timestamp to prevent replay attacks (max 5 min old).

Implement circuit breaker pattern for unreliable endpoints. After 5 consecutive failures, mark endpoint down and use backup channel. Re-test every 30 seconds until recovery confirmed.

Status Page Integration

Update status page automatically when P0/P1 alerts fire. Create incident, post initial assessment within 5 minutes. Include ETA and workaround if available.

Use component-based status updates matching your alert groups. Map alert labels to status page components (API, Database, Auth, etc.). Partial outages should show "Degraded Performance", not "Operational".

Runbook Automation

Embed runbook links directly in alert messages. Format: "Alert: High CPU on web-01. Runbook: https://wiki/runbooks/high-cpu-web" Links must be accessible from mobile devices for on-call engineers.

Trigger automated remediation for known issues. Auto-restart stuck services, clear full disks, reset rate limits. Always require human approval for destructive actions (scaling down, deleting data).

Log all automated actions taken in response to alerts. Include: timestamp, action, result, approval chain. Essential for post-incident reviews and compliance audits.