add trans my-prometheus-is-overwhelmed-help

2021/09/my-prometheus-is-overwhelmed-help/my-prometheus-is-overwhelmed-help.md

@@ -0,0 +1,179 @@
+---
+original: https://hackernoon.com/my-prometheus-is-overwhelmed-help-qi1937xj
+author: Ryan Dawson
+translator: gf457832386 
+original: https://hackernoon.com/my-prometheus-is-overwhelmed-help-qi1937xj
+reviewer: ["审阅者 A 的 GitHub 账号","审阅者 B 的 GitHub 账号"]
+title: My Prometheus is Overwhelmed! Help!
+summary: 
+categories: Prometheus
+tags: ["Prometheus","monitoring","Time Series Databases"]
+originalPublishDate: 2021-07-24
+publishDate: 20XX-XX-XX
+---
+
+# 我的 Prometheus 不堪重负！求助！
+
+Prometheus 是一个用于监视 kubernetes 和时间序列数据的常用流行工具。许多开发人员只是简单地安装使用它。所以，当它开始不堪重负时，开发者往往不知所措。
+
+别慌! 我们将帮助您了解一些您可能遇到的情况以及您可以进行的选择。
+
+## “设置和 forget 策略”
+
+**设置和 forget 策略可以保证让你正常运行 prometheus 很长时间。** 但如果出现以下情况，您可能需要了解更多信息：
+
+- 您有一个大容量用例（您甚至可能没有意识到）。
+- 您需要长时间存储数据（数年或至少数月）。
+- 您在很大程度上依赖使用应用程序中的数据。
+- 有些东西出故障了。
+
+Prometheus 和大多数其他时间序列数据库的工作方式与 SQL 数据库非常不同，下面让我们更好地理解这一点。
+
+## 啊！它故障了!
+
+假设您已经知道如何在 kubernetes 上运行的应用程序中暴露一个指标端点。同时也已经建立了一个 grafana 仪表盘来监控你的应用程序的运行状况或其他数据，并且看起来运行得不错。甚至您已经构建了自己的UI可以直接查询 prometheus。在出问题之前，所有一切都看起来不错。
+
+### 查询变得缓慢
+
+可能有多种原因导致查询缓慢， 首先尝试排除最简单的原因：
+
+1. 如果您在自己的代码中调用 prometheus，您是否**关闭和暂停**您的 http 连接到 prometheus ?
+2. 您是否为 prometheus 分配了足够的资源？ 尝试增加资源并复制负载作为测试（最好在具有类似底层硬件的环境中）。
+3. 当您检查增加 CPU 和 RAM 时，还可以试着增加磁盘。 可能是磁盘已满，prometheus 必须进行清理（更多信息请参见下面的“数据消失”部分）。
+
+可能导致出错的更有趣的原因是数据量增加的方式导致查询速度变慢。 这可能会以惊人的速度发生。 **产生数据的系统可能会发生变化，但也可能是一些小变化产生了巨大影响**。
+
+我们经常没有预料到数据的增加会如何影响 prometheus 的原因是因为我们忘记查看基数。这是 prometheus 文档中一个重要但稍微复杂的部分：
+
+> “标签支持 Prometheus 的维度数据模型：任一对于相同指标名称给定的标签组合都标识一个该指标的特定维度实例（例如：所有使用 POST 方法发送到 /api/tracks 处理程序的 HTTP 请求）。查询语言允许基于这些维度进行过滤和聚合。更改任何标签值，包括添加或删除标签，都会创建一个新的时间序列。”
+>
+
+每个标签的每个不同值都会显著增加 prometheus 的工作。您不仅要考虑每次抓取时的每个指标值，还要考虑应用的每个标签组合。因此，在代码中自动生成标签名称是很危险的。使用像 userid 这样的标签也很危险，它可以有许多不同的值。
+
+我们应该把 prometheus 看作一个监控系统而不是一个数据库。如果标签中有很多变化，那么建议查看数据库（更多内容见下文）。
+
+如果您遇到此问题，有多种方法可以检查您的时间序列的基数。您可以运行查询 `sum(scrape_series_ added) by (job)` 。请参阅演示幻灯片“包含您的基数”获取有关这方面的更多信息以及如何减少基数。
+
+###  Prometheus 实际上故障了
+
+Prometheus 崩溃可能是上述讨论的问题导致的结果，也可能是因为工作负载太重导致内存不足。 除非你能获取更好的信息（例如从日志中），否则我会尝试查看上述内容。
+
+**还有其他相关的故障行为也可能是因为同样的原因发生，例如抓取变慢或内存峰值**。
+
+### 数据消失
+
+假设您运行了一些查询来显示某事发生的次数。 每次事件发生时它都会继续上涨并且一切看起来都很好......然后数值神秘地下降了。 为什么会这样？
+
+prometheus 通常不会永久保留数据。 实际上默认情况下它的保留期为 15 天（您可以配置）。 请注意，这是全局的，没有被任何特定类型的数据过滤。还有一个选项可以设置 prometheus可以使用多少磁盘空间。 因此，如果数据开始占用过多磁盘空间，那么它将开始删除数据。
+
+如果您像使用传统 SQL 数据库一样使用 prometheus，这可能与您的直觉相反。 因为它不是为长期存储而设计的（但如果有空间，您可以将其设置为保留很长时间）。 它是专为监控而设计，主要是关于在有限时间窗口内发生的瞬态数据（您可以将其视为“现在正在发生的事情”数据）。
+
+### 磁盘不足
+
+现在我们知道 prometheus 默认会删除超过保留期的数据。 如果分配的磁盘空间用完，更新版本的 prometheus 可能很快也会删除数据，尽管在撰写本文时这不是默认设置（您必须对其进行配置）。 所以如果你没有配置它，那么你可能会用完磁盘。
+
+### 查询超过最大数据点
+
+如果单个查询返回太多数据点，prometheus 根本不会完全执行它。相反，您会收到一条消息指出查询超出了数据点限制，默认为 11,000。
+
+当我尝试在几个月的时间内运行一个查询时，我遇到了这个问题。但这可能取决于您收集的数据量和密度(包括您的抓取间隔有多短)。
+
+**当我第一次遇到这个问题时我的反应有点过激了**。我写了一个导出器项目从 prometheus 读取 metrics 指标数据，按时间间隔来汇总数据，使间距变大（从而减少数据点的数量），并将其作为新的时间序列输入。（这是导出器的常用用法，它通常用于代表另一个服务抓取数据，而不是从普罗米修斯数据采集服务中取出并重新放回。）
+
+我正在做的事情称为向下采样。获取数据并对其进行重组来增加数据点之间的时间间隔，从而使整体数据点更少。最简单的方法通常是记录规则（这是我当时意识到的）。这些基本上是您写入 prometheus 配置的查询，这些查询从现有的时间序列创建新的时间序列。
+
+### 我真的必须减少我的数据吗？ 没有更简单的方法吗？
+
+到目前为止，我们所说的基本上是：
+
+- 长时间内不要有大量密集数据。
+- 尤其不要尝试长时间查询大量密集数据。
+- 如果您必须查询大量数据，请考虑重组您的数据以降低其密度。
+
+所以此时你可能想知道“我真的必须减少我的数据吗？”这真的取决于你的情况。 如果有人想知道是否有一些工具可以使这变得更容易，让我们来看看一些补充或替代 prometheus 的工具以及它们之间的比较。
+
+## 扩展普罗米修斯
+
+### 高可用性
+
+你可能会想，“我不能通过运行更多的 prometheus 实例来处理更多的数据吗？”答案是可以，同时也不可以。
+
+使用 HA Prometheus，每个 prometheus 处理一些数据。推荐的方法是“功能分片”。这意味着对于每个被抓取的服务，它的所有数据都由一个prometheus处理。功能分片不是切分数据的唯一方法，但是是最简单的方法。这意味着每个 prometheus 都有一个明确、特定的职责。
+
+功能分片更多地用于扩展服务数量。如果您的单个服务产生大量数据（例如，查询的数据过多），那么功能分片是没有帮助的。
+
+Prometheus 数据可以进行不同的分片以实现高可用性。当您拆分数据时，您需要一种将其重新组合在一起以进行查询的方法。这是通过联邦实现的。基本上，某些 prometheus 实例会从其他实例收集数据，以便数据得到充分整合，您可以知道要查询哪个 prometheus。
+
+关于联邦部分prometheus文档中建议使用一些只包含聚合全局数据的普罗米修斯实例。聚合是减少基数的一种方法，并使运行原本会达到限制的查询成为可能。但是设置它仍然需要记录规则。因此，为了减少基数，其实是记录规则在做这项工作，而不是联邦。然而，这并不意味着记录规则是唯一的方法。
+
+### Thanos
+
+Thanos 是 CNCF 中的另一个开源项目。它补充了 prometheus，可用于更好地扩展 prometheus。其要点：
+
+- 将层添加到 prometheus 以进行扩展。
+- 支持对来自多个 prometheus 实例的数据进行下采样、长期存储和聚合。
+- 有几个组件例如 prom sidecars、compactor 和 query 模块——如果全部都使用的话，**是相当笨重的**。
+- 由于组件数量众多，安装和正确测试可能很棘手。
+- 查询模块支持 PromQL。
+
+有关这些组件的详细信息，AWS 有一篇很好的概述文章。主要思想是 thanos 可以帮助长期存储、查询数据点限制和联邦。但这不是一键式解决方案。它针对每个问题有不同的组件。
+
+如果您的主要关注点是单个查询达到限制（这是我之前面临的主要问题），那么您感兴趣的特定组件是 compactor。该组件可以自动对数据进行下采样，以便查询能够在更大的时间范围内运行，而不会达到最大数据点限制。
+
+Thanos 并不是唯一可以与 prometheus 合作以帮助其扩展的工具。有许多工具可以获取普罗米修斯数据并将其长期存储，并且在官方普罗米修斯文档中列出了它们。
+
+同时，还有其他可以替代 prometheus 的工具。实际上有一些工具可以与 prometheus 一起使用，也可以代替 prometheus 使用。这可能会使选择变得混乱，下面让我们尝试解释一下。
+
+## 时间序列数据库场景
+
+这是对一些时间序列数据库的选择性概述。 它并不全面。 我的目标是提供一个可以很好地了解可选择范围以及理解它们的方法和目的的选择。
+
+人们对时间序列数据库感到困惑的一件事是它们不是基于像 SQL 这样的标准或像关系数据库这样的单一设计理念。而是 **任何适用于存储时间戳和值对以及该数据的相关用途（例如监控）的数据库**。
+
+### InfluxDB
+
+InfluxDB 被设计为适用于指标的时间序列数据库。它可以是 prometheus 的替代品，也可以作为 prometheus 的后端作为长期存储。 如果单独运行，它会收集数据。 如果使用 prometheus 运行，则 prometheus 收集数据，InfluxDB 从 prometheus 获取数据。
+
+InfluxDB 的一些关键点：
+
+- 进行向下采样和长期存储。
+- 更年轻所以没有 prometheus 那么多使用。
+- 看起来比 Thanos 更容易运行。
+- 需要自己的查询格式，不支持 PromQL。
+- 能够像 prometheus 一样抓取。
+
+### Elasticsearch
+
+Elasticsearch 当然是一个基于文档的数据库和搜索引擎，所以这可能是一个惊喜。 但是 elasticsearch 也可以用于时间序列数据。 而 elastic 可以作为 prometheus 的长期存储。
+
+Elastic 可用于本地时间序列，无需 prometheus。 他们有一个关于 CPU 指标的示例，表明它可以在查询时进行下采样，同时还可以摄取 kube-state-metrics。
+
+对于对 elastic 感兴趣的 prometheus 用户的主要挑战是 elastic 对于这些使用用例还没有非常好地建立，所以详细的例子可能很难找到（至少在撰写本文时没有找到，但如果有人有请随时与我联系，例如推特）。
+
+与 influx 的比较表明，elastic 和 influx 都可以用于时间序列，而 influx 不能用于文本（例如 nlp 用例、EFK 日志收集）。 这是有道理的—— elastic 是一个也可以做时间序列的文档数据库，而 influx 是专门针对时间序列的。
+
+### TimescaleDB
+
+TimescaleDB 是基于 postgres 的关系型数据库。 TimescaleDB 的一些关键点：
+
+- 提供具有托管的开源产品。
+- 支持下采样和长期存储。
+- TimescaleDB 作者提供了有趣的示例数据集。
+- 可用作 prometheus 数据的长期存储。
+- 可以使用 Promscale 支持 Prometheus 样式的抓取。
+- 可以通过 Promscale 支持 PromQL。
+
+### 其他
+
+这个领域还有很多我们没有介绍的产品，例如 Cortex、VictoriaMetrics、M3db、Graphite、Datadog 等。 以上选择旨在让读者了解空间的多样性，并帮助读者自行探索。
+
+
+
+## 你不是一个人
+
+如果您的 prometheus 不堪重负，请记住您并不孤单。 普罗米修斯遇到限制是很正常的。 有很多工具可以解决这个问题。 甚至还有我们在此未涉及的新兴方法（例如检测基数爆炸的发生方式和时间）。
+
+不存在一个简单的解决方案适用于所有情况。 您需要考虑您的情况以及对您来说最重要的事情。 我要给您的建议是：
+
+- 真正探索普罗米修斯 UI 和 PromQL。 如果您知道如何找到它，则所有记录规则以及正在抓取的内容等等都在 prometheus UI 中。
+- 使用 slack groups 询问其他人做了什么。 这篇文章从关于 kubernetes 的对话和关于 kubernetes slack groups的数据(DOK)中受益匪浅的。