云原生最佳七步实践-可观测性与AIOPS（2）

1. 云原生最佳七步实践-可观测性与AIOPS（2）

在云原生最佳七步实践第一步容器云平台建设初见成效后，其上已经运行了一定的业务服务应用，如何保障这些已经在运行的服务稳定性，以及出现异常时能够告警通知成为接下来的重点建设目标。

系统或应用的稳定性大多数情况下都会归类为“运维”的工作范畴，考虑到这第二步的可落地性与长期演进，故将该步骤拆分成两个大的阶段目标，分别是是可观测性阶段与 AIOPS 阶段。

这里举一个常见的传统运维案例，该案例会贯穿全文，括号中为自动化与智能化运维能力。

运维人员小赵发现 A 服务所在机器的磁盘使用率达到95%（监控与告警）
小赵根据运维经验分析该机器磁盘不久后可能会发生磁盘只读，进而导致该节点上的业务运行异常（趋势预测）
小赵发现占用磁盘空间的文件主要是 A 服务输出的日志文件，配合 A 服务的业务方小李分析产生大量日志的原因是：由于 B 服务异常退出，A 服务无法连接，导致频繁输出请求失败的日志，而 B 服务异常退出是因为内存不足触发发生 OOM 被 KILL 掉了（根因分析）
小赵和小李清理了大量消耗空间的日志文件，然后重新启动 B 服务后，A 服务也恢复了正常（自动化问题处理）
小赵建议小李，给 B 服务再增加 2GB 的可用内存（推荐优化方案）

在这个例子中运维人员小赵和业务方小李以手工+经验的方式完成了一次运维事件的处理，如果企业的建设目标是希望保障业务服务稳定运行，故障后快速定位原因并快速恢复业务服务运行，那么就需要让这些运维动作自动化、智能化，减少或取消“人”的参与。

在运维过程种可观测性是核心基础，如果无法了解系统状态，运维动作就无从发起。因此可观测性阶段是运维的基础阶段，在有健全的可观测性数据后才能结合大数据和人工智能来辅助运维，到达 AIOPS 阶段。

最终的智能化运维系统应该会如图方式建设：

1.1. 可观测性阶段

可以初略将下四层（数据源、数据采集层、数据存储层、应用与展示层）定义为可观测性阶段需要建设的内容，也是当前大多数企业正在实践的部分。

在云原生理念中可观测性是指目标系统可以基于日志（Logging）、链路（Tracing）、指标（Metric）三个维度的数据来观测状态，该状态能够体现该系统的所有的需要关注的内容。

1.1.1. 数据源

可观测的数据源大致分为三类，硬件、操作系统与网络以及软件。硬件如服务器的硬盘、电源、风扇和主板等；网络设备如交换机、路由器和网关等设备；安全设备如防火墙；机房设施如空调、电力等；这些硬件在运行时都会产生状态数据。操作系统其实也是一种软件，由于其特殊性这里将其单独归类，操作系统内会有 CPU、内存、存储相关的使用和状态数据，操作系统间会有通信的网络数据。应用软件是为了某种特定的用途而被开发的软件，他们是核心要保障稳定对象，特别是业务应用。

无论是硬件、操作系统还是应用软件，在云原生场景下都会为容器云提供资源或使用容器云的资源，这也是我们在云原生最佳七步实践要第一步就进行建设容器云的原因。

1.1.2. 数据采集

在了解数据源后，对数据进行分析总结出三种独立的数据类型，他们分别从三个不同的维度来展示应用的状态，这三种数据类型分别是日志数据（Logging）、链路数据（Tracing）和指标数据（Metric）

日志是记录了发生在运行中的操作系统或其他软件中的事件。常见于事件日志、事物日志、消息日志等，而与可观测性相关主要就是事件日志。事件日志（Event logs）记录了在系统运行期间发生的事件，以便于了解系统活动和诊断问题。它对于了解复杂系统的活动轨迹至关重要，尤其是只有很少用户交互的应用程序（例如服务器应用程序）。[1]

日志数据的采集目前已经在 CNCF 毕业的项目是 Fluentd，是推荐的日志采集工具，也可以选择许多企业正在采用 Filebeat 和 Logstash。 由网易开源的、目前已经是 CNCF 沙盒项目的 Loggie，由于其专为云原生场景设计，具有不错的发展潜力。

链路追踪即调用链监控，特点是通过记录多个在请求间跨服务完成的逻辑请求信息，帮助开发人员优化性能和进行问题追踪。链路追踪可以捕获每个请求遇到的异常和错误，以及即时信息和有价值的数据。[2]

链路追踪的技术选型推荐使用目前 CNCF 已经毕业的 Jaeger，也有很多企业选择 SkyWalking 或 Zipkin。

指标数据是应用程序运行时产生的内部指标，以 API 接口的方式提供查询。指标数据具有时间的特性，不同的时间点的指标是不同的，因此用以存储指标数据的数据库一般称为时序列数据库。

Prometheus 是指标数据的集大成者，是云原生场景下的不二选择。 指标数据的采集可由 Prometheus 直接采集应用（如请求 /metrics 接口），或由应用的 Exporter 间接采集。

介绍可观测性还有一个无法绕开的话题就是 OpenTelemetry，OpenTelemetry 目标是将以上三个维度的数据格式进行标准化范。OpenTelemetry 是一组 API、SDK、工具和集成，旨在创建和管理遥测数据，例如Trace、Metrics和Logs。该项目提供了一个与供应商无关的实现，可以将其配置为将遥测数据发送到您选择的后端。它支持各种流行的开源项目，包括 Jaeger 和 Prometheus｡主要解决的问题是观测性领域模型的统一，观测性数据收集的统一，观测性数据输出的统一。这些统一性主要体现在 API 规范，SDK 实现规范，接口规范等。OpenTelemetry 不会负责观测数据的存储，需要存储这些观测数据的 backend。OpenTelemetry 定义数据输出的规范，由各大厂商自行完成数据的持久化。[3]

1.1.3. 数据存储

采集到的数据需要进行一定的处理并进行存储保存，为下一步的数据应用和展示提供数据基础。

一般场景日志数据和链路追踪数据存储推荐使用 ElasticSearch，在大规模日志采集场景下可以添加 Kafka 作为缓冲。对需要进行大数据分析等场景时，也可以选择 HDFS/HBase 存储。

对于指标数据推荐使用 Prometheus 存储（Prometheus 本身也实现了 TSDB 数据库），但是原生的 TSDB 对于大数据量的保存及查询支持不太友好，该数据库不能保证可靠性，且无法支持 Prometheus 集群架构。而 Thanos 和 Cortex 都是在数据可靠性和集群高可用方面进行了优化增强，目前都是 CNCF 孵化中的项目，也是不错的选择。在大规模场景下还可以选择 openTSDB 或 Clickhouse 来进行指标数据存储。

1.1.4. 应用与展示层

应用与展示层是可观测性的最上层，是对采集数据的基础应用，也是当前企业主要的应用场景。

图表展示是可观测性面向用户最为直观的呈现，将复杂的数据以图或表形式展示出来，便于运维人员快速了解应用状态，基于经验做出判断或预测。对于日志数据和链路追踪数据的查看可以通过 Kibana 查看，对于指标数据推荐使用 Grafana 进行展示，也可以使用原生的 Prometheus、Thanos 或 Cortex 查看。

服务拓扑是通过数据流向和调用关系，以 UI 的方式将服务依赖关系拓扑呈现出来。实际业务中，应用之间的关联与依赖非常复杂，需要通过全局视角检查具体的局部异常。可以在服务拓扑查看应用在指定时间内的调用及其性能状况。

监控告警是最常用的场景，也是目前建设可观测系统的核心目标。监控告警通过事前配置好阈值，数据采集上来后通过计算与阈值比对，对于不符合规则要求的数据生成告警事件，通过告警渠道发送到目标设备，如邮箱、手机、企业IM等。推荐使用 Prometheus 生态中的 Alertmanager 进行告警通知，它能够满足大多数企业的告警需求。

对于可观测性数据的初级应用除以上几项外，有些企业还会尝试尽可能多的将三者的数据进行关联，使同一个应用不同维度的事件立体化的展示出来。如请求发生异常时，应用一般会将请求以日志的方式输出，调用链路也会上报调用异常，这两类数据可以通过 RquestID 或 TraceID 进行关联。

1.2. AIOPS 阶段

将可观测性阶段成果+智能化层定义为 AIOPS要建设的内容。AIOPS 是将人工智能和大数据应用于运维的场景，辅助运维实现自动化、智能化，以达到无人值守亦能保证业务服务高效稳定运行的目的。

AIOPS 辅助运维的场景大致可以分为三大类：智能分析、智能决策和智能展示。

1.2.1. 智能分析

智能分析是 AIOPS 的大脑，依托于大数据和人工智能技术对采集的日志、指标和链路数据进行分析，按需产生有价值的结果为智能决策和智能展示提供数据。大数据目前主流选型可以考虑 Spark 、Flink等技术，人工智能中以机器学习为例可以考虑 TensorFlow、PyTorch等。

智能分析的主要场景有趋势预测、根因分析和推荐解决/优化方案。

智能分析场景一：趋势预测，预测可能会发生的事件。例如可以根据磁盘空间增长率预测在多久之后磁盘空间会消耗殆尽；根据集群资源阶段情况分析集群资源水位波动，预测下个周期资源是否能够满足业务运行，以及是否是需要扩容还是缩容集群规模；如运维例子中 2. 小赵根据运维经验分析该机器磁盘不久后可能会发生磁盘只读，进而导致该节点上的业务运行异常（趋势预测），小赵分析的结论磁盘在不久后就会满，满了之后会有更大影响。

智能分析场景二：根因分析，找到异常发生的根本原因。如运维例子中 3. 小赵发现占用磁盘空间的文件主要是 A 服务输出的日志文件，配合 A 服务的业务方小李分析产生大量日志的原因是：由于 B 服务异常退出，A 服务无法连接，导致频繁输出请求失败的日志，而 B 服务异常退出是因为内存不足触发发生 OOM 被 KILL 掉了（根因分析） ，磁盘空间不足是A导致的，但根本原因是B内存不足。

智能分析场景三：推荐解决/优化方案，找到原因后还需要能够提供临时解决方案来解决问题。如例子中实际上的解决方案就是启动B服务，清理A服务机器的磁盘空间；并且提供长期解决方案来优化问题，如：5. 小赵建议小李，给 B 服务在增加 2GB 的可用内存（推荐优化方案）。

1.2.2. 智能决策

智能决策是建立在智能分析基础之上，同时依赖与之匹配的基础设施实现的为保证业务连续性、稳定性而做出的决策结论与自动化执行。智能决策的主要场景有智能决策和智能变更。

智能决策场景一：智能决策，根据分析得出结论并提供应对建议后，决策是否执行该建议。例如系统检测到一台服务器无法 ping 通，也没有在规定的时间上报数据，同机柜其他服务正常，其他维度数据......，分析判断出机器宕机的结论，建议重启机器；智能决策决定“重启机器”。

智能决策场景二：智能变更，依托于基础设施的自动化对智能决策结果进行变更动作的执行。继续智能决策的机器宕机例子，在智能决策决定“重启机器”后，发起调用“重启机器”变更接口并传入相关参数后，智能变更系统通过相关手段如节点 Agent、SSH 或带外的方式对服务器进行重启，重启后机器恢复正常。

智能决策将智能分析的结果确定下来并执行，可以释放大量人力，妥妥的降本增效利器。但是，由于当前智能化系统本身的建设还不成熟，前期投入人力成本大，且在分析结论的准确性不高和决策执行自动化程度也不高时，可能会带来很多的工作量。

1.2.3. 智能展示

智能展示支持将用户想要看到内容准备数据并以合适的方式展示。智能展示的场景主要由立体化观测、智慧大屏和智能客服。

智能展示场景一：立体化观测，是对一个小目标的全方位微观观测。例如以一个应用为中心，观测他的运行环境、资源使用情况、代码方法执行情况、调用与被调用的请求情况等等，就像人体检一样全面。

智能展示场景二：智慧大屏，是对一个大系统宏观展示。例如电商平台双11时的监控大屏，展示整体的状态、子系统运行状态、依赖的供应链状态等，状态的展示评估出一个健康程度。

智能展示场景三：智能客服，可以将关键事件主动通知到目标接受人，或根据需要响应返回内容。在机器宕机例子中，可以考虑将机器宕机结论、建议重启机器、执行机器重启、机器重启成功恢复正常这些事件发送给运维人员，虽然不用运维人员主动参与但应该知情。同时，在运维人员问智能客服为什么机器会宕机时，智能客服能够准确回答原因，如“由于主版故障导致机器宕机，该主版处于维保期，建议联系厂家更换主板。”

1.3. 总结

运维是云原生场景中不可或缺的工作，只是这部分工作在逐渐的转移或被自动化替代，弱化运维的最终目标有两个途径，其一是企业整体上公有云有公由云厂商来承担运维，其二是建设完善的 AIOPS 体系，无论往哪个方向发展，我相信短时间内还是离不开运维的。

最终的 AIOPS 目标是比较理想的，但目前并没有一套完整的技术栈来支撑该解决方案，大多数企业还停留在可观测性的基础应用阶段，期望不久的将来有新的技术或想法来促进 AIOPS 的发展。

可观测性与AIOPS