1. 监控告警系统升级背景

去年我们团队遇到一个棘手问题：某次凌晨3点的核心服务宕机，直到早上9点上班才发现，直接导致6小时业务中断。事后复盘发现，传统的邮件+短信告警存在明显缺陷——邮件容易被忽略，短信成本高且容易被当成垃圾信息。这促使我们开始寻找更高效的监控告警方案。

经过多方对比测试，最终选择了Prometheus+飞书机器人的组合。这套系统运行一年来，累计处理告警事件2371次，平均响应时间从原来的47分钟缩短到2.3分钟，年节省运维成本约2万美元。下面分享具体实现方案和踩坑经验。

2. 技术架构设计解析

2.1 核心组件选型

Prometheus作为监控系统核心，主要考虑以下优势：

• 多维数据模型（metric名称+键值对）
• 强大的PromQL查询语言
• 不依赖分布式存储，单个节点自治
• 通过HTTP拉取（pull）模式采集数据
• 支持服务发现和动态配置

飞书机器人作为告警接收端，相比传统方式有三大突破：

1. 消息必达：强提醒功能确保不被遗漏
2. 交互闭环：直接在消息中处理告警
3. 成本优势：相比短信费用几乎为零

2.2 系统架构图

+---------------------+ | 应用系统 | +----------+----------+ | +-------------+ +-------------v----------+ +-------------------+ | Prometheus <--------+ Service Discovery | | Alertmanager | +------+------+ +------------------------+ +---------+---------+ | | | | +------v------+ +------v---------+ | TSDB | | 飞书Webhook | +-------------+ +----------------+

3. 关键实现步骤

3.1 Prometheus基础配置

首先配置监控目标，建议采用文件服务发现方式：

# prometheus.yml scrape_configs: - job_name: 'node_exporter' file_sd_configs: - files: ['/etc/prometheus/targets/*.json']

对应的targets文件示例：

[ { "targets": ["10.0.0.1:9100"], "labels": { "env": "prod", "app": "payment-service" } } ]

重要提示：label设计要遵循"业务线-环境-服务"三级结构，这对后续告警路由至关重要

3.2 告警规则配置

根据业务特点，我们制定了分级告警策略：

groups: - name: critical-alerts rules: - alert: HighErrorRate expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.1 for: 2m labels: severity: critical annotations: summary: "High error rate on {{ $labels.instance }}" description: "Error rate is {{ $value }}" - name: warning-alerts rules: - alert: MemoryHigh expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.8 for: 10m labels: severity: warning

3.3 飞书机器人对接

创建自定义机器人后，配置Alertmanager：

route: receiver: 'feishu-webhook' group_by: ['alertname'] group_wait: 10s group_interval: 5m receivers: - name: 'feishu-webhook' webhook_configs: - url: 'https://open.feishu.cn/open-apis/bot/v2/hook/your-token' send_resolved: true

4. 告警闭环设计

4.1 消息卡片模板

我们开发了交互式消息卡片，包含：

• 当前告警状态（颜色标识）
• 影响范围说明
• 最近1小时指标趋势图
• 处理按钮（已解决/误报/转派）

{ "msg_type": "interactive", "card": { "elements": [{ "tag": "div", "text": { "content": "**告警名称**: {{.CommonLabels.alertname}}", "tag": "lark_md" } }], "header": { "title": { "content": "[{{.Status}}] 生产告警通知", "tag": "plain_text" } } } }

4.2 处理状态同步

通过飞书开放API实现状态回写：

def handle_alert_action(action): if action == "resolve": requests.post(alertmanager_api, json={ "status": "resolved", "fingerprint": alert_fp }) elif action == "false_positive": store_in_suppression_db(alert_fp)

5. 成本优化实践

5.1 消息频率控制

通过以下策略降低消息风暴风险：

1. 告警分组（group_by）
2. 抑制规则（inhibit_rules）
3. 静默配置（silence）

inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' equal: ['alertname']

5.2 资源消耗对比

6. 典型问题排查

6.1 消息延迟问题

曾遇到飞书消息延迟达15分钟的情况，排查发现：

1. Alertmanager默认resend_interval=1h
2. 飞书API限流100次/分钟

解决方案：

route: repeat_interval: 5m group_interval: 1m

6.2 指标断点问题

当Prometheus抓取目标失败时，建议配置告警：

- alert: ScrapeFailed expr: up == 0 for: 1m labels: severity: critical

7. 运维经验总结

1. 标签设计规范

   • 每个服务必须有env/app/instance标签
   • 避免使用特殊字符（如. /）

2. 告警分级策略

   • Critical：影响核心业务流程
   • Warning：需要关注但可延迟处理
   • Info：仅记录无需立即响应

3. 飞书消息优化

   • 使用Markdown格式提升可读性
   • 关键指标附加趋势图
   • 添加直接跳转Grafana的链接

这套系统稳定运行后，我们的运维效率提升了6倍。最大的收获是建立了完整的监控-告警-处理-复盘闭环，现在任何异常都能在5分钟内响应。对于中小团队，这套方案既能保证效果又极大降低了成本。