随着 DevOps 的兴起，工程团队正在承担越来越多的服务可靠性责任。虽然有些人对运营负担的增加感到不满，但另一些人则欢迎有机会将服务可靠性视为一项关键特性，投资于衡量和提高可靠性的必要能力，并提供尽可能最佳的客户体验。
这种变化在 2019 年 DevOps 状态加速报告中得到了明确衡量。其最有趣的结论之一（如摘要中所述）是
"快速、可靠 [我的重点] 且安全地交付软件是技术转型和组织绩效的核心。我们看到持续的证据表明，软件的速度、稳定性和可用性 [我的重点] 有助于组织绩效（包括盈利能力、生产力和客户满意度）。我们表现最佳的组织实现或超过其组织绩效目标的可能性是其他组织的两倍。"
完整报告指出
"低绩效者比高绩效者和精英绩效者使用更多的专有软件：维护和支持专有软件的成本可能过高，促使高绩效者和精英绩效者使用开源解决方案。这与之前报告的结果一致。事实上，2018 年 DevOps 状态加速报告发现，精英绩效者广泛使用开源组件、库和平台的可能性是其他组织的 1.75 倍。"
这有力地证明了开源作为通用性能加速器的价值。将这两个结论结合起来，就得出了本系列文章相当明显的论点
可靠性是一项关键特性，可观测性是可靠性的必要组成部分，而开源工具至少是一种正确的方法，即使不是唯一正确的方法。
本文是本系列的第一篇，将介绍工程师通常依赖的信号类型，以及您可以用来检测在 Kubernetes 上运行的服务以发出这些信号、摄取和存储它们以及使用和解释它们的机制、工具和平台。
从那里开始，本系列将继续提供动手教程，我将在其中逐步介绍如何开始使用每种工具和技术。到最后，您应该能够很好地开始提高您自己系统的可观测性！
什么是可观测性？
虽然可观测性作为控制理论中的一个通用概念至少自 1960 年以来就已存在，但其在数字系统和服务中的适用性相当新，并且在某些方面是过去二十年来这些系统监控方式的演变。您可能熟悉监控服务的必要性，以确保您在用户受到影响之前了解问题。您可能也熟悉使用指标数据来更好地了解系统的健康状况和状态的想法，尤其是在事件期间的故障排除或调试的上下文中。
监控和可观测性之间的主要区别在于，可观测性是系统或服务的内在属性，而不是某人对系统所做的事情，而监控从根本上来说就是后者。Cindy Sridharan，分布式系统中可观测性免费电子书的作者，在一篇优秀的 Medium 文章中出色地解释了两者之间的区别。
区分这两个术语很重要，因为可观测性作为您构建的服务的属性，是您的责任。作为服务开发人员和所有者，您可以完全控制系统发出的信号、这些信号的摄取和存储方式和位置，以及它们的使用方式。这与“监控”形成对比，“监控”可能由其他人（以及您）完成，以衡量服务的可用性和性能，并生成警报以告知您服务可靠性已降低。
信号
现在您已经了解了可观测性作为您可以控制的系统属性的想法，并且它明确地表现为您指示系统发出的信号，因此重要的是要理解和描述在此上下文中通常考虑的信号类型。
什么是指标？
指标是一种基本类型的信号，可以由服务或其运行的基础设施发出。从最基本的角度来看，它是以下各项的组合
- 一些标识符，最好是描述性的，指示指标代表什么
- 一系列数据点，每个数据点包含两个元素
a. 生成（或摄取）数据点的时间戳
b. 一个数值，表示您在那个时间点测量的事物的状态
时序指标过去是并且仍然是监控和可观测性实践中使用的关键数据结构，并且是随时间推移表示系统状态和健康状况的主要方式。它们也是警报的主要机制，但该实践和其他实践（如事件管理、随叫随到和事后分析）不在此处的范围之内。目前，重点是如何检测系统以发出指标、如何存储它们以及如何将它们用于图表和仪表板，以帮助您可视化系统的当前和历史状态。
指标主要用于两个目的：健康状况和洞察力。
了解您的基础设施、平台和服务的健康状况和状态对于保持它们对用户的可用性至关重要。通常，这些是由选择构建服务的各种组件发出的，而这只是设置正确的收集和存储基础设施以便能够使用它们的问题。从简单的（节点 CPU 利用率）到深奥的（垃圾回收统计信息）的指标都属于这一类。
指标对于了解系统中正在发生的事情以避免服务中断也至关重要。从这个角度来看，服务可以发出自定义遥测数据，精确描述服务的功能和性能的特定方面。这将要求您检测代码本身，通常通过包含特定的库，并指定导出目标。
什么是日志？
与表示随时间变化的数值的指标不同，日志表示离散事件。日志条目既包含日志负载（服务或代码的组件发出的消息），又包含元数据，例如时间戳、标签、标记或其他标识符。因此，这是您需要存储的最大数据量，并且在您希望应对不断增长的用户流量时，您应该仔细考虑日志摄取和存储策略。
什么是追踪？
分布式追踪是可观测性工具包中相对较新的补充，并且与微服务架构特别相关，使您能够了解延迟以及各种后端服务调用如何导致延迟。Ted Young 发表了一篇关于这个概念的优秀文章，其中包括它起源于 Google 的 Dapper 论文以及随后的演变。本系列将特别关注可用的各种实现。
检测
一旦您确定要发出、存储和分析的信号，您就需要指示您的系统创建信号并构建一个机制来存储和分析它们。检测是指代码中用于生成指标、日志和追踪的部分。在本系列中，我们将讨论开源检测选项，并通过动手教程介绍其基本用法。
Kubernetes 上的可观测性
Kubernetes 是当今部署和维护容器的主导平台。随着它上升到行业意识的最前沿，为它提供有效的可观测性工具的新技术也随之兴起。以下是这些基本技术的简短列表；在本系列的后续文章中将更详细地介绍它们。
指标
一旦您选择使用指标检测服务的首选方法，下一个决定就是将这些指标存储在哪里，以及哪些服务集将支持您监控环境的工作。
Prometheus
Prometheus 是开始监控 Kubernetes 基础设施和集群中运行的服务的最佳选择。它提供了您需要的一切，包括客户端检测库、存储后端、可视化 UI 和警报框架。运行 Prometheus 还提供了大量的开箱即用的基础设施指标。它还进一步提供与第三方提供商的集成以进行存储，尽管数据交换在每种情况下都不是双向的，因此如果您想在多个位置存储指标数据，请务必阅读文档。
在本系列的后续文章中，我将逐步介绍如何在集群中设置 Prometheus 以进行基本的基础设施监控，以及如何使用 Prometheus 客户端库向应用程序添加自定义遥测数据。
Graphite
Graphite 源于 Orbitz 的内部开发工作，现在被定位为企业级监控工具。它提供指标存储和检索机制，但没有检测功能。因此，您仍然需要实施 Prometheus 或 OpenCensus 检测来收集指标。在本系列的后续文章中，我将逐步介绍如何设置 Graphite 并将指标发送到它。
InfluxDB
InfluxDB 是另一个专门为存储和检索时序指标而构建的开源数据库。与 Graphite 不同，InfluxDB 由一家名为 InfluxData 的公司支持，该公司同时提供 InfluxDB 软件和名为 InfluxDB Cloud 的云托管版本。在本系列的后续文章中，我将逐步介绍如何在集群中设置 InfluxDB 并将指标发送到它。
OpenTSDB
OpenTSDB 也是一个开源的、专门构建的时序数据库。它的优势之一是能够使用 HBase 作为存储层，这允许与云托管服务（如 Google 的 Cloud Bigtable）集成。Google 发布了一个关于设置 OpenTSDB 以监控 Kubernetes 集群的参考指南（假设它在 Google Kubernetes Engine 或 GKE 中运行）。因为它是一个很好的介绍，如果您有兴趣了解更多关于 OpenTSDB 的信息，我建议您遵循 Google 的教程。
OpenCensus
OpenCensus 是 Google 开发的 Census 库的开源版本。它提供指标和追踪检测功能，并支持许多后端以导出指标—包括 Prometheus！请注意，OpenCensus 不会监控您的基础设施，如果您选择使用 OpenCensus 进行自定义指标遥测，您仍然需要确定最佳方法。
在本系列的后续文章中，我们将重新讨论这个库，我将逐步介绍如何在服务中创建指标并将它们导出到后端。
用于可观测性的日志记录
如果指标提供“正在发生什么”，那么日志记录会讲述“为什么”的部分故事。以下是一些用于持续收集和分析日志的常用选项。
使用 fluentd 收集
在 Kubernetes 生态系统中，fluentd 是收集集群中发出的日志并将其转发到指定后端的实际开源标准。您可以使用 config map 来修改 fluentd 的行为，在本系列的后续文章中，我将逐步介绍如何在集群中部署它并修改相关的 config map 以解析非结构化日志并将其转换为结构化日志，以便更好、更轻松地进行分析。与此同时，您可以阅读我的文章“自定义 Kubernetes 日志记录（第 1 部分）”，了解如何在 GKE 上执行此操作。
使用 ELK 存储和分析
日志最常见的存储机制是由 Elastic 以“ELK”堆栈的形式提供的。正如 Elastic 所说
“'ELK' 是三个开源项目的首字母缩写：Elasticsearch、Logstash 和 Kibana。Elasticsearch 是一个搜索和分析引擎。Logstash 是一个服务器端数据处理管道，它可以同时从多个来源摄取数据、对其进行转换，然后将其发送到像 Elasticsearch 这样的“存储库”。Kibana 让用户可以使用 Elasticsearch 中的图表和图形可视化数据。”
在本系列的后续文章中，我将逐步介绍如何在
集群中设置 Elasticsearch、Kibana 和 Logstash，以存储和分析 fluentd 收集的日志。
分布式追踪和可观测性
在分析服务问题时询问“为什么”时，日志只能提供应用程序旨在与之共享的信息。更深入的方法是收集追踪。正如 OpenTracing 倡议所说
“分布式追踪，也称为分布式请求追踪，是一种用于分析和监控应用程序的方法，尤其是那些使用微服务架构构建的应用程序。分布式追踪有助于查明故障发生的位置以及导致性能不佳的原因。”
Istio
Istio 开源服务网格为微服务架构提供了多项优势，包括流量控制、安全性和可观测性功能。它不会将多个 span 组合成单个追踪以组装用户调用遍历分布式系统时发生的完整画面，但它仍然可以作为分布式追踪的简单第一步非常有用。它还提供其他可观测性优势——它是获取每个服务的 “黄金信号” 指标的最简单方法，并且它还为每个请求添加日志记录，这对于计算错误率非常有用。您可以阅读我的关于将其与 Google 的 Stackdriver 结合使用的文章。我将在本系列中重新讨论它，并展示如何在集群中安装它并将其配置为将可观测性数据导出到后端。
OpenCensus
我在上面的“指标”部分中描述了 OpenCensus，这是选择它用于分布式追踪的主要原因之一：使用单个库进行指标和追踪是减少检测工作的好选择——但需要注意的是，您必须使用支持追踪和统计信息导出器的语言。我将回到 OpenCensus 并展示如何开始检测代码以进行分布式追踪。请注意，OpenCensus 仅提供检测库，您仍然需要使用存储和可视化层，例如 Zipkin、Jaeger、Stackdriver（在 GCP 上）或 X-Ray（在 AWS 上）。
Zipkin
Zipkin 是一个完整的分布式追踪解决方案，包括检测、存储和可视化。它是一套经过尝试和验证的工具，已经存在多年，并且拥有强大的用户和开发者社区。它也可以用作其他检测选项（如 OpenCensus）的后端。在未来的教程中，我将展示如何设置 Zipkin 服务器并检测您的代码。
Jaeger
Jaeger 是另一个开源追踪解决方案，它包含您需要的所有组件。这是一个较新的项目，正在云原生计算基金会 (CNCF) 中孵化。您选择使用 Zipkin 还是 Jaeger 最终可能取决于您对它们的经验以及它们对您编写服务的语言的支持。在本系列中，我将逐步介绍如何设置 Jaeger 并检测代码以进行追踪。
可视化可观测性数据
使用指标的工具包的最后一部分是可视化层。这里基本上有两种选择：持久层启用的“原生”可视化（例如，Prometheus UI 或 Flux with InfluxDB）或专门构建的可视化工具。
Grafana 目前是开源可视化的事实标准。在本系列的后续文章中，我将逐步介绍如何设置它并使用它来可视化来自各种后端的数据。
展望未来
Kubernetes 上的可观测性包含许多部分，并且每种类型的需求都有许多选项。指标、日志记录和追踪检测提供了做出有关服务决策所需的信息基础。检测、存储和可视化数据也至关重要。本系列未来的文章将深入探讨所有这些选项，并为每个选项提供动手教程。
评论已关闭。