国产监控之光-夜莺监控（Nightingale）

国产监控之光-夜莺监控（Nightingale）

夜莺是什么？

夜莺是一个服务端组件，类似 Grafana，可以对接不同的TSDB时序数据库作为数据源，支持的TSDB时序数据库如Prometheus、VictoriaMetrics、Thanos等等，只要数据进到这些库里了，夜莺就可以对数据源的数据进行分析、告警、可视化，以及后续的事件处理、告警自愈。

当然，夜莺也有端口接收监控数据，可以跟开源社区常见的各种监控采集器打通，比如Telegraf、Categraf、Grafana-agent、Datadog-agent、Prometheus生态的各类Exporter等等。这些agent采集了数据推给夜莺，夜莺适配了这些agent的数据传输协议，所以可以接收这些agent上报的监控数据，转存到后端对接的数据源，之后就可以对这些数据做告警分析、可视化。

夜莺部署架构

根据生产网络环境，夜莺可以实现中心汇聚式部署方案和边缘下层式混杂部署方案。

对于网络结构简单或小规模网络场景下，采用中心汇聚式部署方案实施比较简单，可以n9e核心组件采用单机或集群方式搭建，集群模式下前端需架设Nginx作为软负载或F5进行硬件设备负载，同时依赖MySQL和Redis中间件存储基础的元数据、用户信息等，不存在大数据量问题，因此，不用太考虑性能瓶颈。

Categraf是夜莺团队开发维护的监控采集侧核心组件，类似Telegraf、Grafana-Agent、Datadog-Agent，希望对所有常见监控对象提供监控数据采集能力，采用All-in-one的设计，不但支持指标采集，也希望支持日志和调用链路的数据采集。Categraf采集器采集了数据推送给夜莺，然后转存到后端数据源，如TSDB、ElasticSearch等。

注意：Categraf不属于夜莺监控系统组件，夜莺定位是服务端组件，不侧重监控数据采集侧。

所有机房网络域下监控数据采集器都直接推数据给n9e，这个架构最为简单，维护成本最低。当然，前提是要求机房网络域结构简单、规模不大场景，即不太关注跨网络域访问安全问题和大规模跨网络域传输数据网络带宽限制等。

如果非上述场景，则要使用下面的边缘下沉式混杂部署方案：

这个图尝试解释 3 种不同的情形，比如 A 机房和中心网络链路很好，Categraf 可以直接汇报数据给中心n9e模块，另一个机房网络链路不好，就需要把时序库下沉部署，时序库下沉了，对应的告警引擎和转发网关也都要跟随下沉，这样数据不会跨机房传输，比较稳定。但是心跳还是需要往中心心跳，要不然在对象列表里看不到机器的 CPU、内存使用率。还有的时候，可能是接入的一个已有的Prometheus，数据采集没有走Categraf，那此时只需要把Prometheus作为数据源接入夜莺即可，可以在夜莺里看图、配告警规则，但是就是在对象列表里看不到，也不能使用告警自愈的功能，问题也不大，核心功能都不受影响。

边缘下沉式混杂部署方案中涉及到两个核心组件：n9e-pushgw组件和n9e-alert组件。

n9e-pushgw组件提供类似于remote_write和remote_read功能，categraf采集器将数据通过remote_write推送给n9e-pushgw组件，然后转存到tsdb时序数据，n9e服务端查询检索数据时通过remote_read讲求转发到对应机房下的n9e-pushgw组件。n9e-alert组件提供基于tsdb时序库中的指标数据告警功能。

一键部署

笔者已经在公有云上搭建了一套临时环境，可以先登录体验下：

http://124.222.45.207:17000/login
账号：root/root.2020

下面介绍下使用docker-compose快速一键部署。

1、代码在这里：