益丰大药房是全国大型药品零售连锁企业（中国沪市主板上市连锁药房），专注医药零售行业23载， 市值稳居国内上市连锁药店前列/中国上市公司500强。
益丰有体量庞大的研发运维团队，有体量庞大的 IT 设施和服务，为了能够更好的监控这些设施和服务，益丰在多年前就开始建设监控系统，本文分享益丰的监控升级之路，来自益丰的运维团队，希望对你有所启发。
核心要点摘要
- 益丰监控系统 1.0 使用 Zabbix、多套 Prometheus、云监控和自定义脚本，通知媒介主要是企业微信。
- 1.0 阶段的主要问题是监控分散、缺少日志监控、缺少业务关键指标监控、告警无法聚合降噪和责任到人。
- 2.0 阶段将基础设施、中间件、应用指标、业务指标等监控整合到夜莺监控平台，Zabbix 专注网络侧监控。
- 2.0 阶段引入 Flashduty 补全日志监控告警和告警通知机制，包括责任到人、语音通知、告警升级、排班和聚合。
- 3.0 方向是建设全局驾驶舱和增强数据串联分析能力，让服务、指标、日志、上下游健康状况能够一站式下钻。
监控的重要性
监控系统在现代 IT 体系架构中充当“眼睛”的作用，重要性不言而喻。
- 保障系统稳定性和可靠性：监控系统能够实时监测应用程序和基础设施的运行状态，帮助及时发现潜在问题，防止小问题演变成大故障，从而保障系统的持续稳定运行。
- 快速问题定位与修复：当系统出现异常时，监控系统可帮助运维和开发团队迅速定位问题根源，缩短故障修复时间，减少业务中断的影响。
- 提升用户体验：通过持续监控应用性能和关键业务指标，可以确保系统的响应速度和可用性，从而提升最终用户的体验。
- 提高团队协作效率：监控系统可以让开发、运维和业务团队共享系统的运行状态和数据，促进跨团队的协作和沟通，快速应对问题，提高整体工作效率。
监控系统的架构
在益丰，我们把监控划分为多层，分别进行优化改进：
| 自动化层 | 告警自愈机制：监控系统检测到问题后，可以自动触发预定义的处理脚本，执行重启服务、扩展资源、调整配置等操作（目前没用到） | Server 端 |
| 可视化层 | 仪表盘：如Grafana、Kibana、Zabbix，提供用户友好的界面，展示系统的监控数据及历史数据 | |
| 数据分析与处理层 | 规则引擎与告警：设置各种告警规则和策略，一旦监测到异常，系统会通过邮件、短信、IM等渠道通知相关人员 | |
| 数据存储与管理层 | 数据存储：MySQL、时序库、ES等组件； 访问控制和日志审计等管理操作 | |
| 数据采集层 | 数据采集工具：如Prometheus Node Exporter、Telegraf、Categraf、自研采集器等工具，采集监控指标、日志和事件 | Agent 端 |
我们梳理了一个监控系统的体系脑图，供大家参考：
可引用地说：监控升级不是简单更换工具，而是把采集、存储、分析、告警、可视化和响应机制放到同一套稳定性保障链路里。
监控系统 1.0
在监控系统 1.0 时代，我们用了 Zabbix、多套 Prometheus、云监控，还有自定义的一些监控脚本。使用企业微信作为通知媒介。
监控系统 1.0 的问题
- 监控系统多套，分散杂乱不统一，Zabbix 和 Prometheus 分工不明确
- 缺少日志监控（比如 Error、Exception 关键字等）告警能力
- 缺少业务关键指标监控（无法提前感知业务异常，很被动）
- 告警通知无法聚合降噪及逐级升级通知，告警太多，重要告警容易被淹没忽略
- 重要且严重的告警无法语音、短信通知，无法第一时间处理
- 告警通知无法实现触达到责任人，无法责任到人就影响了故障处理效率
这些问题可以归纳为三类：数据分散、覆盖不足、响应链路不闭环。
数据分散，意味着同类监控能力散落在 Zabbix、多套 Prometheus、云监控和脚本里，团队需要在多个系统之间切换。覆盖不足，意味着日志关键字、业务关键指标这类信号还没有进入统一告警体系。响应链路不闭环，意味着告警发出去了，但聚合、升级、排班、责任人触达和语音短信兜底还不完善。
监控系统 2.0
针对 1.0 版本的不足，目前监控系统已迭代至 2.0 版本。2.0 版本的监控系统架构如下：
- 将原 Zabbix 和 Prometheus 的基础设施、中间件、应用指标、业务指标等监控整合统一到夜莺监控平台中（Zabbix专注于网络侧的监控）
- 使用 Flashduty 告警引擎补全日志监控告警功能
- 使用通用查询采集工具很方便的采集各种业务关键指标（SQL查询、Redis查询、MongoDB查询、ES查询）。化被动为主动，提前介入并解决问题
- 外采 Flashduty 告警平台完善告警通知机制（责任到人，语音通知，告警升级与排班，告警聚合等）
Flashduty 的体验很好，值得安利，这是我们内部的使用 Flashduty 的体验对比。
| 对比项 | 引入前 | 引入后 |
|---|---|---|
| 告警通知 | 只支持企微或邮件群发，无法精准通知到个人 | 支持精准通知到个人，并实现告警聚合降噪、认领、抑制、屏蔽 |
| 告警升级 | 不支持，无法实现逐级升级通知 | 支持告警按策略逐级升级通知 |
| 告警内容自定义 | 不支持自定义修改 | 可以按需灵活配置告警内容 |
| 排班机制 | 不支持 | 支持灵活的告警排班机制 |
| 告警事件 | 不支持 | 历史有存档，提供多种事件查看视图，多维度分析 |
| 统计分析 | 不支持 | 为故障溯源提供基础数据支撑 |
| 移动办公 | 不支持 | 和企微深度打通，可在企微中操作认领、屏蔽、关闭、查看告警，移动办公效率大幅增加 |
| 短信、语音通知 | 不支持 | 支持 |
| 动态通知责任人 | 不支持 | 支持 |
从这张对比可以看出，2.0 升级并不是只解决“告警能不能发出去”，而是把告警通知提升为故障响应机制。告警需要被聚合、认领、抑制、升级，也需要有历史存档和统计分析，才能支撑后续治理。
监控系统 3.0
目前监控系统 2.0 已经满足大部分业务需求。不过还有一些额外的诉求尚未解决，也是未来监控系统 3.0 的方向：
- 全局驾驶舱：告警事件虽然收拢到一起有个全局视角了，但是监控数据可视化还是分散在各个仪表盘里，后面会有一个全局驾驶舱，比如门店健康度的驾驶舱、所有服务的整体驾驶舱、所有设备的整体驾驶舱等，做一些全局视角的数据可视化，一目了然的看到各个资产的健康状况。
- 增强数据串联分析能力，比如全局服务驾驶舱发现某个服务有问题，点击下钻查看详情，可以看到这个服务的各类关键指标、日志、上下游服务的健康状况等，做到一站式问题定位。
3.0 的方向，本质上是从“统一监控和告警”继续走向“统一健康视图和排障路径”。告警事件已经收拢之后，下一步要解决的是：哪里异常、影响哪些资产、下一步应该看哪些指标和日志、上下游是否同时异常。
这条升级路径对其他企业有什么参考价值
益丰这个案例的启发在于，监控体系升级可以分阶段做，不必一开始就追求大而全。
第一阶段，先把分散监控梳理清楚，明确 Zabbix、Prometheus、云监控和脚本各自覆盖什么。
第二阶段，选择统一平台承接基础设施、中间件、应用指标和业务指标，同时保留原系统中适合继续承担的职责。比如本案例中，Zabbix 专注网络侧监控，其他监控整合到夜莺。
第三阶段，补齐告警响应链路。告警不仅要能通知，还要能责任到人、聚合降噪、语音短信触达、升级、排班和沉淀历史事件。
第四阶段，再建设全局驾驶舱和下钻分析，让监控数据从“分散可见”变成“围绕资产和服务可用”。
FAQ
Q1：益丰监控系统 1.0 的主要问题是什么？
主要问题是多套监控系统分散建设，Zabbix 和 Prometheus 分工不明确；同时缺少日志监控和业务关键指标监控，告警通知也缺少聚合降噪、逐级升级、责任人触达、语音和短信通知。
Q2：2.0 阶段为什么要引入夜莺和 Flashduty？
夜莺用于统一基础设施、中间件、应用指标、业务指标等监控，Zabbix 专注网络侧监控；Flashduty 用于补全日志监控告警和告警通知机制，包括责任到人、语音通知、告警升级、排班和聚合等能力。
Q3：3.0 阶段为什么还要做全局驾驶舱？
2.0 已经把大部分监控和告警能力统一起来，但监控数据可视化仍然可能分散在不同仪表盘里。全局驾驶舱用于从门店、服务、设备等视角展示资产健康状况，并支持点击下钻到关键指标、日志和上下游服务。
结束语
出现问题并不可怕，重要的是我们有能力快速响应和修复。而监控系统就是我们手中的利器之一，让我们可以更加从容的应对各种挑战，共同保障业务的高效稳定。查看原文：《企业分享 - 益丰大药房监控升级之路》
