基于 DNS 查找的警报答案

【问题标题】：Alerting based on DNS lookup基于 DNS 查找的警报
【发布时间】：2019-11-11 12:52:25
【问题描述】：

我目前有一些基于“tcp_connect”和“http_2xx”探测的警报规则，它们指示非常高级别的 TCP 和 HTTP 问题，尚未针对特定警报。

每当探测器由于 DNS 查找问题而无法成功与其目标通信时，我会从“tcp_connect”或基于 HTTP 状态代码 (0) 的 TCP 连接收到警报“http_2xx”，但这两个警报都不是真正正确的。

我想，每当 DNS 查找失败时，probe_dns_lookup_time_seconds 可能为 0，但事实并非如此，这也是合乎逻辑的。

所以我尝试了probe_http_duration_seconds{phase="resolve"}，当 DNS 查找出现问题时，它似乎为 0，但我并不认为这是正确的做法。

我检查了负责 DNS 查找的代码，似乎如果出现错误或无法解析 IP，它会返回“0.0”的查找时间。

我希望我能够得到一些保证，即这是正确的做法，或者获得一些反馈以找到更合适的解决方案。

注意
我不是在说DNS服务器的DNS探测，或者我可能对DNS探测应该用于什么有误解，显然这也是一种可能！

【问题讨论】：

【解决方案1】：

我希望我能够得到一些保证，即这是正确的做法，或者获得一些反馈以找到更合适的解决方案。

您想要的指标是probe_success，因为您并不真正关心导致端点关闭的原因，因为您会以一种或另一种方式发出警报。可以在您被寻呼后找出确切的问题，并且避免必须维护许多脆弱的特定原因警报。

我不是在说DNS服务器的DNS探测，或者我可能对DNS探测应该用于什么有误解，显然这也是一种可能！

你的理解是正确的。

【讨论】：

在我的情况下，我确实喜欢更具体的警报，因为如果它是 DNS 的问题，甚至是应用程序正在运行的服务器本身的可访问性问题，我想提醒其他人，而不是说它是应用程序本身返回 503。我确实认为特定于原因的警报可能过于具体，但我也认为在某种程度上值得拥有特定于原因的警报，以便正确的人尽快了解问题，而不是必须通知他们的人。