【博客668】prometheus如何调试和解决out of order samples

prometheus debugging out of order samples

prometheus tsdb is append only

Prometheus 内部的 TSDB 是仅附加的，一旦系列有 t=10 的样本，您就不能摄取任何更早时间的样本，例如 t=9。如果刮擦尝试这样做，您将收到如下警告：

level=warn ts=2020-05-26T11:01:50.938Z caller=scrape.go:1203 component=“scrape manager” scrape_pool=test target=:8000/metrics msg=“Error on ingesting out-of-order samples” num_dropped=1

这里的 test 是抓取配置的 job_name，target 是被抓取的 URL。只提供了有多少样本受到影响，否则它可能是垃圾邮件。如果您使用 --log.level=debug 打开调试日志记录，您可以获得相关系列的名称：

level=debug ts=2020-05-26T11:01:50.938Z caller=scrape.go:1245 component=“scrape manager” scrape_pool=test target=:8000/metrics msg=“Out of order sample” series=“a{foo=“bar”}”

如何调试和解决来自 Prometheus 的“Error on ingesting out-of-order samples”警告？

你如何解决这个问题？首先，您需要了解导致这种情况的原因。

• 这种最简单但可能性最小的情况是：单个目标在一次抓取中（即多次公开同一系列，时间戳向后）或跨抓取公开乱序时间戳。这可以通过多次刷新抓取端点并查看事情是否正在倒退或是否存在具有递减时间戳的重复系列来检查。如果这是问题所在，则需要在该目标的代码中修复它。请记住，目标应该很少公开时间戳。
• 另一个可能但不太可能的原因是您设法创建了两个具有相同目标标签的目标。这在一个抓取配置中是不可能的，因为目标将被删除重复，但可以在多个抓取配置中发生。这不需要目标公开时间戳，如果发生这种情况，您会注意到生成的指标（如 up 和 scrape_duration_seconds）会受到影响。那么这是如何发生的是两个抓取循环将按照自己的时间表独立抓取目标。提取数据的时间戳默认是抓取统计信息时的时间戳。假设第一次刮擦从 t=1 开始，第二次刮擦从 t=2 开始，第二次刮擦在 t=3 结束，第一次刮擦在 t=4 结束。当第二次抓取完成时，将使用时间戳 t=2 摄取，因此当第一次抓取完成并随后尝试摄取 t=1 时，由于出现故障而失败。这是一种竞争条件，因此可能不会始终如一地显示，并且通常只会从两个相关目标之一生成日志。要检查这是否是原因，请检查 Prometheus 中的任何其他目标是否具有与日志消息中引用的目标相同的目标标签。要解决此问题，请确保 Prometheus 中的所有目标都具有唯一的目标标签，方法是添加可区分的标签或删除重复的目标。
• 一个相关的潜在原因是系统时间在运行 Prometheus 的机器上倒退。对于时间更改之前和之后存在的所有目标，这将显示为广泛的无序，从而影响已抓取的系列和生成的系列，例如 up。要检查这是否是原因，请评估普罗米修斯正在抓取的某个目标的时间戳（向上），看看它是否在未来。要解决此问题，您可以等待系统时间恢复，或者从 Prometheus 中删除“未来”数据。
• 最常见的原因是联合，其中 HA 设置中的两个 Prometheus 服务器自然包含所有具有不同时间戳的相同系列，并且正在使用 honor_labels 但时间系列没有得到区分。如果是这种情况，修复只是为了确保两个 Prometheus 服务器都具有不同的 external_labels，这是您在任何情况下都应该做的。如果您有两个 pushgateways，给定的批处理作业正在向这两个 pushgateways 推送，也可能发生这种情况，在这种情况下，添加一个与任何被抓取的标签不冲突的可区分目标标签应该可以修复它。如果不是像这样更简单的情况，您可能需要花费大量时间来弄清楚到底是什么导致了冲突。从不需要它们的任何目标中删除 honor_labels 和过于宽泛的 metric_label_configs 也是明智的。

如何确定有这种情况发生

• prometheus_target_scrapes_sample_out_of_order_total 指标还跟踪这种情况在 Prometheus 中发生的频率。您的目标应该是确保这种情况永远不会发生，因为它通常表示存在编码、架构或配置缺陷。所有这些只涉及与其他目标交互的目标，这个问题可能发生在您可以应用类似调试技术的记录和警报规则中。