问题描述
在逐步将 Prometheus 集成到监控工作流程中，以便收集有关正在运行的基础架构的详细指标。然而，他在使用过程中遇到了一个奇怪的问题：有时 Prometheus 需要从某个 exporter 中获取数据，但该 exporter 变得不可响应。可能是由于网络配置错误（无法访问）或 exporter 崩溃等原因。不论原因是什么，他发现一些期望在 Prometheus 中看到的数据缺失，某个时间段内的系列数据完全缺失。有时，一个 exporter 失败（超时？）似乎还会导致其他 exporter 也失败（第一个超时导致整个任务超过顶层超时？这只是猜测）。
用户在可视化中只能看到系列数据中的空白。当问题发生时，日志中没有任何内容。Prometheus 的自我指标也相对较少。用户已尝试手动复制 Prometheus 的操作并查看何处中断，但这种方法令人不快。用户希望能找到更好的方法。虽然他不需要实时警报，但至少希望能够看到 exporter 未能传递数据的情况。甚至一个布尔型的“嘿，检查你的数据”标志也是一个好的开始。
用户想知道如何获得有关 Prometheus 无法从 exporter 获取数据的有意义信息。如何了解为什么会出现数据缺失，而无需手动模拟 Prometheus 数据收集？在这方面，有什么明智的做法，甚至可以扩展到一般的监控数据收集，超越 Prometheus？
解决方案
根据您的情况，我们将提供几种解决方案来解决 Prometheus 数据缺失问题。
方案1：使用告警规则监测指标的变化
您可以使用 Prometheus 的告警规则来监测 exporter 是否未能传递数据。以下是一个示例告警规则，用于在某个 exporter 的指标速率为零时触发警报：
# 当 <metric_name> 指标的速率为零，持续 3 分钟时触发告警
ALERT DropInMetricsFromExporter
IF rate(<metric_name>[1m]) == 0 FOR 3m
ANNOTATIONS {
summary = "指标速率为零 {{ $labels.<your_label> }}",
description = "指标速率为零，实际值: {{ $value }}%",
}
这里的关键在于选择正确的监测指标。在告警规则中，您可以根据实际情况调整 <metric_name> 和 <your_label> 等参数。
方案2：检查 exporter 是否不可达
如果某个 exporter 不可达，它的 up 指标将为 0。您可以创建一个告警规则来在 exporter 不可达时触发警报，如下所示：
# 当实例不可达超过 5 分钟时触发告警
ALERT InstanceDown
IF up == 0 FOR 5m
LABELS { severity = "page" }
ANNOTATIONS {
summary = "实例 {{ $labels.instance }} 不可达",
description = "{{ $labels.instance }} 作业的实例已不可达超过 5 分钟。",
}
此外，如果 Prometheus 服务器过载，可能会导致采集停止，也会造成数据缺失。您可以通过以下告警规则来监测这种情况：
# 当 prometheus_target_skipped_scrapes_total 指标的速率超过阈值时触发告警
ALERT PrometheusSkipsScrapes
IF rate(prometheus_target_skipped_scrapes_total[2m]) > 0 FOR 5m
方案3：修复 Java exporter 的 Full GC 问题（仅适用于 Java 应用）
如果您的 exporter 是 Java 应用，您可能会遇到由于 Full GC 导致的数据收集中断问题。您可以通过显式使用 G1 垃圾回收器（Java 8+）并设置 GC 活动持续时间限制来解决这个问题。
请注意，每种方案的适用性取决于您的具体情况，您可能需要根据您的环境和需求进行调整。
总之，通过告警规则监测指标变化、检查 exporter 可达性以及解决 Java Full GC 问题，您应该能够更好地了解并解决 Prometheus 数据缺失的问题。