企业官网建设流程全解析

夜莺这个项目我从 v5 一直用到 v6，中间经历过不少"部署完、页面能打开、但就是没数据"的阶段。很多人下载完夜莺监控系统安装部署包，看到登录页、看到默认面板，就以为已经搞定了，其实真正的工作才刚刚开始。这篇"服务器监控软件夜莺使用（二）"不打算重复讲安装包怎么解压、服务怎么启动，而是聚焦在一个更实际的问题：部署完成之后，怎么把一台真实的服务器接进夜莺，让它的 CPU、内存、磁盘、端口、进程都变成可观测的数据，再让这些数据在异常时主动通知你。

不管你是刚装完夜莺正在对着空面板发呆，还是已经接了几台机器准备做告警策略，这篇内容应该都能给你一些能直接照做的经验。

1. 先搞清楚夜莺部署完成之后，到底有哪些东西在跑

很多文章会把安装过程写得特别简单，比如一条命令启动所有组件。这没毛病，但如果你不知道后台有哪些组件，后面遇到问题会非常被动。夜莺监控系统安装部署完成之后，实际是一个小的组件集群，而不是单个进程。

1.1 组件全景：每个进程是干什么的

以最常见的 Docker Compose 或二进制方式部署为例，一个完整的夜莺环境里通常会有这么几类角色：

其中最容易被人忽略的是时序数据库。夜莺本身不是一个完整的时序存储方案，它默认对接 Prometheus 或 VictoriaMetrics，负责接收采集器上报的指标并存储。也就是说，哪怕你夜莺的 Web 界面开着，数据库和 Redis 都正常，一旦时序库没配好，页面上照样什么都看不到。

1.2 你的场景适合用哪个时序库

新版本夜莺支持多种时序库，实际部署中最常见的是 Prometheus 和 VictoriaMetrics 两种。我个人的建议是：单机监控数量在几百台以内，用内置的 Prometheus 就够了；机器数量多、写入量大的场景，优先上 VictoriaMetrics，因为它的磁盘占用和查询性能都要好不少。

补充一个细节：如果你用的是【夜莺监控官网】提供的一键部署脚本，它默认拉起的时序库多半是 Prometheus。生产环境里我更倾向于单独部署 VictoriaMetrics，然后修改 n9e-server 配置文件中时序库相关地址。原因很简单——Prometheus 的本地存储是单机的，数据目录一旦损坏恢复起来非常麻烦，而 VictoriaMetrics 在这方面容错性好很多。

1.3 数据流转：一条指标是怎么从服务器走到页面上的

理解数据流是排查一切"没数据"问题的基础，用文字描述一下完整链路：

• categraf 在被监控机上采集 CPU 使用率、内存、磁盘等指标。
• categraf 通过 remote write 协议，把指标 POST 到 n9e-server 的/prometheus/v1/write接口（或者是直接写到时序库）。
• n9e-server 做一层写入转发，把数据落到 Prometheus / VictoriaMetrics。
• 前端页面查询数据时，调 n9e-server 的查询接口，n9e-server 再去时序库拉数据。
• 告警引擎周期性读取告警规则，从时序库查询指标数据，判断是否触发告警。

这套链路里任何一环断了，表象都是"页面看不到数据"或者"告警不响"。所以后面所有问题排查，基本都围绕这条链路逐段检查。

2. 第一批服务器接入：categraf 采集器配置实测

夜莺的官方采集器是 categraf，它前身是 Telegraf 的一个分支，但针对夜莺做了大量优化。第一次用的时候不要贪多，先把一台机器完整接进来，确认数据通路是通的，再批量铺开。

2.1 下载安装 categraf 的正确姿势

categraf 通过二进制单文件运行，不依赖 Java 之类的运行时环境。去官方 GitHub Releases 页面下载对应架构的压缩包即可。服务器是 amd64 就用categraf-vx.x.x-linux-amd64.tar.gz；ARM 架构的服务器不要下错，否则会直接提示exec format error。

下载完解压之后，目录结构大概是这样的：

categraf/ ├── categraf # 主程序 ├── conf/ │ ├── config.toml # 全局配置 │ └── input.*/ # 各种采集插件的配置目录 └── README.md

先看conf/config.toml，最核心的几个配置项如下：

[global] hostname = "" # 留空会自动取机器 hostname，建议显式写成有意义的名称 omit_hostname = false [writer_opt] batch = 2000 chan_size = 10000 [[writers]] url = "http://192.168.1.10:17000/prometheus/v1/write" # 夜莺服务端写入接口 basic_auth_user = "" basic_auth_pass = ""

这里面[[writers]]的 url 是最重要的，必须指向夜莺服务端的写入地址。很多人以为要直接写时序库的地址，其实不对，应该写 n9e-server 的 HTTP 端口（默认 17000）下的/prometheus/v1/write。写错地址之后，categraf 日志里会频繁报错，但页面没有任何提示，容易让人一头雾水。

2.2 启动并验证数据是否上报

在 categraf 目录下直接执行：

./categraf --test

这个命令会检查配置语法，并尝试连接写入端。没问题的话，再用 systemd 方式管理：

/etc/systemd/system/categraf.service

内容参考：

[Unit] Description=categraf After=network.target [Service] WorkingDirectory=/opt/categraf ExecStart=/opt/categraf/categraf Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

启动之后，去夜莺的"机器列表"页面看有没有多出一台主机。如果机器列表里出现了新主机，说明心跳和标签上报已经通了。如果机器列表没出现但指标页有数据，往往是 categraf 的 hostname 和ident配置不一致导致的，后面会细说。

2.3 默认采集了哪些指标

刚启动的 categraf 会默认启用一批系统采集插件，包括 cpu、mem、disk、net、kernel、system 等。这些指标覆盖了最初级的服务器监控需求，可以先把这些数据看明白，再去扩展额外插件。

我一般在生产环境里会调整几个插件的配置，避免无效指标太多：

• conf/input.system/下可以关闭负载均值的部分采集项，云服务器上/proc/loadavg的负载含义和在物理机上不一样，容易误判。
• conf/input.disk/默认会有mount_points和fs_types过滤，建议把临时文件系统如tmpfs、overlay排除，不然磁盘分区列表会被一堆 Docker overlay 目录刷屏。
• conf/input.net/建议打开interfaces = ["eth0", "ens33"]白名单，避免统计到docker0、veth*这类虚拟网卡。

这些配置改完之后记得重启 categraf：

systemctl restart categraf

数据会在下一轮采集周期生效，默认采集间隔是 15 秒，等一下就能在夜莺页面看到。

2.4 自定义监控端口和进程

服务器监控不可能永远只看系统指标，MySQL、Redis、Nginx 这些中间件和自定义进程才是业务血条。categraf 里提供了丰富的采集插件，比如redis、mysql、nginx，但很多场景下你只是想确认"端口还活着"或者"进程还在不在"，不需要拉一堆中间件指标。

这时候有两个轻量做法：

第一种，在conf/input.net_response/里配置 TCP 端口探测：

[[instances]] targets = [ "127.0.0.1:3306", "127.0.0.1:6379", ] protocol = "tcp" timeout = "1s"

第二种，在conf/input.procstat/里按进程名匹配：

[[instances]] search = "mysqld" pattern = "mysqld"

这种方式会在每台机器上产生procstat_lookup和进程存活相关指标，告警规则直接针对这些指标写即可。它比单纯端口探测更可靠，因为有些服务端口虽然还在监听，但进程已经处于半死状态了。

3. 告警规则配置：从"能收到"到"收得准"

接入数据只是第一步，夜莺真正值钱的是告警引擎。这个引擎的灵活度非常高，但灵活也是有代价的，就是初学时容易搞混"规则、指标、通知"三者之间的关系。

3.1 告警规则在夜莺里的模型

夜莺的告警体系涉及几个核心概念：

• 数据源：告警规则去哪个时序库查数据，默认是你配置的那个 Prometheus/VictoriaMetrics。
• 告警规则：定义 PromQL 查询语句、持续时长、告警级别、通知模板。
• 通知媒介：内置支持邮件、钉钉、企业微信、Webhook 等。
• 告警屏蔽：在维护窗口内不触发告警，比如凌晨发布变更时可以提前屏蔽。

这个模型和大部分监控系统类似，区别在于夜莺的规则可以做到非常细：可以一条规则批量匹配所有机器，也可以精确到某台机器的某个指标。它用的是 PromQL 来写查询条件，所以不懂 PromQL 的人上手会有一点门槛。

3.2 一个完整的 MySQL 端口监控告警案例

假设你要监控一批 MySQL 服务器的 3306 端口，同时想把"端口挂了"这件事立刻通知到钉钉群。操作步骤如下：

先在【告警管理】->【告警规则】里新建一条规则：

• 规则名称：MySQL端口探测失败
• 查询语句（PromQL）：

  net_response_response_code{port="3306"} != 0

  实际上 categraf 的 net_response 插件在探测失败时，net_response_response_code会等于 1 或者直接缺省。更稳妥的写法是判断net_response_result_code == 1，或者用up语义的指标，具体要看上报的字段名。
• 持续时长：建议 30 秒，避免端口单次抖动就报警。
• 告警级别：P1（紧急）或 P2（重要），按业务对 MySQL 的依赖程度来定。
• 通知媒介：选择钉钉 Webhook，配置好加签密钥。

这里要专门提醒一个新手容易犯的错误：不要用== 0来判断"端口存活"。因为当采集器自己挂了、网络不通的时候，指标会直接消失，== 0的表达式结果会变成"无数据"，夜莺默认不会因为"无数据"触发告警，于是机器彻底挂了反而没反应。

更好的方式是采用"对端不可达才算故障"的表达式，比如：

net_response_result_code == 1

这条条件下，端口能连上时返回 0，连不上时返回 1，指标存在并且等于 1 才告警。如果 categraf 进程都挂了，指标消失，这条规则不触发，但你会有另外的"agent 心跳异常"规则兜底。

3.3 告警风暴是怎么来的，怎么避免

第一次配告警规则的人，通常会遇到"一告警就是一大片"的情况。比如你写了一条磁盘使用率大于 90% 的规则，结果同一批机器全部触发，钉钉群瞬间被刷屏。这时候需要做好两件事：

一是合理设置持续时长。磁盘使用率超过阈值之后不一定会立刻导致故障，持续 5 分钟以上再告警，能过滤掉大量瞬时抖动。当然，像磁盘只读这种高优先级场景，持续时长应该设短一些。

二是善用告警升级和收敛。夜莺的告警规则里可以配置"静默时间"，指的是同一个规则、同一个告警对象，在一次告警之后隔多久才能再次触发。比如 MySQL 端口挂了一次，恢复之前不需要每隔 15 秒就再告警一次，把静默时间设置为 300 秒或者更长，能有效避免"告警风暴"。

另外一个实用技巧是标签分组。PromQL 返回的指标可以带不同的 instance 标签，夜莺默认按标签分组产生独立告警事件。如果你希望"任何一台机器磁盘满"合并成一条通知发出来，而不是每个机器一条，可以通过分组配置来实现。这里不展开写具体界面了，因为不同小版本的字段位置略有差异，但逻辑是通用的。

4. 监控看板和巡检：数据不只是用来告警的

很多人的服务器监控实践到最后变成了"只有告警才打开页面"，这其实很可惜。夜莺的看板功能虽然不如 Grafana 花样多，但覆盖日常巡检足够。

4.1 用内置看板快速掌握机器状态

夜莺自带了一些内置大盘，比如主机基础监控大盘，能展示 CPU 使用率、内存使用率、磁盘 IO、网络流量等。机器列表里打开某一台机器的详情，就能看到这些图。

我个人的习惯是：会把每类业务机器单独分一个业务组，然后在看板里按业务组过滤，而不是所有机器混在一起看。比如电商服务的机器组单独一个筛选条件：business=shop，这样告警记录、看板数据都对得上号。

需要看更炫的图，夜莺也支持与 Grafana 对接。可以把夜莺作为数据源，然后在 Grafana 里做更灵活的仪表盘。具体操作是：在 Grafana 中新增 Prometheus 类型数据源，地址填夜莺的查询接口，剩下的就和用 Prometheus 一样了。这个功能比较适合那些公司本来就在用 Grafana 的团队。

4.2 定时巡检报告

夜莺在较新的版本里提供了"内置大盘"和"报表"相关能力。比如可以配置每日或每周的巡检报告，把服务器 CPU、内存、磁盘、网络的关键指标汇总成一份 PDF 或图片，定时发到邮箱或群里。

这个功能对没有专职运维的团队非常有用。领导不需要天天去翻监控页面，每天定点收到一份"你的服务器还健康"的报告，心里有底。配置方式一般是在"报表管理"里新建报表，选择大盘、选择接收人、设置时间计划即可。

有一点要注意：如果服务器组数量多，报表里的图表数量也会很多，生成的报告体积会很大。建议在报表里勾选关键指标和自己最关心的几台机器，不要一次性把所有主机全塞进去，不然 PDF 打开慢，也没人愿意看。

5. 夜莺部署使用中的常见问题与排障记录

这部分是我个人运维夜莺以来踩坑最多的区域。每个问题背后基本都有一条清晰的原因链路，搞清楚之后再遇到就不会慌了。

5.1 部署和页面都能打开，但机器列表和指标都是空的

这是装机后最高频的问题。排查链路如下：

先看 categraf 进程有没有起来：

ps -ef | grep categraf

再看 categraf 日志：

journalctl -u categraf -f

如果日志里出现write ... failed或者connection refused，说明写入端地址不对，或者夜莺服务端没起来。如果日志里没有任何报错，但夜莺页面还是空的，去夜莺服务端手动验证一下写入接口：

curl -v http://127.0.0.1:17000/prometheus/v1/write

正常会返回 405 或 400 之类的响应，但连接是通的。如果 curl 直接 timeout，说明 n9e-server 没有监听这个端口，得去查看服务端进程和防火墙。

还有一个容易被忽略的点是 categraf 的hostname和夜莺里的机器标识不一致。夜莺默认用ident字段标识一台机器，而 categraf 上报时会带上hostname字段。如果 categraf 配置里手动写了 hostname，但机器列表里搜索的是系统主机名，就会看到"机器离线"或者干脆搜不到。

5.2 告警触发正常，但恢复通知一直收不到

夜莺的告警恢复机制和 Prometheus Alertmanager 有点类似，一个告警在持续时间内不再匹配触发条件，才会进入恢复流程。如果你发现告警恢复了但没收到恢复通知，多数情况是恢复通知的媒介没启用，或者通知规则里只勾选了"触发告警时"而没有勾选"恢复时"。

另外，如果告警规则里配置了静默时间，恢复之后短时间内相同告警再次触发，可能不会立刻发通知。这个是正常行为，不是故障。

5.3 指标数据出现断档

数据断档通常分两种：一种是个别机器断档，一种是全部机器断档。

个别机器断档，先去被监控机上看 categraf 日志，大概率是采集插件 panic 重启了，或者系统时间被改动过。categraf 对系统时间比较敏感，时间跳变会导致 remote write 的数据时间戳异常，时序库可能拒绝写入或者写入后查询不到。

全部机器断档，优先查时序库的存储和磁盘空间。Prometheus 在数据目录所在磁盘写满时会停止所有写入，表现就是夜莺页面上曲线同时消失。这种问题尤其在 Docker 部署方式下经常出现，因为容器日志、临时文件都可能落在系统盘，系统盘一满，监控先挂。

5.4 数据存储的清理与容量规划

夜莺接的机器多了之后，时序库的磁盘占用会涨得很快，尤其是你开启了大量中间件采集插件时。规划容量时，我习惯按"每天新增数据量 × 保留天数"来估算。

Prometheus 的保留时间可以通过启动参数--storage.tsdb.retention.time控制，比如保留 15 天：

--storage.tsdb.retention.time=15d

VictoriaMetrics 则用-retentionPeriod参数。时间太长意义不大，服务器监控数据一个月内的价值最高，更早的基本没人查。如果公司有合规要求非要留半年，建议把数据落到单独的归档存储，而不是无限堆在时序库里。

另外，对夜莺上报的数据也可以在 categraf 这一层做裁剪。比如conf/config.toml里的[global]有hostname、labels配置，而各 input 插件也可以配置interval和instances。不要让所有插件都在捞数据，没用的一律禁用。磁盘、CPU、内存这些基础指标必须采集，而像 net 下的几十个计数器，很多环境里根本用不上，关掉能省不少存储。

6. 我的一些使用习惯和后续建议

如果你正准备把夜莺铺到整个机房，我的建议是先别急着追求"大而全"。先把十台以内的机器接好，把系统指标、端口探测、统一告警消息这三件事跑顺，再逐步加中间件监控和自定义脚本采集。

在后续使用中，我比较推荐把夜莺的一些扩展能力用起来：

• 告警自愈：夜莺支持通过回调 Webhook 对接自愈平台，但把自愈动作接到监控上之前，一定要先小范围灰度。我第一次用告警回调时，因为表达式写反，差点把生产环境的 Nginx 全部重启了一遍，这教训比较深刻。
• 自定义采集脚本：categraf 支持 exec 插件，可以定期执行一个脚本并采集输出。这个能力适合做业务层监控，比如统计某个接口的响应时间、数据库连接池剩余数。脚本输出格式要按 categraf 的要求写成一行一条指标，否则采集不上来。
• 多云环境统一监控：夜莺的机器列表里可以通过用户标签区分云厂商和业务线，比如cloud=aliyun、business=web。这样在多云环境下，告警规则可以按标签批量套用，非常方便。

最后分享一个我实际使用中发现的小技巧：夜莺的告警规则编辑页面里有一个"测试"按钮，可以手动输入 PromQL 并查看当前返回的指标数据。写告警规则的时候不要凭感觉，先把查询语句贴进去看看返回的指标名称、标签值对不对，再保存规则。这能省下大把调试时间。

夜莺这套系统如果只是轻轻用，可能感觉它就是"又一个监控面板"。但真正用起来之后，你会发现它的价值集中在告警收敛和批量管理能力上。把基础数据接好、告警规则调准，后面再扩容只是重复操作而已，不会再有学习成本了。希望这篇内容能帮到你正在做的监控部署，少走点弯路。