SkyWalking UI 深度探索：Alerts（告警系统）

原创于 2025-09-02 00:15:46 发布 · 1k 阅读

29 ·

CC 4.0 BY-SA版权

文章标签：

#skywalking #ui #告警系统 #学习

性能监控专栏收录该内容

82 篇文章

订阅专栏

SkyWalking 可观测性的主动防御体系 —— Alerts（告警）。

如果说前面的功能（Dashboard、Tracing、Logs）是“事后排查”，那么 Alerts 就是“事前预警”，帮助你实现 从“被动救火”到“主动防控” 的转变。

🔔 SkyWalking UI 深度探索：Alerts（告警系统）

📌 访问路径：UI → 左侧菜单 → “Alerts”

一、什么是 Alerts？

Alerts（告警） 是 SkyWalking 的自动化通知机制，当系统性能指标达到预设阈值时，自动触发告警并通知相关人员。

✅ 一句话：
“当服务响应时间 > 1秒持续 5 分钟，自动发钉钉/邮件告诉我。”

二、核心价值：让监控“活”起来

传统方式	SkyWalking Alerts
手动巡检 Dashboard	自动检测异常
问题发生后才发现	异常初现即告警
依赖人工经验	基于规则 + 数据驱动
通知分散	统一通过 Webhook、邮件等推送

✅ 适用场景：

接口响应时间突增
错误率飙升（如 > 5%）
服务实例宕机
JVM 内存使用率过高
数据库慢查询增多

三、告警数据从哪来？—— 告警源（Alert Sources）

SkyWalking 的告警基于 OAP 收集的实时指标数据，主要包括：

指标类型	示例
服务级指标	`service_resp_time`, `service_sla`
服务实例级指标	`instance_resp_time`, `instance_jvm_memory`
端点级指标	`endpoint_avg`, `endpoint_sla`
数据库指标	`database_access_resp_time`
消息队列指标	`mq_consume_resp_time`

⚙️ 这些指标由 Agent 上报，OAP 聚合后用于告警判断。

四、如何查看告警信息？—— Alerts 页面详解

进入 Alerts 页面，你会看到一个结构化的告警列表：

列名	说明
Alert Name	告警规则名称（如 `Service Response Time Too High`）
Service / Endpoint	触发告警的服务或接口
Severity	严重等级： • `CRITICAL`（严重） • `WARN`（警告） • `INFO`（提示）
Trigger Time	告警触发时间（精确到毫秒）
Message	告警详情（可包含动态变量，如 `{name}`, `{value}`）
Rule Name	对应的告警规则（在配置文件中定义）
Start Time	异常开始时间（可能早于触发时间）

✅ 示例告警：

Alert Name: High Error Rate
Service: order-service
Severity: CRITICAL
Trigger Time: 2025-04-05 11:23:45
Message: 服务错误率过高: order-service, 当前值: 8.7%
Rule: service_sla_rule

五、告警是如何触发的？—— 告警规则（Alert Rules）

告警规则定义在 SkyWalking OAP 的配置文件中，典型路径：

config/alarm-settings.yml

示例：服务响应时间告警规则

rules:
  # 服务响应时间过高
  service_resp_time_rule:
    metrics-name: service_resp_time
    op: ">"
    threshold: 1000  # 毫秒
    period: 10      # 连续 10 分钟
    count: 3        # 触发 3 次
    silence-period: 5
    message: 服务响应时间过长: {name}, 当前值: {value}ms

  # 服务错误率过高
  service_sla_rule:
    metrics-name: service_sla
    op: "<"
    threshold: 98.0  # SLA < 98%
    period: 10
    count: 3
    silence-period: 5
    message: 服务成功率下降: {name}, 当前值: {value}%

🔍 参数详解

参数	说明
`metrics-name`	监控的指标名称
`op`	比较操作符：`>`, `<`, `=`
`threshold`	阈值
`period`	统计周期（分钟）
`count`	连续多少个周期满足条件才触发
`silence-period`	告警触发后，相同问题的静默时间（分钟），避免重复通知
`message`	告警消息模板，支持 `{name}`, `{value}`, `{endpoint}` 等占位符

六、告警如何通知？—— Webhooks & Integrations

SkyWalking 支持多种通知方式，配置在 alarm-settings.yml 的 webhooks 或 email 部分。

1. 🌐 Webhook（最常用）

webhooks:
  - http://your-dingtalk-webhook
  - http://your-feishu-bot
  - https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx

✅ 示例：钉钉机器人消息

{
  "msgtype": "text",
  "text": {
    "content": "【SkyWalking 告警】\n服务: order-service\n错误率: 8.7%\n时间: 2025-04-05 11:23:45"
  }
}

2. 📧 Email（需 SMTP 配置）

email:
  smtp-host: smtp.example.com
  smtp-port: 587
  username: alert@example.com
  password: your-password
  from: alert@example.com
  to: devops@example.com, team-leader@example.com

3. 其他集成

Slack
PagerDuty
WeCom（企业微信）
Kafka（自定义消费）

七、实战：如何排查一个告警？

场景：

收到告警：“服务响应时间过长: payment-service, 当前值: 1200ms”

排查流程：

进入 Alerts 页面
- 查看告警详情，复制 service name 和 trigger time
跳转到 Dashboard
- 选择 payment-service
- 查看“过去 15 分钟”的 Response Time 趋势图
进入 Topology
- 查看 payment-service 的上下游
- 发现 payment → third-party-pay-api 的边变红
进入 Tracing
- 查询该时间段的慢请求
- 找到 Span：HTTP GET https://api.pay.com/v1/pay，耗时 1.1s
查看 Logs
- 按 traceId 查日志
- 发现 SocketTimeoutException
结论：

第三方支付接口响应慢，导致整体超时。
动作：
- 通知合作方优化
- 本地增加熔断策略

✅ 告警不是终点，而是排查的起点。

八、最佳实践

项目	建议
🎯 告警阈值	根据业务 SLA 设置，避免误报/漏报
📊 分层级告警	关键服务用 CRITICAL，非核心用 WARN
🔕 静默期	设置合理 `silence-period`，避免刷屏
🧩 结合运维流程	告警 → 工单系统 → 责任人
📅 定期回顾	每周 review 无效告警，优化规则