故障排除本身就是一门艺术，在本章中，我们将提供一些有关如何快速检测和修复问题的有用指南。您将发现公开关键信息的有用端点，了解 promtool、Prometheus 的命令行界面和验证工具，以及如何将其集成到您的日常工作流程中。最后，我们将研究 Prometheus 数据库并收集有关其使用的有见地的信息。
简而言之，本章将涵盖以下主题：
在本章中，我们将专注于 Prometheus 服务器并将部署一个新实例，以便我们可以使用新的测试环境应用本章中介绍的概念。
要创建 Prometheus 的新实例，请移至正确的存储库路径：
确保没有其他测试环境正在运行并启动本章的环境：
您可以使用以下方法验证测试环境的成功部署：
这应该输出以下内容：
新实例将可供检查，Prometheus Web 界面可通过 http://192.168.42.10:9090 访问。
您现在可以通过执行以下命令来访问 Prometheus 实例：
现在您已连接到 Prometheus 实例，您可以验证本章中描述的说明。
完成测试后，只需确保您在 chapter08/ 内并执行以下命令：
不要太担心——如果需要，您可以轻松地再次启动环境。
Prometheus 附带了一个非常有用的支持命令行工具，称为 promtool。这个小的 Golang 二进制文件可用于快速执行多个故障排除操作，并包含有用的子命令。
可用的功能可以分为四类，我们将在接下来介绍。
属于此类别的子命令为用户提供了检查和验证 Prometheus 服务器的多个配置方面和指标标准合规性的能力。以下部分描述了它们的用法。
promtool 提供了几种类型的检查。最有价值的一项是检查 Prometheus 服务器的主要配置文件。
check config 需要一个 Prometheus 主配置文件的路径，并输出其对配置有效性的评估。当出现问题时，此子命令可以告诉用户问题所在：如果是非破坏性问题，例如空的发现文件，它将输出警告但允许 promtool 成功退出;当遇到破坏性错误时，例如不正确的语法，它会输出错误并将检查标记为失败。使用工具返回的退出代码 - 0 表示成功，1 表示失败 - 是确保配置更改不会在重启时破坏 Prometheus 的好方法，应该使用作为飞行前检查。除了主配置文件外，此选项还递归检查任何引用的文件，例如规则文件。
下面的例子说明了它的用法：
检查规则 分析和查明规则配置文件中的错误配置。它允许直接定位特定规则文件，这使您可以测试尚未在主要 Prometheus 配置中引用的文件。此功能在规则文件的开发周期和使用配置管理时验证所述文件中的自动更改时都很方便。我们将在 第 9 章中深入介绍这些概念， 定义警报和记录规则。
这是检查规则文件时的预期输出：
check metrics 子命令验证传递给它的指标在一致性和正确性方面是否遵循 Prometheus 指南。这在开发周期中很有用，可以确保新仪器符合标准，如果您可以控制新作业是否遵循相同的规则，也可以在自动化中使用它。它期望度量有效负载通过 STDIN 作为输入，因此您可以将文件或 curl 的输出直接通过管道传输到其中。 为了这个例子，我们暴露了 Prometheus 中发生的一个问题 version 2.8.0 :
如您所见，prometheus_tsdb_storage_blocks_bytes_total 指标似乎存在问题。让我们看一下这个特定的指标来解决错误：
在这些旧版本的 Prometheus 中，该指标似乎被声明为量规，但具有 _total 后缀，只能在计数器中使用。
属于此类别的子命令可以直接从命令行执行 PromQL 表达式。这些查询依赖于 Prometheus 公共 HTTP API。以下主题演示了如何使用它们。
query instant 子命令允许根据当前时间直接通过命令行查询 Prometheus 服务器。为了使其工作，必须提供 Prometheus 服务器 URL 作为参数，以及要执行的查询，如下所示：
与前面的子命令类似，query range 可以在指定的时间范围内显示结果。因此，我们必须提供开始和结束 Unix 格式的时间戳，以及查询和 Prometheus 服务器端点。
例如，我们将使用 date 命令定义开始和结束时间戳，生成五分钟前的 Unix 格式时间戳和现在的另一个时间戳。我们还可以使用 --step 标志指定查询的分辨率，在我们的示例中为一分钟。最后，我们放置要执行的 PromQL 表达式，最后得到类似于以下的指令：
使用 query series 子命令，您可以搜索与一组指标名称和标签匹配的所有时间序列。以下是如何使用它：
使用查询标签，您可以在所有可用指标中搜索特定标签并返回附加到它的所有可能值；例如：
属于此类别的子命令允许从正在运行的 Prometheus 服务器中提取调试数据，以便对其进行分析。接下来我们将演示如何使用它们。
Prometheus 服务器与大多数用 Go 编写的严肃软件一样，使用标准库中名为 pprof 的包进行检测，该包使用特定格式提供运行时分析信息。以这种格式生成的文件随后可以由具有相同名称 (pprof) 的命令行工具读取，该工具使用它们来生成分析数据的报告和可视化。 promtool 提供了 debug pprof 子命令，我们可以在以下代码段中看到它的作用：
当我们提取上一个命令生成的存档时，我们可以看到几个文件：
使用 pprof，我们可以生成转储的图像，我们可以在下一个片段中观察到：
在您的主机上，在 ./cache/ 路径下的代码存储库中（相对于存储库根目录），您现在应该有一个名为 heap.svg，可以通过浏览器打开进行检查。以下屏幕截图显示了您在查看前面示例生成的文件时可能会看到的内容：
此子命令将提供的 Prometheus 实例公开的指标下载到压缩存档中。 debug metrics 并不常用，因为 /metrics Prometheus 端点可供任何能够运行此命令的人使用；它的存在是为了在被要求时更容易将 Prometheus 实例的当前状态提供给外部协助（例如 Prometheus 维护者）。该子命令可以按如下方式使用：
此选项将先前的调试子命令聚合为一条指令，如下例所示：
promtool 最近获得了针对定义的记录和警报规则运行单元测试的能力。在您可能需要检查表达式是否匹配以前从未发生过的某些条件的情况下，此功能非常有用，因此很难确保它们在时机成熟时会起作用。此子命令称为 test rules，它采用一个或多个测试文件作为参数。稍后我们将深入探讨此功能，当我们解决如何最好地利用 第 9 章，定义警报和记录规则。
在接下来的部分中，我们将介绍几个有用的 HTTP 端点和服务日志，它们对于解决 Prometheus 实例的问题非常重要。
检查 Prometheus 是否启动并运行通常非常简单，因为它遵循大多数云原生应用程序用于服务健康的约定：一个端点检查服务是否健康，另一个端点检查它是否准备好开始处理传入请求。对于过去使用或曾经使用过 Kubernetes 的人来说，这些可能听起来很熟悉；事实上，Kubernetes 也使用这些约定来评估容器是否需要重新启动（例如，应用程序是否死锁并停止响应健康探测）以及是否可以开始向容器发送流量。在 Prometheus 中，这些是 /-/healthy 和 /-/ready 端点。
您可以通过在测试环境中运行以下命令并检查它们的输出以及它们的 HTTP 状态代码来自己尝试这些端点：
此外，Prometheus 公开了一个 /debug/pprof/ 端点，由 promtool debug pprof 命令使用，如上一节所示。此端点还公开了一个可导航的 Web UI，可以在其中查阅 pprof 调试信息，例如当前的 goroutine 及其堆栈跟踪、堆分配、内存分配等：
与大多数当前软件相比，Prometheus 日志记录非常简洁。这是 Prometheus 维护人员非常有意识的努力，因为无关的日志记录可能会导致性能问题。此外，支持不同的日志流（例如应用程序日志、访问日志和慢查询日志）而不只是将其全部写入标准输出 - 从而使用其他类型的日志向应用程序日志发送垃圾邮件 - 将迫使 Prometheus 明确支持写入文件，这在云原生环境中是不可取的。话虽如此，您可以通过设置 --log.level 标志来配置 Prometheus 以增加应用程序日志的详细程度。例如，失败的抓取被认为是正常的操作行为，因此不会出现在日志中；但是，可以通过将日志详细程度增加到 debug 日志级别来记录它们。
本章测试环境中的 Prometheus 实例已经配置了日志级别设置为调试。您可以通过运行以下命令来确认这一点：
相关部分应设置以下标志：
所以，现在我们可以看到当一次抓取失败时会发生什么。为此，我们可以在测试环境中停止 node_exporter 服务并查看 Prometheus 日志：
Prometheus 服务器的一个关键组件是它的时间序列数据库。能够分析该数据库的使用情况对于检测系列流失和基数问题至关重要。在这种情况下，流失是指变得陈旧的时间序列（例如，从原始目标停止收集或序列从一次刮到下一次消失），然后开始收集具有稍微不同身份的新序列。一个常见的流失示例与 Kubernetes 应用程序部署有关，其中 pod 实例 IP 地址发生变化，使以前的时间序列过时，并用新的时间序列替换它。这会影响查询时的性能，因为返回的样本可能没有相关性。
值得庆幸的是，Prometheus 数据库的源代码中有一个不起眼的工具，可以分析其数据，并恰当地命名为 tsdb。
tsdb 工具可以针对 Prometheus 的整个数据库或仅针对特定数据块运行，并输出有关该数据健康状况的有用信息。要运行此工具，我们必须确保 Prometheus 服务器已停止：
我们将运行针对 Prometheus 数据库路径的 tsdb 工具。为简洁起见，我们将每个部分的输出限制为三个条目。如果没有将块名称指定为参数，则将使用最后一个可用的名称：
输出分为几个部分。在标题中，我们可以找到该块的摘要，包括以下内容：
在这里，我们可以看到上一条指令生成的输出：
虽然流失在我们的测试环境中并不是真正的问题，但我们可以看到检测到哪些标签对与产生流失的关联度最高：
接下来，我们可以找到流失率最高的标签名称：
在标签名称流失之后，我们会看到最常见的标签对：
最后，我们到达高基数部分，从标签开始：
最后，我们找到有关指标名称的统计信息：
如前所述，您可以选择不同的块进行分析：
tsdb 报告的好处在于，它可以更深入地了解指标和标签的使用方式，并针对其目标确定要探索和验证的优秀候选者。
在本章中，我们有机会尝试了一些有用的工具来解决和分析 Prometheus 配置问题和性能。我们从 promtool 开始，浏览了所有可用的选项；然后，我们使用了几个端点和日志来确保一切都按预期工作。最后，我们描述了 tsdb 工具，以及如何使用它来解决和查明普罗米修斯数据库中的基数以及指标和标签的流失问题。
我们现在可以进入记录和警报规则，这将在下一章中介绍。