问题起因
夜莺监控支持配置数据源，并对数据源里的数据做告警判定，但是如果数据源本身挂了，如何快速知道呢？在添加数据源的时候是有判断连通性的，添加之后数据源异常应该如何监控呢？
核心问题是：如果某个数据源已经离线，再让这个数据源判断自己的数据是否正常，就会产生循环依赖。更可靠的做法，是让另一个采集链路或另一个数据源对它做存活探测。
数据源离线告警解决思路
这是典型的数据源离线告警问题，有一些解决思路：
- 夜莺监控直接提供内置产品功能，比如在告警规则里，增加一个“数据源连通性”告警类别，后面有精力的话会安排，目前还没有内置这个功能；
- 使用 Flashduty 这类第三方轻量级告警方案，之前写过一篇文章可以参考：《监控系统的自监控怎么做》
- 使用多个数据源互相监控，比如 A 数据源监控 B 数据源，B 数据源监控 A 数据源
本文重点介绍第三个解法。
| 方案 | 适合场景 | 注意点 |
|---|---|---|
| 内置数据源连通性告警 | 产品内置能力完善后直接使用 | 原文提到目前还没有内置这个功能 |
| Flashduty 等外部轻量级告警方案 | 监控系统自身故障、告警链路需要外置兜底 | 告警通道尽量不要复用故障链路 |
| 多数据源互相监控 | 已经有多个 Prometheus、VictoriaMetrics 或其他数据源 | 避免 A 监控 A，要跨数据源探测 |
数据源互相监控，及时发现离线问题
所谓的 A 数据源监控 B 数据源，不是太准确，准确的架构如下：
上例使用的 agent 是 categraf，categraf 有一个 http_response 采集插件，用于探测 HTTP 地址的存活性，如果对端 HTTP 服务（这里就是 prom）挂了，categraf 会生成 http_response_result_code 的指标，只要监控这个指标就可以知道 prom 的存活性。告警规则的 promql 如下：
http_response_result_code != 0
当然了，你也可以使用 telegraf、blackbox_exporter 等工具，原理都是一样的。
落地时可以按这个顺序做：
- 选一个不依赖目标数据源的采集器，例如部署在另一个数据源侧的 Categraf。
- 用
http_response探测目标 Prometheus、VictoriaMetrics 或其他 HTTP 数据源的健康地址。 - 把探测结果写入另一个可用的数据源。
- 在夜莺里针对
http_response_result_code != 0配置告警规则。 - 告警通知最好走一条独立可靠的通道，避免数据源和告警链路同时失效。
FAQ
Q1：为什么不能让数据源自己监控自己是否离线？
因为数据源离线时，采集、存储或查询链路本身可能已经不可用。此时由它自己产生告警，容易形成循环依赖，故障时反而发不出告警。
Q2：只用 Categraf 才能做这个探测吗？
不是。原理是 HTTP 存活探测和指标告警，Categraf、Telegraf、blackbox_exporter 等工具都可以做，本文示例使用的是 Categraf 的 http_response 插件。
Q3：http_response_result_code != 0 表示什么？
在本文示例里，它表示 HTTP 探测结果异常。只要对端 Prometheus 服务不可达或探测失败，就可以通过这个指标触发告警。
