Kubernetes 上的开源可观测性介绍

本文，开发者可以学习到用来观察 Kubernetes 上运行服务的信号、机制、工具和平台。

随着 DevOps 的出现，工程团队对服务可靠性越来越重视，其中一部分人对增加的运营负担感到不满，另一部分人则认为有必要将服务可靠性作为关键特性来对待，需要投资必要的精力来度量和提高可靠性，并提供能力范围内的最佳客户体验。

这一变化在 《 2019 年加快发展 DevOps 报告》 中得到明确体现。它最有趣的结论之一 (如总结中所写) 是：

“快速、可靠、安全地交付软件 (我们的重点) 是技术转换和组织绩效的核心。我们不断地看到软件速度、稳定性和可用性对公司效益 (包括盈利能力、生产力和客户满意度) 的贡献。我们表现最好的员工达到或超过组织绩效目标的可能性是其他公司的两倍。

报告 全文称:

“低绩效者比高绩效者或精英使用更多的专业软件：维护和支持专业软件的成本可能高得令人望而却步，这促使高绩效者和精英使用开源解决方案。这与以前报告的结果一致。事实上根据《2019 年加快发展 DevOps 报告》的调查，精英人士广泛使用开源组件、库和平台的可能性是普通人的 1.75 倍。”

这有力地证明了开源作为性能通用加速器的价值。结合这两个结论可以得出本系列文章的一个相当明显的主题:

可靠性是一个关键的特性，可观察性是可靠性的必要组成部分，开源工具至少是一个正确的考虑方向，虽然可能并不是最终选择的解决方案。

本文是本系列的第一篇文章，将介绍工程师通常依赖的信号类型，以及可以用来检测运行在 Kubernetes 上的服务的机制、工具和平台，以发出、接收和存储这些信号，并使用和解释这些信号。

在此基础上，本系列将继续提供动手实践教程，我将从头到尾介绍每种工具和技术。最终，希望您能着手改进自己系统的可观测性!

可观测性是什么?

虽然可观测性作为 控制理论中的一个普遍概念 至少从 1960 年就已经存在，但它对数字系统和服务的适用性是相当新的，而且在某种程度上是过去 20 年对这些系统的监控方式的演变。您可能熟悉监视服务的必要性，以确保在用户受到影响之前了解问题。您可能还熟悉使用度量数据来更好地了解系统的健康状况和状态的概念，特别是在故障排除或调试期间。

监视和可观察性之间的关键区别在于，可观察性是系统或服务的固有属性，而不是某人对系统所做的事情，这才是监视的本质。 Cindy Sridharan 是一本关于分布式系统可观测性的免费 电子书 的作者，她在一篇优秀的 媒体文章 中很好地解释了这种差异。

区分这两个术语很重要，构建具有可观察性的服务属性也是您的责任。作为服务开发人员和所有者，您可以完全控制系统发出的信号、如何接收和存储这些信号以及如何使用它们。这与“监视”形成了对比，“监视”可以由其他人 (或您) 执行，以度量服务的可用性和性能，并生成警报，让您知道服务可靠性已经降低。

信号

既然你已经理解了可观察性是你所控制的系统的一种属性，并且明确表现为你指示你的系统发出的信号，那么理解和描述在这种情况下通常考虑的信号类型是很重要的。

指标是什么?

指标是一种基本类型的信号，它可以由服务或其运行的基础设备发出。最基本的是:

1、一些标识符，最好是可描述性的，表示指标所代表的内容

2、一系列数据点，每个数据点包含两个元素:

a. 数据点生成 (或摄入) 的时间戳

b. 一个数字值，表示您所测量的对象在当时的状态

时间序列指标一直是并仍然是监控和可观察性实践中使用的关键数据结构，是表示系统状态和健康状态随时间变化的主要方式。它们也是警报的主要机制，但是这种实践和其他实践 (如事件管理、on-call 机制和事后分析) 不在本文讨论范围之内。目前，重点是如何测量系统发出的指标数据，如何存储它们，以及如何将它们用于图表和仪表板，以帮助您可视化系统的当前和历史状态。

度量标准主要用于两个目的：健康和洞察力。

了解您的基础设施、平台和服务的健康状况和状态对于保证它们对用户可用是至关重要的。通常，这些数据是由构建服务所选择的各种组件发出的，只要设置正确的收集和存储基础设施就可以使用它们。从简单的指标 (节点 CPU 利用率) 到复杂的指标 (垃圾收集统计数据) 都属于这一类。

度量标准对于理解系统中发生的事情也很重要，这样可以避免服务中断。从这个角度来看，服务可以发出定制的遥测数据，精确地描述服务如何运行和执行的特定方面。这将要求您测试代码本身，通常包括特定的库，并指定导出目的地。

日志是什么?

与表示随时间变化的数值的指标不同，日志表示离散事件。日志条目包含日志有效负载 (由服务组件或代码发出的消息) 和元数据 (如时间戳、标签、标记或其他标识符)。因此到目前为止，这是您需要存储的最大数据量，在考虑增加用户流量时，应该仔细考虑日志摄取和存储策略。

跟踪是什么?

分布式跟踪是可观性工具包中一个相对较新的功能，它与微服务体系结构特别相关，可以帮助您了解延迟以及各种后端服务调用对延迟的影响。Ted Young 发表了一篇关于 这个概念的优秀文章 ，其中包括对它源自谷歌 Dapper 论文 及后续发展的介绍。本系列文章将会特别关注各种可用的实现。

仪表化

一旦确定了要发出、存储和分析的信号，就需要指示系统创建信号并构建一种机制来存储和分析这些信号。仪表化是指代码中用于生成度量、日志和跟踪的部分。在本系列中，我们将讨论开源工具选项，并通过实践教程介绍它们的基本用法。

Kubernetes 的可观测性

Kubernetes 是当今部署和维护容器的主要平台。随着它在行业内地位的提高，提供有效的可观察性工具的新技术也理所应当。下面会简单的介绍下它的基本技术，在本系列的后续文章中将更详细地讨论它们。

指标

一旦您选择了您喜欢的方法使用指标来度量您的服务，下一步就要决定在哪里存储这些数据，以及哪些服务集需要支持您的工作以便监视您的环境。

Prometheus

Prometheus 是监视 Kubernetes 基础设施和集群中运行的服务的最佳切入点。它提供了您需要的所有东西，包括客户端工具库、 存储后端 、可视化 UI 和警报框架。Prometheus 运行时还提供大量现成的基础设施指标。尽管数据交换不是双向的，但它也进一步提供了与第三方的 集成 以进行存储，所以如果您希望在多个位置存储度量数据，请务必阅读文档。

在本系列的后面部分，我将介绍如何在集群中设置 Prometheus，用于基础设施监视，并使用 Prometheus 客户机库将定制的遥测技术添加到应用程序中。

Graphite

Graphite 诞生于 Orbitz 的内部开发工作，现在定位为企业级的监控工具。它提供了度量的存储和检索机制，但是没有仪表功能。因此，您仍然需要实现 Prometheus 或 OpenCensus 工具来收集指标。在本系列后面的文章中，我将介绍如何设置 Graphite 并向其发送度量标准。

InfluxDB

InfluxDB 是一个开源数据库，专门用于存储和检索时间序列指标。与 Graphite 不同，InfluxDB 由一家名为 InfluxData 的公司提供支持，该公司同时提供 InfluxDB 软件和一个名为 InfluxDB 云的云托管版本。在本系列的后面部分，我将介绍如何在集群中设置 InfluxDB 并向它发送度量数据。

OpenTSDB

OpenTSDB 也是一个开源的、专门构建的时间序列数据库。它的优点之一是能够使用 HBase 作为存储层，这允许与云管理服务 (如谷歌的 cloud Bigtable) 集成。谷歌发布了关于设置 OpenTSDB 来监视 Kubernetes 集群的 参考指南 (假设它在谷歌 Kubernetes 引擎或 GKE 中运行)。由于这是一个很好的指导教程，如果您有兴趣了解更多关于 OpenTSDB 的内容，我建议您学习下谷歌的教程。

OpenCensus

OpenCensus 是谷歌开发的 Census 库的 开源版本。它提供度量和跟踪工具功能，并支持许多 输出 度量的后端——包括 Prometheus。请注意，OpenCensus 并不监视您的基础设施，如果您选择使用 OpenCensus 进行自定义度量遥测，那么仍然需要选择一个更佳的入口方案。

我们将在本系列文章的后面部分重新讨论这个库，我将介绍如何在服务中创建指标并将它们导出到后端。

日志记录的可观测性

如果度量标准提供了“发生了什么”，那么日志记录可以部分地说明“为什么”。以下是一些持续收集和分析日志的常见设置。

收集与 fluentd

在 Kubernetes 生态系统中， fluentd 是事实上的开放源码标准，用于收集集群中发出的日志并将它们转发到指定的后端。您可以使用配置映射来修改 fluentd 的行为，在本系列文章的后面，我将逐步将它部署到一个集群中，并修改相关的配置映射来解析非结构化日志，并将它们转换为结构化日志，以便更好、更容易地进行分析。同时，您可以阅读我的文章“ 定制 Kubernetes 日志 (第 1 部分) ”，了解如何在 GKE 上实现这一点。

使用 ELK 进行存储和分析

最常见的日志存储机制是 Elastic 的“ELK”堆栈。  正如 Elastic 所说:

ELK 是三个开源项目的缩写：Elasticsearch、Logstash 和 Kibana。Elasticsearch 是一个搜索和分析引擎。Logstash 是一个服务器端数据处理管道，它同时从多个源获取数据，对其进行转换，然后将其发送到一个类似于 Elasticsearch 的“ stash”中。Kibana 允许用户在 Elasticsearch 中使用图表和图形来可视化数据。”

在之后的文章中，我将介绍如何设置 Elasticsearch、Kibana 和 Logstash 用于存储和分析由 fluentd 收集的日志的集群。

分布式跟踪和可观测性

当在分析服务问题时询问“为什么”时，日志只能提供应用程序设计时共享的信息。要想获得更多的数据，就得收集痕迹。正如 OpenTracing 倡议所 说:

分布式跟踪，也称为分布式请求跟踪，是一种用于分析和监视应用程序的方法，特别是那些使用微服务体系结构构建的应用程序。分布式跟踪有助于查明故障发生的位置和导致性能低下的原因。”

Istio

Istio 开源服务网格为微服务体系结构提供了多种好处，包括流量控制、安全性和可观察性能力。它不会将多个跨越组合成单个跟踪，从而对用户调用遍历分布式系统时所发生的情况进行全面描述，但是它仍然可以作为实现分布式跟踪的第一步。它还提供了其他可观察性优势——这是为每个服务获取“ 黄金信号 ”指标的最简单方法，而且它还为每个请求添加了日志记录，这对于计算错误率非常有用。你可以阅读我的关于 使用它与谷歌的 Stackdriver 的文章 。在本系列文章中，我将重新讨论它，并展示如何在集群中安装它，以及如何将它配置为将可观察性数据导出到后端。

OpenCensus

在之前我描述指标部分提到过 OpenCensus ，这是选择它做分布式跟踪的主要原因之一：使用一个库完成指标和跟踪工作是不错的方案， 这样可以减少很多基础性的工作。需要注意的是，您必须使用一种同时支持跟踪和统计导出的语言。之后我会回来重新讨论 OpenCensus，并展示如何开始检测用于分布式跟踪的代码。请注意，OpenCensus 只提供了仪表库，您仍然需要使用存储和可视化层，比如 Zipkin、Jaeger、Stackdriver(在 GCP 上) 或 X-Ray(在 AWS 上)。

Zipkin

Zipkin 是一个完整的分布式跟踪解决方案，包括工具、存储和可视化。这是一组久经考验的工具，已经存在多年，拥有强大的用户和开发人员社区。它还可以用作其他检测方案 (如 OpenCensus) 的后端。在以后的教程中，我将展示如何设置 Zipkin 服务器并测试代码。

Jaeger

Jaeger 是另一个开源跟踪解决方案，它包含您需要的所有组件。这是一个在云本地计算基金会 (CNCF) 孵化的新项目。无论您选择使用 Zipkin 还是 Jaeger，最终都可能取决于您使用它们的经验以及它们对您所使用的服务语言的支持。在本系列中，我将介绍如何设置 Jaeger 和插装用于跟踪的代码。

可观察性数据可视化

使用度量标准的工具包的最后一部分是可视化层。这里基本上有两种选择：您的持久层支持的“本机”可视化 (例如，Prometheus UI 或 fluxdb)，或专门构建的可视化工具。

Grafana 是当前开源可视化的实际标准。在本系列的后面部分，我将逐步介绍如何设置和使用它来可视化来自各种后端的数据。

展望未来

Kubernetes 上的可观察性有许多部分，对于每种需求都有许多选择。指标、日志记录和跟踪工具提供了关于服务决策所需的基础信息。插装、存储和可视化数据也是必不可少的。本系列的后续文章将深入讨论所有这些选项，并提供每个选项的实践教程。

英文原文： Introduction to open source observability on Kubernetes