监控系统的功能
核心功能
- 获取当前环境的全局状态,以及核心节点的状态信息;
- 追溯历史问题时提供数据支持。
衍生辅助功能
- 可视: 友好的图、表、曲线、地图、声音、光等感知方式;
- 趋势:通过对数据的分析,以支持对未来情况预估的数据支撑。
- 智能: 支持将多类数据组合分析
- 开放: 将能力开放给外部系统,以支持一些业务实现根据环境改变自身逻辑的能力。
监控系统的数据流模型
两种模式,区别是 是否存储数据
模式一: 采集数据 -> 展示数据
例如: top 实时查看主机情况,或者是早期的 nagios 等都是这种模式
侧重点是 当前 状态
模式二: 采集数据 -> 存储数据 -> 展示数据
例如: sar 采集数据后生成文件, 后续在去这些文件查看历史情况。
zabbix 也是这种模式, 存储在 mysql 内, 然后通过一个 php 页面展示数据
后面的 prometheus 等也是这个模式;
侧重点是可以 追溯历史信息
监控系统选型
-
nagios
单独列出来只是想说,目前这类’不存储历史数据’的方案几乎不会再被考虑了。 -
zabbix
如果是新业务系统,很难找到继续使用的理由; -
prometheus
应该说已经成为监控体系的标准了吧,倒不是这个软件本身,而是说这种通过 http+metrics 方式进行信息采集的方式已经标准化了,已经到了几乎没得选的阶段; -
自研方式
有特殊业务需要,或历史成本原因,那就考虑自己定制!
监控的内容
什么指标需要被监控呢?
- 基础设施;
如机房、硬件、网络、主机、操作系统等。 - 运行环境;
如 kafka, mysql, redis, kubernetes 等通过业务支持的软件服务。 - 业务应用;
面向具体业指标,如交易量,登陆数,XX耗时等。
内容分级
- 多数的内容都是为了在故障后用于综合分析使用。
- 少部分的指标是在线需要告警或需要触发事件的。
监控系统设计的一些考量点
-
采集数据是推还是拉:推荐还是拉数据好一点,附带探活作用,如果是推的话,还要考虑这份数据是不是哪里积压的缓存,是不是某节点推错了,或者篡改了身份等。
-
配置指标维护方式: 节点上线前加指标, 还是上线后加指标, 还是同步加指标(注册)
-
数据灵活性: 能否以较灵活的方式以自定义维度来对存量的数据进行分析
-
告警机制: 核心是通知到正确的人, 然后才是减少打扰到人
监控系统迭代递进过程
- 从无到有阶段: 选一些支持核心诉求的开源工具来用即可;
- 中期: 需要定制大量的自定义插件和脚本, 应用程序也需要部分改造以进行适配;
- 成熟阶段: 形成了一套标准化模式进行接入;
关于告警
监控+告警应该是一对组合, 小规模场景下一般融合在一个组件内使用。
但是大规模环境下,还是着力拆开来设计更合适。
因为监控面对的是业务环境,而告警针对的是人。
自监控设计
早期传统业务监控模式一般是研发人员交付代码和包,运维人员上线和部署监控,
研发一般只提供需要监控的指标,不实际去操作监控系统。
但是这里存在很大的问题,就是这个监控指标从运维这里转一下后,往往会变质很多。
其实完全没有必要增加这一步骤。
现代系统更推荐的是自监控模式,
即被交付服务主动暴露相关需要被监控的指标数据,且暴露需要告警的阈值数据。
而且现代微服务架构一般都通过CI/CD来进行快速发布,监控也是自动发现,为什么告警不能也自动发现呢?当然是可以的。
监控自动发现比较好实现,告警阈值自动发现能力,暂没有什么标准,需要改造的内容较多。
例如:
服务通过 /metrics 暴露指标数据, 并在指标的 HELP 内标识阈值,
这样即兼容了 Prometheus 等基于 metrics 的标准监控系统,又可以实现告警发现功能。
一些个人的理解
- 覆盖面应该尽可能的广, 方便事后数据分析,但不应该是重心。覆盖面应该是增量递进,逐步补全。
- 图表其实不是那么重要, 因为真实情况除了值班人员,没有谁会一直盯着看,核心还是数据能否方便的以多维度展示。
- 监控大盘还是需要的,虽然不会一直看,但偶尔看一下,还是能很好地了解全局状态;
- 监控数据一定要极为方便的获取, 获取核心数据时不能太繁琐。
- 除了从内不监控,还得从外部用户侧视角进行业务探测。