核心改造

夜莺监控(Nightingale)V5基本上已经覆盖了指标监控的方方面面，你可以借助夜莺V5，对多种不同的数据源，完成统一的可视化、统一的告警配置和管理等工作。不过可观测性领域通常有“三支柱”：metrics、logs、traces，只是搞定metrics还远远不够，所以夜莺6.x版本计划引入logs、traces相关的能力，这是V6最重要的一个改造方向。当下开源社区，在logs、traces领域已经有很多成熟的解决方案，夜莺不会也不需要重复造轮子，夜莺V6将会进一步将数据源的概念，从支持metrics的基础上，扩展到支持logs、traces，即借助于夜莺V6，你就可以通过配置不同的 DataSource，将指标、日志、链路追踪数据进行统一集成，完成对“三支柱”的统一可视化、统一告警，打通“三支柱”，提升监控分析的效率。

如果要做到这个效果，需要对DataSource有较好的管理UI，夜莺5.x版本是在配置文件里管理DataSource的，也就是Readers的配置项，6.x版本要把这个管理逻辑做到页面上，产品化。

其次，重新规划模块。夜莺5.x版本包含两个模块n9e-webapi、n9e-server。6.x希望把这俩模块合并成一个(姑且称为n9e-center)，用户只需要部署一个进程就可以接入多个DataSource。当然，对于一些网络连通性不好的地域，监控数据是下沉到地域内存储的，此时告警引擎和数据转发模块都要尽可能离数据近一些。所以除了中心的n9e-center是必选的，也有可选的n9e-alerting-engine、n9e-pushgateway可以下沉到各个地域。

最后，准备改造一下agent失联告警，在PUSH模型下，agent失联是个挺难处理的事情，当下的逻辑是自动生成了一个 target_up 指标用于标识 agent 是否存活，数据有滞后性，6.x版本会解决这个问题。

贪多嚼不烂，先做这些，如果都能做好，已经非常不错了，据此，系统应该如何架构呢？

系统架构

这是一个前期架构图，大概能表达出当下的想法，或许后面会改，不过总体框架应该不变了：

上图是画了4个Region，Beijing这个区域部署了中心的n9e-center、MySQL，还有中心的时序库VictoriaMetrics，Beijing和Shanghai网络链路比较好，Shanghai部署了CK、ES、Jaeger，Beijing的n9e-center会直连读取Shanghai区的数据，对Shanghai区的数据做告警判断，Beijing和Sgp的两个机房链路不好，告警引擎n9e-alerting-engine下沉到了Sgp的两个机房，只对本机房的数据做告警判断。n9e-pushgateway 只是下沉到了 Sgp02，没有部署在 Sgp01，是因为 Sgp01 是用 Prometheus 拉取各个 Exporter 的数据，走的 PULL 模型，Sgp02 才是用的各种 PUSH 型 agent。

register targets 这个表示设备注册，这个是可以没有的，比如已有的一个 Prometheus，通过 PULL 的方式拉取监控数据，拉到数据之后直接存入时序库了，数据没有流经 n9e-pushgateway，这个影响不大，不影响看图也不影响告警。但是对于 PUSH 型架构，需要对 agent 是否存活做告警，这个注册 target 的逻辑就很关键了。回头单独写个文章来分享这块逻辑如何改造优化。

总结这个架构，如果公司的网络环境比较简单，多个机房相互之间有很好的连通性，就只需要在中心部署一个 n9e-center，对接多个数据源就好了。如果某个地域的机房网络链路不好，就需要在这个地域单独搭建时序库 + 告警引擎 + Pushgateway(可选)。

后记

通过此次架构改造，夜莺将和Grafana既有异曲同工之处，又各有擅长侧重，或许最终殊途同归。

Grafana 专注于可视化，可以对接各种不同的数据源，极致的可视化，附带有简单的“告警”功能。夜莺则更擅长于“告警”，对接各种数据源，覆盖“三支柱”，极致的“告警”能力，比如支持各种告警规则、订阅规则、屏蔽规则的管理、有告警事件的管理、有告警自愈的机制、有设备管理。同时夜莺在V5版本中，可视化上也有了跨越式的进步，提供了不输于Grafana的可视化能力。从产品蓝图上来看，夜莺将会更加全面一些。

关于作者

本文作者秦晓辉，Flashcat合伙人，文章内容是快猫技术团队共同沉淀的结晶，作者做了编辑整理，我们会持续输出监控、稳定性保障相关的技术文章，文章可转载，转载请注明出处，尊重技术人员的成果。