网站策划工具上传wordpress到服务器要多久

网站策划工具,上传wordpress到服务器要多久,橙色短信网站模板,汽车网站有哪些莺的告警逻辑整体是追随 Prometheus 的逻辑#xff0c;本文默认你已经对 Prometheus 的告警逻辑比较清楚。前置知识夜莺有两个进程#xff1a;n9e 部署在中心#xff0c;既是告警引擎#xff0c;又是 webapin9e-edge 部署在边缘机房#xff0c;作为告警引擎夜莺作为告警引…莺的告警逻辑整体是追随 Prometheus 的逻辑本文默认你已经对 Prometheus 的告警逻辑比较清楚。前置知识夜莺有两个进程n9e 部署在中心既是告警引擎又是 webapin9e-edge 部署在边缘机房作为告警引擎夜莺作为告警引擎可以对接多种数据源哪些告警引擎负责哪些数据源的告警判定是需要用户告知夜莺的。所以启动夜莺的进程的时候要做好规则在 config.toml 配置文件里指定 EngineName即引擎的名字相同名字的引擎会当做一个引擎集群要在夜莺里配置数据源的信息包括连接地址以及和告警引擎集群的关联关系然后告警引擎就开始干活了对自己负责的那些数据源做告警判定。告警判定是需要有告警规则的即哪些监控指标阈值是多少需要用户给出。所以需要用户在夜莺页面上配置告警规则可以导入内置的现成的一些告警规则然后二次修改。OK进入正题。告警处理流程概述我们来看整个告警流程示意图image用户在 Web UI 配置告警规则规则保存在 DB 中通常是 MySQL。告警引擎n9e 进程内置一个告警引擎边缘模式下 n9e-edge 进程里也内置告警引擎从 DB 同步告警规则到内存中通常 n9e-edge 无法直接读 DB是调用的中心端 n9e 的接口获取的告警规则。告警引擎会为每条告警规则创建一个 goroutine协程姑且可以理解为轻量级线程按照用户在告警规则里配置的频率周期性查询存储对数据做异常判定最终生成告警事件。产生告警事件后判定是否被屏蔽了如果被屏蔽了直接丢弃事件否则要把事件持久化到 DB 中通常是 MySQL然后再走后面的通知规则。通知规则包含两部分一个是若干事件处理器比如 relabel、event update、event drop、ai summary 等另一个是若干告警通知配置比如 Critical 的告警事件打电话、发短信Warning 的告警事件只发邮件。1. 生成告警事件这块逻辑和 Prometheus 很像只不过 Prometheus 只支持对自身 TSDB 的数据做告警判定夜莺支持其他更多类型的数据源。以 Prometheus、VictoriaMetrics 等时序数据源为例夜莺会根据告警规则里的 promql 查询数据按照执行频率周期性查询查到了就认为有异常数据就要产生告警事件如果配置了持续时长则要连续等待更长时间每次都查到异常数据才产生告警事件。产生告警之后如果后面某次查询查不到对应的异常数据了就认为告警恢复。如果配置了留观时长则要多等待留观时长对应的时间这个时间内没有再查到异常数据才算恢复。注意告警之后如果新的监控数据写入时序库有延迟比如数据采集链路出了问题或者变慢了告警引擎查询的时候查不到数据也会报恢复。因为引擎分辨不出是数据不符合阈值了所以没有返回还是数据延迟了所以没有返回。2. 告警事件的数据结构告警事件是根据告警规则查询数据源产生的。告警事件有很多属性以及标签。属性比如告警级别、规则标题、事件状态、触发时间、触发时的值等里边很多属性是来自事件对应的告警规则标签事件的标签有两个来源一个是查询数据源返回的数据里的标签一个是告警规则的附加标签比如某个告警规则其 promql 为 disk_used_percent0根据这个 promql 查到的数据为image那就会产生 3 条告警事件因为 promql 返回了 3 条数据3 条数据的标签不同用于区分三个事件。后续的各类规则比如屏蔽规则、订阅规则、通知配置都要对告警事件做筛选核心就是按照告警事件的属性、标签进行筛选。3. 告警屏蔽告警事件产生之后会去找告警规则所属的业务组下面是否有屏蔽规则如果有就拿着这个告警事件挨个去匹配屏蔽规则如果匹配了某个屏蔽规则则告警被屏蔽直接丢弃告警事件不会写入 DB。后面可能会修改这块的逻辑屏蔽的告警事件也存 DB只是打个“已屏蔽”的标记。注意屏蔽规则只生效在同业务组下的告警规则产生的事件。防止某个新兵配置了一个全局屏蔽规则把公司所有告警都屏蔽了。屏蔽规则的多个条件之间是 AND 的关系即 与 的关系这点请注意。官网文档里也有相关说明这里不再赘述。4. 告警事件持久化告警事件如果没有被屏蔽就要入库持久化写入 alert_his_event 表这是所有历史事件的全量存档表同时也会修改 alert_cur_event 表这是活跃告警表即当前尚未恢复的告警事件的一个表。如果从细节来讲其实可以把告警和事件区分开后面版本的夜莺可能会做这个改进。比如 a 机器 mem_free 指标在 10:00:00 告警了产生了一条告警事件其 id 是 1hash 是 xx告警规则里通常会配置重复通知每隔 1h 重复产生一条新的事件。即 a 机器 mem_free 指标在 11:00:00 会再次产生一条告警事件其 id 可能为 2hash 仍然是 xx。这两条事件是在两个时刻产生的是两个对象所以 id 不同但是确实都是说的一个事都是 a 机器的 mem_free 告警所以 hash 值相同后面告警恢复的时候会产生一个新的事件其 id 可能为 3hash 值仍然是 xx这样才能关联起来。有了上面的讲解alert_cur_event 表的更新逻辑就成了来了一个新的事件根据这个事件的 hash删除 alert_cur_event 的记录如果这个新事件是恢复事件就啥都不用干了相当于恢复告警就要从活跃告警里清理掉如果新事件是告警事件就把最新的事件写入 alert_cur_event这个设计其实不太好在整个体系里只有 event 的概念没有 alert 的概念少抽象了一个领域对象。后面的版本可能会改进。5. 事件关联通知规则告警事件产生了后面可能涉及对告警事件的二次处理比如做 relabel、做过滤等以及把告警事件投递发送出去。这就涉及到“通知规则”了。那告警事件具体和哪个通知规则关联呢在夜莺里有两种方式告警规则里直接配置通知规则这个告警规则产生的所有告警事件都直接走这个通知规则使用订阅规则订阅规则相当于是写了一个告警事件的筛选条件会筛选到一堆告警事件筛到的这些事件交予订阅规则里配置的通知规则去处理通常走第 1 种方案就可以了对于某些全局级别的通知规则可以走方案 2。6. 通知规则通知规则最核心的是配置通知媒介和告警接收人。之前这些信息是在告警规则里直接配置的感觉不灵活从 V8 开始单独提取出来了。如果各个团队分别收告警通常每个团队要对应一个通知规则在这个通知规则里一次性配置好什么样的告警发什么通知媒介然后这个团队的所有告警规则都绑定这个通知规则即可。通常根据告警级别定义不同的通知媒介比如Critical 的告警打电话、发短信、发邮件、钉钉Warning 的告警只发短信、发邮件、钉钉Info 的告警只发邮件、钉钉通知这里还要对两个东西做实体建模抽象一个是通知媒介一个是消息模板。V8 版本可以很方便对接一个企业内部的通知媒介。具体可以参考相关文档这里不再赘述。7. 事件处理器V8 还引入了一个事件处理器的概念可以把多个处理器组成一个 Pipeline通知规则里可以引用多个 Pipeline。这里的思考是告警事件产生之后可能有各种不同的处理比如做 relabel、filter、enrichment 等Pipeline 相当于抽象了一个 workflow让用户在事件处理的链路上插入一些自定义的逻辑给用户极大的灵活性。