监控系统的功能

核心功能

1. 当前的状态信息;
2. 追溯历史问题时提供数据支持。

衍生辅助功能

1. 可视: 友好的图、表、曲线、地图、声音、光等感知方式；
2. 趋势：通过对数据的分析，以支持对未来情况预估的数据支撑。
3. 智能: 支持将多类数据组合分析
4. 开放: 将能力开放给外部系统，以支持一些业务实现根据环境改变自身逻辑的能力。

监控体系的发展阶段

1. 人工巡检+脚本定时检测通知
2. naios这类基础监控逐步平台化
3. zabbix这类可视化平台, 自动发现和注册模式开始出现
4. prometheus标准化监控体系
5. 可观测性标准化体系: 指标+日志+链路跟踪

抽象的监控对象属性字段

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

zone: 所在区域
model: 业务模块
level: 重要级别
status: 当前状态
告警状态: 是否处于告警中
关联人: []
监控频率：
目标地址:
正确响应:
当前响应:

理解目标

1. 对象的基本信息，性质，工作原理，以确定怎么进行监控
2. 确定目标有哪些指标，即监控对象的属性
3. 阀值和故障等级

监控模型体系

数据流

1. 采集–>展示: 例如 top 或 早期的 nagios 等都是这种模式, 侧重点是当前状态;
2. 采集–>存储–>展示: 侧重点是可以 追溯历史信息;
3. 暴露–>采集–>处理–>存储–>展示–>告警;

选型

1. nagios 单独列出来只是想说，目前这类’不存储历史数据’的方案几乎不会再被考虑了。
2. zabbix 如果是新业务系统，很难找到继续使用的理由；
3. prometheus 标准监控体系, 标准化
4. 自研方式: 有特殊业务需要，或历史成本原因，那就考虑自己定制！

监控的目标

1. IDC基础设施: 如机房、硬件、网络、主机等不会动态改变的内容;
2. 运行时环境: 虚拟机, mysql, kafka, kubernetes 等业务支撑类设施;
3. 业务应用: 面向具体业指标，如交易量，登陆数，XX耗时等。

内容分级

1. 多数的内容都是为了在故障前后用于综合分析使用。
2. 少部分的指标是在线需要告警或需要触发事件的。

数据的推拉模型

pull 拉数据优缺点:

• 附带探活作用
• 采集端端压力可控
• 扩展方便, 被采集方与采集方解耦, 可以多个不同的采集端同时进行采集
• 缺点: 对于临时性任务不友好
• 对于需要及时展示的指标不友好(需要等待轮询周期)

push 推数据优缺点:

• 网络策略一般开得少, 应用侧不需要暴露被采集的端口
• 适合移动端或网络经常断开的场景
• 自动上报, 不需要做服务发现
• 时效性高
• 缺点: 可能是自身积压数据
• 数据真实性, 是否被篡改
• 不方便根据服务器端压力调整推送频率
• 节点存活性; 如果一段时间没有上报数据, 不好确认原因(停了,网络故障,已经迁移等)
• 采集端地址变更或迁移比较麻烦

综合来说, 还是 pull 方式最合适, 特殊网络和业务场景可以考虑 push 方式

数据可视化

两种不同的理念

1. 完全不看: 因为确实很少去日常查看监控面板的图表
2. 监控大盘型: 只保留一个监控大盘
3. 都看: 每个指标和告警项都预设一个图表

监控大盘

为什么需要大盘

1. 大局观，全局观, 以及最核心的一些指标;
2. 避免来回切换，繁琐操作，一眼看出当前环境是否存在异常;
3. 如果有异常, 能快速定位关键路径;

需要包含的信息

1. 当前状态: 毫无问题, 小问题, 明显异常，业务基本不可用, 监控数据的可信度
2. 故障范围: 区域级, 节点级别, 链路级别, 单业务模块级别
3. 业务指标: 接口成功率, 接口耗时, 核心业务指标幅度;

统一的监控事件平台

大型传统企业的趋势是将监控平台和管理平台、资产管理平台、配置管理平台、工单事件平台合并, 整合为一体化运维平台;

分布式监控

1. 采用 数据源采集-代理-管理端 三级模式
2. 或者 多主模式分区pull 采集的方式

数据采集方式

1. 应用程序: 主流方式为应用程序自己暴露相关指标, 采集端采集
2. 应用程序 push方式, 应用程序推送数据
3. exporter: 标准化模式
4. 旁路模式: 例如通过流量镜像等方式进行拦截分析后获取到数据

常见采集形式

1. sdk 暴露指标
2. agent/exporter 采集暴露指标
3. snmp
4. ssh
5. ipmi
6. http 接口，REST API
7. JMX

业务监控方式

1. 外部拨测: 前置到用户侧进行模拟操作; 缺点: 对业务有干扰，探测频率间隙中的故障不能及时发现;
2. 日志和链路分析: 事中分析, 即监控业务流中各组件的状态和链路完整度; 例如一次正常登录行为是否经过了完整的组件。
3. 数据分析: 即事后分析, 分析业务完成后的数据库数据; 具有滞后性;

自服务设计

早期传统业务监控上线的一般流程为

1. 管理人员提出监控需求
2. 运维人员提出表格模板
3. 业务或开发人员按模板补充信息
4. 运维人员配置监控和告警

这个流程中涉及到太多的人和流程, 实际就是上线一个监控指标会很慢，下线也很慢;

其实这个指标完全不需要从运维这里过一下;

现代监控体系更推荐的是监控自注册模式，即业务应用上线时就自己注册相关监控项目, 例如k8s集群:

1. 业务应用上线
2. k8s环境附加 ServiceMonitor 定义直接就上线监控了;

如果是非k8s集群环境, 那就在ci/cd环境进行监控的注册;

告警方式也相同，也可以采用自注册的方式;

应用的附加元数据

• 监控端点
• 监控方法和正确响应状态, 告警阈值数据;
• 告警接收人

例如：
服务通过 /metrics 暴露指标数据, 并在指标的 HELP 内标识阈值,
这样即兼容了 Prometheus 等基于 metrics 的标准监控系统，又可以实现告警发现功能。

告警体系

事件

1. 阀值触发
2. 趋势触发：即根据最近的数据推测后续将要发生的事件

分级

• p0 已经造成核心业务影响
• p1 已经造成业务影响, 但核心业务暂不受影响
• p2 普通异常: 例如延迟突增但幅度不大, pod重建
• p3 提醒事件: cpu/磁盘 使用率略高

分级通知策略

• p0 多渠道通知核心人员, 一线人员, 决策层
• p1 多渠道通知核心人员, 一线人员
• p2 群消息
• p3 表格记录, 不需要通知; 只需要展示和记录

附加时间分级通知

例如 p1 类事件, 按时间分级，突发时发给一线，10分钟后发给二线，30分钟后发给管理层

告警信息

1. 简明简要，尽量精简
2. 一目了然，能快速判断故障的影响和节点, 如成功率低于60%，某某某服务停止
3. 时间：开始时间，持续时间，恢复时间

告警方式

1. 钉钉飞书群: 内容灵活, 通知也及时, 是目前主要告警方式;
2. 短信告警: 适合简要信息，及时通知, 但是目前基本没人即时看;
3. 邮件告警: 适合通知外部第三方人员, 可以使用html邮件，内容丰富，可以带详细的附件;
4. 电话告警: 可以是自动语音接口，或者是人工发现告警后电话通知，重大事件的效果好；
5. 监控大盘显示: 适合办公室大屏展示, 办公室内抬头或路过就能看见;
6. 声音灯光告警: 智能音箱播放，配合灯光闪烁，工作区域内使用，非常即时;
7. 浏览器插件: 或者是pc端agent, 弹框通知, 适合传统企业有轮值班人员场景;

告警方式组合

主要原因是人不可能一直坐在电脑旁, 也不是一直看着手机，可能在路上或睡觉;

1. 工作日工作时段，可以采用群告警+办公室设备告警+agent弹框告警等组合方式
2. 下班时间，可以选用短信、微信、电话等时效性高的方式
3. 汇总类告警、非突发性告警, p3级别，可以采用邮件的形式

告警收敛

目的:

1. 避免海量告警风暴掩盖关键信息;
2. 故障暂时不能恢复或处置阶段阶段, 重复发送告警;

方式:

1. 相同重复事件合并
2. 模块合并: 按业务模块进行合并
3. 按严重程度合并: 主机宕机即忽略该主机上所有服务的告警;
4. 时间合并：比如同一类型的服务，在前几个服务刚发生故障时，可以实时告警；随后逐渐故障的其它服务应该合并告警；
5. 每人每分钟不超过1条短信的的频率

告警静默:
指定系统变更期间忽略某类告警

告警收敛策略:

业务收敛：当某集群产生了高等级故障时，收敛其它告警；
接口收敛：某接口的多个探测都失败时，根据URL收敛为1次接口告警；
定时收敛：每分钟或每10分钟
时间收敛：58,724

其它告警相关事件

1. 恢复时也需要通知
2. 定期复查；例如对故障的应用进行每隔1小时的复查，并提示已经故障的时间长度；
   即超过一定时长仍未恢复的应用，需要再通知一次；
3. 告警链路健康性: 独立的监控模块对告警链路进行健康性检查;
4. 告警接受人员信息动态从hr系统中获取, 避免人事变更造成的无响应；
5. 每周告警数量不应该超过10条, 超出说明有重大管理问题
6. 告警信息中应该附带引导信息或分析信息
7. 持续对每月/每周 Top5 的告警进行优化，可以较大的减少告警量
8. 告警的核心是通知到正确的人, 然后才是减少打扰到人

指标

不同人员角色 需求的核心指标侧重不一样

• 项目经理: PV、UV、日活、月活、ARPU等
• 开发人员: Bug、TPS、QPS、JVM、消息队列等
• 运维人员: 服务可用性、机器负载、带宽流量等
• 用户: 能否打开, 响应时长, 是否能完成

精简指标

1. 重点关注业务入口和关键业务指标
2. 摘取关联度较高的指标(即N项故障都会引起此指标变动)

业务类

常见业务指标

1. 订单类/交易类
2. 用户数: 每分钟/小时/日的用户访问数
3. 接口: 状态码, 调用次数, 成功率, 最慢响应时间，平均响应时间, p99响应时间

安全类

对于安全方面的监控，一般建议对接第三方厂商接口进行

1. 按攻击类型分类统计
2. 按攻击源分类统计
3. 按攻击深度统计

基础设施类

• 服务器硬件: 电源, 网卡, 风扇, 温度, 硬盘, 阵列卡, 电压
• 网络设备: 网口up/down, 速率, 质量, cpu、内存, 连接数, 延迟,丢包率,误码率
• 存储设备:
  1. 存储交换机(设备状态、端口状态、传输速度)
  2. 磁盘阵列(缓存，速率)
  3. 磁带库(备份起止时间、是否成功、出错告警)

操作系统:

• 性能指标: cpu 使用率/负载, 任务队列数, 上下文切换次数
• 内存指标: 总量、空闲、使用率、swap、缓冲区
• 磁盘: 容量使用情况, IO繁忙度, 速率, inode数量
• 网络: socket状态, 速率, 连通性

应用中间件

• 活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
• 最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
• 连接数、队列数、生产速率、消费速率、消息堆积量

数据库核心指标

• 连接池: 最大连接数，活跃连接数
• 慢查询: 耗时的sql, cpu占用高的sql
• 每秒指令数量: 按不同语句类型的分类
• 锁状态
• 主从延迟
• 容量使用情况
• 内存使用情况
• 备份: 执行情况、备份完整度
• 缓存命中率

自研监控平台要点

用途

1. 告警预警
2. 性能分析
3. 故障分析
4. 运营支持
5. 自动化运维: 联动

原始数据暴露和采集

• 标准化暴露数据

支持api接口管理

1. 监控指标的注册和注销
2. 外部查询某资源或某模块的状态
3. 获取统计信息
4. 订阅消息

数据存储

• 关系型数据库: 例如 MYSQL，好处在于历史数据都在，方便统计分析和制作报表
• RRD: 基于圆形队列的数据库，大小固定，不担心数据过大，但时间序列间隔不能调整；
• 时序库: 时序库优势很多，可以算是专门为监控体系准备的
• 对象存储: 本地wal写入, 加对象存储存历史数据

告警设计

• 监控+告警应该是一对组合, 小规模场景下一般融合在一个组件内使用;
• 大规模环境下，还是将监控和告警拆开来设计更合适。因为监控面对的是业务环境，而告警针对的是人。

管理功能

• 日检/月检报告
• 资产管理
• 事件管理, 事件自动关联相关文档或智能分析
• 多用户和角色体系
• 知识库

一些个人的理解

1. 覆盖面应该尽可能的广, 方便事后数据分析，但不应该是重心。覆盖面应该是增量递进，逐步补全。
2. 图表其实不是那么重要, 因为真实情况除了值班人员，没有谁会一直盯着看，核心还是数据能否方便的以多维度展示。
3. 监控大盘还是需要的，虽然不会一直看，但偶尔看一下，还是能很好地了解全局状态；
4. 监控数据一定要极为方便的获取, 获取核心数据时不能太繁琐。
5. 除了从内部监控，还得从外部用户侧视角进行业务拨测。

实施阶段

采用小步快走方式

• 阶段1: 覆盖基础和关键业务指标, 可采用标准化开源工具;
• 阶段2: 追求覆盖面和标准化；推进插件开发和应用程序改造;
• 阶段3: 减少误报率, 形成了一套标准化模式进行接入
• 阶段4: 提升可靠性、友好性、扩展性;
• 阶段5: 数据开放, 要能服务运营和研发;

业务拨测

即程序模拟用户进行一次核心业务的访问(涉及到主要链路)都是有必要;

• 自动拨测: 程序需要放置在环境外部, 贴近真实用户
• 人工验证: 内部人员定时访问和使用业务;