泰钢材企业网站源码巩义网站建设工程

泰钢材企业网站源码,巩义网站建设工程,wordpress代码优化,漫画网站开发说明一、为什么传统巡检不够用#xff1f; 传统的巡检系统都是基于固定阈值来判定指标是否异常#xff0c;一般为了防止产生过多的指标异常信息#xff0c;这种阈值设置的都偏高。虽然这种方式也能发现异常#xff0c;但是场景过于单一#xff0c;无法感知指标的动态变化&…一、为什么传统巡检不够用传统的巡检系统都是基于固定阈值来判定指标是否异常一般为了防止产生过多的指标异常信息这种阈值设置的都偏高。虽然这种方式也能发现异常但是场景过于单一无法感知指标的动态变化例如在业务逐渐进入高峰期时数据库的QPS、负载或者数据体量也都是逐渐升高的等达到日常的异常阈值再处理时间上会比较紧张而如果能提前发现数据库核心指标的变化以及变化幅度那DBA就能提前介入分析和处理也减小了因为负载过高或者容量紧张带来的业务异常的可能性。二、异常检测巡检的“第二双眼睛”近年来机器学习和人工智能技术快速发展为时序监控提供了新思路机器学习可以从历史数据中找到自身的规律识别出常规之外的行为。去哪儿网DBA将时序监控数据的异常检测运用到日常巡检中通过智能分析来发现数据库指标的动态变化异常。整体思路如下特征分析有些实例的指标具有周期性的变化规律在周期内可能会出现快速的上涨或下降这种符合周期性变化的场景不应该算作异常例如部分Redis内存的使用量会在夜间快速的降低而在早上又快速的上涨需要把这种具有周期性规律的实例提取出来进行周期性检测。而有些实例的指标或许是持续平稳上涨的如MySQL服务器磁盘使用量一般是平稳增长的如果短时间内上涨很多那么就可能有异常。所以第一步我们需要把实例指标的周期性平稳性等变化特征进行提取。算法选择根据不同特征需求使用不同的转换算法或异常检测算法进行处理。通过滑动窗口法将监控数据转换生成新的曲线通过四分位距法进行异常点的检测通过周期检测算法将有周期性规律的指标识别出来并且获得周期长度检测出不符合周期规律的情况通过水位检测识别出指标水位突然上升的情况等等。调优通过算法识别出来的异常点不一定是真实业务场景的异常点因为异常算法只是从数学的角度进行的检测即使考虑到历史规律特性在某些场景下的算法识别的异常点我们并不需要处理所以最终结果需要通过动态阈值和静态阈值参数相结合。机器学习可以通过历史数据自动计算出动态阈值可以通过窗口大小、灵敏度等算法参数影响动态阈值的变化但有些场景还需要静态阈值给予辅助判断例如磁盘空间虽然快速上涨如果使用率还很低这种场景我们暂时不需要做任何处理也就不需要把它识别成异常点所以需要设置一个上边界阈值。通过一些特定的参数和静态阈值对不同的指标不同的集群赋予一些特殊的意义我们希望最终暴露出来的异常点都是我们需要处理的场景。另外一些已知干扰项例如节点迁移改表工单参数配置不合理等也需要考虑进算法中。报警收敛为避免同一消息发送很多次从一个报警第一次发送开始计时同一个消息在近n个小时只发送一次消息剩下的报警在原消息的内容上更新只显示最新的检测内容。另外一个集群的多个实例同时报警收敛为一个消息一组集群同时报警收敛为一个消息这样大大减少了报警数量,可以避免由于接收到大量的相同消息而把其它需要关注的消息忽略掉。三、三大典型应用场景3.1 平稳趋势异常检测MySQL服务器磁盘使用量、服务器内存使用量、Redis内存使用量等绝大部分监控指标的监控曲线特征基本是相同的也就是正常情况下趋势平稳平稳上升/下降或者变化趋势不明显这类监控指标在底层可以共用一套异常检测逻辑通过不同的参数来调整各自的特征。上面再封装一层不同的业务检测逻辑进行定制化减少误报。本章节以MySQL磁盘使用率检测为例进行介绍。3.1.1 场景分析MySQL磁盘使用率一般都是均匀上涨的如下面监控曲线展示在红框标识的范围之前使用率变化非常平稳对于这种场景如果使用率突然增加可视为异常如红框范围内的数据报警信息如下3.1.2 平稳趋势异常检测实现平稳趋势异常检测使用的DoubleRollingAggregate算法是一种窗口检测算法其主要原理如下在监控曲线上创建两个滑动窗口每个窗口覆盖n个监控点可设置两个窗口依次从左向右滑动右窗口的平均值-左窗口的平均值的结果生成一条新的曲线也可以根据需求计算每个窗口的中位数/最大值/IQR等指标得到的数据曲线如下新曲线小于0的点说明是原曲线在下降新曲线大于0的点说明是原曲线在上升曲线上绝对值越大那么变化上升/下降的幅度就越大。可以根据新曲线大于0/小于0的点的个数占总点数的比例来判断整体趋势上升或下降的程度。窗口大小可调节窗口越大结果越平缓IQR检测时越能消除噪音负面影响就是可能漏掉一些异常点。3.1.3 检测调优根据磁盘增长的特性检测逻辑如下:首先对主机进行筛选例如对于磁盘使用率小于50%的主机不进行检测。增长幅度大于设定阈值说明增长过快则判定为异常。最近使用率大于设定阈值则判定为异常和普通的固定阈值异常检测相结合。和具体场景结合a.在磁盘使用率小于设定阈值时检测到有变化异常但是异常时间范围内有对应实例中的表在执行DDL操作功能且工单执行时间范围和异常时间范围吻合度较高则不记为需要关注的异常现象。b.在磁盘使用率小于设定阈值时检测到有变化异常但是有数据在往其主机上进行迁移迁移执行时间范围和异常时间范围吻合度较高则不记为需要关注的异常现象。主机磁盘使用辅助报表有些实例没有设置max_binlog_files参数只设置了保留7天的binlog在有归档任务时可能会产生几百G的binlog导致磁盘异常上涨这种场景会把这台服务器上的所有实例信息展示出来包括参数配置binlog大小等信息方便快速定位问题。所以在磁盘使用量异常报警消息中增加了一个辅助报表协助DBA定位磁盘使用异常的原因。报表内容如下3.1.4 稳定性算法延伸稳定性算法通过调整一些参数就可以检测到长期缓慢增涨的场景例如下面监控图是MySQL扫描行数的监控图由于业务新上线了一个sql随着表数据量增加和执行频率增加导致实例扫描行数长期缓慢上涨在造成严重的慢查询前需要检测出这种异常来。具体实现如下先过滤出近一天最大扫描行数大于设定阈值的实例。对于这种长期增长的检测可以简化为对比每天高峰期时间扫描行数异常变化的检测取每天高峰时间内的一个监控点连续取近30天的监控数据然后对这30个监控点进行平稳性异常检测如设置窗口大小为5每个窗口取最大值计算两个窗口的差通过判断新曲线正值的比例即可判断出这种增长异常。为什么不简单的使用扫描行数大于某个阈值就视为异常呢首先各个实例对应业务场景不同阈值的设定无法进行较好的统一设置较低告警信息太多设置较高会导致漏报。如果和趋势判断结合就能弥补固定阈值检测导致的漏报问题并且可以提前发现风险进行介入处理。3.2 周期性变化异常检测对于实例的QPSMySQL的扫描行数Redis内存使用这些指标有些业务场景下是具有周期性变化规律的。但是最近一段时间突然脱离了周期性的变化范围或幅度这种异常情况也需要进行识别本章节以Redis周期性内存使用量异常检测介绍符合周期性变化特征的异常检测。3.2.1 场景分析以下是一个Redis实例内存使用率监控数据:从监控图上可以看出该Redis实例的内存使用有两个明显特点内存使用量呈现以一天为周期的变化规律。在周期内Redis使用量具有波动性。对于这种情况我们重点关注的是连续周期的变化趋势是不是一致的最近的变化和之前的同周期变化有无较大差异而对于单个周期内的增减变化不予以重点关注。通过周期性异常检测算法检测结果如下红色的监控点是检测出来的异常点。可以看出最近一个周期的变化量明显高于前面的。报警消息如下:3.2.2 周期性异常检测算法实现原理周期性检测通过SeasonalAD算法实现此算法通过pipenet连接多个数据转换器和异常检测器来检测出异常点具体流程如下a.数据转换器deseasonal_residual: deseasonal_residual通过ClassicSeasonalDecomposition算法去除周期性的规律特性。基于自相关函数(ACF)获取周期长度经典的周期性分解假设时间序列是由趋势项 (trend)、季节项 (seasonal pattern) 和噪声即残差 三部分加和而成的。此步骤通过移动平均计算并移除趋势成分通过计算去趋势化后序列在多个季节周期上的平均值来提取季节模式最终返回残差序列。 返回的结果如下b. 异常分析异常分析通过由两条检测链路进行检测然后取两个链路结果交集。链路1 sin_check用于检测上升的异常或检测下降的异常或者都检测通过参数side设置。例如side positive那么sin_check输出的异常点是所有deseasonal_residual大于0的点如下这样再和链路2的iqr_ad求交集后就只剩下iqr_ad上涨的异常点了。链路2中有两个算法首先是abs_residual用于计算deseasonal_residual结果的绝对值转化为绝对值是为了在使用四分位距法检测异常时便于计算转化为绝对值后的结果如下通过abs_residual转换的结果再通过iqr_ad(InterQuartileRangeAD)的四分位距法计算离群点检测结果如下其中红色为离群点异常点:最后将链路1 sign_check检测出来的异常点和链路2 检测出来的异常点求交集得到最终结果如下其中红色部分为我们需要关注的异常点:在原始监控图标识出上面检测到的异常点得到的最终结果如下3.2.3 检测调优在使用周期性变化异常检测之前首先要识别出要检测的指标是否具有周期性变化的规律通过机器学习模型训练对近n天的监控数据进行分解周期特征计算自相关性来获得周期信息。一般情况下这种周期性规律不会有很大的变化所以在初始节点将需要进行检测的指标全部遍历检测一遍然后将符合周期性的集群信息记录到元数据库中后面再定时更新相关元数据。在进行周期性变化异常检测时只检测数据库中有相应记录的集群即可。另外对于有周期性变化规律的集群指标在进行平稳性异常检测时可以很好的进行过滤或者设置特殊的阈值。在使用周期性变化异常检测时还需要有其他检测标准进行联合判断否则可能会导致很多无效的异常信息在满足下列其中一项条件的情况下对于Redis内存使用量检测即使周期性变化监测到有异常行为也被视为安全范围内的异常波动不需要关注和进行消息提醒检测时间范围内如果Redis内存使用量或使用率小于一定阈值。实际使用内存最大值-最小值的差小于设定阈值(波动小)。在一定时间段内异常点的数量小于设定阈值。3.3 突变异常检测这种情况是指在很短时间范围(瞬时)内监控指标突然发生较大幅度的变化下面以MySQL服务器CPU水位变化检测和QPS异常检测为例分别介绍。3.3.1 MySQL服务器CPU水位变化3.3.1.1 场景分析正常情况下MySQL的CPU水位在20%以下常规报警阈值设置为50%在达到报警阈值之前如果cpu水位突然上涨并持续一段时间说明业务有不合理的请求需要关注。 如下面所示的监控曲线在16:25时间点突然上涨约一倍的量并一直持续保持在30%的使用率对于这种瞬时突变的场景应视为异常现象:图4-1-1报警信息3.3.1.2 水位监测实现原理水位突变检测使用LevelShiftAD检测算法它使用了多个转换器和检测器通过pipenet连接起来。链路1先用DoubleRollingAggregate(diff_abs)算法进行数据转换,同时使用两个滑动窗口从左向右滑动计算两个滑动窗口的中位数的绝对差值(Absolute difference)产生一组新的时间序列。再通过InterQuartileRangeAD(iqr_ads)四分位距法计算离群点。diff_abs将图4-1-1监控数据转换成新的时间序列形成的曲线结果如下:将diff_abs转化后的时间序列作为iqr_ads的输入通过iqr计算出异常点,异常检测之后的图示结果如下红色点是异常点链路2同样先通过DoubleRollingAggregate(diff)算法进行数据转换不同的是这次是计算的两个窗口中位数的差值产生另一组新的时间序列形成的曲线如下。然后再通过ThresholdAD(sign_check)算法检测异常点。sign_check作用和周期性检测中的sign_check一样,用于区分方向性这里只检测水位上升所以所有正数都是异常点。 图示结果如下链路1和链路2的检测结果求交集获得最后的结果检测出水位突然上升的边缘图示如下3.3.1.3 检测调优通过静态参数过滤掉一些没有必要的报警例如如果cpu的最大值小于阈值则不算异常。如果最近几个点的平均值小于阈值则不算异常因为已经恢复了没必要重复报警。一些BI类业务设置高阈值。3.3.2 QPS异常负增长检测QPS虽然波动很大但一般都是向上突增即使有向下的波动其变化幅度也不应该很大。如果一个实例的QPS突然降低到几乎为零然后又快速恢复那这种情况是存在异常的。本章节介绍检测QPS掉0的场景。注意这里说的掉0是突然降低到很低的水平不一定全是0。3.3.2.1 场景分析在大事务提交时由于写binlog耗时长将Binlog Events写入Binlog文件的过程必须要串行执行只有一个事务写完了另外一个事务才能执行这时可能导致写操作掉0。低版本的MySQL是单线程复制从节点应用大事务时也会导致从节点QPS掉0并伴有主从延迟。如下监控所示在约16:30时刻QPS突然大幅度降低然后又快速恢复。通过异常检测算法检测出来的效果如下(红色点是异常点)3.3.2.2 算法实现原理这种指标突然掉0的异常情况使用IQRInterquartile Range四分位距检测可以快速地把异常值筛选出来。IQR是统计学中衡量数据分散程度的指标特别适合处理非正态分布或存在异常值的数据。通过聚焦数据中间50%的分布范围规避极端值干扰是数据分析中稳健的离散度度量工具。很多异常检测都是把原始数据转换后通过IQR进行的离群点检测是一种基本的离群点检测算法。IQR 描述的是数据集中“中间50%”的数据范围详细概念如下将数据从小到大排序后平均分成4段Q1第1四分位数排名在前25%位置的数值例班级考试第25名的分数Q3第3四分位数排名在前75%位置的数值例班级考试第75名的分数IQR Q3 - Q1 ,即中间50%数据的跨度如下图示若数据超出 [1−1 * , 32 * ] 范围则视为异常值。举例说明# 把监控数据从小到大排序后数据如下 data [5,7,10,15,19,21,21,22,22,23,23,23,23,23,24,24,24,24,25] len(data) # 19 # 散列图 import matplotlib.pyplot as plt plt.scatter(range(len(data)),data) # 直方图 是频率分布 plt.hist(data)# 第一个四分位数 Q1 df.number.quantile(0.25,interpolationnearest) Q1 # 19 # 第三个四分位数 Q3 df.number.quantile(0.75,interpolationnearest) Q3 # 24 #四分位间距IQR IQR Q3-Q1 IQR # 5 # 假设c1设为1.5第一个四分位数以下并检查较低的离群值。小于这个值的数为异常点 Q1 - 1.5*IQR #11.5 # 假设c2设为1.5,第三个四分位数以上并检查较高的离群值。大于这个值的数为异常点 Q3 1.5*IQR # 31.5正常范围是 [1−1 * , 32 * ] [11.5,31.5]所以超出[11.5,31.5]范围的点认为是异常点5710这3个点是小于下限点异常点没有大于上限的异常点。3.3.2.3 检测调优在实际场景中很多集群的QPS波动幅度很大且没有明显的规律性从数学意义上的离群点中过滤出我们需要关心的异常点是此检测项中的重点。首先我们需要明确这种场景下我们只想检测出突然掉为0的这种变化比较极端的情况所以c2设一个很大值不检查突增的异常点c1设一个合理值这样可以检测出突然掉0的异常点。因为这种掉0的情况持续很短检测监控点的时间范围一般不能太长否则容易丢掉异常或者有误判所以从prometheus获取监控数据的step设为了15s提高采集精度。如果由于故障导致QPS长时间掉0那么其他核心指标也会出现异常数据库报警会发现这种情况进行报警这种情况不在该异常检测场景中。在做这种突然掉为0的极端变化异常检测时还需要考虑周期性和先突增又突降的情况a.周期性下降上图这种周期性掉0的情况不应该算做异常需要剔除掉。检测思路如下计算近一段时间是否具有周期性规律如果有周期性规律计算出一个周期的长度n(一个周期里有n个监控点)计算最近连续的2个低水位的异常点的平均值a获得这2个点对应的前一个周期同一时刻的监控平均值b和前两个周期对应同一时刻的监控平均值c对比a和b的绝对值a和c的绝对值因为正常情况下异常点的值都很小所以这里用绝对值进行比较没有用比例。如果绝对值差别不大说明此次掉0是具有周期性的不算做异常。从历史曲线中计算出周期长度的思路如下因为非等间隔采样会破坏自相关计算的基础,需要先检测输入的监控点是否连续相邻的时间戳的差是否相等。使用自相关函数ACF计算自相关性,获得自相关系数寻找有效自相关起点。检测显著峰值。如果有多个候选峰值获得自相关值最大的位置返回周期长度。对周期性下降检测处理后的结果如下这种不会发送巡检异常消息这里为了展示处理效果。b.水位上升然后下降上图这种下降后持续保持低位可能是有任务导致的IQR检测时取的近30分钟的数据但定时任务可能执行很长时间所以这里取近10个小时的监控数据如下需要把这种水位上升之前qps本来就很低的场景识别出来这种场景不应该算作异常。水位异常变化的场景基于LevelShiftAD算法检测,和MySQL服务器CPU水位检测算法一样检测结果如下。这样就获得了levelshift变化的异常点但这种异常点有很多例如上图中水位高的这部分中又有一个峰值(qps大于1000的这部分)需要进行处理。从iqr返回的异常点中获取最近一段连续的异常点求最小值min_iqr这个值就是最近的qps掉0时的值。从levelshift返回到异常点中从右向左遍历获取每组连续的异常点剔除最右边的一组(这组是qps下降的点),获取剩下的异常点的值因为窗口法滑动时有滞后性所以还要获得每个异常点左边的window个点的值(window为一个窗口覆盖多少个点)求最小值min_ls,比较min_iqr和min_ls的绝对值如果水位增长前的点和iqr最近的异常点的差值在很小的一个范围内或者min_ls比min_iqr还小则认为水位前后的qps一样不算做异常。为了调试方便把详细过程发送到消息里:四、实战经验与调优目前我们已经在线上成功部署了CPU/磁盘/内存/表大小/QPS/扫描行数等十几个关键指标检测项系统报警准确率在80%以上显著提高了巡检效率并有效减少了常规报警数量。在算法策略方面 我们认识到不同指标具有各自的数据特征无法依赖单一算法覆盖所有场景。因此我们通过对指标进行相似特征归类提取其数学意义上的共性对同一类指标采用适配的算法体系。目前通用算法已覆盖约 80% 的检测需求其余部分则通过定制化逻辑精准补充。我们将算法与业务场景深度结合主动识别并过滤由 DDL 工单执行、数据迁移等不定期操作引起的指标波动。这类业务行为属于正常范畴不应触发异常报警从而有效降低误报率。在阈值管理方面采用动态与静态相结合的策略动态阈值通过机器学习自动学习指标历史规律实现敏感度的自适应调整静态阈值则作为硬性边界提供兜底保护防止极端情况下的漏报。针对报警通知我们实施了多维收敛机制纵向收敛基于时间窗口对连续出现的同一报警进行合并与消息更新横向收敛依托关联分析对同一集群下多个实例的相同报警或同一业务组内多个集群的同类报警进行聚合处理从根源上避免告警风暴提升告警可读性和可操作性。五、未来展望在推进智能异常检测系统演进的过程中我们坚持由简入繁、循序渐进的策略首先从单指标异常检测入手逐步拓展到多指标联合分析最终实现自动化的根因定位。目前去哪儿网DBA团队已在单指标检测方面覆盖绝大多数运维场景并针对特定集群和业务需求完成了定制化处理有效提升了检测的适用性与准确性。当前我们正稳步推进多指标联合异常检测的探索与实践旨在通过指标间的关联分析进一步提升检测覆盖率和精准度。未来系统将逐步承担更多自动化诊断工作帮助DBA减少重复性巡检负担使其能够将精力聚焦于更高价值的技术优化与紧急故障处置中。