乐知网孙敏1. 为什么需要这套监控方案？
在分布式系统和容器化环境中，传统的监控手段往往力不从心。我曾经历过一次线上事故——某个微服务实例的内存泄漏导致整个集群雪崩，而传统的Zabbix监控因为采集粒度太粗（5分钟一次），等收到告警时服务已经瘫痪了半小时。这正是我转向Grafana+Prometheus技术栈的转折点。
这套组合拳的核心优势在于：
- 多维数据采集：node_exporter抓取主机指标，cAdvisor专攻容器指标，形成立体监控
- 秒级告警：Prometheus的Pull模型配合飞书webhook，最快10秒内触发告警
- 零侵入性：所有组件通过HTTP暴露metrics，无需修改业务代码
- 成本效益：相比商业方案，开源组合节省90%以上的监控成本
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 组件选型与架构设计
2.1 核心组件功能拆解
| 组件 | 职责范围 | 关键指标示例 | 部署位置 |
|---|---|---|---|
| Prometheus | 时序数据存储与告警规则管理 | 存储所有metrics，触发Alertmanager | 独立服务器 |
| Grafana | 数据可视化与仪表盘管理 | 展示CPU/内存/网络等面板 | 与Prometheus同机 |
| node_exporter | 主机级监控（物理机/虚拟机） | CPU温度、磁盘IO、网络吞吐量 | 所有被监控主机 |
| cAdvisor | 容器级监控（Docker/K8s） | 容器内存使用、CPU限额、OOM次数 | 容器环境节点 |
| Alertmanager | 告警去重与分发 | 对接飞书webhook | 与Prometheus同机 |
2.2 数据流向架构
code复制被监控主机（node_exporter+cAdvisor）
↓ HTTP暴露/metrics
Prometheus Server（定时Pull数据）
↓ 存储TSDB
Grafana（通过PromQL查询数据）
↑↓
Alertmanager（接收Prometheus告警 → 飞书机器人）
这个架构的巧妙之处在于：
- 无单点故障：每个组件都可以水平扩展
- 低耦合：组件间通过标准HTTP接口通信
- 弹性伸缩：新增节点只需部署exporter，Prometheus自动发现
3. 实战部署指南
3.1 环境准备（以CentOS 7为例）
先解决依赖问题：
bash复制# 安装基础工具
yum install -y wget tar gzip
# 关闭SELinux（生产环境需谨慎）
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
# 时间同步（关键！）
yum install -y ntpdate
ntp