前言
本篇是夜莺监控V6最新版本（v6.0.0.ga8）的架构介绍，ga8版本开始和之前的v6版本在边缘机房部署场景，做了一点优化–去除了边缘机房中夜莺监控模块（n9e-pushgw数据转发，n9e-alert告警引擎）对中心节点机房中mysql数据库的依赖。
就像秦老板所说一样，架构原理是学习夜莺的必备知识，所以打卡学习一下。本文源于SRETalk的视频介绍。
中心机房部署架构
在中心机房部署需要用到n9e这个程序，它对依赖于两个数据源，一个是mysql数据库，存放一些系统用到的配置信息；另一个是redis，存放时token和心跳信息。客观性的三大指标时序数据（如Prometheus、VictoriaMetrics ），日志数据（如ElasticSearch ），以及链路追踪数据（如Jaeger）它们都可以接入n9e，由n9e统一管理，进行看图，告警，告警自愈等操作。数据的采集器可以用社区推荐的Categraf，管理方便并且啥都能采集，更重要是可以用到社区版n9e的完整功能（只有Categraf会上报心跳信息，并展示在机器列表中）。
以采集时序数据为例，Categraf 采集到数据后，通过push方式转发给n9e，数据经过n9e会按设置把原始数据自动添加一些标签，并且解析出ident标签存入mysql中作为机器列表的来源。之后这些添加标签的数据会被push给时序数据库保存，告警引擎模块会按配置去计算，达到触发条件后生成一条告警；看图会通过promQL查询到结果，并展示在页面上。
机器列表页面中cpu，内存，时间偏移，架构等信息都是Categraf上报的心跳信息存入redis中。
高可用的实现非常简单只需要部署多个n9e实例即可实现，实例之前用4/7层负载均衡，来接收数据或者用户请求，从而达到部分实例挂了不影响全局。实例之间是通过数据分片方式均分告警监控。
边缘机房部署架构
边缘机房如果和中心机房的网络链路比较好的情况下，可以只部署Categraf来采集数据，并且安全起见开启用Basic Auth相关配置。但是更常见的边缘机房和中心机房的网络不是很好，这时候架构上就需要稍微复杂一些，在边缘机房除了部署Categraf外还需要部署n9e-pushgw（数据转发模块），n9e-alert（告警引擎模块），以及时序数据库。
下沉部署的n9e-pushgw也会和把原始数据加上额外标签，解析的机器信息因为需要存入数据库所以之前v6版本需要打通mysql连接，但是ga8的版本去除了这部分依赖，让n9e-pushgw把机器信息通过请求中心端n9e http接口的方式来保存数据。
下沉部署的n9e-alert会把会在网络可用时候，把中心端的告警规则拉取下来缓存在内存中，有了告警规则后就可以按配置频率即时查询时序数据库，用来计算告警触发的条件。只要边缘机房外网是通的，告警就可以正常发出。而对中心端来说不会有太大影响，可能会存在告警事件没发通过n9e http接口把告警上报给中心端mysql的情况（ga8之前的v6也是需要n9e-alert去连接中心端mysql）。
所以可以清楚的看到由于去除了下沉部署中n9e-pushgw和n9e-alert对中心端mysql的依赖，让mysql可以更好的控制权限，部署起来整体更优。
