夜莺-Nightingale
夜莺V6
项目介绍 架构介绍
快速开始 快速开始
黄埔营
安装部署 安装部署
升级
采集器 采集器
使用手册 使用手册
API API
数据库表结构 数据库表结构
FAQ FAQ
开源生态
Prometheus
版权声明
第1章:天降奇兵 第1章:天降奇兵
第2章:探索PromQL 第2章:探索PromQL
第3章:Prometheus告警处理 第3章:Prometheus告警处理
第4章:Exporter详解 第4章:Exporter详解
第5章:数据与可视化 第5章:数据与可视化
第6章:集群与高可用 第6章:集群与高可用
第7章:Prometheus服务发现 第7章:Prometheus服务发现
第8章:监控Kubernetes 第8章:监控Kubernetes
第9章:Prometheus Operator 第9章:Prometheus Operator
参考资料

安装部署详解

前置说明

各种环境的选型建议

  • Docker compose 方式:仅仅用于简单测试,不推荐在生产环境使用 Docker compose,升级起来挺麻烦的,除非你对 Docker compose 真的很熟
  • 二进制部署:最推荐的方式,稳,升级也方便
  • Helm 方式:公司大规模使用了 Kubernetes,可以选择 Helm 方式,前提是贵司对 Helm 这套真的很熟
  • 存储选型:如果之前没有部署过,是个新环境,时序库选型建议使用 VictoriaMetrics,单机版 VictoriaMetrics 就可以抗住每秒上百万数据点,性能很好,CPU、内存的占用都比 Prometheus 少,而且,完全兼容 Prometheus 的查询接口
  • 时间校准:社区反馈的很多问题都是因为机器时间没有校准,监控系统对时间很敏感,请各位先把机器时间校准一致,让服务端的机器、时序库的机器、要监控的目标机器、浏览器所在的 PC 时间,都保持一致

用户名密码

默认用户是 root,密码是 root.2020

使用 Docker compose 快速体验

具体可以参考这个文档。不推荐使用,除非你对 Docker compose 真的很熟!

安装前置依赖

我们更推荐二进制的方式来部署,后文都是以二进制的方式来说明部署方式以及架构。夜莺依赖 mysql 存储用户配置类数据,依赖 redis 存储 jwt token 和机器心跳上报的 metadata,所以,先准备 mysql 和 redis。这俩组件请大家自行安装,这里也提供一个小脚本来安装这两个组件,大家可以参考:

# install mysql
yum -y install mariadb*
systemctl enable mariadb
systemctl restart mariadb
mysql -e "SET PASSWORD FOR 'root'@'localhost' = PASSWORD('1234');"

# install redis
yum install -y redis
systemctl enable redis
systemctl restart redis

上例中 mysql 的 root 密码设置为了 1234,建议维持这个不变,后续就省去了修改配置文件的麻烦。如果你想修改默认用户名和密码,就要对应的修改配置文件中的 mysql 连接信息,配置文件的哪个地方配置了 mysql 的密码呢?通过下面的命令可以找到:

# 夜莺的主配置文件是 etc/config.toml
grep "1234" etc/config.toml

安装夜莺

可以去 https://flashcat.cloud/download/nightingale/ 找最新版本的包,文档里的包地址可能已经不是最新的了

# 创建个 n9e 的目录,后面把 n9e 相关的文件解压到这里
mkdir -p /opt/n9e && cd /opt/n9e

# 下载 n9e 发布包,amd64 是 x84 的包,下载站点也提供 arm64 的包,如果需要其他平台的包则要自行编译了
tarball=n9e-v6.0.1-linux-amd64.tar.gz
urlpath=https://download.flashcat.cloud/${tarball}
wget -q $urlpath || exit 1

# 解压缩发布包
tar zxvf ${tarball}

# 解压缩之后,可以看到 n9e.sql 是建表语句,导入数据库
mysql -uroot -p1234 < n9e.sql

# 启动 n9e,先使用 nohup 简单测试,如果需要 systemd 托管,请自行准备 service 文件
nohup ./n9e &> n9e.log &

# 检查 n9e.log 是否有异常日志,检查端口是否在监听,正常应该监听在 17000
ss -tlnp|grep 17000

如果日志和端口都没啥问题,恭喜,你完成了夜莺的安装!通过浏览器访问这个机器的 17000,理论上就可以看到登录页面了。

玩法1:仅使用夜莺做告警管理

如果您之前已经部署了 Prometheus、Thanos、VictoriaMetrics、M3DB、Mimir 等某个时序库,只是想使用夜莺的告警管理功能,没问题,架构如下:

20230517172701

假设你之前有个 Prometheus,只需要把 Prometheus 作为数据源配置进来就可以了,入口在:

20230517174351

具体配置样例如下:

20230517174558

这里一些配置项的含义解释如下:

  • 名称:随意取名,就是个标识,使用英文命名
  • URL:Prometheus 的访问地址,如果是其他时序库,这个地址就不同喽,比如集群版本的 VictoriaMetrics,可能是类似这么个地址:http://127.0.0.1:8481/select/0/prometheus
  • 超时时间:单位是毫秒,建议最小设置为10000,即10s,如果一些大的查询,就会比较耗时
  • 授权:如果时序库启用了 Basic auth,这里就配置对应的 Basic auth username 和 password 即可
  • 跳过 SSL 验证:如果证书不是正儿八经的证书想要跳过校验,就勾选这个项
  • 自定义 HTTP 头:访问时序库的时候可以附加一些 HTTP Header
  • write_addr:这个是时序库的 remote write 地址,我的例子中是 Prometheus,所以 url path 是 /api/v1/write,如果是其他时序库可能不同,比如集群版本的 VictoriaMetrics,remote write 地址可能是类似这个样子:http://127.0.0.1:8480/insert/0/prometheus/api/v1/write。这个信息用在哪里呢?平时都用不到,除非你在夜莺里使用了记录规则(recording rule),记录规则会生成新指标,新指标要回写时序库,所以要求时序库提供 remote write 地址。如果你不知道啥是 recording rule,可以 google 一下,google 关键字:“Prometheus recording rule”,或者跳过以后再说
  • 关联告警引擎集群:这个说起来有点复杂了,选中默认的 default 即可,如果需要在边缘机房单独部署 n9e-alert 的时候,才需要详细了解这个信息

以上配置完成之后,我们去即时查询验证一下,看看能否查询到这个 Prometheus 的数据:

20230517181834

如上就表示正常的,如果有些数据确定时序库里是有的,但是在即时查询里查不到,有可能是时间没有校准,请自行检查时间。之后,就可以在夜莺里配置告警规则了,具体可以参考后续告警相关的文档

玩法2:使用 categraf 采集数据,使用夜莺接收数据

社区里经常有小伙伴咨询,问夜莺可以监控xx么?

其实,夜莺啥都可以监控,又啥都监控不了。夜莺是一个服务端组件,类似 Grafana,可以接入不同的数据源,比如 Prometheus、VictoriaMetrics、Thanos 等等,只要数据进到这些库里了,夜莺就可以对数据源的数据进行分析、告警、可视化,以及后续的事件处理、告警自愈。

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

所以夜莺本身不做监控数据采集,啥都不能监控,但是夜莺可以对接数据源,又啥都可以监控。

这一小节,我们介绍使用 Categraf 作采集器,然后推数据给夜莺,夜莺转存到时序库,并且后续对这些数据做可视化、告警等,整个架构如下图所示:

20230517182817

图上画了三个 agent:datadog-agent、telegraf、categraf,都可以和夜莺对接,我们推荐的是 categraf,所以本节主要以 categraf 举例。夜莺默认监听的端口是 17000,通过 api:/prometheus/v1/write 接收 remote write 协议的监控数据,categraf 恰好可以以 remote write 协议上报监控数据,所以二者可以对接,telegraf、grafana-agent 其实也可以以 remote write 协议上报监控数据,所以也可以和夜莺对接。

夜莺收到监控数据之后,夜莺自身不存储这些时序数据,直接转存到后端时序库,在这里,夜莺的角色只是一个 Pushgateway 的角色。我们推荐的时序库是单机版本的 VictoriaMetrics,后文就以此演示。当然了,夜莺可以同时并行转发数据给后端多个时序库,就像上图画的,把一份数据同时存储在 VictoriaMetrics 和 Prometheus,也是可以通过配置实现的。

安装单机版本的 VictoriaMetrics

如果选用集群版本的 VictoriaMetrics,可以参考 这里。当然,单机版本对绝大部分公司,够用了,配合云盘保障数据可靠性,稳。所以这里,我就演示单机版本的部署。

安装 VictoriaMetrics

VictoriaMetrics 下载地址在 github releases 上,作为技术人员,我想,你应该可以下载的到。我的环境是 x86_64 的 linux,所以选择下载:victoria-metrics-linux-amd64-v1.90.0.tar.gz (撰写这个文档的时候,最新版本是 v1.90.0)。

VictoriaMetrics 解压缩之后,里边就一个二进制:

[root@vm-159 tarball]# ll vic*
-rw-r--r--. 1 root root 10370599 5月  17 18:43 victoria-metrics-linux-amd64-v1.90.0.tar.gz
-rwxr-xr-x. 1 1000 1000 20191152 4月   7 09:00 victoria-metrics-prod

启动它:

[root@vm-159 tarball]# nohup ./victoria-metrics-prod &> stdout.log &
[1] 12632
[root@vm-159 tarball]# ss -tlnp|grep 12632
LISTEN     0      128          *:8428                     *:*                   users:(("victoria-metric",pid=12632,fd=10))

通过上面的命令可以看出,单机版本的 VictoriaMetrics 监听在 8428 端口。通过浏览器访问 VictoriaMetrics 的 8428,理论上可以看到下面的页面:

20230517184645

如上,就表示 VictoriaMetrics 安装成功,当然,我仅仅使用 nohup 简单启动的,如果生产环境,建议使用 systemd 托管并设置开机自启动。

打通夜莺和 VictoriaMetrics

分两个步骤,首先就类似上面配置 Prometheus 数据源那种方式,在夜莺里配置一个 VictoriaMetrics 的数据源,比如我的配置:

20230517185115

其次,就需要修改配置文件了。打开夜莺的 etc/config.toml 配置,找到 HTTP.APIForAgent 部分,默认配置如下:

[HTTP.APIForAgent]
Enable = true 
# [HTTP.APIForAgent.BasicAuth]
# user001 = "ccc26da7b9aba533cbb263a36c07dcc5"

这个表示:开启夜莺的监控数据接收类的 API,默认就是开启的,所以,默认配置就够了,不用动。那个 HTTP.APIForAgent.BasicAuth 表示 BasicAuth(不懂啥是 BasicAuth 请自行 Google 哈) 的配置,如果是内网环境就维持注释就可以了,不用开启 BasicAuth,如果要把夜莺接收数据的接口暴露到公网,为了安全考虑,就需要 HTTPS + BasicAuth 双重保障了,这里的 HTTP.APIForAgent.BasicAuth 相关的配置在公网环境下就应该打开,而且,应该修改这个 password:ccc26da7b9aba533cbb263a36c07dcc5,不要使用默认的 password。

另一个要修改的配置是 Pushgw.Writers 部分,把 VictoriaMetrics 的 remote write 地址配置上,我的环境的例子如下:

[Pushgw]
LabelRewrite = true
[[Pushgw.Writers]]
Url = "http://127.0.0.1:8428/api/v1/write"

这里的 [[Pushgw.Writers]] 是双中括号扩起来的,这在 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"

OK,这样一来,夜莺接收到 categraf、telegraf、grafana-agent 等各类 agent 上报上来的监控数据,都会转发给后端的 VictoriaMetrics,完活。

部署 categraf 上报监控数据

Categraf 的安装请 参考文档,这个文档已经很详细了就不再赘述了。重点关注配置文件 config.toml,一个是 heartbeat 的配置:

[heartbeat]
enable = true
url = "http://127.0.0.1:17000/v1/n9e/heartbeat"

这个配置是 Categraf 向夜莺心跳的地址,夜莺 v5 的话没有这个机制,需要把 Categraf heartbeat 的 enable 关掉。我这里演示的夜莺 v6,所以 heartbeat 的 enable 要设置为 true,建议大家用高版本的 Categraf,我这里用的是 v0.3.4。

另一个配置是 writers 部分:

[[writers]]
url = "http://127.0.0.1:17000/prometheus/v1/write"

这表示:把数据推给夜莺的 17000 端口,url path 是 /prometheus/v1/write 这是夜莺的 remote write 协议的数据接收地址。

上面我的例子中,夜莺的地址都是:127.0.0.1:17000,因为我的 Categraf 和 夜莺 在一台机器上,如果你的 Categraf 和夜莺在不同的机器,注意改成合适的 IP。

按照 文档 中介绍的方法启动 Categraf,我这只是临时测试,所以,直接 nohup 启动得了:

nohup ./categraf &> categraf.log &

验证结果

如果一切正常,Categraf 就会推数据给夜莺,夜莺转发给 VictoriaMetrics,而 VictoriaMetrics 又是夜莺的数据源,所以在夜莺的即时查询页面,理论上可以查询到 VictoriaMetrics 的数据,验证一下:

20230517192730

cpu_usage_active 这个指标就是 Categraf 采集上报的,看起来一切正常。欧耶!

夜莺高可用方案

这里服务端总共涉及到4个组件:时序库、mysql、redis、夜莺,其中时序库、mysql、redis 的高可用,大家 Google 一下网上大堆资料,这里不展开。关键是夜莺如何做高可用?

其实,很简单,多部署几个 n9e 实例就可以了。多个 n9e 实例会自动组成集群,分担压力。n9e 前面可以架设负载均衡,四层、七层都可以,某个 n9e 实例挂掉,负载均衡会自动踢除,用户通过浏览器访问夜莺的时候,访问负载均衡的地址,Categraf 的 writer 和 heartbeat 也配置成负载均衡的地址,就可以了。

如果夜莺里配置了3千条告警规则,部署了3个n9e实例,这三个n9e实例就会自动分配(通过一致性哈希算法)要处理的告警规则,确保每个n9e实例只处理大概1千条告警规则,分担告警引擎处理压力。如果某个n9e实例挂掉,其他实例会自动感知(利用mysql做了一些心跳机制)自动接管未被处理的告警规则,这也是把n9e集群化部署的好处。

高级玩法

如果,夜莺部署在北京机房,某些机房和北京机房网络链路较差,此时,应该把时序库、告警引擎下沉部署,具体应该如何做呢?看这里

快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat
FlashDuty
Flashduty