基于海量日志和时序数据的质量建设最佳实践

一 前言

在云原生和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。但太多的选择也不见得是好事，在这种情况下，可观测性数据的管理又给我们带来了如下几个痛点：

• 运维成本高：完整的质量系统需要数个甚至十多个软件的协同，从而也带了极高的运维成本。
• 学习成本高：每个软件都有自己的使用插件、插件系统，有些还会