更加人性化的无阈值监控不再担心无效警报，可能依赖于跨多个基于云和本地环境的数百个服务和基础设施组件，识别错误、检测高延迟原因和确定问题的根本原因。即使您已经拥有强大的监控和警报系统，您的基础设施和应用程序可能会随着时间发生变化，这很可能会导致难以可靠地检测到异常行为，而7*24小时不间断运行的后台服务、监控警报是稳定运行的基石。很多开发者都有过这样的经历。他们对服务的每一个指标都进行了严格的监控和告警，唯恐错过报警而无法发现问题，导致每天收到大量无效告警。警报的泛滥逐渐麻痹了警惕性，结果真正的问题在第一次浮出水面时被忽视，导致严重的故障。如何提高告警的有效性，在不被大量无效告警淹没的情况下准确识别问题，正是本文所要探讨的。告警是可靠性的基础首先我们来看一下告警的重要性，为什么我们要花那么大的精力去优化告警。尽管我们都希望服务无故障，但事实是没有100%无问题的系统。我们只能不断提高服务的可靠性。我们期望能够：很好地了解服务的当前状态，并且能够第一时间控制它，第一时间发现问题，快速定位问题的原因。要想做到以上两点，只能靠完善的监控告警来监控和展示服务完整的运行状态，但不可能一直盯着屏幕，也不可能关注到所有一方面，如果想被动了解系统状态，只能通过告警自动检测异常情况。因此，告警是团队监控服务质量和可用性的最重要手段。告警面临的实际问题对于业务动态变化的指标，很难设置合适的静态阈值。随着服务的变化，相关指标往往以小时、天、周为周期呈现季节性特征。这些指标本身存在波动，导致静态门槛与同比门槛匹配不佳。但是，懒惰地选择为所有应用程序/接口的响应时间、错误率、调用量等指标设置固定的阈值，自然会产生大量的误报。不同的应用对同一个指标有不同的阈值。以应用程序响应时间指标为例。部分接口正常时，响应时间可能在200ms左右。那么，当响应时间大于300ms时，就可以判断为异常。但在实际业务场景中，部分接口有大量的长时间访问，整体指标正常波动在500ms左右，所以此时合适的告警阈值可能在600ms左右。然而，一个应用程序可能有数百个接口。这时候就需要为所有接口配置合适的阈值，时间成本会变得非常高。指标的阈值会随着业务的变化而变化。随着公司业务的发展和新应用的推出，部分指标正常状态的阈值将不断发生变化。如果阈值更新不及时，很容易产生大量误报。告警设置原则每当告警发生时，运维同学需要暂停手头的工作，查看告警。但是，这种中断极大地影响了工作效率，增加了研发成本，尤其是对于正在开发调试的同学来说，影响非常严重。因此，每当我们收到告警时，我们都希望它能够真实的反映出异常，即尽可能不要误报告警（针对正常状态的告警）；每当出现异常时，应及时发出警报，即警报不能漏报（漏报）。假阳性和假阴性永远是一对矛盾的指标。以下是一些告警设置原则：告警必须是真实的：告警必须反映真实的现象，表明您的服务出现问题或即将出现问题。告警说明：从内容上看，告警要接近或详细。现象，比如服务器在某个时间点出现特定的异常告警，是可操作的：每当收到告警，一般需要进行一定的操作，最好取消一些不需要任何操作的告警.当且仅当需要进行某种操作时，才需要通知新的告警。使用保守的阈值：在告警配置之初，应尽可能扩大监控告警的覆盖范围，选择保守的阈值，尽量避免误报。告警持续优化：后续将对告警进行持续统计分析。对于误报，通过屏蔽、简化、阈值调整、更准确地反映原因等方式减少误报。这是一个比较长期的过程。以请求失败为例，如果只有在请求失败次数超过一定阈值时才发出告警，可能有多种原因。例如，一些恶意构造的请求也会触发失败次数的告警。这样的报警既不真实也不可行，因为真的不需要任何处理。对于此类情况，我们应该尽量通过特征来识别，从而更准确的分辨出告警的原因。报警工具选择观测云VSGrafanaVSZABBIXVSOpen-falconVSARM3.0阈值报警异常值检测区间检测突变检测日志检测观测云√√√√√Grafana√××××ZABBIX√××××Open-falcon√××××Grafana检测配置Grafana不仅支持丰富的数据源和图表功能，还支持告警功能，这也让Grafana从一个数据可视化工具变成了真正的监控工具。Grafana可以通过Alerting模块的配置，对监控数据中的异常信息进行告警。报警规则可以直接基于已有的数据图表进行配置。当发生报警时，它还会通知异常图表，让我们的报警通知更加友好。但是Grafana的告警的触发条件主要是通过指标频次与既定阈值的比较，相对缺乏离群点检测、突变检测等高级项。Zabbix检测配置Zabbix检测配置相对繁琐，需要大量自建检测脚本支持。配置步骤首先是创建一个检测场景，在场景中新建一个监控界面并为对应的主机创建一个触发器来创建一个新的检测。zabbix的告警规则以表达式为主，主要支持阈值检测，在离群点检测、突变检测等高级进阶项上相对欠缺。open-falcon检测配置Open-falcon与zabbix相比，具有强大灵活的数据采集能力，支持自动发现，支持falcon-agent，snmp，支持用户主动推送，支持用户自定义插件，opentsdb数据模型like(timestamp),endpoint,metric,key-valuetags）和水平扩展能力，支持亿级数据采集、告警判断、历史数据存储和周期查询，但不支持很多基础服务器监控插件（如Tomcat、apache等）而且功能相比zabbix还是不够完善。同样，Open-falcon的告警触发条件主要是指标频次与既定阈值的比较，离群点检测、变异检测等高级项相对缺失。观察云的区间检测与监控随着公司业务的发展和新应用的上线，一般的阈值检测已经难以满足我们的需求。在观察云使用区间检测后的每一次检测中，监控器都会根据指标的过去值计算出一个正常上限和一个正常下限，即一个正常区间，然后使用指标的当前值（一段时间内的平均值/最小值/最大值）value/sumvalue）与这个上下界进行比较。如果出现异常情况，监视器会发出警告。这里，我们使用局部离群因子算法（LocalOutlierFactor-LOF）。这是一种结合了距离和密度因素的异常检测算法。LOF中定义了第k距离、可达距离、局部可达密度等概念，很好地平衡了距离因子和密度因子。要在监视器中使用这个算法，我们需要使用指标过去的值来训练模型，然后计算一个或多个区间，落在这个区间内的点可以认为是正常的。具体方法是使用拟合模型在训练集的最大值max和最小值min之间遍历，比如采样1000个数据点，或者采样n倍训练集的数据点，然后相邻的正态分布合并数据点以找到所有可能的正常间隔。采样点越多，可能的区间就越多。我们可以根据需要合并较小的间隔。在特殊情况下，比如当指标表现比较稳定时，我们只能计算一个正常的区间。如上图所示，红线左边代表我们使用的过去参考值，右边代表我们需要判断的当前值，绿色阴影部分代表我们根据过去值计算出的一个正常区间.我们可以使用不同的聚合函数和比较方式来达到不同的效果。这样可以尽可能避免无效告警的发生。告警工具使用观察云监控进行间隔检测间隔检测配置基本信息规则名称：检测规则名称关联仪表盘：需要关联的仪表盘或可能受异常事件影响的仪表盘检测配置检测频率：监控算法执行周期，当前配置固定，检测间隔为5分钟、5分钟、15分钟、30分钟、1小时、1小时。检测间隔：每次执行任务时检测指标查询（获取数据范围）检测指标的时间范围：监控的指标数据，一次只允许检测一个指标（只支持指标数据）。触发条件：设置告警级别的触发条件告警级别：包括五个级别：紧急（红色）、重要（橙色）、警告（黄色）、无数据（灰色）、正常（绿色），只有一个触发可以为每个级别条件设置。触发条件：基于周期范围、异常个数、异常方向、异常点占比。如果查询结果有单位，则提示单位取整后的结果。警报级别为紧急（红色）、重要（橙色）和警告（黄色）。顺）、上或下三个检测标准。异常比例：当前区间检测到的异常方向异常点的比例超过区间。报警级别无数据（灰色）、正常（绿色）配置检测周期，如下：检测周期=检测频率自定义检测周期=检测频率*N无数据（灰色）：无数据状态支持三种配置：“触发无数据”事件”、“触发恢复事件”、“不触发事件”，需要手动配置无数据处理策略。检测规则生效后，如果第一次检测无数据且持续无数据，则不会产生无数据告警事件；如果检测中有数据，在配置的自定义检测周期内，数据上报中断，会产生无数据告警事件。可以参考以下场景：场景中最后一个没有数据的事件最后一个事件状态结果数据一直正常--数据没有中断，正常数据中断--数据中断，没有数据事件生成。新上报不存在——数据是第一次上报，正常新数据上报中有数据正常重报，数据恢复上报事件已经发送，不会产生告警事件.新数据报表没有数据。重新上报数据，数据恢复上报事件会一直没有数据——连续没有数据，不会产生告警。事件正常（绿色）：检测规则生效后，发生紧急、重要、警告异常事件后，在配置的自定义检测周期内，如果数据检测结果恢复正常，则产生恢复告警事件。可以参考以下场景：场景最后一次事件产生时间结果从未异常——没有恢复事件异常被恢复。如果自定义检测周期为15分钟，最后一次事件产生时间小于15分钟。未恢复任何恢复事件异常。定义检测周期为15分钟，在15分钟最后一个事件产生时产生恢复事件。注意：恢复报警事件不受报警静音的限制。如果未设置恢复报警事件检测周期，报警事件将不会被恢复，会一直出现在“事件”-“未恢复事件列表”中。事件通知事件名称：设置告警触发条件的事件名称。事件内容：设置告警触发条件的事件内容。它支持使用预设的模板变量。有关详细信息，请参阅模板变量。告警策略：当监听器满足触发条件时，立即向指定的通知对象发送告警信息。告警策略包括需要通知的事件级别、通知对象和告警静默时间。如何用好间隔检测在某些业务场景下，当业务出现异常时，可能导致磁盘使用异常，或者其他应用写入错误时，也可能导致磁盘使用发生变化。这里以检测磁盘使用率异常为例。当发现磁盘使用率上升较快，超出范围时，需要及时排查当前主机可能影响业务的进程。检测配置检测间隔：为了更好的检测磁盘使用异常增长，检测间隔以近15分钟获取的数据为检测依据，分析异常情况（可根据业务重要性动态调整）检测index：检测指标是目标主机，设备的内存使用指标M::disk:(AVG(used_percent))BYhost,devicetriggerconditionalarmlevelemergency（红色）：我们认为当磁盘使用发生在最近15分钟（5秒为一个聚合点）当超出范围的异常数据比例超过50%，即为紧急异常事件，需要我们及时进行人为干预和排查，避免影响线上业务的正常运行（green：当连续两个检测周期（2个检测结果内没有异常事件），我们认为当前磁盘使用异常已经检查到specific流程已经解决问题当没有数据告警时，会触发无数据告警。当没有数据告警时，需要及时检查采集的相关异常，保证数据采集正常，并触发事件。创建监控器后，发现检测频率为5分钟的任务出现波动，导致内存占用急剧上升，产生异常告警事件。查看事件详情，发现主机izbp152ke14timzud0du15z的磁盘使用率异常点超过区间边界，比例达到99.45%。也可以通过监控关联的视图来判断是否可以定位问题。可以通过查看相关的流程功能跳转到具体的流程页面进行分析，看哪个流程相对可以接受。通过分析可以判断是有人在这个业务环境中测试，导致大量资源占用。可以通过处理相关流程来进行业务恢复。当事件连续检测10个周期没有发现异常时，是因为异常已经被人为干预处理，事件的异常状态会自动调整为recovery，而不是recovered-1
