SRE Google运维解密——第10章 基于时间序列数据进行有效报警

第10章 基于时间序列数据进行有效报警

• 一个大型的系统不应该要求运维人员持续关注其中使用的无数个小组件，而是应该汇总所有的信息，自动抛弃其中的异常情况。
• 监控系统应该从高级服务质量目标层次进行报警，但是也应该保持足够的力度，可以追踪到某个具体组件

Borgmon 的起源

1. 依靠一种标准数据分析模型进行报警。使得批量，大规模，低成本的数据收集变得可能 ，成为白盒监控
2. 报警规则使用简单的数学表达式形式表达，所有历史数据可以用来作为报警规则计算元素
3. 使用一次对/varz http请求，可以收集到一个监控对象的所有监控指标
4. 可以从其他Borgmon 实例上收集信息，可以建立层级体系，主机汇总监控指标，抛弃无用信息。一般来说每个集群运行一个Borgmon 实例，在全球范围内在运行两个对等的实例。
5. 部署非常的服务集群内部部署专门收集信息的Borgmon实例，集群实例用于汇总

应用软件的监控埋点

1. /varz http 接口 ，文本方式列出监控变量值 如 ： http_response map:code 200:25 404:0 500:12 。定义为25 个http200响应， 12个http500相应

• 维护起来十分麻烦，Google开发了一个工具来自动校验Borgmon 规则的正确性

监控指标的收集

1. Borgmon实例配置可自动扩展的需要收集的目标列表，目标位置可以使用各种地址解析服务支持的格式
2. Borgmo按照配置规定的周期，定时抓取/var URL，得到的信息解码存储内存中
3. Borgmon 将每个目标收集工作均匀分散在整个周期内，避免Borgmon 多层任务堆积
4. Borgmon同时为每个监控目标记录自动生成的合成指标，用在检测监控任务不可用状态的规则编写中
   4.1. 目标是否成功解析成IP和端口
   4.2. 目标是否相应了一次收集请求
   4.3. 目标是否响应了一次健康检查请求
   4.4. 数据收集成功结束的时间点
   varz 和SNMP(简单网络监控协议)非常不同，SNMP协议在设计中需要最简单的传输协议支持，保障其他网络应用失败的时候也能正常运行，利用http协议收集监控信息设计理念正好相反

时间序列数据的存储

1. Borgmon将多软件服务器指标数据整理统一存储，也可以灵活查看数据
2. 每份数据按< 时间戳 , value>值进行存储，值是多标签的单维矩阵
3. 垃圾回收期定时将过期数据从内存清除，Borgmon 定时将内存状态归档外部数据库，一般从内存查，或者从外部数据库(TSDB)查

标签与向量

1. 某一列（同一类型）的成为向量，标签集合指向具体的值
2. 标识一个time-series 标签必须有以下几个标签
   2.1. var : 代表变量名称
   2.2. job : 被监控软件服务器类型名
   2.3. service ： 一个松散定义的服务器类型组名，可以对外名称分类，也可以对内名称分类
3. 标签的来源
   3.1. 监控目标的名称，如job 和instance 来源于任务名与实例地址
   3.2. 监控目标自行提供，如提供的Map类型变量
   3.3. Borgmon配置文件，其中可以添加和替换标签
   3.4. Borgon 规则

Borg 规则计算

1. Borgmon 编程语言，由简单的代数计算表达式组成，使用一个time-series 作为输入，计算另外一个time-series
2. Borgmon 规则一般运行在一个线程池中，受限于规则定义的输入是否包含谦虚规则输出。由查询结果向量大小决定执行速度
3. 汇总计算是分布式环境中不可缺失的一环，将一个任务中所有实例中某个timeseries 相加，通过计算总数，计算整体速率
4. 汇总举例 – 非HTTP200 回复报警
   4.1. 汇总所有实例HTTP回夫的速率，按回复代码分类得到一个向量
   4.2. 计算所有的“错误服务”的速率总和，得到单值，作为整体集群的错误速率
   4.3. 计算整个集群的错误速率比例，用错误回复速率初一所有请求的速率总和
5. 将有用的结果作为控制台的永久图表

报警

1. 每条报警规则都指定一个最小的持续时间周期，当报警持续时间超过这个值时才会报警（一般两个计算周期）
2. Borgmon 连接到全局共享服务，Alertmanager。报警管理服务接收报警进入等待状态和出发状态时产生的Alert RPC ，并转发到合适的通知渠道，配置如下
   1. 当有其他报警出发的时候，一直某些报警
   2. 将多个Borgmon发来的报警信息进行整合排重
   3. 根据标签信息将收到的报警信息展开或者将多个报警信息整合一个
      详细的报警策略见第四章

监控系统的分片机制

1. 节约成本设计一种流式传输协议，用于Borgmon 之间传输timeseries 数据
2. 标准部署模型运行多个Borgmon 负责全局汇总，每个数据中心运行一个Borgmon 负责汇总所在数据中心运行的实例。
3. 更复杂的部署模型中，进一步将数据中心Borgmon 划分为一个收集层一个汇总层
   1. 数据收集层主要负责规则运算和汇总
   2. 全局层也会划分为计算层和展示层
   3. 上游的Borgmon 可以过滤从下游Borgmon 收集来的信息，全局Borgmon 就不需要保留所有任务实例层的time-series信息

黑盒监控

1. Borgmon是白盒监控系统并不能监控系统所有状态
   1. 例 白盒监控系统只能看到已经接受的请求，并不能看到由DNS故障导致没有发送成功的请求
2. 探针程序（黑盒）使用应用级别的自动请求探测目标是否成功返回
3. 探针程序可以直接探测前端，也可以探测负载均衡服务后面的服务

配置文件的维护

1. 配置文件中规则定义与具体目标分开组织，一套规则可以应用到许多不同的收集目标上
2. Borgmon 提供针对Borgmon 规则的单元测试和回归测试工具
3. Google内部Borgmon 通用模板库最大两类：
   1. 将某一个代码类库保罗所有监控系统模板化
   2. 如何将单实例监控数据按级汇总到全局范围的模型
4. 通过Borgmon标签机制，可以针对任务进行区分，Borgmon给每个目标添加对应实例名称，分页，以及所在的数据中心，可以分组汇总对应的timeseries。标签作用如下
   1. 标签可以标记数据维度
   2. 标签可以标记数据来源
   3. 标签可以标记局部分组信息和汇总信息

十年之后

1. 保证监控系统维护成本与服务的部署模型呈线性相关增长是非常关键的