1. 可观测性与分析（Observability and Analysis）

现在我们已经完成了 CNCF 景观的各个层次，我们将重点关注从可观测性性和分析开始的专栏。

在进入这些类别之前，让我们首先定义可观测性性和分析。可观测性性是一种系统特性，描述了从外部输出中可以理解系统的程度。通过CPU时间、内存、磁盘空间、延迟、错误等衡量，计算机系统或多或少可以观察到。分析是一项活动，您可以在其中查看这些可观测性到的数据并对其进行理解。

为了确保没有服务中断，您需要观察和分析应用程序的各个方面，以便立即检测和纠正每个异常。这就是这个类别的全部内容。它横跨并观察所有层，这就是为什么它位于侧面，而不是嵌入特定层的原因。

这类工具分为日志记录、监控、跟踪和混沌工程。请注意，类别名称有些误导 -- 尽管此处列出了混沌工程，但将其视为可靠性工具，而不是可观测性或分析工具。

1.1. 监控（Monitoring）

1.1.1. 是什么？

监控是指检测应用程序以收集、聚合和分析日志和指标，从而提高我们对其行为的理解。虽然日志描述了特定的事件，但指标是在给定时间点对系统的指标-它们是两个不同的东西，但都是全面了解系统健康状况所必需的。监视包括从监视单个节点上的磁盘空间、CPU使用情况和内存消耗到执行详细的合成事务，以查看系统或应用程序是否正确、及时地响应。监控系统和应用程序有许多不同的方法。

1.1.2. 解决什么问题？

运行应用程序或平台时，您希望它按照设计完成特定任务，并确保只有授权用户才能访问它。通过监控，您可以了解它是否工作正常、安全、经济高效，是否只有授权用户才能访问，以及您可能正在跟踪的任何其他特征。

1.1.3. 有什么作用？

良好的监控使运维人员能够在发生事故时快速甚至自动做出响应。它可以深入了解系统的当前运行状况，并监视变化。监控跟踪从应用程序健康到用户行为的所有方面，是有效运行应用程序的重要组成部分。

1.1.4. 技术 101

在云原生场景中监控通常与监控传统应用程序类似。您需要跟踪指标、日志和事件，以了解应用程序的运行状况。主要区别是，一些云原生托管对象是短暂的，这意味着它们可能不会持续很长时间，因此将您的监控与自动生成的资源名称等对象联系起来并不是一个好的长期策略。在这个领域，有许多 CNCF 项目主要围绕着 CNCF 毕业项目 Prometheus 展开。

1.2. 日志（logging）

1.2.1. 是什么？

应用程序会发出稳定的日志消息流，描述它们在任何给定时间正在做什么。这些日志消息捕获系统中发生的各种事件，例如失败或成功的操作、审核信息或运行状况事件。日志工具收集、存储和分析这些消息，以跟踪错误报告和相关数据。除了指标和跟踪之外，日志记录也是可观察性的支柱之一。

1.2.2. 解决什么问题？

收集、存储和分析日志是构建现代平台的一个关键部分，日志可以执行其中的一项或全部任务。有些工具处理从收集到分析的各个方面，而其他工具则专注于单个任务，如收集。所有日志工具都旨在帮助组织控制其日志消息。

1.2.3. 有什么作用？

在收集、存储和分析应用程序日志消息时，您将了解应用程序在任何给定时间通信的内容。但是，由于日志只表示应用程序或平台故意发出的消息，因此它们不一定能查明给定问题的根本原因。也就是说，随着时间的推移，收集和保留日志消息是一种非常强大的功能，将帮助团队诊断问题并满足法规和遵从性要求。

1.2.4. 技术 101

收集、存储和处理日志消息决不是一个新问题，但云原生模式和 Kubernetes 已经显著改变了日志的处理方式。一些适合于虚拟机和物理机的传统日志记录方法，如将日志写入本地磁盘上的文件，不适合于容器化的应用程序，因为在这种应用程序中，文件系统的寿命比应用程序长得多。在云原生环境中，像 Fluentd 这样的日志收集工具与应用程序容器一起运行，并直接从应用程序收集消息。然后，消息被转发到中央日志存储，以进行聚合和分析。

Fluentd是该领域唯一毕业的 CNCF 项目。

1.3. 跟踪（Tracing）

1.3.1. 是什么？

在微服务世界中，服务通过网络不断地相互通信。跟踪是日志记录的一种专门用途，允许您在请求通过分布式系统时跟踪其路径。

1.3.2. 解决什么问题？

了解微服务应用程序在任何给定时间点的行为是一项极具挑战性的任务。虽然许多工具可以深入了解服务行为，但很难将单个服务的操作与对整个应用程序行为的更广泛理解联系起来。

1.3.3. 有什么作用？

跟踪通过向应用程序发送的消息添加唯一标识符来解决此问题。该唯一标识符允许您在单个事务在系统中移动时跟踪它们。您可以使用此信息查看应用程序的运行状况，并调试有问题的微服务或活动。

1.3.4. 技术 101

跟踪是一个非常强大的调试工具，允许您对分布式应用程序的行为进行故障排除和微调。这种力量是有代价的。应用程序代码需要修改以发出跟踪数据，任何跨度（分布式系统中完成的单个工作单元的表示）都需要由应用程序数据路径中的基础结构组件（例如服务网格及其代理）传播。 Jaeger 和 Open Tracing 是该领域的 CNCF 项目。

1.4. 混沌工程（Chaos Engineering）

1.4.1. 是什么？

混沌工程是指故意将故障引入系统，以测试系统的恢复能力，并确保应用程序和工程团队能够承受动荡和意外事件的实践。混沌工程工具将提供一种可控的方法来引入故障并针对应用程序的特定实例运行特定的实验。

1.4.2. 解决什么问题？

复杂系统出现故障。它们失败的原因很多，在分布式系统中，其后果通常很难理解。混乱工程实践的组织往往会积极接受异常，并不是试图防止异常，而是练习从失败中恢复。这称为平均修复时间（MTTR）优化。

提示

维护应用程序高可用性的传统方法称为优化平均故障间隔时间（MTBF）。您可以在使用“变更审查委员会”和“长期变更冻结”之类的东西来通过限制变更来保持应用程序环境稳定的组织中观察到这种做法。Accelerate 的作者建议，高性能 IT 组织通过优化平均恢复时间（MTTR）来实现高可用性。

1.4.3. 有什么作用？

在云原生世界中，应用程序必须动态适应故障，这是一个相对较新的概念。这意味着，当某些东西发生故障时，系统不会完全崩溃，而是会优雅地降级或恢复。混沌工程工具使您能够在生产中的软件系统上进行实验，以确保它们在发生真正的故障时能够正常运行。

简而言之，你试验一个系统是因为你想确信它能经受住动荡和意外的条件。不要等待事情发生并被发现，而是将其置于受控条件下，以识别弱点并在机会为您发现之前修复它们。

1.4.4. 技术 101

混沌工程工具和实践对于实现应用程序的高可用性至关重要。分布式系统往往过于复杂，任何一个工程师都无法完全理解，任何更改过程都无法完全预先确定更改对环境的影响。通过引入故意的混乱工程实践，团队能够实践并自动化故障恢复。Chaos Mesh 和 Litmus Chaos 是该领域的两种CNCF工具。

1.5. 总结：可观测性与分析

正如我们所看到的，可观测性和分析专栏都是关于了解系统的健康状况，并确保即使在恶劣条件下也能保持运行。日志工具捕获应用程序发出的事件消息，监视日志和指标，并跟踪单个请求的路径。当组合使用时，这些工具理想地提供了系统中正在发生的事情的 36 0度视图。混沌工程有点不同。它提供了一种安全的方法来验证系统能够承受意外事件，确保其保持健康。

接下来，我们将关注云原生平台。在整个环境中配置工具，使它们能够很好地协同工作并不是一件容易的任务。平台将它们捆绑在一起，便于采用。

1.6. 经验推荐

云原生可观测性主要分大类日志（logging）、指标（metric）和跟踪（tracing），可以分别使用不同的工具来采集对应的数据，聚合后整体分析来了解系统运行健康状况。

对于监控系统，目前主流的就是 Prometheus，他提供一套完整的监控数据采集、分析和告警的能力。在 Prometheus 生态基础之上衍生了解决特定场景的项目或标准，如：Cortex、OpenMetrics、Thanos等。VictoriaMetrics 也有不错业务使用实践。一般还会结合 Grafana 来进行数据报表展示。其他如 Zabbix、Nagios等在传统主机场景下被广泛使用，但是云原生场景下实践并广泛。其中 graphite 即 influxdata 等提供 Prometheus 底层时序列数据存储功能被广泛使用。

对于日志管理，fluentd 已经毕业，是个不错的选择。但显然 ElasticSearch 和 Logstash 的 ELK 或者 EFK 是很多用户的选择。Loggie 作为专为云原生场景下设计的日志采集和处理工具，处于高速增长期。除此之外，商业的版本使用 splunk 的用不也不在少数。

而关于服务链路跟踪，推荐使用 Jaeger 来采集，OpenTelemetry 旨在提供可观测性领域的标准化方案。此外，Skywalking、Pinpoint、Zipkin 也是很多企业的选择。

而混沌工程在分类上容易被误导，它其实是可靠性工具，而不是可观测性或分析工具。Chaos Mesh 和 Litmus Chaos 是推荐的选择。