共计 6647 个字符，预计需要花费 17 分钟才能阅读完成。
前置阐明
各种环境的选型倡议
- 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…