网站摇奖活动怎么做,wordpress 主题类型,wordpress 用户评分,门户网站开发价格简介#xff1a;基于报告#xff0c;ARMS 能快速的整合上下文#xff0c;包括 Prometheus 监控进行监控。还有前端监控的相关数据#xff0c;都会整合到报告里面#xff0c;进行全方位检测来收敛相关问题。
作者#xff1a;延福
在开始正式内容前#xff0c;我想跟大家…简介基于报告ARMS 能快速的整合上下文包括 Prometheus 监控进行监控。还有前端监控的相关数据都会整合到报告里面进行全方位检测来收敛相关问题。
作者延福
在开始正式内容前我想跟大家聊一聊为什么要做告警平台。
随着越来越多企业上云会用到各种监控系统。这其中用 Skywalking 做 tracingPrometheus 做 matchesES 或者云上日志服务做日志相关监控随便算算就至少有三套系统了这其中还不包括云监控等云平台自身的监控平台。这么多监控平台如果没有统一配置告警的地方就需要在每个系统中都维护一套联系人这会是一个复杂的管理问题。与此同时会非常难以形成上下文关联。比如某一个接口出现问题那可能云监控的拨测在报警日志服务的日志也在报警甚至 ARMS 应用监控也在报警。这些报警之间毫无关联这是在云上做告警云很大的痛点。
其次无效告警非常多。什么叫无效告警当业务系统出现严重故障时关联系统也可能出现相关告警。而且关联告警会非常多进而将关键信息淹没在告警海洋中导致运维人员没办法及时对告警进行处理。最后现在很多报警经常发生但是没有人处理就算有人处理了但处理情况怎么样关键性告警从发生到修复的时间到底有多长每天有多少人在处理企业的 MTTR 能不能算出来这也是我们要做统一告警平台要解决的问题。 为了解决以上三个问题ARMS 的智能告警平台应用而生。
首先集成了众多监控系统包括 ARMS 本身的应用监控、云监控、日志服务等十几家监控系统并提供开箱即用的智能降噪能力。同时为了更高效的协作整个协同的工作流都可以放在钉钉、企业微信等 IM 工具上用户可以更加便捷的去处理和运维相关的告警。最后提供告警分析大盘帮助用户来分析告警是不是每天都有人在处理处理情况是什么样的。 告警要在脑海里形成抽象的概念到底分成哪些步骤
第一、从事件源产生告警事件事件是告警发送之前的状态。事件并不会直接发送进来它需要和告警的联系人匹配完成以后才能生成告警流程。这张图简单的介绍了告警的过程。这也是很多同学用系统时候会经常出现的问题配置了事件却不知道怎么样产生告警。必须要事件加联系人才能产生告警。 第二、很多同学用的告警系统默认没有接入。我们也提供了灵活告警事件源的接入方式。可以按照自定义的接入方式将事件传进来我们来清洗字段最后接入形成告警平台可以理解的告警。 工单系统举例希望系统里产生很重要的事件也往告警平台去传时可以把工单系统的报警事件通过 webhook 的方式发送到告警平台。识别并设置相关内容再通过电话或短信方式通知到相应联系人。告警平台本质上是接受事件把告警团队相关信息配到告警平台帮用户把事件给这些团队的联系人进行匹配发送。 接下来展示一下这部分能力是怎么实现的在界面上是什么样的功能。
首先打开 ARMS 控制台拉到最下面告警管理模块。我们可以看到概览其中包括大部分接入过程、事件处理流程等等。 现在已经用 ARMS 应用监控的用户,可以直接在其中先创建一个告警的规则。条件是应用响应时间调用次数大于一次的时候它就会产生一个事件。 如果是开源 Skywalking 或其他服务需要到其中去把告警规则设好把相应的事件传递过来。传递进来以后在报警事件列表里面就能看到对应报警的事件了。
报警事件发送进来以后。首先会对告警事件进行降噪处理识别告警目前最多关键词是什么样哪些关键词高度重复或者哪些内容是高度匹配的。同时根据我们给出的关键词进行压缩。比如不希望能收到来自于测试环境的告警可以把“测试”这两个字作为屏蔽词这样带“测试”相关屏蔽词的功能告警事件就不会进行二次报警。
告警事件传递过来后整个数据都会放在事件大池子里面。需要对这些事件进行分配这个事件到底谁去接收他谁来对这些事件做通知和排班管理。按照告警名称或者其他的字段等在告警里面预制的字段去匹配对 Pod 状态的异常做匹配那它会生成告警。 生成告警以后可以在联系人里面去配置相关联系人其中包括导入通讯录或配钉钉机器人等等。在通用策略里面进一步配置让用户配一个机器人或者真实的人去接受告警。也可以是对工单系统比如 Jira 等平台里面去做对接保证信息可以传递到他们那边。 配完通知策略以后一旦产生告警就可以收到相关的告警了。比较推荐您使用的是通过钉钉来接收相关的报警。
这里展示一下怎么样通过钉钉来接收相关的告警。比如这是我们接收到钉钉相关告警。在接收到这个告警以后对这条告警消息只需有一个钉钉账号不需要有理解这些相关信息或者登录到系统直接对这个告警进行认领。因为和钉钉系统深度集成可以去认领告警也可以在认领完以后点解决这条告警。 我们会把过程记录在活动里面。用户就会知道认领和关闭告警的整个过程。同时每天会针对情况做统计比如今天发生告警的数量是否有处理哪些没有处理整体处理情况是怎么样的。如果团队比较大有非常多运维同学而且会有 L1 和 L2 分层运维同学的时候可以使用排班功能进行线上排班。比如这一周是某个同学接受告警下一周是另外的同学。同时也可以做升级策略的排班管理。重要告警在十分钟内没有人去做认领时对重要告警做相应升级。 作为运维主管或运维总监需要了解每天发生的这么多告警经过一段时间后它是不是有收敛或平均 MTTR 用了这些工具以后有没有提升。我们提供了告警大盘通过这个告警大盘可以了解到每天告警平均响应时间以及大家处理情况。MTTx 相关时间等统计数据会在这个大盘里面给用户进行展示同时这个大盘是集成在 Grafana 上面可根据实际需求把相关数据放 Grafana 上或者您的 Prometheus 数据源里面做二次的开发。 告警不仅是管理和收集的过程。很多时候虽然发现了告警。在告警处理过程中阿里云是否可以提供一些建议参考。对此我们也提供了相应功能来增强这一块的能力。 首先基于类似应用监控的产品提供一系列默认报警能力。一旦产生相关报警我们会提供相关诊断能力。在如上图 20 多种场景下会提供自动诊断报告。
举一个例子应用的响应时间做突增我们会生成一个直观的报表。在这个报表中会告诉你当前突增的原因是什么。然后会整体的检测这个应用突增以后到底是哪些因素导致的。一般来说这个诊断逻辑和普通的诊断逻辑是一样的。应用突增会去先检测一下多个主机是不是有突增然后是不是接口有突增。这些接口如果它响应时间的数据特征是和整个应用一致会在进一步分析这个接口里面到底又是哪些方法有突增他传递的入参是什么为什么有这样的突增同时我们也会给出来一些特征请求告诉用户慢的请求是怎样运行的。
以这个 version.json 接口为例它是在对应的这个时刻与应用有类似的突增。主要的核心方法就是这样一个方法导致了接口缓慢。 同时我们结合当时打出来的堆栈可以再次确认当时就是个 handler 方法导致了它的缓慢那接下来我们就可以结合代码进一下进一步的优化了。
这就是 ARMS insight 针对常见问题深入分析的一个 case。基于报告ARMS 能快速的整合上下文包括 Prometheus 监控进行监控。还有前端监控的相关数据都会整合到报告里面进行全方位检测来收敛相关问题。
原文链接
本文为阿里云原创内容未经允许不得转载。
