【夜莺监控】初识夜莺，还是强！

前言

可观测性是大部分中小公司比较头疼的问题，主要表现以下几个方面：

1. 需要不同的开源软件来组装以实现不同的功能，比如使用 Skywalking 实现链路监控，使用 ELK 实现日志收集监控，使用 Grafana+Prometheus 来实现指标监控。
2. 每个开源软件背后都是独立的一套体系，它们之前是相互独立的（Grafana 全家桶已经实现组合）。
3. 数据孤岛，链路、日志、指标各玩各的，没有建立联系。目前市面上的解决方案要么是商业化产品，要么是自研。

本文的主角其实也没有做大一统，目前阶段依然是不同的开源组件实现不同的功能，只不过N9e可以在同一个主面板查看它们，但是数据之间的联系依然没有实现。

那为什么还要学习研究N9e呢？

因为它正在向这方面发展。

上面提到 Grafana 其实已经在做了，基于 Grafana+Loki+Tempo+Prometheus 组合可以实现监控、指标、链路的联动，N9e 和 Grafana 有什么不同呢？

用秦总的话说：Grafana更擅长监控面板的管理，N9e更擅长告警规则的管理。

N9e 可以将不同的告警规则发送到不同的业务组，不同的群体，避免在一个群里产生大量的告警信息，久而久之就上演了狼来了的故事。

说了这么多，N9e到底长啥样？

下面是我部署好的一套系统。

可以看到，在该面板上，我们可以实现：

• 告警管理
• 时序指标查询
• 日志分析
• 链路追踪
• 告警自愈
• 人员管理
• …..

这样就不用几个应用来回切了，方面快捷。

系统架构

说一千到一万，架构不懂都白干。

现在我们来看看 N9e 的架构到底是什么样的，只有从架构逻辑上理清楚 N9e 是怎么玩的，不论是对部署还是维护都大有裨益。

N9e 主要有中心汇聚式部署方案以及边缘下沉式混杂部署方案，下面会分别做解释。

中心汇聚式部署方案

先上图：

这种方案就是建立一个 N9e 集群，其他 region 的监控数据都往这一个集群发送数据，这要求中心集群和其他 region 要有很好的网络连接。

对于中心集群来说，主要包括以下组件：

• MySQL：用于存放配置信息以及告警事件。
• Redis：用于存储 JWT Token，机器元信息等数据。
• TSDB：时序数据库，存放监控指标。
• N9e：核心服务，处理 Web 请求、提供告警引擎
• LB：为多个 N9e 提供负载功能。

对于其他 Region，只需要部署 Categraf 即可，它会将本地的监控数据推送到中心集群。

这个架构的特点是简单，维护成本比较低。前提是要求机房之间的网络链路要比较好，如果网络不好就要用下面的方案了。

边缘下沉式混杂部署方案

这种架构是对中心式部署方案的补充，主要是针对网络不好的情况：

1. 把时序数据库 TSDB、转发网关、告警引擎都下沉到具体的 Region，由 Region 自己的来处理。不过 Region 依然需要和中心集群建立心跳连接，用户还是可以通过中心集群的监控面板查看其他 Region 的监控信息。
2. 对于已有 Prometheus 的情况，也可以直接将 Prometheus 作为数据源接入即可。

边缘机房，下沉部署时序库、告警引擎、转发网关的时候，要注意，告警引擎需要依赖数据库，因为要同步告警规则，转发网关也要依赖数据库，因为要注册对象到数据库里去，需要打通相关网络。

!! PS：对于这种方案，本身网络不好，还要打通网络，可能还是会受网络问题影响。

单机部署

为什么这里要选择单机部署呢？

其实我是想挨着部署各个组件，这样对于理解整个 N9e 的运行模式有一定的帮助。

!! Tips：我这里使用的是 Ubuntu 22.04.1 系统

安装 MySQL

!! Tips：为了快速我安装的是 Mariadb

# 更新镜像源
$ sudo apt-get update
# 更新软件
$ sudo apt-get upgrade
# 安装Mariabd
$ sudo apt-get install mariadb-server-10.6