第二章 监控体系搭建：监控指标定义、监控工具选型与架构设计
大家好，我是老张。这一章咱们聊聊监控体系怎么搭。
说实话，很多企业ERP上线后，运维团队最头疼的就是——系统出问题了，没人知道。等用户打电话来骂，才发现数据库连接池满了、磁盘写爆了、某个接口卡死了。嗯，这就是典型的「监控缺失」。
我经历过一个项目，客户ERP跑了一年多，突然某天早上财务模块打不开。查了半天，发现是日志文件把C盘撑爆了。你说冤不冤？其实只要一个磁盘监控告警，这事根本不会发生。
2.1 监控指标定义：到底该盯什么？
很多人一上来就问：「用什么监控工具？」
我的习惯是——先别急着选工具。先想清楚：你要监控什么？
ERP系统不像普通网站，它涉及业务连续性、数据一致性、性能稳定性。我一般把监控指标分成四个维度：
| 维度 | 核心指标 | 说明 |
|---|---|---|
| 基础设施 | CPU、内存、磁盘、网络 | 服务器别挂，磁盘别满，网络别丢包 |
| 中间件 | 数据库连接数、慢查询、队列积压 | 数据库是ERP的心脏，必须盯死 |
| 应用层 | 接口响应时间、错误率、吞吐量 | 用户感知到的性能，才是真性能 |
| 业务层 | 订单成功率、单据流转延迟 | 这个最容易被忽略，但最重要 |
我的经验：业务层监控才是ERP监控的灵魂。我曾经帮一个客户排查「月底结账慢」的问题，发现不是数据库慢，而是某个审批流程卡在了一个离职员工的待办里。这种问题，基础设施监控根本发现不了。
具体到指标定义，我建议遵循「黄金信号」原则：
- 延迟：用户操作从发起到返回，花了多久？
- 流量：系统每秒处理多少请求？峰值是多少？
- 错误：HTTP 5xx、业务异常、数据库超时，各有多少？
- 饱和度：资源用了多少？还有多少余量？
举个例子，ERP的登录接口，你不能只看它返回200就完事了。你得看：
- 平均响应时间是不是超过2秒？
- 并发登录数是不是接近了连接池上限？
- 登录失败率是不是突然升高了？
避坑指南：我曾经见过一个团队，给每个接口都配了告警，结果一天收到几千条告警。最后运维直接把告警群屏蔽了。记住：告警不是越多越好，关键是要「可行动」——收到告警，你得知道该干嘛。
2.2 监控工具选型：Zabbix vs Prometheus
好，指标定义清楚了，接下来选工具。
目前企业里用得最多的就是两派：Zabbix 和 Prometheus。我两个都用过，说说我的感受。
2.2.1 Zabbix：老牌稳定，适合传统架构
Zabbix 的特点是什么？
- 部署简单：装个Server，配个Agent，就能跑起来
- 自带告警：邮件、短信、企业微信，开箱即用
- 模板丰富：监控MySQL、Nginx、Tomcat，都有现成模板
但Zabbix也有短板：
- 数据存储用的是关系型数据库，量大了性能下降明显
- 动态扩缩容不太方便，容器化环境适配一般
- 告警规则配置比较死板，复杂场景需要写脚本
我个人的建议：如果你的ERP跑在物理机或虚拟机上，团队规模不大，Zabbix完全够用。我上一个项目就是Zabbix，监控了200多台服务器，跑了三年没出过大问题。
2.2.2 Prometheus：云原生，适合微服务
Prometheus 是后起之秀，现在越来越火。
- 拉模式采集：主动去抓指标，比Zabbix的推模式更可控
- 时序数据库：存储效率高，查询快，适合海量指标
- 动态发现：配合Consul或K8s，服务上下线自动感知
但Prometheus也有坑：
- 学习曲线陡，PromQL查询语法需要专门学
- 高可用方案相对复杂，需要搭配Thanos或VictoriaMetrics
- 告警管理依赖Alertmanager，配置起来比Zabbix麻烦
我的经验：如果你正在做ERP的微服务改造，或者上了K8s，那Prometheus是首选。我去年帮一个客户搭监控，他们ERP拆成了30多个微服务，用Zabbix根本搞不定动态发现，换成Prometheus后，一切自动搞定。
2.2.3 选型对比表
| 对比维度 | Zabbix | Prometheus |
|---|---|---|
| 部署难度 | 低，文档齐全 | 中，需要理解组件关系 |
| 数据存储 | MySQL/PostgreSQL | 自带TSDB |
| 容器支持 | 一般，需额外配置 | 原生支持，自动发现 |
| 告警能力 | 强，内置丰富 | 强，但需配置Alertmanager |
| 社区活跃度 | 高，老牌社区 | 极高，CNCF毕业项目 |
| 适用场景 | 传统架构、中小规模 | 云原生、微服务、大规模 |
注意：不要盲目追新。我见过一个团队，明明只有10台服务器，非要上Prometheus全家桶，结果光维护就花了一个人力的三分之一。工具是拿来用的，不是拿来炫的。
2.3 监控架构设计：分层与解耦
工具选好了，接下来就是架构设计。
我个人习惯把监控架构分成三层：
- 采集层：负责从各个目标拉取或接收指标数据
- 存储层：负责时序数据的存储和查询
- 展示层：负责可视化、告警、报表
为什么要分层？说白了就是解耦。采集挂了不影响展示，存储挂了不影响采集。我见过一个项目，把所有功能塞到一个进程里，结果一次升级把整个监控搞瘫了。
2.3.1 采集层设计
采集层要考虑几个问题：
- 覆盖度：所有需要监控的节点，是不是都能采集到？
- 可靠性：采集器挂了怎么办？有没有备用？
- 性能开销：采集本身不能影响业务系统
以Prometheus为例，我一般这样设计：
# 采集层架构示意
业务服务器 → Node Exporter（系统指标）
数据库服务器 → MySQL Exporter（数据库指标）
应用服务器 → 自定义Exporter（业务指标）
↓
Prometheus Server（拉取+存储）
↓
Grafana（展示）+ Alertmanager（告警）我的经验：对于ERP系统，我建议在应用层埋点。比如在Java代码里用Micrometer暴露指标，这样能监控到业务层面的数据——订单量、审批延迟、接口调用链。这些是基础设施监控看不到的。
2.3.2 存储层设计
存储层是监控系统的核心。数据存不好，啥都白搭。
几个关键点：
- 数据保留策略：原始数据保留多久？聚合数据保留多久？
- 高可用：单点故障怎么避免？
- 查询性能：历史数据查询不能太慢
我一般这样配置：
- 原始数据保留7天，用于实时排查
- 5分钟聚合数据保留30天，用于日常分析
- 1小时聚合数据保留1年，用于容量规划
避坑指南：我曾经犯过一个错——把所有指标都保留90天。结果半年后磁盘满了，查问题查不了，还得重建索引。后来学乖了，按重要性分级：核心指标保留久一点，辅助指标早点删。
2.3.3 展示层设计
展示层是给谁看的？
- 运维团队：看实时状态、告警、故障排查
- 开发团队：看性能趋势、代码级问题
- 管理层：看SLA、系统健康度、资源利用率
不同角色，看不同的仪表盘。我习惯用Grafana，因为它支持多数据源，而且仪表盘可以共享。
举个例子，我给ERP系统设计的仪表盘包括：
- 总览仪表盘：系统整体健康度、关键业务指标
- 数据库仪表盘：连接数、慢查询、锁等待
- 应用仪表盘：接口响应时间、错误率、吞吐量
- 基础设施仪表盘：CPU、内存、磁盘、网络
我的建议：不要试图在一个仪表盘上展示所有信息。我曾经见过一个仪表盘，放了50多个图表，密密麻麻的，根本看不清。记住：一个仪表盘只回答一个问题。
2.4 总结
这一章我们聊了监控体系搭建的三个核心步骤：
- 指标定义：从基础设施到业务层，逐层细化
- 工具选型：Zabbix适合传统架构，Prometheus适合云原生
- 架构设计：采集、存储、展示三层解耦
下一章，咱们会深入讲告警规则怎么配，以及告警风暴怎么避免。嗯，那也是个坑很多的话题。
记住一句话：监控不是为了看数据，而是为了在出问题之前，提前知道。