wordpress 后台密码错误,新手seo入门教程,中国咨询公司排名前十名,网站seo竞争分析工具一、告警与通知 告警与通知是服务监控平台的主要输出#xff0c;但二者是又一定差别的。 告警会在某些时间发生时#xff08;如指标达到阈值#xff09;时触发。然而#xff0c;这并不一定意味着有人被告知此事件的发生#xff09;这是通知的来源。 所谓通知#xff0…一、告警与通知 告警与通知是服务监控平台的主要输出但二者是又一定差别的。 告警会在某些时间发生时如指标达到阈值时触发。然而这并不一定意味着有人被告知此事件的发生这是通知的来源。 所谓通知是将告警告知到某人某事通过发送IM消息、发送短信/电子邮件、电话通知或创建工单等。 虽然看起来非常简单但其中通常包含众多复杂因素很难实施和管理 哪些问题需要被通知谁需要被通知如何告知他们多久告知他们一次何时停止告知以及何时升级到其他人等等、等等 如果配置不当会导致海量的告警通知产生那么人们将无法对它们采取任何行动甚至有可能故意忽略掉。笔者在工作中有这样的经历每天邮箱中充满了来自监控系统成千上万的通知邮件根本无从看起后面直接告警疲劳、直接全选告警邮件标记已读。现在来看这样一定会错过真正重要的通知。 更重要的是告警通知的内容——它们需要间接、清晰、准确易于理解且可以操作。 例如笔者曾经介绍过关于数据库慢SQL告警但整条通知内容洋洋洒洒一大堆却就是没有告诉被通知对象慢SQL具体是什么导致收到之后想要去进一步打开、定位是极其困难的。 因此对于告警的通知我们应当重点关注 应当清晰、准确、可操作。应当使用人而非计算机的语言来进行通知内容的表达。应当为通知添加上下文包含组件的其他信息。仅发送有意义的通知。 二、告警中台设计与实践 1、平台定位 告警平台是DevOps下运维中心的标配相信从业者或多或少都有了解与使用。 由于整体内容较多、文章较长笔者会分成几部分来做记录。 在这些告警平台中一般的配置过程为 选择监控对象配置告警触发条件配置告警通知对象配置收敛周期多长时间内告警不重复发送 这样的监控平台一般是以自身所提供的监控能力为准、对指标普遍来说功能可能相对单一从而造成服务的运维人员需要在不同的平台日志、调用链、拨测等配置使得告警分散难以集中配置管理、也难以对告警做统一的数据分析。 举个例子对于接口的5XX错误故障类型可以通过很多维度进行观测——接口日志、调用链分析等一般为了避免监控遗漏SRE都会对这方面做冗余告警配置也即在多个平台配置相似的监控类型接口5xx错误监控告警。 当服务真的产生这方面故障时在监控平台整体稳定可靠的基础上会同时为服务推送类似的告警这对于服务OnCall来说是冗余的。 如果能够有一个中心化的告警平台自动按照指标识别相同故障、自动收敛避免重复告警可以很大程度提升用户的告警体验。 这里我们所提出的 “告警中台” 的概念主要在于 平台本身不具备监控与指标收集能力通过OpenAPI的形式对外暴露告警能力基于指标类型、故障产生阶段、告警等级等对告警请求做约束和管理对告警通知的发送提供收敛、汇聚能力提供告警抽象汇聚、告警信息数据全量保存管理能力 这其中我们主要从以下三个角度进行设计与实现。 告警策略定义告警消息与事件告警通知发送 2、告警策略定义 基于中台化的告警策略在定义与设计上与普通的监控告警平台在告警策略有部分不同本质上有些类似于一种 “过滤器” 三方服务调用告警OpenAPI时提供必要参数筛选后找到满足条件的一条告警策略根据告警请求信息内容生成告警消息与告警事件根据告警策略详情找到告警对象、检查告警收敛情况并发起告警通知 1基于统一配置与维护的策略设计 总体来说告警策略会在中台统一托管、维护三方服务在发起告警请求时只需关注告警本身无需在意策略本身的分发、实施以及告警的收敛、恢复与关闭操作。 a、策略信息组成 策略名称 用与描述该策略的具体用途必选 指标类型 说明策略的具体指标类型必选参与标识与筛选策略的字段限定在指定范围 例如主机、数据库、状态码等 指标子类型 在某种指标下的子指标类型非必选参与标识与筛选策略的字段限定在指定范围 例如在主机类型下子类型可选为进程、CPU、内存等 告警等级 策略对应的告警等级必选参与标识与筛选策略的字段限定在指定范围 提示、轻微、严重、致命 阶段类型 策略对应的服务环境阶段必选参与标识与筛选策略的字段限定在指定范围 ALPHA、BETA、GAMMA、PROD 通知方法 告警策略通知的具体类型必选json限定在指定范围 PUBLIC公共类型告警具体通知主体通过通知策略详情记录SERVICE服务类型告警具体通知主体根据告警服务对象OnCall内容记录OnCall为独立维护二者可以同时选择样例 {notice_types: [PUBLIC, SERVICE],notice_methods: {PUBLIC: [IM, MSG, TEL],SERVICE: [IM, TEL, TICKET],}}通知策略详情 通知类型为PUBLIC时所需的告警主体信息非必选通知类型为PUBLIC时需要写明否则无法定位到通知对象限定在指定范围 IM卡片、电话、短信、提单等IM卡片需要写名群号电话短信需要写明电话号码提单需写明具体责任人 样例 {IM: [114514],MSG: [138XXXX9527],TEL: [138XXXX9527], }责任人 告警策略的定义与维护责任人 恢复周期 作用于告警原子事件恢复策略必选默认值为15分钟时间长度说明告警原子事件在多长事件无新增告警后会自动转换状态为“已恢复” b、兜底的默认全局策略 除了上述的定义为特定指标的告警策略外很多时候三方服务可能并不需要、也没有定义特定告警策略这个时候我们会提供默认的全局告警策略以作为兜底的告警策略避免致命告警未能触达OnCall等问题这里我们根据告警等级类型做了如下分类 提示非生产环境不发送 / 生产环境发送告警到服务对应OnCall工作群轻微发送告警到服务对应OnCall工作群严重发送告警到服务对应OnCall群环境级、提3级单致命发送告警到服务对应OnCall群环境级、提3A级单、打电话、发短信 需要注意的是上述策略是一种兜底策略只有在为匹配到策略时使用上述策略。 但同时也要求告警请求参数合法如果请求参数中连告警等级、对象都不携带那么我们会认为请求非法。 2策略实施与说明 在我们完成最基础的告警策略模型与相关机制设计后对于策略具体如果落地实施、以及策略与通知动作的具体关系还需要详细说明。 a、策略实施流程 在告警策略的具体实施上主要通过三方服务调用OpenAPI传递特定参数、执行策略匹配、最后由告警发送模块实施。 这里服务的接口请求参数应当包含 {alarm_type # 告警指标类型alarm_sub_type # 告警子类型可选alarm_level # 告警等级alarm_stage # 告警阶段reference_uuid # 告警对象UUID为CMDB环境层级信息 }这里简单举个例子 三方拨测服务希望发起告警并给定了以下参数 {alarm_type: dial_test,alarm_level: SEVERE,alarm_stage: PROD,reference_uuid: DEV_TOOL-ENV-9527, }中台侧接受到告警请求后解析对应字段并找到了对应的告警策略根据解析得到的告警发送方法以此发送告警 b、告警策略与通知动作 告警策略本质上是一种过滤器一方面找到对应的通知方法动作另一方面也对告警请求进行了具体识别与分类、方便告警数据归档与后续分析。 匹配策略采取DFS深度优先搜索思想进行策略查找若未查找到对应策略则会使用我们上面所定义的兜底策略发起告警对于完全无效、未按照接口参数要求的请求 我们会直接返回接口调用失败、告知参数问题我们也会打印日志、采取日志关键字告警方法根据接口请求APPID知会到对应服务OnCall 而对于通知动作而言这里主要涉及告警通知方法的解析、告警策略详情的匹配以及SERVICE下的OnCall获取。 具体流程大致如下 解析对应对应策略通知方法字段获得相应内容根据上述样例我们可以得到 告警需要发送PUBLIC类型以及SERVICE类型PUBLIC类型需要进行IM卡片、短信、电话通知SERVICE类型需要进行IM卡片、电话、提单通知 PUBLIC类型直接解析通知策略详情可得到对应IM群号、发送短信的电话号打电话的电话号SERVICE类型根据告警请求参数中的reference_uuid进行服务OnCall的查找获取服务相关信息 服务在对应告警等级、对应阶段下的IM群组号服务对应的OnCall人员包含电话号服务提单所对应的公共编码信息 汇总两种通知类型所有的通知方法和通知对象在进行去重后依次发起通知操作