共计 5597 个字符，预计需要花费 14 分钟才能阅读完成。
简介：在云原生和 DevOps 研发模式的挑战下，一个零碎从开发、测试、到上线的整个过程中，会产生大量的日志、指标、事件以及告警等数据，这也给企业品质平台建设带来了很大的挑战。本议题次要通过可观测性的角度来探讨基于海量日志和时序数据的品质建设最佳实际。
作者 | 寂之
起源 | 阿里技术公众号
一 前言
在云原生和 DevOps 研发模式的挑战下，一个零碎从开发、测试、到上线的整个过程中，会产生大量的日志、指标、事件以及告警等数据，这也给企业品质平台建设带来了很大的挑战。本议题次要通过可观测性的角度来探讨基于海量日志和时序数据的品质建设最佳实际。
二 品质建设痛点
家喻户晓，在云原生开发模式下，可观测性是十分重要的一部分，它通过日志、指标、Trace 等数据，让咱们能够深刻理解零碎的运行状态和衰弱水平。在 CNCF Landscape 大图中，可观测性也占据了相当大的一块地位。
然而在理论应用过程中，许多人对可观测性的关注，次要集中在零碎上线之后。这当然是没有问题的，但实际上，从一个零碎开发开始，始终到线上运行，都是能够从可观测的角度来对系统的品质进行评估和掂量，咱们能够称之为对品质的观测。
下图比拟概括地形容了一个零碎的品质观测残缺生命周期，大体上能够分为如下四个阶段，并且在每个阶段都有须要特地关注的一些数据和指标：
- 开发阶段：重点须要关注代码的品质，例如动态代码扫描以及依赖查看会发现潜在的代码缺点和平安危险，由此咱们能够统计千行代码缺陷率或者重大缺点比例，从而来掂量一个零碎的代码品质是否符合要求
- 测试阶段：在此阶段须要重点关注测试的品质，例如测试覆盖率，以及测试用例的失败率等指标
- 灰度验证：须要关注零碎的稳定性以及不同版本之间的差别，因而也会有一系列的业务指标，例如 HTTP Error 比例，不同版本的提早等指标的比照
- 线上运行：此时须要重点关注零碎的稳定性以及业务的稳定性，因而各种线上的性能指标、业务指标、利用日志、Trace 等各种数据都是十分重要的
在整个品质观测的生命周期中，除了各种各样的数据，咱们也会波及到各种各样的零碎，例如 GitLab、sonarqube、Allure、JMeter、Jenkins、Travis CI、Argo CD 等等。这些不同的零碎作用于不同的阶段，会产生大量的异构数据，如何对这些数据进行正当的治理和应用，从而能够比拟不便地挖掘出其中的数据价值（不局限于软件品质方面），对咱们来说是一个比拟大的挑战。
基于上述的探讨，咱们能够大体总结出品质观测的几个痛点：
- 海量的异构数据：在零碎开发、测试、验证、上线等各个阶段产生了大量的日志、时序、Trace 等数据，这些数据产生的地位、数据格式、以及存储的地位，都有可能是不一样的。如何从这些数据中疾速精准地挖掘出潜在的品质问题比拟艰难。
- 依赖规定，不足智能：品质监控比拟依赖于人的教训，很大水平上受限于人为设定的规定和阈值，无奈做到数据自适应，因而无奈施展出真正的数据价值。另一方面就是随着零碎的倒退和演进，须要大量的人工干预和一直调整，才可能让监控比拟无效。
- 告警风暴与告警误报：为了不错过轻微的问题，咱们可能会配置大量的监控，从而导致在残缺的软件生命周期中可能产生大量的告警，难以从其中辨认出无效信息。另外大量的告警也带了很大水平上的误报问题，从而导致“狼来了”效应，于是真正的问题反而很容易又被疏忽掉。这就陷入了恶性循环。
三 数据对立接入和治理
1 海量数据管理痛点
首先咱们来探讨第一个痛点，也就是如何对海量的异构数据进行治理。目前可观测性相干的零碎形形色色。
例如日志可能会应用 ELK 或者 Splunk，指标会应用 Prometheus，Trace 应用 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 地址：https://landscape.cncf.io/
2、Time-Series Event Prediction with Evolutionary State Graph：https://dl.acm.org/doi/pdf/10…
3、RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series：https://ojs.aaai.org/index.ph…
原文链接
本文为阿里云原创内容，未经容许不得转载。
