Day 034｜做一个最小 Agent 面板：用户需要看见进度和结果
2026/8/11 2:46:17
1. 项目概述：企业级监控告警系统搭建实战
去年接手公司运维体系改造时，我面临一个典型的中型企业监控困境：20+物理服务器、50+容器实例分散在多个机房，传统的Zabbix监控体系存在配置复杂、可视化单一的问题，尤其缺乏对容器化环境的原生支持。经过技术选型，最终采用Grafana+Prometheus+cAdvisor+node_exporter的技术栈，配合飞书机器人实现了分钟级告警响应。这套方案在三个月内将故障平均发现时间从47分钟缩短到3.2分钟，今天就把完整实现过程拆解给大家。
这套监控系统的核心价值在于：
- 全栈监控：覆盖主机性能、容器指标、应用埋点等不同维度数据
- 实时可视化：Grafana强大的仪表板功能支持多维度数据关联分析
- 智能告警：基于PromQL的灵活告警规则配置，结合飞书实现分级通知
- 低资源消耗：相比传统方案，整体资源占用降低60%以上
2. 核心组件选型与架构设计
2.1 技术栈深度解析
Prometheus作为时序数据库核心，其拉取模式(pull-based)设计特别适合动态变化的云环境。我选择它的核心原因是其多维数据模型和强大的PromQL查询语言——比如统计容器CPU使用率时可以用：
sum(rate(container_cpu_usage_seconds_total{image!=""}[1m])) by (pod_name)Grafana的选型考量是其丰富的可视化插件生态。实际使用中发现其"Variables"功能特别实用，可以创建动态仪表板。例如定义一个$host变量后，所有面板都能联动筛选。
cAdvisor是Google开源的容器监控工具，自动采集CPU、内存、网络等指标。它在Kubernetes环境中会以DaemonSet形式运行，对每个节点的容器进行监控。
node_exporter的部署需要注意版本匹配问题。曾踩过坑：v1.3.0版本在CentOS 6上会出现内存泄漏，后来锁定使用v1.1.0稳定版。
2.2 架构拓扑设计
生产环境推荐的分层部署方案：
[ 数据采集层 ] ├─ node_exporter (主机指标) ├─ cAdvisor (容器指标) └─ 业务埋点 (自定义指标) [ 数据处理层 ] └─ Prometheus Server ├─ 主实例 └─ 备用实例(配置相同) [ 展示告警层 ] ├─ Grafana (可视化) └─ Alertmanager (告警路由)关键设计要点：
- Prometheus采用分片(sharding)策略，按业务域划分不同实例
- 所有配置采用Terraform代码化管理
- 飞书机器人通过webhook接入Alertmanager
3. 详细部署实施指南
3.1 基础环境准备
以CentOS 7为例的准备工作：
# 关闭SELinux和防火墙 setenforce 0 sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config systemctl stop firewalld && systemctl disable firewalld # 创建专用用户 useradd -M -s /sbin/nologin prometheus useradd -M -s /sbin/nologin grafana3.2 Prometheus部署
二进制安装方式（推荐生产环境使用）：
VERSION=2.37.0 wget https://github.com/prometheus/prometheus/releases/download/v${VERSION}/prometheus-${VERSION}.linux-amd64.tar.gz tar xvf prometheus-*.tar.gz mv prometheus-* /usr/local/prometheus配置示例（/usr/local/prometheus/prometheus.yml）：
global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'node' static_configs: - targets: ['192.168.1.10:9100', '192.168.1.11:9100'] - job_name: 'cadvisor' static_configs: - targets: ['192.168.1.10:8080', '192.168.1.11:8080']重要提示：生产环境建议配置scrape_timeout为10s，避免慢响应目标阻塞采集
3.3 Grafana配置技巧
安装后必做的优化设置：
- 修改默认配置文件(/etc/grafana/grafana.ini):
[security] allow_embedding = true [auth.anonymous] enabled = true org_role = Viewer- 导入官方仪表板模板：
- Node Exporter Full：ID 1860
- Docker and system monitoring：ID 893
- 配置Prometheus数据源时，建议开启"Manage alerts via Alertmanager"选项
3.4 飞书告警集成方案
Alertmanager配置关键点（alertmanager.yml）：
route: group_by: ['alertname'] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: 'feishu-webhook' receivers: - name: 'feishu-webhook' webhook_configs: - url: 'https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_TOKEN' send_resolved: true飞书机器人消息模板示例：
{ "msg_type": "interactive", "card": { "elements": [{ "tag": "div", "text": { "content": "**[[{{ .Status | title }}]]**\n\n{{ .CommonAnnotations.summary }}", "tag": "lark_md" } }], "header": { "title": { "content": "[{{ .Labels.severity }}] {{ .Labels.alertname }}", "tag": "plain_text" } } } }4. 高级配置与优化策略
4.1 PromQL实战技巧
- 计算CPU使用率推荐公式：
(1 - avg(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance)) * 100- 内存使用率避免的误区：
# 错误写法（未考虑缓存） (node_memory_MemTotal_bytes - node_memory_MemFree_bytes) / node_memory_MemTotal_bytes * 100 # 正确写法 (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100- 容器内存限制检测（OOM预警）：
sum(container_memory_working_set_bytes{name!=""}) by (pod) / sum(container_spec_memory_limit_bytes{name!=""}) by (pod) > 0.84.2 告警规则最佳实践
生产环境必备的告警规则示例：
groups: - name: host.rules rules: - alert: HostHighCpuLoad expr: (1 - avg(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance)) * 100 > 80 for: 5m labels: severity: warning annotations: summary: "高CPU负载 (instance {{ $labels.instance }})" description: "CPU使用率持续高于80% (当前值: {{ $value }}%)" - alert: HostOutOfMemory expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 10 for: 3m labels: severity: critical annotations: summary: "内存不足 (instance {{ $labels.instance }})"4.3 性能调优经验
- Prometheus存储优化：
# 启动参数调整 --storage.tsdb.retention.time=30d --storage.tsdb.max-block-duration=2h --storage.tsdb.min-block-duration=2h- 应对高基数问题：
- 避免过度使用label
- 定期执行
prometheus_tsdb_head_series监控 - 对业务指标实施cardinality限制
- Grafana性能提升：
- 启用
rendering_server配置 - 对大型仪表板使用
"snapshot": true选项 - 限制每个面板的查询时间范围
5. 故障排查与日常维护
5.1 常见问题速查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| Prometheus靶点消失 | 网络问题或 exporter崩溃 | 检查exporter日志journalctl -u node_exporter |
| Grafana面板无数据 | 时间范围设置错误 | 检查右上角时间选择器 |
| 告警未触发 | PromQL表达式有误 | 先用Graph页面验证查询 |
| 飞书收不到告警 | webhook配置错误 | 测试curl -X POST -d '{"version":"4","groupKey":"...' URL |
5.2 监控系统自身监控
必须配置的元监控项：
- Prometheus自身健康状态
up{job="prometheus"} == 0- 采集延迟检测
scrape_duration_seconds{job=~".+"} > 10- 存储空间预警
(prometheus_tsdb_storage_blocks_bytes / prometheus_tsdb_storage_blocks_bytes_max) * 100 > 855.3 升级与迁移策略
- 版本升级步骤：
# 1. 停止旧进程 systemctl stop prometheus # 2. 备份数据目录 cp -r /data/prometheus /backup/prometheus-$(date +%F) # 3. 安装新版本 tar zxvf prometheus-2.40.0.linux-amd64.tar.gz -C /usr/local # 4. 启动验证 systemctl start prometheus && journalctl -f -u prometheus- 数据迁移注意事项：
- 使用
--storage.tsdb.allow-overlapping-blocks参数处理时间重叠 - 迁移后务必检查
prometheus_tsdb_head_series指标变化 - 建议在低峰期操作，避免数据丢失
这套监控体系在我们生产环境稳定运行两年多，期间经历过三次大版本升级。最深刻的体会是：初期就要建立完善的配置管理机制，所有组件版本、配置文件必须纳入版本控制。曾经因为测试环境和生产环境的PromQL规则不一致，导致漏报重要故障，这个教训价值百万。