商城网站源码免费,网站建设 设计创意,网络安全公司排名前十名,济南本地网站建设公司简介#xff1a; 在云原生和DevOps研发模式的挑战下#xff0c;一个系统从开发、测试、到上线的整个过程中#xff0c;会产生大量的日志、指标、事件以及告警等数据#xff0c;这也给企业质量平台建设带来了很大的挑战。本议题主要通过可观测性的角度来讨论基于海量日志和时…简介 在云原生和DevOps研发模式的挑战下一个系统从开发、测试、到上线的整个过程中会产生大量的日志、指标、事件以及告警等数据这也给企业质量平台建设带来了很大的挑战。本议题主要通过可观测性的角度来讨论基于海量日志和时序数据的质量建设最佳实践。 作者 | 寂之 来源 | 阿里技术公众号
一 前言
在云原生和DevOps研发模式的挑战下一个系统从开发、测试、到上线的整个过程中会产生大量的日志、指标、事件以及告警等数据这也给企业质量平台建设带来了很大的挑战。本议题主要通过可观测性的角度来讨论基于海量日志和时序数据的质量建设最佳实践。
二 质量建设痛点
众所周知在云原生开发模式下可观测性是非常重要的一部分它通过日志、指标、Trace等数据让我们可以深入了解系统的运行状态和健康程度。在 CNCF Landscape大图中可观测性也占据了相当大的一块位置。
然而在实际使用过程中许多人对可观测性的关注主要集中在系统上线之后。这当然是没有问题的但实际上从一个系统开发开始一直到线上运行都是可以从可观测的角度来对系统的质量进行评估和衡量我们可以称之为对质量的观测。
下图比较概括地描述了一个系统的质量观测完整生命周期大体上可以分为如下四个阶段并且在每个阶段都有需要特别关注的一些数据和指标
开发阶段重点需要关注代码的质量例如静态代码扫描以及依赖检查会发现潜在的代码缺陷和安全风险由此我们可以统计千行代码缺陷率或者严重缺陷比例从而来衡量一个系统的代码质量是否符合要求测试阶段在此阶段需要重点关注测试的质量例如测试覆盖率以及测试用例的失败率等指标灰度验证需要关注系统的稳定性以及不同版本之间的差异因此也会有一系列的业务指标例如HTTP Error 比例不同版本的延迟等指标的对比线上运行此时需要重点关注系统的稳定性以及业务的稳定性因此各种线上的性能指标、业务指标、应用日志、Trace等各种数据都是非常重要的
在整个质量观测的生命周期中除了各种各样的数据我们也会涉及到各种各样的系统例如 GitLab、sonarqube、Allure、JMeter、Jenkins、Travis CI、Argo CD 等等。这些不同的系统作用于不同的阶段会产生大量的异构数据如何对这些数据进行合理的管理和使用从而可以比较方便地挖掘出其中的数据价值不局限于软件质量方面对我们来说是一个比较大的挑战。
基于上述的讨论我们可以大体总结出质量观测的几个痛点
海量的异构数据在系统开发、测试、验证、上线等各个阶段产生了大量的日志、时序、Trace 等数据这些数据产生的位置、数据格式、以及存储的位置都有可能是不一样的。如何从这些数据中快速精准地挖掘出潜在的质量问题比较困难。依赖规则缺乏智能质量监控比较依赖于人的经验很大程度上受限于人为设定的规则和阈值无法做到数据自适应因此无法发挥出真正的数据价值。另一方面就是随着系统的发展和演进需要大量的人工干涉和不断调整才能够让监控比较有效。告警风暴与告警误报为了不错过细微的问题我们可能会配置大量的监控从而导致在完整的软件生命周期中可能产生大量的告警难以从其中识别出有效信息。另外大量的告警也带了很大程度上的误报问题从而导致“狼来了”效应于是真正的问题反而很容易又被忽略掉。这就陷入了恶性循环。
三 数据统一接入和管理
1 海量数据管理痛点
首先我们来探讨第一个痛点也就是如何对海量的异构数据进行管理。目前可观测性相关的系统五花八门。
例如日志可能会使用 ELK 或者 Splunk指标会使用 PrometheusTrace 使用 Skywalking、Jaeger 或者 zipkin。但太多的选择也不见得是好事在这种情况下可观测性数据的管理又给我们带来了如下几个痛点
运维成本高完整的质量系统需要数个甚至十多个软件的协同从而也带了极高的运维成本。学习成本高每个软件都有自己的使用插件、插件系统有些还会有自己的DSL语法学习成本非常高很难完全掌握使用。扩展困难随着数据规模的增长软件的扩展能力、性能、稳定能力等方面都会有很大的挑战。数据孤岛不同的数据处于不同的系统中协同困难。例如想要将 ES 中的日志和 Prometheus 中的指标进行一个 Join 查询就无法实现除非做额外的二次开发。
2 数据统一接入和管理
基于上述几个痛点我们的解决方案是将这些异构的数据进行统一的存储和管理如下图所示 在这里我们将日志、指标、Trace等数据全部接入到一个统一的可观测性存储中。然后基于这个统一的存储进行后续的查询分析、可视化、监控告警、AI 等上层能力甚至还可以进行数据的加工和规整一站式地完成异构数据到同构数据的转换过程。
基于统一的存储我们可以构建统一的查询和分析语法从而一套语法适配不同的数据并且让不同的数据之间进行联合查询也变成了可能。如下图所示我们以标准 SQL 为基础进行了部分 DSL 扩展和 SQL 函数扩展并融合了 PromQL从而让不同类型的数据查询和分析变得统一。 例如下面的例子
我们可以通过标准 SQL 语句对日志进行分析还可以通过 PromQL 扩展的 SQL 函数对指标数据进行分析还可以通过嵌套查询对指标数据的分析结果进行再聚合此外还可以再通过机器学习函数给查询和分析赋予 AI 的能力基于上述统一的数据存储和查询分析我们可以非常轻松地实现统一的可视化和监控。如下图所示虽然不同阶段的数据产生自不同的系统也有着不同的格式但是由于它们的存储和分析是一致的因此我们可以构建出统一的报表来查看各个阶段的软件质量以及统一进行监控的配置和告警的管理而无需将这些分散到各个不同的系统中脱离例如 ES Kibana、Prometheus Grafana 等组合。 四 智能巡检
1 传统监控的困难和挑战
接下来我们来看如何基于这些数据让监控更加智能。传统的监控大多是基于一些固定的阈值或者同环比。但是在很多场景下这种模式存在着诸多问题。例如
监控对象爆炸式增长随着云原生的普及服务部署越来越从以“主机”为中心向“容器化”方向转化容器本身的轻量化以及短生命周期等特点导致监控对象和监控指标急剧增加。如果要全方位的覆盖这些监控对象和指标需要配置大量的监控规则并且它们的阈值也可能是各不相同的因此会有很大的工作量。监控规则无法自适应基于人为定义的阈值很大程度上依赖于人的经验随着系统的演化和业务的发展这些规则往往不能很好地适应由此不可避免地导致漏报、误报等问题。无法做到数据的自适应因此需要人为介入不断调整阈值。例如下图 上面是一个指标有规则性的毛刺。如果通过阈值来判断是否需要告警当一个毛刺点异常的时候可能由于不满足阈值导致告警漏报。下面是另一个指标可能随着系统的进化新版本发布之后该指标的值会发生一个陡增。此时如果是固定阈值告警的话会将陡增之后的所有数据都认为是异常点导致告警频繁触发。此时需要人为介入去调整阈值。监控规则泛化能力弱不同的业务、甚至同一业务的不同版本指标的规律性、阈值都有可能是不同的。因此我们需要为不同的业务、不同的版本去做监控规则的适配。例如下图虽然两个指标整体上有着比较相似的波动规律但是由于它们的取值范围、以及局部的抖动情况会有差异因此需要分别去做监控。2 智能巡检
基于上述痛点我们提出了智能巡检的方案。它具备以下几个优势
智能前置现在有很多系统是在告警触发后进行智能的管理但是这无法避免告警误报、漏报等问题。智能巡检可以将 AI 的能力前置到监控层从而在源头上避免潜在的告警问题挖掘出真正有效的数据价值。监控自适应可以基于历史数据自动学习和进化进行动态的阈值判断从而让告警更加精准。另外对数据的学习也是实时的可以更加快速地发现异常问题。动态反馈除了自动学习之外还可以通过用户的反馈对告警进行确认或者误报标记将 AI 能力与人的经验相结合相辅相成进一步完善模型减少误报。
在一些数据波动比较大指标没有固定阈值的场景下例如用户访问量、外卖订单量等智能巡检的优势可以得到很好的体现。例如下图指标本身呈现出周期性的波动假如一个新版本上线了之后由于bug导致网络流量异常抖动。如果基于固定阈值来判断此时处于指标值的上下界范围内就很难发现问题但是基于智能巡检就可以很容易地判定这是一个异常点。 3 智能巡检实现思路
智能巡检的基本思路如下 我们采用无监督学习算法自动识别实体的数据特征根据数据特征选取不同的算法组合针对数据流实时建模完成异常任务检测。并根据用户的打标信息对告警进行确认或者误报反馈训练监督模型对算法进行不断优化从而提高监控的准确率。
目前异常检测我们使用了两种算法它们的比较如下 五 告警智能管理
1 告警管理痛点
在质量观测的完整生命周期中会产生大量的告警。如下图所示 这导致的问题就是
多套工具难维护在不同的阶段可能使用了不同的工具每个工具可能都提供了一部分的告警能力最终导致难以维护。好在通过统一的数据接入和管理我们可以统一去配置监控和管理告警。海量告警无收敛另一个问题就是海量的告警难以收敛尤其是当告警之间有相互依赖关系的时候。例如主机负载高导致该主机上服务异常、接口延迟高、HTTP Error 报错多等多种问题并发从而段时间内有大量的告警触发以及大量的告警消息通知。缺乏合理的降噪机制。通知管理能力弱许多告警管理系统只是简单地将告警消息发送出去存在着通知渠道不完善、通知内容不符合用户需求、无法支持值班需求等等问题。
2 告警智能管理
我们可以通过告警智能管理来解决上述问题如下图所示 告警智能降噪包含以下几种机制
自动去重每个告警会根据告警自身的关键特征计算出一个告警指纹然后根据告警指纹自动去重。例如某主机每一分钟触发CPU使用率过高告警1小时触发60次但对于告警管理系统来说这只是一个告警的60个快照而不是60个独立的告警同时假如通知设置为30分钟重复则一共只会发送两次通知而不是每一分钟就发送一次通知。路由合并相关的告警合并起来一并进行通知而不是针对每个告警分别通知从而减少通知的数量。例如根据告警所在集群进行合并假如某集群短时间内产生了10个告警则只会发送一条通知包含这10个事件。告警抑制主要用于处理告警之间的互相影响。例如某一k8s集群发生OOM严重告警可以暂时忽略同一集群的低级别告警。告警静默满足特定条件的告警无需通知。例如测试集群在凌晨有计划内变更期间服务会有短暂不可用触发预期内告警该告警可以忽略。
动态分派包含如下功能
多渠道支持短信、语音、邮件、钉钉、企业微信、飞书、Slack等多种通知渠道同时还支持通过自定义 Webhook 进行扩展。同一个告警支持同时通过多个渠道、每个渠道使用不同的通知内容进行发送。例如通过语音和钉钉来进行告警通知既可以保证触达强度又可以保证通知内容的丰富程度。动态通知可以根据告警属性动态分派通知。例如测试环境的告警通过短信通知到张三并且只在工作时间通知而生产环境的告警通过电话通知到张三和李四并且无论何时都要进行通知。通知升级长时间未解决的告警要进行升级。例如某告警触发后通过短信通知到了某员工但是该问题长时间未被处理导致告警一直没有恢复此时需要通知升级通过语音的方式通知到该员工的领导。另外就是值班和代班机制。值班是非常常见的一个场景通常情况下告警不是发送给所有的负责人而是通过轮转的方式进行分别值班。既然有了值班也必须要考虑特殊的场景需要代班例如某人值班的当天由于有事所以让另外一个人来代替他值班。例如下面的例子2021年8月由张三和李四值班每班一周仅工作日值班首个工作日交班8月17日张三请假由小明代值班。 六 总结和展望
综合上面的讨论完整的架构大图如下 通过将日志、时序、Trace、事件等数据接入到统一的可观测存储从而实现统一的查询分析、可视化等功能基于此可以实现统一的监控和告警管理从而赋能研发、运维、安全等各个角色。除此之外还支持通过开放告警的功能将其它系统例如 Prometheus、Grafana、Zabbix 等的告警直接接入进行告警的统一管理。 关于对未来的展望
目前质量观测数据的统一采集和管理分析、可视化、监控等能力已经都相对完善从监控角度来说智能巡检已经可以比较好的自适应数据另外就是进行智能根因分析自动发现问题的根源加快问题溯源减轻排障困难告警的智能管理除了基于规则的降噪还会加入更多的算法支持根据告警内容自动进行聚类减少告警通知风暴最后一步是问题的后续响应目前我们已经可以通过对接自定义的Webhook来进行一些简单的操作后续还会加入更多自动化的能力例如代码故障自动修复自动回滚变更等。
随着以上几步的不断建设和完善相信对于质量的观测和把控会越来越朝着人性化、自动化、智能化的方向迈进。
链接
1、CNCF Landscape地址CNCF Cloud Native Interactive Landscape
2、Time-Series Event Prediction with Evolutionary State GraphTime-Series Event Prediction with Evolutionary State Graph | Proceedings of the 14th ACM International Conference on Web Search and Data Mining
3、RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time SeriesRobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series| Proceedings of the AAAI Conference on Artificial Intelligence
原文链接 本文为阿里云原创内容未经允许不得转载。
