业务监控, 主要侧重对业务状态数据的实时监控, 收集数据后对业务数据进行深入的统计分析, 帮助业务方发现问题, 定位问题根源. 这其中数据分为: 业务自身输出的业务日志(比如: 提单, 推单, 接单等状态数据), 业务异常, 报警事件等.
发现问题原因之后我们需要解决问题, 最终目的是可以基于我们分析的结果给运维动作做出决策, 以达到自动化运维的目的. 另外, 明确系统用户将有助于把控业务监控产品的设计方向, 业务监控系统的第一用户是RD, 不是老板, 我们是要帮助RD更快的发现问题, 预知问题, 提供标准化解决问题的建议.
系统设计
数据模型
数据模型
BusinessLog: 需要在业务中进行埋点, 业务主动以固定的格式通过日志输出的方式上报数据, 然后Digger会实时汇总分析, 通过各种曲线展示业务状态的走势.
EventLog: 随着各个业务系统的成长, 每天会有各种事件产生. 当某些系统有问题时, 通常会产生各种报警事件. 另外, 系统大部分的故障都会和发布新版本,配置变更有关系, 记录这些事件并加以分析, 可以帮助我们快速定位问题的根源.
ExceptionLog: 当业务代码运行时没有达到预期将会抛出运行时异常, 对这些异常进行收集并设置分类器, 将会帮助我们更细粒度的定位到问题的起因.
数据收集流向
数据收集流向
业务服务中产生的数据主要包含两大类:
(1) 不需要业务服务埋点, 通用底层监控框架自动收集的数据. 这其中包括: 系统指标,性能指标,服务异常等.
(2) 需要业务服务埋点,自己上报业务状态日志. 这部分数据会直接通过日志的方式流入日志收集通道.
底层监控系统主要是类似zabbix的系统层级的监控系统, 我们主要使用的是Cat,Falcon等开源系统, 这些系统本身可以配置各种报警规则, 并可以对异常日志进行归类统计. 因为各个系统产生的事件发送方式繁多, 我们如果各个去适配,后续的维护成本会非常高.这时我们将考虑推动事件接收通道的统一.
公司层面所有的事件都会通过IM的方式推动给各个团队, 这时我们申请开通了Digger系统自己的IM账号, 并推动各个事件产生方统一给Digger的IM账号发送事件信息.
Digger系统会部署自己的数据收集器(Digger-collector), 用来收集IM通道中的各种事件,以及其他特殊原因产生的监控数据.
不管是业务埋点发送的业务状态日志, 还是Digger-collector收集的事件等信息, 最终都会统一发送到统一的日志通道中.
我们最终使用Elasticsearch让监控日志落地, 利用Elasticsearch做各种复杂的近实时的统计分析.
Elasticsearch中会存储聚合分析后的结果数据, 最终通过Digger-admin读取展示监控图表给用户.
系统结构
系统结构
Digger-client: 业务监控系统首先需要有一个足够轻量的client用来帮助业务服务低成本的进行业务状态数据的埋点收集.
Digger-collector: 对已有的基础监控系统产生的数据进行收集, 这其中需要兼容各种数据收集接口,同时对于一些特殊的系统, 还需要暴露自己的http服务, 以便其他系统通过回调http接口的方式收集监控数据.
Digger-processor: 该组件主要是针对收集上来的各种类型的数据定时的进行统计分析, 并将结果数据以日志的方式回写到Elasticsearch中.
Digger-admin: 该组件主要是暴露给Digger业务监控的用户管理界面, 在这里面可以定制自己的监控图表,对自己关系的服务进行监控检查等. 关于核心业务监控产品都将在该组件中体现.
现有报警数据种类繁多, 每天产生的数量庞大, 这其中有相当一部分数据是因为阈值设定不合理而引起的误报而是会降低报警的实用性, 我们需要实时收集这些报警事件并做二次统计分析, 报警事件由多种方式发出, 所以需要有独立的collector组件负责收集这些事件, 后续其他类型业务数据的收集也可以通过collector完成.由于异常数据, 业务数据, 事件数据都有各自的结构, 为了简化日志格式化处理过程, 我们需要封装一个client来做这个事情, 尽量使日志格式化的动作对业务方透明.
核心产品功能
业务大盘
业务大盘
在基础监控平台(比如:Cat, Falcon)中, 我们是可以看到各自服务的QPS, TP99, JVM, CPU等基础监控指标. 针对核心业务流程中的业务状态的监控, 每个业务服务的监控需求各不相同, 有的业务需要很多维度的监控, 并且需要快快速的帮助开发规范化问题排查的SOP.
以订单核心业务流程为主, 针对提单-> 推单-> 接单-> 分配送等流程配置订单监控大盘.
以分钟粒度可以查看近三日的业务曲线,给用户一个直观的趋势变化.
当曲线中出现陡升或者陡降时, 通过点击出现菜单, 菜单中针对各个业务服务定制自己排查问题的SOP, 在出现问题时快速引导用户排查问题并可以在曲线中快速做好标注.
针对每个业务曲线可以进行未来一天的预测, 并在每分钟对未来一分钟的预测数据进行实时修正, 已达降低根据预测曲线进行报警的错误率.
每个业务流程点上可能会有多个数据状态产生, 可以查看每个状态的时间变化曲线.
事件监控
事件监控
事件大盘主要针对收集到的报警事件, 慢查询事件, 发版事件, 配置管理事件, 服务器上下线事件等, 进行统计分析, 目前来说每个事件都会有总计折线图和按APPKEY维度统计的TOP20来展示. 下面以报警事件为例说明核心功能:
可以选择开始时间和结束时间. 页面默认会统计最近一个小时的数据.
鉴于公司的服务非常多, 如果不加区分则很容易让用户查看不到自己关心的统计数据, 所以会针对业务线来区分.
报警事件以时间维度的统计图, 可以点击统计图从而引导用户进入事件检索列表页, 查看具体的事件详情.
针对报警事件TOP20, 会默认按照所有报警级别的报警信息之和进行TOP排名, 用户也可以选择按照其他报警级别进行TOP排名.
用户可以点击柱状图, 会带上APPKEY和当前检索时间区间进入到事件检索列表页, 查看具体的事件详情.
健康检查
健康检查
健康检查的目的是将关心的业务服务进行分组, 可以直接打开某个分组的健康大盘, 该健康大盘将直观的展现组中每个服务在选的时间范围内的多维度数据统计, 以帮助开发人员检查服务的健康状况.
主要针对收到的QPS, TP99, TP90等性能报警进行统计, 左侧的都是以时间轴维度的报警数量的统计, 可以直观的发现该服务在哪个时间点存在性能瓶颈. 右侧的图则是该服务中每个接口方法的性能报警排名.
主要是通过分析报警级别来判断服务的健康状态, 如果我们在报警设置时, 给不同的阈值设定不同的报警级别, 将可以更细粒度的区分服务所收到报警的关注等级.
我们可以对业务服务中主动抛出的异常进行分类统计,帮助用户定位到底是哪些异常引起的系统不稳定.
在分布式系统中, 数据库从来都是稀缺资源, 所有对数据库慢查询的监控也是必不可少的, 我们可以针对该服务中所有操作数据的DAO中的方法进行慢查询排名.
预测报警
基线计算任务:
每天运行两次, 上午3点8分, 计算当日的基线；下午3点8分, 计算明日上午的基线；计算基线的算法很简单, 主要是: 历史同期数据去除噪点后进行加权平均，然后对结果去除噪点后进行移动平均. 这其中有些外部因素引起的一些异常数据, 我们需要针对这部分数据进行去噪操作, 主要是: 取同时刻周期数据的中值, 排除掉大于中值2.5倍以上或者小于中值0.4的数据. 计算某天基线时，移动平均时取30个点，对于当天的前15个点和最后15个点，因为这些值无法计算移动平均数, 则直接用加权平均代替.
修正预测数据任务:
每分钟运行一次，计算当前分钟的未来一分钟的预测数据. 其计算步骤：根据前60分钟的基线和真实值，用一次指数平滑法进行预测, α参数默认0.6，时间点越近的历史数据对当前预测数据的影响越大.
基于预测线的报警任务:
每分钟运行一次，对比真实数据和预测数据，根据离散度、阈值、历史趋势对比.
报警步骤：
(1) 利用分段线性函数，传入当前预测值，计算4个阈值梯度：threadholdNonSensitive > threadholdSensitive_1 > threadholdSensitive_1 > threadholdSensitive_2 > threadholdSensitive_3 .
(2) 取最后一个残差（计作diff1），最后2个残差的平均数（计作diff2），最后3个残差的平均数（计作diff3）.
(3) 如果是对于数据下降敏感的（比如提单、推单），则当数据下降时（残差 < 0），diff1/2/3，分别大于threadholdSensitive_1/2/3，则进入下一步；当数据上升时（残差 > 0），diff1/2/3，分别大于threadholdNonSensitive，则进入下一步.
(4) 如果是对于数据上升敏感的（比如消单），则当数据上升时（残差 > 0），diff1/2/3，分别大于threadholdSensitive_1/2/3，则进入下一步；当数据下降时（残差 < 0），diff1/2/3，分别大于threadholdNonSensitive，则进入下一步
由于分段阈值的设置需要考虑分段和对业务理解，也可以不用分段阈值，直接用百分比，比如浮动30%报警.
历史趋势对比，和历史数据进行纵向比较，取过去5天，当前分钟前后各1分钟，共计15个点，如果超过3个点报警，说明这个点的数据突变是这个业务的特性，则不会报警.
经过离散度、阈值、历史趋势对比判断，都监测通过之后，开始根据配置进行报警.
离散度判断，某一分钟，前15分钟（含当前）的真实值和基线，取残差，计算后3个和前12个平均数之差（记作A），计算前12个的标准差（计作B），如果|A| <= 2.5 * |B|，认为数据的突变程度不够，不往下走；
阈值判断，阈值和业务相关，其实是经过不断的报警实验之后，作出的认为合理的值，判断步骤如下：
监控收藏
监控收藏
公司现在有很多第三方监控系统, 比如: Falcon, Cat等. DIGGER项目提供对这些第三方监控页面的收藏, 以便方便的进行快速方位, 大家可以通过系统菜单中的菜单管理来进行配置, 主要功能如下:
可以在某一节点中添加子菜单, 最多支持四级菜单(层级太多, 显示不友好).
在编辑或者新增菜单时, 可以直接将第三方监控地址添加在链接文本框中.
可以支持已有菜单接口的位置变更, 该功能只有管理员可以使用.
对菜单项进行编辑之后, 直接DIGGER系统的左侧菜单在一分钟之后变更为最新的菜单列表(非管理员用户只可以管理"其他监控收藏"下面的菜单项).
降级限流管理
在业务系统碰到极端情况下, 可能会引起部分服务的不稳定, 这个时候我们需要对非核心路径的服务进行降级, 限流, 以保护核心服务的正常运转. 那这些降级开关, 限流开关和业务监控系统紧密结合将会极大的提高业务系统的运维效率. 我们可以在各个业务监控大盘周围来对相关的降级限流开关进行配置管理, 当触发开关时可以实时观测到其对业务流量, 性能的影响. 随着业务复杂度的提高, 系统之间的依赖服务越来越多, 涉及的降级限流开关也会越来越多, 这个时候一个树形结构的, 可对降级开关进行分类管理的功能也是非常必要的.
自动化运维
这里涉及到事件相关性的分析过程, 还在整理中 ... ...
碰到的问题
业务监控产品设计方向容易出现偏差, 我们需要时刻明确系统的第一用户是谁, 实际需求需要从一线开发的同学那收集过来, 不可以仅凭自己的经验进行遐想.
在公司已有的多套基础监控系统并存的前提下, 怎样推广系统, 避免重复造轮子, 使系统功能最大发挥作用.
因为是业务监控系统,跨团队沟通协调在所难免. 在公司近四个月的时间里和大大小小的14个开发团队进行沟通, 展开了30多个主题的讨论和相关需求的推动.
业务监控系统有些时候需要比普通管理系统更好的界面交互体验来帮助用户降低使用门槛, 前端资源是现阶段的一个瓶颈.
CIO之家 www.ciozj.com 公众号:imciow