目录
1.导读
2.背景
3.1 优化日志
3.2 使用链路追踪
3.3 优化监控指标
4.解决误告警
4.1 制定SLO指标
4.2 燃烧率告警
4.3 告警管理
5.掌控全局
6.整体总结
7.参考文献
8.作者介绍
导读
-
日志（Log）：记录离散事件，并以此来分析出程序的行为。 -
链路（Trace）:一般指分布式追踪数据，用于构建出用户完整的分布式调用堆栈信息。链路的主要目的是排查故障，如分析调用链的哪个方法超时或错误，输入输出是否符合预期等。 -
指标（Metrics）:指对系统某一类信息的统计聚合。通过多维度、可视化工具的展示，可以帮助管理人员快速了解系统的运行状态。 
背景
-
排错困难：部分认证方式流程长，跨越服务众多，当遇到问题时难以定位根源服务，排查主要依赖当值人员的个人经验，很难形成较为完整的思路体系，快速准确定位问题。 -
告警存在误报：告警精确率差，常因流量抖动或用户错误重试导致告警，消耗值班人员精力，以致对告警麻木，忽视真正告警信息。 -
缺乏全局性视角：对系统整体表现如何缺乏全局性的认知，例如最近一段时间系统表现如何，怎样优化等很难直观描述出来。以成功率或失败量衡量有些片面，一直处于问题来了就解决的被动状态，不利于业务的长期发展。
如何排错
3.1 优化日志
3.2 使用链路追踪
3.3 优化监控指标
针对出现告警后不能快速定位的问题，促使我们丰富监控指标，总体上将指标分为两类：SLI/SLO指标和辅助指标。SLI/SLO指标为核心指标，关联告警，辅助指标则围绕核心指标建设，用来描述SLI/SLO该指标。
如某个核心指标为认证成功率，则辅助指标为导致认证成功率降低的各项指标，如下表所示：
图4：监控指标示例
用一句话概括就是：SLO指标尽量精简，辅助指标尽量全面，当某个SLO发出告警后，查看其辅助指标即可了解异常原因，即可快速定位。
解决错误警告
流量抖动包括网络抖动、单个账号频繁重试或其他无关紧要的原因导致的短时错误量上升，这种情况的特点是短时间可恢复，很难影响服务的SLO目标，却不得不因为报警而高度紧张。假设一个服务的可靠性目标设定为99.9%，告警窗口为10分钟。那么在这10分钟内，只要错误率达到0.1%就会触发告警，一天内极端情况甚至会出现144次告警，而即便忽略这些告警，服务的稳定性依然可能是达标的，低流量导致的误报更是如此。
这种情况下告警的查全率（所有重大事件都检测出来的比例）固然很高，但精准率（所有检测事件中确定是重大事件的比例）却很差，违背了监控告警的初衷。
受google SRE思想启发，我们引入了燃烧率告警来解决因抖动而导致的误报。燃烧率告警和SLO息息相关，在介绍燃烧率告警之前，有必要重新认识下SLO。
4.1 制定SLO指标
-
100%可靠性的系统是不存在的，SLO则是衡量系统是否满足预期的关键指标，监控告警以及服务优化均以SLO为中心制定。 -
当服务不满足SLO时，需要采取如持续优化、减少更新等补救措施，具体依服务及现状确定，但是要有行动，避免SLO流于表面。 -
SLO不是越多越好，一个服务（在云认证场景中为认证类型）以2-4个为宜，最多不超过5个。 -
触发的告警必须是能够影响服务SLO指标的重大事件，尽量避免无效告警。
4.2 燃烧率告警
采用燃烧率告警主要解决误报问题，即提升告警的精准率，使精准率和查全率都保持在合理的区间。
燃烧率的告警模式是基于错误预算的，所谓错误预算，即系统在不产生约定后果的情况下可以出现故障的最长时间。一般以1个月为时间窗口，比如设置系统的SLO在4个9，则一个月内系统最多允许(1-0.9999)*24*30*60=4.32分钟的服务不可用。
而燃烧率的含义是相对于SLO，服务消耗错误预算的速度，等于当前错误率和期望的最大错误率的比值，其公式为 燃烧率=错误率/(1-SLO)。当燃烧率为1时，错误率等于期望错误率，表示按当前的错误率消耗错误预算，到时间窗口（如一个月）结束时，错误预算恰好为0。同理，当燃烧率为2时，错误率为期望错误率的两倍，在15天即可消耗完整月错误预算。
检测用时 = ((1-SLO)/error_ratio)) * 告警窗口 * 燃烧率
错误预算 =（燃烧率 * 告警窗口）/ 时间窗口
( error_ratio_rate1h > 14.4 and error_ratio_rate5m > 14.4 ) or
( error_ratio_rate6h > 6 and error_ratio_rate30m > 6 ) or ......
-
当请求量低于流量阈值时，采用更高的燃烧率，如流量阈值在100以下时，燃烧率设置200，以3个9为SLO为例，表示在1小时内，错误率高于20%才会告警。 -
当请求量高于流量阈值时，采用上述正常燃烧率。
4.3 告警管理
公司内部的告警管理平台Algalon（奥尔加隆）集成了SLO指标管理、燃烧率告警配置等众多繁琐配置，支持对监控告警的全流程管理，包括接入服务管理、SLO管理、告警及后续工单处理等，如下图是流程示意图：
经上述改造后，我们的某项业务在2周的告警数量由445次降低到了3次，召回率降低了99%，同时召回量的降低使得准确率由不到1%提升到了95%以上。
图9：公司内部告警平台流程图
掌控全局
一直以来，云认证缺少一目了然的业务大盘，目前的报表和大盘只会告诉我们今天的请求量是多少，认证了多少用户，过去一段时间的成功失败率等等，很难直观告诉我们今天云认证整体表现如何，近期表现如何，有无影响稳定性的因素出现这些全局性的答案。
如果说之前评估系统稳定性有不同角度的话，那在引入可观测性以及SLO之后，围绕SLO满足率和错误预算设计仪表盘则是一个简单且有效的办法。
如下是SLO满足率的报表示例：
监控主体为服务，时间单位为月（可以根据情况调整），各表格的n/m表示该服务包含的m项SLO指标该月满足n个，以下列表展示了6-8月各服务的SLO满足情况：
整体总结
图13：云认证可观测性体系架构图
图14：云认证可观测性体系流程图
参考文献
作者简介：
-
王同贺：58同城-信息安全部-java高级开发工程师 -
辛佳锟：58同城-信息安全部-java高级开发工程师
本文分享自微信公众号 - 58技术（architects_58）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
