prometheus_0">prometheus如何应对告警目标消失带来的评估缺失问题

1、up指标剖析

基于拉取的监控（例如 Prometheus）的优势之一是，您可以在抓取过程中判断目标是否健康。

关于 Prometheus 的一个常见问题是如何判断服务器是否没有响应或检测样本是否不再从目标中摄取。简单黑盒监控的首选工具是黑盒导出器，您可以使用 unless 和 offset 进行边缘检测，以检测时间序列是否未更新。然而，有一种更简单的方法可以涵盖大多数用例。

当 Prometheus 抓取目标时，它不只是摄取返回的样本。它还添加了一些关于抓取本身的额外示例。主要的是 up指标，如果抓取失败则为 0，如果抓取成功则为 1。

关于 up 有几件事你应该知道：

• 1、它不是来自 scrape 本身，所以 metric_relabel_configs 不适用。也就是说，up 总是有目标的标签，每个服务发现和 relabel_configs。

• 2、只要目标从服务发现中返回，up 就会获得新值。这意味着如果自动缩放删除了一个实例，您将不会收到它已关闭的警报，这正是您想要的。但是，这也意味着如果自动缩放删除了所有实例，您也不会收到警报。为了防止这种情况，明智的做法是为所有工作消失的情况创建一个带有表达式 absent(up{job=“myjob”}) 的警报。

• 3、有额外的时间序列表现得像up，都是以scrape_为前缀的。这些对于调试很有用

  • scrape_duration_seconds{job=“”, instance=“”}: duration of the scrape.
  • scrape_samples_post_metric_relabeling{job=“”, instance=“”}: the number of samples remaining after metric relabeling was applied.
  • scrape_samples_scraped{job=“”, instance=“”}: the number of samples the target exposed.
  • scrape_series_added{job=“”, instance=“”}: the approximate number of new series in this scrape.

• 4、即使他们遇到的实例失败，一些exporter也会成功，通常是因为在这种情况下他们仍然可以提供一些有用的信息。因此，up 为 0 的警报是必要的，但还不够。在这种情况下，您可能还需要关于 haproxy_up、mysqld_up、consul_up、probe_success（由black box exporter使用）等的警报。

2、Alerting on Down Instances（探测目标down）

假设已经设置了监控并正在抓取实例，无论是用于机器监控的节点导出器还是其他导出器。要为已关闭 10 分钟的每个实例生成警报：

groups:
- name: node.rules
  rules:
  - alert: InstanceDown
    expr: up{job="node"} == 0
    for: 10m

标签的强大功能意味着您只需定义一次此警报，它就会自动应用于您所有带有节点标签的实例！

单个实例发生故障不值得叫醒某人。只在 25% 的实例停机时发出警报怎么样？

groups:
- name: node.rules  
  rules:
  - alert: InstancesDown
    expr: avg(up{job="node"}) BY (job) 

3、Absent Alerting for Jobs（探测目标缺失）

使用 Prometheus 可以轻松地对数字过大或过小发出警报。但是，如果数字丢失了怎么办？

在正常操作中，您的 Prometheus 会发现您的目标，抓取它们，并将运行您针对它们定义的任何警报规则。但这可能会出错。例如，您的实例可能会从服务发现中消失，这将导致任何警报（例如 avg by (job)(up) < 0.5 不返回任何内容而不是发出警报）。如前所述，当没有输入时，聚合器不产生输出。

因此，建议对作业消失的所有目标发出警报，例如：

groups:
- name: example
  rules:
  - alert: MyJobMissing
    expr: absent(up{job="myjob"})
    for: 10m

这使用了 absent 函数。如果给定的选择器不匹配任何内容，则返回值为 1 的单个时间序列和任何相等匹配器的标签。例如，在这种情况下，警报的标签为 job=“myjob”。如果有匹配的系列，则不返回任何内容。

Prometheus 不知道应该存在哪些标签集，因此您需要为每个作业设置一个这样的警报。这仅适用于不存在和其他时间序列缺失的情况，如果您只想检测目标是否已关闭，您可以像往常一样使用一个警报规则来完成。

4、Absent Alerting for Scraped Metrics（探测metrics缺失）

如果想针对一个目标消失的特定指标发出警报怎么办？

注意：最好避免出现和消失的指标，但是目标的某些子系统并不总是返回它们应该返回的所有指标。可以通过注意到 up 指标存在但所讨论的指标不存在来检测这种情况。此外，您需要检查 up 是否为 1，以便在目标关闭时不会误触发警报。如果您已经收到有关该工作的警报，则无需再向自己发送有关缺少指标的垃圾邮件。

警报看起来像：

groups:
- name: example
  rules:
  - alert: MyJobMissingMyMetric
    expr: up{job="myjob"} == 1 unless my_metric
    for: 10m

5、对于使用可能不存在的指标的规则如何处理

如果您正在对多个指标进行数学运算，而其中一些指标并不总是存在，那么处理起来可能会很困难，并会导致警报不触发。这方面的一个例子是:

如果您有一个失败指标和一个成功指标（忽略建议改为使用失败指标和总指标）。如果标记了这些但没有成功，则将失败率计算为： rate(failure[1m]) / (rate(failure[1m]) + rate(success[1m]))
由于缺少成功指标中的匹配标签集。因此，100% 的故障率会导致高级别故障警报永远不会触发！

对于您正在使用可能不存在的指标的情况，例如成功/失败示例，方法是根据我们知道存在的某些指标（通常是 up）或在缺失的标签集中。因此，例如，上面的故障率将变为：

(rate(failure[1m]) or up * 0)
  /
((rate(failure[1m]) or up * 0) + (rate(success[1m] or up * 0))