我要评论
夜莺监控是一款开源云原生观测分析工具，采用 all-in-one 的设计理念，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日，在 github 上发布 v1 版本，已累计迭代 100 多个版本。
夜莺最初由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（ccf odc），为 ccf odc 成立后接受捐赠的第一个开源项目。夜莺的核心研发团队，也是 open-falcon 项目原核心研发人员，从 2014 年（open-falcon 是 2014 年开源）算起来，也有 10 年了，只为把监控这个事情做好。
夜莺架构
整体来看，分三大部分：
- 中间紫色部分：夜莺的服务端相关模块，是夜莺的核心组件，包括夜莺进程本身，以及依赖的 mysql、redis，图上也画了时序库 victoriametrics 和 prometheus，这部分其实不是必须的，后面会讲到。
- 左侧蓝色部分：是各类采集器，我们推荐您使用 categraf，和夜莺的整合最为丝滑，当然，您也可以使用 telegraf、datadog-agent 等其他社区常见采集器。
- 右侧红色部分：是告警通道，夜莺可以把告警发给钉钉、企微、飞书、slack 等 im，也可以发邮件、电话、短信，也可以通过 webhook 推给第三方，如果您对告警收敛、降噪、排班、认领升级等功能有诉求，可以接入 flashduty 事件 oncall 中心。
下面我们详细解释各个部分的功能。
夜莺服务端
中间灰色部分是夜莺服务端，即 n9e 进程，包含三个功能，分别是：
- pushgateway：接收各类采集器推送的指标数据，这个是可选的，待会会讲到。
- webui：夜莺的 web 界面，提供给用户配置监控、查看监控数据、查看告警等功能。
- alertengine：告警引擎，根据用户配置的告警规则，连到各个时序库数据源，查询数据做异常判断。
pushgateway
pushgateway 是 n9e 进程的一部分能力，可以接收各类采集器推送的指标数据，然后转发给时序库。不同的采集器推送的数据格式不同，比如 categraf 是按照 prometheus remote write 协议推送的，datadog-agent 有自己的格式，telegraf 则比较开放，支持 opentsdb、influxdb、prometheus 等格式。pushgateway 提供多种数据接收接口，接收到数据之后，会把监控指标数据转发给时序库。
以 categraf 为例，categraf 采集了数据推送给夜莺，需要配置服务端的地址，配置样例如下:
[[writers]]
url = "http://127.0.0.1:17000/prometheus/v1/write"
basic_auth_user = ""
...
这里的 127.0.0.1:17000，要改成您的环境的夜莺的地址。这里的 /prometheus/v1/write 就是夜莺提供的一个 api，用于接收 prometheus remote write 协议的数据。夜莺还提供了其他数据接收的 api，具体可以参考这里。
夜莺收到数据后，需要转发给时序库，那夜莺怎么知道要转发给那些地址呢？在夜莺的配置文件 etc/config.toml 中配置：
[[pushgw.writers]]
url = "http://127.0.0.1:9090/api/v1/write"
...
这里的 127.0.0.1:9090 是 prometheus 地址样例，夜莺转发数据给时序库也是走的 prometheus remote write 协议，所以上面的 url 的 urlpath 是 /api/v1/write，这是 prometheus 的数据接收路径。注意，这个配置文件是 toml 格式，在 toml 中 [[]] 表示数组，这意味着，你可以配置多份 [[pushgw.writers]] 区块，即，夜莺可以同时转发数据给多个时序库。
上面讲解的数据流是 categraf 作为采集器，采集了数据推给夜莺，夜莺再转发给时序库，那如果你不用 categraf，比如你使用 prometheus 直接抓取各类 exporter 的数据，数据已经在时序库了，那这个 pushgateway 其实就没用了，夜莺的配置文件 etc/config.toml 中也不需要配置 pushgw 相关的信息。
不过，如果不使用 categraf，夜莺的机器列表就会为空，告警自愈功能也没法用了，所以我们推荐您使用 categraf 作为机器常规指标的采集器，在每个机器上部署 categraf，至于各类中间件、数据库的监控数据，倒不强求使用 categraf 采集。
另外，categraf 的配置文件 conf/config.toml 中还有 heartbeat 的配置，配置的是夜莺的 heartbeat 地址，注意修改为您的夜莺地址。heartbeat 会采集机器的一些元信息上报给夜莺，之后您可以在夜莺页面的机器列表中，点击各个机器，看到具体有哪些元信息。
webui
夜莺提供了一个 webui 页面，用于查看监控数据、管理告警规则、查看生成的告警事件等等，页面有权限控制体系，如果您想把监控能力开放给公司所有团队，让各个团队自助服务，权限体系就比较有用了。
夜莺 v7 版本默认监听的端口是 17000，您在浏览器中使用 http://your_n9e_ip:17000 就可以访问到夜莺的 webui 页面，如果您想修改端口，可以修改配置文件 etc/config.toml 中的 http.port 配置项（在配置文件中搜索 17000 就可以看到具体在哪个位置了）。
alertengine
告警引擎是夜莺最核心的能力。通常一个公司会有多个时序库，管理告警规则比较费劲，使用夜莺的话，可以在一个地方维护告警规则，然后生效到不同的时序库。
您要针对某些时序库的数据做告警，首先要在页面配置数据源，目前支持 prometheus 兼容的各类数据源，比如 thanos、victoriametrics、m3db、prometheus 等，也支持接入 tdengine、loki 数据源，对这些数据源的数据做告警判断。
告警引擎会根据告警规则的配置，拿着规则中的 promql，周期性查询时序库，如果查到了就产生告警事件，查到几条数据就产生几条事件。当然，如果告警规则中配置了持续时长，那就是说，只有连续几次查询都查到了，才会产生告警事件。告警引擎的判定逻辑参考这里：触发告警和恢复的底层逻辑是什么？。
服务端高可用
夜莺依赖 mysql、redis，mysql 和 redis 的高可用社区有很多方案，这里不再赘述。对于 n9e 进程本身的高可用，非常简单，就是找多个机器，每个机器部署一个 n9e 进程即可，集群中的多个 n9e 进程，其配置完全一样。
多个 n9e 前面最好是搞一个负载均衡，用户使用负载均衡的地址来访问夜莺，categraf 中的夜莺的地址也配置为负载均衡的地址。
边缘模式
如果某公司是多机房，某个机房与其他机房的网络质量很差。比如，夜莺 n9e 进程部署在北京，某个时序库部署在美东，美东和北京的网络不好，此时 n9e 作为告警引擎，周期性查询美东的时序库，就经常会超时，导致告警不准确。怎么办呢？
我们提供了 n9e-edge 模块，用于这类边缘机房的场景。在这里，可以把 n9e-edge 部署在美东，n9e-edge 会从中心 n9e 同步告警规则，缓存在内存中，然后查询美东的时序库做告警判定，即便美东和国内网络断了，美东的 n9e-edge 内存中还缓存了一份告警引擎，可以继续判定告警。
n9e-edge 要连 n9e 进程的 api，所以，我们要在 n9e-edge 的配置文件中给出中心 n9e 的地址，即 centerapi 相关的配置项，具体可以参考：边缘机房部署夜莺，应对网络割裂的情况。
总结
本文从大面上讲解了开源夜莺的架构，希望对您有帮助，夜莺的 github 地址是：https://github.com/ccfos/nightingale 如果您对此开源项目感兴趣，可以 star 一下留备后用。
发表评论