关于运维:夜莺官方文档优化第一弹手把手教你部署和架构讲解消灭所有部署失败的-case干

前置阐明

各种环境的选型倡议

• 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.0-ga.7.0.2-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 等某个时序库，只是想应用夜莺的告警治理性能，没问题，架构如下：

假如你之前有个 Prometheus，只须要把 Prometheus 作为数据源配置进来就能够了，入口在：

具体配置样例如下：

这里一些配置项的含意解释如下：

• 名称：随便取名，就是个标识，应用英文命名
• 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 的数据：

如上就示意失常的，如果有些数据确定时序库里是有的，然而在即时查问里查不到，有可能是工夫没有校准，请自行查看工夫。之后，就能够在夜莺里配置告警规定了，具体能够参考后续告警相干的文档。

玩法 2：应用 categraf 采集数据，应用夜莺接收数据

社区里常常有小伙伴征询，问夜莺能够监控 xx 么？

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

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

所以夜莺自身不做监控数据采集，啥都不能监控，然而夜莺能够对接数据源，又啥都能够监控。

这一大节，咱们介绍应用 Categraf 作采集器，而后推数据给夜莺，夜莺转存到时序库，并且后续对这些数据做可视化、告警等，整个架构如下图所示：

图上画了三个 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，实践上能够看到上面的页面：

如上，就示意 VictoriaMetrics 装置胜利，当然，我仅仅应用 nohup 简略启动的，如果生产环境，倡议应用 systemd 托管并设置开机自启动。

买通夜莺和 VictoriaMetrics

分两个步骤，首先就相似下面配置 Prometheus 数据源那种形式，在夜莺里配置一个 VictoriaMetrics 的数据源，比方我的配置：

其次，就须要批改配置文件了。关上夜莺的 etc/config.toml 配置，找到 HTTP.Pushgw 局部，默认配置如下：

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

这个示意：开启夜莺的监控数据接管类的 API，默认就是开启的，所以，默认配置就够了，不必动。那个 HTTP.Pushgw.BasicAuth 示意 BasicAuth（不懂啥是 BasicAuth 请自行 Google 哈）的配置，如果是内网环境就维持正文就能够了，不必开启 BasicAuth，如果要把夜莺接收数据的接口裸露到公网，为了平安思考，就须要 HTTPS + BasicAuth 双重保障了，这里的 HTTP.Pushgw.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 的数据，验证一下：

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 集群化部署的益处。

高级玩法

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

https://flashcat.cloud/docs/content/flashcat-monitor/nighting…