Author:rab
官方文档:https://flashcat.cloud/docs
以下为夜莺官方解释。
夜莺监控是一款开源云原生观测分析工具,采用 All-in-One 的设计理念,集数据采集、可视化、监控告警、数据分析于一体,与云原生生态紧密集成,提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日,在 github 上发布 v1 版本,已累计迭代 100 多个版本。
夜莺最初由滴滴开发和开源,并于 2022 年 5 月 11 日,捐赠予中国计算机学会开源发展委员会(CCF ODC),为 CCF ODC 成立后接受捐赠的第一个开源项目。夜莺的核心研发团队,也是 Open-Falcon 项目原核心研发人员。
首先上图中间的飞鸟代表夜莺的核心进程 n9e (下文以 n9e 代替),它的集群方式非常简单只需部署多节点即可实现。
对于 n9e 来说,它本身依赖的存储有两个
从 v6 版本开始,夜莺尝试转型为统一可观测性平台,n9e 不再仅支持接入时序数据源(Prometheus、Victoriametrics、M3DB、Thanos),也可以接入日志类数据源(Elasticsearch,Loki【预】),链路追踪数据源(Jaeger)。
这种中心架构还有一种就是:将 Prometheus、Thanos、VictoriaMetrics、M3DB、Mimir 等某个时序库作为夜莺的数据源,即只使用夜莺的告警管理功能。
但是本次我们并不使用时序数据库“作为数据源”
的这种方式,而是采用夜莺接收数据并存储到时序数据库的方式!
当然了,作为后端时序数据存储的 prometheus 也是可以在该架构中用作数据源,这样的话,n9e 不仅能展示数据,也能读取 prometheus 数据进行告警。
从 v6.0.0.ga.9 开始,合并了 n9e-alert、n9e-pushgw 模块为 n9e-edge,应对边缘机房的场景。n9e-edge 不依赖 mysql、redis,只依赖中心端的 n9e,所以 edge.toml 配置文件里,需要配置中心端 n9e 的地址。
1、主机
OS | Version | Comment |
---|---|---|
Rocky Linux | 8.5/4.18.0 | - |
2、服务
Service | Version | Comment |
---|---|---|
n9e | 6.7.2 | 夜莺 - 服务端(数据展示) |
Categraf | 0.3.45 | 夜莺 - 客户端(数据采集) |
MySQL | 5.7.36 | DB 存储 |
Redis | 6.2.6 | DB 缓存 |
Prometheus | 2.37.0 | 时序数据库 |
时序数据存储选型:官方建议 VictoriaMetrics,但得根据你的实际业务场景来决定,如果你已经有 Prometheus 服务了,那也可以继续使用 Prometheus 直接作为数据源,如果没有,则可选择 VictoriaMetrics 作为时序库。
3、服务部署方式
DB 我采用 Docker 部署(当然你也可以采用其他方式部署),其他采用二进制部署!
MySQL 用于存储用户、监控大盘、告警规则等。
# 部署过程略,本次通过shell脚本化部署
存放访问令牌(JWT Token),心跳信息,如机器列表中CPU、内存、时间偏移、核数、操作系统、CPU架构等。
# 部署过程略,本次通过shell脚本化部署
作为时序库接收 remote write 协议的数据,即夜莺收到时序数据之后,会将时序数据写入 Prometheus 中。夜莺也可以同时将此时的时序库用作 n9e 的数据源。
1、二进制包下载
2、解药安装包
tar xf prometheus-2.45.2.linux-amd64.tar.gz -C /data/
3、配置 Systemd 管理
注意:启动 Prometheus 时需要在启动参数里添加
--enable-feature=remote-write-receiver
,否则夜莺转发数据的时候会报 404,因为没有这个参数,Prometheus 就不会开启/api/v1/write
接口的处理监听。
cat <<EOF >/etc/systemd/system/prometheus.service
[Unit]
Description="prometheus"
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
ExecStart=/data/prometheus-2.45.2.linux-amd64/prometheus --config.file=/data/prometheus-2.45.2.linux-amd64/prometheus.yml --storage.tsdb.path=/data/prometheus-2.45.2.linux-amd64/data --web.enable-lifecycle --enable-feature=remote-write-receiver --query.lookback-delta=2m
Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=prometheus
[Install]
WantedBy=multi-user.target
EOF
4、启动
systemctl daemon-reload
systemctl enable prometheus
systemctl restart prometheus
systemctl status prometheus
5、访问验证
http://yourIP:9090/
生产环境中建议使用二进制方式部署,便于后续的升级维护等管理。
1、二进制包下载
2、创建 work 目录
mkdir /data/n9e
3、上传安装包至服务器并解压
tar xzf n9e-v6.7.2-linux-amd64.tar.gz -C /data/n9e/
4、导入 sql 文件
mysql -h 10.206.0.17 -u root -p'Zhurs@123' < /data/n9e/n9e.sql
创建监控用户并授权:
CREATE USER 'nightingale'@'%' IDENTIFIED BY '67by5DV7vK3fiygm';
GRANT ALL PRIVILEGES ON n9e_v6.* TO 'nightingale'@'%';
5、修改配置文件
主要修改 DB 部分。
cp etc/config.toml etc/config.toml.bak
vim etc/config.toml
时序数据库配置:
如果你想把数据转发给后端多个时序库,就可以配置多个
[[Pushgw.Writers]]
,比如:[Pushgw] LabelRewrite = true [[Pushgw.Writers]] Url = "http://127.0.0.1:8428/api/v1/write" [[Pushgw.Writers]] Url = "http://127.0.0.1:9090/api/v1/write"
配置完成后,此时夜莺接收到 categraf、telegraf、grafana-agent 等各类 agent 上报上来的监控数据,都会转发给后端的 Prometheus。
6、配置 systemd 管理并启动
cat <<EOF >/etc/systemd/system/n9e.service
[Unit]
Description="n9e.service"
After=network.target
[Service]
Type=simple
ExecStart=/data/n9e/n9e
WorkingDirectory=/data/n9e
Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=n9e.service
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl start n9e.service
systemctl enable n9e.service
systemctl status n9e.service
监听 17000 端口:
1、概述
需要部署 categraf 上报监控数据,因为夜莺本身其实只是一个服务端组件,不负责数据采集。但如果我们 Prometheus、VictoriaMetrics、Thanos 等时序数据库已经存储有相关的监控指标数据,那也可以将他们作为夜莺的数据源使用,此时夜莺就相当于 Grafana 一样。
比如原本有一套 Prometheus + 各类 Exporter 的体系,复用即可,不需要非得用 categraf 替换采集逻辑,把这套 Prometheus 作为数据源接入夜莺,用夜莺告警就可以了。
我觉得官方文档说得已经非常明白了。
2、客户端下载
下载地址:https://github.com/flashcatcloud/categraf
3、上传服务器并解压
tar xzf categraf-v0.3.45-linux-amd64.tar.gz -C /data/
4、修改配置文件
官方参考文档:https://flashcat.cloud/docs/content/flashcat-monitor/nightingale-v6/agent/categraf/
vim /data/categraf-v0.3.45-linux-amd64/conf/config.toml
将数据推送到 n9e 服务端
数据到达 n9e 时,然后 n9e 服务端再将数据写入后端时序数据库(本次我们配置的是 Prometheus)
这里要清楚,官方文档说了,写入 prometheus 前,会将监控数据的一些元数据存储到 DB 中(MySQL/Redis)
Categraf 建立与 n9e 的心跳检测
5、配置 systemd 管理
cat <<EOF >/etc/systemd/system/categraf.service
[Unit]
Description="categraf.service"
After=network.target
[Service]
Type=simple
ExecStart=/data/categraf-v0.3.45-linux-amd64/categraf
WorkingDirectory=/data/categraf-v0.3.45-linux-amd64
Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=categraf.service
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl start categraf.service
systemctl enable categraf.service
systemctl status categraf.service
因此这里我们要清楚的是,采集器(客户端)不止 Categraf,还有 telegraf、grafana-agent 等。
6、那该 agent 是如何采集数据的呢?
我们下载后的安装包中就包含了基本的采集项:即以 input.
开头的目录就是各种采集插件的配置目录,运行 Categraf 客户端时,它就会通过这些目录的配置去采集数据。如果某个采集器 xx 不想启用,把 input.xx 改个其他前缀(或者删除这个目录),比如 bak.input.xx,categraf 就会忽略这个采集器。
categraf启动时 可以通过-configs
参数指定配置目录,如果不指定,会默认读取工作目录下的conf。 conf 目录结构如下:
config.toml
# 主配置logs.toml
# logs-agent 配置prometheus.toml
# prometheus agent 配置traces.yaml
# trace-agent 配置conf/input.*/*.toml
插件配置文件主配置文件看官方文档解释就行,说得很清楚了。
一般地,Categraf 采集 agent 中的采集插件已经实现了基本的数据采集(CPU、内存、磁盘、磁盘 IO、网络),因此我们直接运行采集客户端 Categraf 时就会帮我们采集这些基础数据。
默认账户/密码:root/root.2020
默认的密码可登陆后自行更改即可。
查看是否监控到主机:
但此时的主机是没有归组的,我们可创建用户及团队,然后将对应主机放入该团队中,那团队中的用户就可以看见监控主机了。
创建用户:
创建团队:
注意书写:rab-dev => 这表示一个层级关系,如下图
创建业务组:
将监控的机器归到指定的业务组中:
此时该服务器就属于 cctv/web 这个业务组了,同时这个业务组中的团队就可以查看这些服务器:
如何将我们的时序库作为 n9e 的数据源(如下操作即可):
官方文档说的很清楚【看文档】,无需再造轮子。
边缘监控无需依赖 MySQL、Redis 存储。
所谓的下沉,其思想就是将中心 N9e 的时序数据库下沉部署到边缘机房,避免大量时序数据传输到中心机房带来的网络带宽压力,同时也避免了因网络问题,边缘机房无法上报数据的问题。但是其本质还是需要和中心机房建立网络通信,尽管有时也会因为网络原因,边缘监控与中心监控也会存在延迟,但是边缘机房的监控数据是不会丢的。
图中 region02 的机房中采集器使用的是 vmagent,并把采集的数据直接写入时序数据库,通过 n9e-edge 对监控数据做告警判断。这种架构比较简洁,但是会有一点点小问题,由于采集数据没有流经 n9e-edge,就没法从数据流中解析出机器信息,也就没法把机器信息写入数据库 target 表,也就导致页面上机器列表页面看不到相关的机器。这不影响告警,看图这些核心功能,只是用不了机器分组,自定义标签,告警自愈之类的功能。
更推荐使用 Categraf + n9e-edge 的方式来采集数据,其架构如图 region01 所示。当 Categraf 采集的数据上报给 n9e-edge 后,n9e-edge 就可以从监控数据中解析出机器信息,然后通过中心端的 n9e 写入数据库 target 表,这样就可以在页面上看到机器列表了。就可以使用机器分组,自定义标签,告警自愈之类的功能。
在 4.1 你会看到服务器的主机名是 blog,为了实验方便查看,我这里先将主机命令为 n9e,另一个测试主机为 pro-blog。
hostnamectl set-hostname n9e
OS | Host | Comment |
---|---|---|
RockyLinux 8.5 | n9e(10.206.0.17) | VPC/南京 |
RockyLinux 8.5 | pro-blog(172.xx.xx.15) | VPC/香港 |
这里相当于模拟了两个机房,n9e 作为监控中心机房,pro-blog 作为边缘监控机房。
上面说了,边缘主机的监控数据会采集到边缘主机的时序库(Prometheus、VIVTORIA 等时序库),因此这里需要部署时序数据库。
部署方式同 4.1.3
小结,这里不再演示。
这个应用程序已经包含在 n9e 压缩包中,直接使用即可。
1、二进制包下载
2、创建 work 目录
mkdir -p /data/n9e-edge
3、解压二进制包
tar xzf n9e-v6.7.2-linux-amd64.tar.gz -C /data/n9e-edge/
4、配置 n9e-edge 连接中心 n9e
从 v6.0.0.ga.9 开始,合并了 n9e-alert、n9e-pushgw 模块为 n9e-edge,应对边缘机房的场景。n9e-edge 不依赖 mysql、redis,只依赖中心端的 n9e,所以 edge.toml 配置文件里,需要配置中心端 n9e 的地址。
vim /data/n9e-edge/etc/edge/edge.toml
...
[CenterApi]
Addrs = ["http://119.45.140.59:17000"]
BasicAuthUser = "user001"
BasicAuthPass = "ccc26da7b9aba533cbb263a36c07dcc5"
# unit: ms
Timeout = 9000
...
认证信息(BasicAuthUser、BasicAuthPass)对应中心端 n9e 的 HTTP.APIForService.BasicAuth 配置段,如下:
/data/n9e/etc/config.toml
当然,这个值是可自定义的。
5、配置 n9e-edge 时序数据库
vim /data/n9e-edge/etc/edge/edge.toml
# 填写时序库IP+Port即可
6、启动 n9e-edge
cat <<EOF >/etc/systemd/system/n9e-edge.service
[Unit]
Description="n9e-edge.service"
After=network.target
[Service]
Type=simple
ExecStart=/data/n9e-edge/n9e-edge --configs /data/n9e-edge/etc/edge
WorkingDirectory=/data/n9e-edge
Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=n9e-edge.service
[Install]
WantedBy=multi-user.target
EOF
systemctl start n9e-edge.service
systemctl enable n9e-edge.service
systemctl status n9e-edge.service
注意,n9e-edge 启动命令中 --configs 选项指定的是一个目录,而不能是文件,否则报错:
监听 19000 端口:
问题?
边缘机房的 n9e-edge 如果只有一个实例,挂了就麻烦了,如何做高可用?简单,只需要在边缘机房部署多台 n9e-edge 就可以了,注意,同一个 edge 集群,edge.toml 里配置的 EngineName 要一样。n9e-edge 前面再搞个负载均衡,给 agent 上报数据、心跳使用,这样就可以实现 n9e-edge 的高可用了。
安装同 4.1.5
小节,这里不再演示。
不同之处1:上报数据
注意端口号
不同之处2:心跳检测
categraf 向 n9e-edge 心跳的话,urlpath 就不能写
/v1/n9e/heartbeat
了,而要写成/v1/n9e/edge/heartbeat
。
配置好后,就去中心夜莺监控,看边缘机房的数据是否正常采集成功。
1、到 n9e 去查看告警引擎
如下图,n9e-edge 已经和 n9e 建立心跳连接了。
边缘机房的 n9e-edge 默认的引擎名字是 edge,与中心端 n9e 的引擎名字(default)相区分。注意:边缘机房的时序库在夜莺里添加数据源的时候,要选择边缘机房的告警引擎(edge)。如果你有两个边缘机房,注意两个边缘机房的 n9e-edge 的引擎名字要不一样。下图是配置数据源的时候,选择告警引擎的地方:
如何设置每个边缘机房的 n9e-egde 的引擎名?
vim /data/n9e-edge/etc/edge/edge.toml
# 修改其配置文件即可
...
[Alert]
[Alert.Heartbeat]
# auto detect if blank
IP = ""
# unit ms
Interval = 1000
EngineName = "edge" # 修改此处(保证各个边缘机房的引擎名唯一)
# [Alert.Alerting]
# NotifyConcurrency = 10
...
2、中心 n9e 配置数据源
3、查看数据
注意:边缘式下沉部署不是通过 n9e-edge 推送数据,而是将 n9e-edge 边缘机房的时序数据库作为 n9e 中心机房的数据源。
1. 中心机房
2. 边缘机房
官方:如果机房之间网络链路很好,就让所有的 categraf 和中心端的 n9e 通信即可,如果某个机房和中心端网络链路不好,就让 categraf 和 n9e-edge 通信,n9e-edge 和中心端的 n9e 通信。
—END