我目前有一些基于“ tcp_connect”和“ http_2xx”探针的警报规则，这些警报规则在非常高的级别上指示TCP和HTTP问题，尚未针对特定警报。
每当由于DNS查找问题而导致探针无法与目标成功对话时，我要么从“ tcp_connect”获得有关TCP连接的警报，要么从HTTP收到基于HTTP状态代码（0）的警报。 “ http_2xx”，但是这两个警报都不正确。
我认为，每当DNS查找失败时，probe_dns_lookup_time_seconds可能为0，但事实并非如此，考虑到这一点也是合乎逻辑的。
因此，我尝试了probe_http_duration_seconds{phase="resolve"}，当DNS查找出现问题时，该尝试似乎为0，但我并不十分确信这是正确的做法。
我检查了负责DNS查找的代码，似乎如果有错误或无法解析IP，则会返回“ 0.0”的查找时间。
我希望我可以保证这是正确的方法，或者希望得到一些反馈以找到更合适的解决方案。
注意
我不是在谈论针对DNS服务器的DNS探针，否则我可能对DNS探针的用途有误解，显然这也是有可能的！
答案 0 :(得分：0)
我希望我可以保证这是正确的方法，或者希望得到一些反馈以找到更合适的解决方案。
您想要的指标是probe_success，因为您并不真正在意什么会导致端点崩溃，因为您将以一种或多种方式对其进行警报。您可以在分页后找出确切的问题，并且避免维护许多脆弱的特定于原因的警报。
我不是在谈论针对DNS服务器的DNS探针，否则我可能对DNS探针的用途有误解，显然这也是有可能的！
您的理解是正确的。