今年年中我把公司的Linux服务器监控体系整个翻新了一遍从原来的Zabbix切换成了夜莺监控加categraf采集器的组合。老实说Zabbix不是不好但对于我们这种没有专职DBA、运维也就两三个人的小团队来说光是把模板和触发器理清楚就够喝一壶的了。夜莺这套方案服务端一个二进制采集端一个二进制从部署到出图再到告警一天之内就能跑通后面再想加监控项无非就是往采集器conf目录里加个小配置文件的事。这篇文章我会把完整的配置过程、关键参数含义、以及我实际踩过的坑按顺序写出来。不管你是刚接触Linux系统监控、还在选型阶段还是已经决定用夜莺categraf但卡在配置上都能照着一步步操作。文章里涉及的路径和配置都是以我这边实际使用的夜莺v7.x和categraf最新版为准如果你用的版本不同个别字段名可能会有差异原理是相通的。1. 为什么我会把监控体系换成夜莺categraf1.1 中小团队选监控方案的几重现实先说一句可能得罪人的话很多人选监控系统不是选最好的是选最熟的。Zabbix一堆人推但真正落地时你得先学会它那套模板继承、宏变量、触发器表达式熟练工配一个业务监控项都要十几分钟。Prometheus那一套则是组件拆得太细exporter一堆、服务发现要配、告警规则要另外维护还要考虑高可用沉没成本不低。我用过一段时间的Zabbix最让我头疼的不是功能不够而是改一个监控模板要同时动好几层配置排查一个误报要顺着items、triggers、actions翻好几页。后来换了夜莺监控categraf这个组合两条腿走路服务端只负责存储、查询、告警采集逻辑全部下沉到categraf的conf目录里一个插件一个目录配置就像写作业所见即所得。对比项ZabbixPrometheusexporter全家桶夜莺监控categraf部署复杂度中高前端ServerDBProxy高Prometheus本身多exporter服务发现低服务端和采集端各一个二进制采集器形态Agent配置集中在服务端exporter分散部署每个目标一个进程categraf一个进程按插件目录管理告警能力触发器体系功能全但学习曲线陡依赖Alertmanager和rules文件内置告警引擎Web上直接写PromQL上手速度慢概念多中等组件多快核心配置就一个toml文件适合规模各种规模都行但维护成本随规模上升中大规模需要专人维护几十到几千台都能覆盖中小团队友好1.2 夜莺和categraf各自解决什么问题夜莺监控Nightingale是国内开源的可观测性平台本身是CNCF的sandbox项目社区活跃度一直不低。它解决的是服务端那一大摊事数据接收、时序存储、告警规则管理、通知渠道、用户权限、监控大盘。v7版本之后内置了时序数据库不需要再额外部署Prometheus或VictoriaMetrics这对小团队来说省了很大的维护量。categraf则是配套的采集器基于Telegraf二次开发兼容Telegraf的插件体系同时重写了不少常用插件。它解决的是采集端的问题一个进程一个配置文件目录CPU、内存、磁盘、网络、进程、端口、MySQL、Redis、Nginx这些常见的采集场景全都能覆盖。之所以选categraf而不是直接用Telegraf是因为它跟夜莺服务端的对接是开箱即用的writer配置、心跳上报、机器列表这些都提前封装好了不用自己调协议。1.3 这套方案真正适合谁如果你的情况符合下面几条我建议你认真考虑这套方案团队没有专职监控开发运维只有几个人希望在一天内看到第一张监控图表机器规模在几十到几千台不需要那种超大规模的联邦部署对告警及时性有要求希望直接在Web上写PromQL配规则而不是改一堆yaml文件预算有限不想为每个节点买商业监控授权。我也不是劝所有人扔掉Zabbix或Prometheus。如果你团队里已经有人精通Zabbix模板体系或者你们的基础设施已经深度绑定Prometheus生态那就继续用折腾迁移的成本可能比收益大。但如果你正在选型或者在旧方案里维护得越来越吃力这套组合值得花半天试试。2. 配置前先弄清楚这条监控链路是怎么工作的2.1 两端部署的分工夜莺categraf是典型的两端架构中间走HTTP协议不需要额外开奇怪的端口。服务端就是夜莺的n9e-server进程它把Web页面、API接口、远程写入接收、告警引擎、时序存储全包在一个二进制里。采集端就是categraf进程跑在被监控的Linux服务器上按conf目录里的插件配置去采集指标然后批量推给服务端。需要提前记住的端口就两个17000是服务端的HTTP端口负责接收categraf上报的数据、提供Web和API20090是RPC端口主要用于服务端内部组件间的通信一般不需要从外部访问。categraf默认上报数据的地址是http://服务端IP:17000/prometheus/write采用的是Prometheus的remote write协议所以只要这个地址在categraf所在机器上能访问通数据就能进来。2.2 数据是怎么流到告警通知的这条链路的完整走向是categraf按固定时间间隔执行采集插件拿到一批指标后打包发送到夜莺服务端的remote write接口服务端把指标写入内置的时序数据库用户在Web上查询监控大盘时前端从内置TSDB按时间范围取数据告警引擎每隔一段时间加载一遍告警规则把规则里的PromQL拿去TSDB里查一旦查出来的结果满足触发条件并且持续了设定时长就生成一条告警事件再按通知媒介把消息发出去。理解这条数据链非常关键。后面排查问题时大部分故障其实都能在这个链路上定位一个大致环节到底是采集端没采到还是数据没推上来还是服务端没存下来还是告警规则没查到想要的数据。很多人一上来就怀疑是告警规则的问题查了半天结果是采集端数据根本没上来白白浪费时间。2.3 两个必须提前确认的环境前提第一个是时间同步。监控数据严重依赖时间戳如果被监控机器和服务端时间差太多数据要么查不到要么告警计算出来的结果完全不对。建议所有服务器都装好chrony或ntp并确认时间源可达。我遇到过一台机器比服务端慢了两分钟告警触发时间乱七八糟最后排查了一圈源头就是时间偏移。第二个是网络连通性。categraf到服务端17000端口的TCP连通性以及服务端到MySQL、Redis的连通性都要提前确认。很多部署失败的案例是服务器上有防火墙或安全组规则放行了某些端口但没放行17000categraf那边死活推不上去服务端Web上自然一个点都看不到。动手之前先用telnet 服务端IP 17000或nc -vz 服务端IP 17000验一下。3. 夜莺服务端部署二进制方式完整跑通3.1 下载安装与目录结构夜莺服务端推荐用二进制方式部署不需要Docker对机器要求也不高4核8G内存的机器跑个几百台规模的监控完全够用。从GitHub releases页面下载对应架构的压缩包比如n9e-v7.x.x-linux-amd64.tar.gz解压到/opt/n9e。mkdir -p /opt/n9e tar -xzf n9e-v7.x.x-linux-amd64.tar.gz -C /opt/n9e cd /opt/n9e解压之后的目录结构需要有个概念n9e是服务端主程序etc目录下是配置文件sql目录下是初始化数据库用的SQL脚本首次启动后还会生成data目录这个目录就是内置时序数据库的数据存放位置。这里要提醒一句如果数据目录所在磁盘空间不够后面存储写满会导致监控数据丢失甚至服务端异常上线前一定给data所在分区留足空间最好单独挂一块数据盘。3.2 初始化MySQL数据库夜莺服务端的告警规则、用户信息、大盘配置、通知渠道这些元数据需要存到MySQL里。先准备好MySQL服务版本建议5.7以上8.0也完全兼容。登录MySQL创建数据库并导入初始化SQLCREATE DATABASE IF NOT EXISTS n9e DEFAULT CHARACTER SET utf8mb4;mysql -uroot -p n9e /opt/n9e/sql/n9e.sql导入成功后可以简单验证一下表是否都建出来了mysql -uroot -p -e use n9e; show tables;应该能看到几十张表包括alert_rule、user、dashboard这类核心表。如果SQL导入时报错优先检查MySQL版本和字符集设置utf8mb4不要换成utf8否则后面写入汉字类配置可能出现编码问题。3.3 调整服务端config.toml夜莺服务端的核心配置是/opt/n9e/etc/config.toml。需要动的主要是数据库和Redis两段配置。打开文件找到[MySQL]段把地址、账号、密码、库名改成你自己的[MySQL] addr 127.0.0.1:3306 username root password 你的数据库密码 dbname n9e max_open_conns 128 max_idle_conns 32再找[Redis]段夜莺v7的告警引擎和某些缓存功能依赖Redis[Redis] addr 127.0.0.1:6379 password db 0如果Redis没有密码就留空有密码就填上。密码里如果包含#、、:这些特殊字符建议先在外面用单引号包一层或者在配置里做一下转义否则toml解析很容易断在特殊字符那里服务端启动直接报配置错误。改完配置后可以先把服务端启动起来但先别急着刷页面我们还要完成验证步骤。3.4 启动验证与systemd托管在/opt/n9e目录下直接执行./n9e看到日志正常滚动后打开浏览器访问http://服务端IP:17000。首次登录账号是root默认密码是root.2020登录后第一件事就是改密码。如果页面能正常打开并登录说明服务端的Web、API、数据库连接都没问题。开发环境的验证越简单越好但生产环境一定得让进程托管起来不然机器重启后服务不会自动恢复。在/etc/systemd/system/n9e.service里写一个systemd服务[Unit] DescriptionNightingale Server Afternetwork.target mysqld.service redis.service [Service] Typesimple WorkingDirectory/opt/n9e ExecStart/opt/n9e/n9e Restartalways RestartSec10 LimitNOFILE655350 [Install] WantedBymulti-user.target然后执行systemctl daemon-reload systemctl enable n9e systemctl start n9e这里有一点需要注意WorkingDirectory必须指向/opt/n9e因为夜莺的二进制默认会从当前目录找etc和data如果你直接把ExecStart写成绝对路径而工作目录不对启动时大概率会报找不到配置文件的错。我用systemd托管后碰到过一次排查了一圈发现是工作目录问题调整后就好了。4. categraf采集器安装与主配置4.1 安装与目录结构服务端就绪后接下来在被监控的Linux机器上安装categraf。同样从GitHub releases下载对应架构的压缩包解压到/opt/categrafmkdir -p /opt/categraf tar -xzf categraf-v0.x.x-linux-amd64.tar.gz -C /opt/categraf cd /opt/categrafcategraf的目录结构很直观categraf是主程序conf目录下是全部配置。打开conf目录会看到config.toml主配置文件以及一堆以input.开头的子目录每个子目录对应一种采集插件比如input.cpu、input.mem、input.disk、input.mysql。如果某个插件目录被删掉或移走categraf启动时就不会加载这个采集项这种设计让启停插件变成了一件非常自然的事。4.2 config.toml里的三个关键段categraf的conf/config.toml有三个段落必须理解清楚。第一段是[global]用于设置采集器的主机身份[global] hostname ip labels { env prod, region bj }hostname理论上会自动取系统主机名但我建议手动指定成有业务含义的名字比如web-01、db-master-01。因为自动取的主机名经常是一串没规则的随机ID后面在夜莺的机器列表里根本认不出来是哪台机器。labels可以打一些自定义标签比如环境、机房、业务线这些标签会作为指标的一部分上报后续按标签聚合查询和告警非常有用。第二段是[writers]这是数据上报的出口[writers] urls [http://服务端IP:17000/prometheus/write]这个地址就是前面说的remote write接口一定确保categraf机器能访问到。第三段是[heartbeat]控制心跳上报[heartbeat] enable true url http://服务端IP:17000/v1/n9e/heartbeat开启心跳后夜莺的机器列表会自动维护在线状态主机离线时在页面上会直接显示出来。如果不开心跳机器列表可能为空或状态不准。url路径如果和你的版本对不上打开categraf自带的默认config.toml看一眼最终路径即可。4.3 用自检命令验证采集器配置完成后先别直接推到systemd里categraf自带一个特别好用的自检参数可以前台运行指定插件并打印采集结果./categraf --test --inputs cpu如果一切正常终端会输出一批采集到的指标和标签比如cpu_usage_idle、cpu_usage_util这些后面再带上host、cpu等标签。看到输出就能确认两方面采集插件本身工作正常config.toml里的writer配置也加载成功。这个命令是我整个配置过程中用得最多的工具每次改动插件配置后我都会跑一遍--test亲眼看到指标名和标签对不对再去写告警规则能省下大量排查时间。验证通过后同样用systemd把categraf托管起来[Unit] DescriptionCategraf Afternetwork.target [Service] Typesimple WorkingDirectory/opt/categraf ExecStart/opt/categraf/categraf Restartalways RestartSec10 [Install] WantedBymulti-user.targetsystemctl daemon-reload systemctl enable categraf systemctl start categraf注意categraf同样有WorkingDirectory的问题它默认从当前目录找conf目录目录不对就加载不到配置这点跟夜莺服务端是一样的。5. 常用采集插件的实战配置5.1 基础四件套cpu、mem、disk、netcategraf对基础指标的采集基本做到了开箱即用。input.cpu/cpu.toml里可以设置interval默认是15秒采集一次采集CPU各项使用率、load等指标。多核服务器上指标会同时带上单核和总的标签比如cpucpu-total和cpucpu0、cpucpu1写告警规则时一般用cpucpu-total来代表整机CPU状态。input.mem/mem.toml采集内存相关指标重点看mem_used_percent这是已用内存的百分比。注意Linux系统因为page cache的原因内存指标看起来会比业务上理解的“实际占用”高一些这是正常的不用大惊小怪。input.disk/disk.toml需要关注一下挂载点过滤。默认配置会采集所有挂载分区但像/proc、/sys这类伪文件系统需要排除掉否则会产生一堆无意义的指标。一般配置里会有一个mount_points [/, /data]之类的白名单选项或者用ignore_mount_points排除指定路径。我建议把磁盘监控集中在根分区和数据盘分区上既能减少数据量也能避免后面写告警时被一堆临时挂载点干扰。input.net/net.toml采集网卡流量指标名是net_bytes_recv和net_bytes_sent如果机器上有很多虚拟网卡或Docker网桥建议在interfaces配置里指定物理网卡名比如interfaces [eth0, bond0]否则默认收集所有网卡会让监控图非常杂乱。5.2 进程与端口监控进程监控是我用得最多的一个插件。input.process/process.toml支持按进程名匹配也支持正则模式[[instances]] cluster 核心业务 mode pattern patterns [nginx, mysqld, java.*] # mode comm 时用进程的可执行文件名精确匹配配置多个[[instances]]段可以分别监控不同进程每段都带不同的cluster标签。这样夜莺页面上就能按业务维度区分不同进程的状态告警规则里也能针对单个进程单独设阈值。端口监控用input.port/port.toml这个插件解决的是“进程在跑但端口没监听”的漏网场景[[instances]] targets [ tcp://127.0.0.1:3306, tcp://127.0.0.1:80, udp://127.0.0.1:514 ]它支持TCP和UDP探测TCP方式实际上是在建立连接比单纯看进程存在更能反映服务是否可访问。我把核心服务的关键端口都加进来了比如MySQL、Redis、Nginx、Java应用端口通过--test --inputs port可以看到一个连通性指标写告警规则时判断这个指标的值就能覆盖端口异常。5.3 MySQL、Redis和Ping探测中间件监控方面input.mysql/mysql.toml配置了MySQL地址和账号[[instances]] address 127.0.0.1:3306 username categraf password 采集密码 extra_status_metrics true extra_innodb_metrics true metrics [status, innodb, connection_vars]MySQL采集账号不建议直接用root单独建一个只读账号授权范围控制在查询状态信息和进程信息即可GRANT SELECT, PROCESS, REPLICATION CLIENT ON *.* TO categraf127.0.0.1 IDENTIFIED BY 采集密码;input.redis/redis.toml配置Redis地址和密码[[instances]] addr 127.0.0.1:6379 password 如果Redis有密码就填采集到的指标包括内存使用、连接数、命中率等这些对于排查Redis性能问题非常有用。另外如果你有大量目标需要探测网络连通性input.ping/ping.toml可以配置一批目标地址categraf会周期性发起ICMP探测把丢包率和延迟上报上来这个插件在专线监控和跨机房监控场景特别实用。每个插件配置完都建议立即用./categraf --test --inputs 插件名验证一下确认能看到数据再保存。这套“改配置-自检-确认”的循环速度很快能让你对每个插件采集到的指标名了如指掌后面配告警时几乎不会写错PromQL。6. 让监控真正有用的告警配置6.1 写PromQL前先做一步验证很多人在夜莺Web上配置完告警规则等半天不触发第一反应就是怀疑告警引擎有问题其实绝大多数情况是PromQL写得不对或者指标名不存在。所以我的固定流程是在夜莺Web的“即时查询”页面先跑一遍PromQL确认能查出数据再建告警规则。比如我想对CPU使用率做告警先在即时查询里输入cpu_usage_util{cpucpu-total}如果页面能展示出曲线说明指标名和标签都对。如果查询结果为空就去被监控机器上跑./categraf --test --inputs cpu对比一下自检输出里的指标名和标签跟PromQL里的写法是否一致。这一步虽然多花两分钟但能省掉后面数小时的排障时间是我强烈建议的操作习惯。6.2 一条完整告警规则的配置参数在夜莺Web的“告警管理-告警规则”页面创建一条规则核心参数如下。我以CPU使用率告警为例配置项示例值说明规则名称CPU使用率过高建议带上机器或业务标识规则内容cpu_usage_util{cpucpu-total} 80PromQL表达式持续时间5分钟持续多长时间才触发告警告警级别P2按影响程度分级通知媒介企业微信/邮件选择已配置的通知渠道持续时间这个参数很容易被忽略。如果设成0或1分钟网络抖动、临时高负载都可能触发告警误报率会很高。我一般把CPU、内存这类指标设成5分钟把端口探活、进程存活这类严重故障设成0或1分钟因为端口挂了多等一分钟都可能造成业务影响。夜莺还内置了一批告警规则模板在创建规则页面可以直接导入覆盖了CPU、内存、磁盘、存活等常见场景。第一次用可以先从模板导入再根据自己的阈值偏好修改比自己从零写PromQL稳得多。6.3 通知媒介与告警收敛告警规则配好之后通知媒介不配置告警只会停留在页面上不会主动找你。在“通知媒介”里配置渠道信息夜莺支持邮件、钉钉、企业微信、飞书、Webhook等。企业微信机器人最简单复制一个Webhook地址填进去保存后在告警规则里勾选即可。邮件方式需要在配置里填SMTP服务器和账号生产环境建议至少配置一个Webhook渠道和一个邮件渠道互相兜底。告警收敛也是上线前必须处理的。否则某台机器磁盘满了每台机器每五分钟刷一条告警团队群里很快就会被刷屏。夜莺支持告警规则的“静默时间”和“告警升级”以及通知频率限制。实际操作中我习惯在非工作时间段把CPU、内存这类的P3低级别告警静默掉只保留端口、进程这种严重影响业务的告警。另外合理设置持续时间也能天然过滤很多瞬时抖动比事后加静默规则更科学。7. 高频问题排查实录与根因分析7.1 机器离线、看不到数据的排查链路这套方案在中小规模下其实很稳但真出问题时特征往往都集中在“机器列表离线”和“页面没数据”上。我总结了一套排查链路从现象到根因一步步来。第一步检查采集进程。ps -ef | grep categraf如果进程不存在systemctl status categraf看是不是被OOM杀掉或启动失败。第二步用自检判断插件本身是否正常。第三步检查网络连通。telnet 服务端IP 17000如果不通被监控机器和服务端之间可能被防火墙或安全组拦住。第四步看writer地址。cat /opt/categraf/conf/config.toml | grep -A2 writers确认url写的是不是服务端IP而不是默认的127.0.0.1。第五步看服务端日志。在夜莺服务端执行journalctl -u n9e -f然后重启categraf看有没有写入请求进来如果服务端收到请求但没写库大概率是内置TSDB数据目录出了问题。这套链路我实际用过好多次大部分问题都卡在前三步。有一次排查了很久最后发现是服务端和采集端的时间差了快10分钟夜莺页面默认查最近1小时按理说应该有数据但TSDB对时间戳有一定校验延迟过大的数据会被拒绝写入。所以再次强调时间同步一定提前做好。7.2 告警不触发时我是怎么查的告警不触发的排查我的经验是先看数据再看规则最后看通知。按这个顺序找基本十有八九。首先在即时查询里执行告警规则里的PromQL确认返回的数据点确实超过了阈值。这一步能过滤掉“指标名不存在”、“标签写错”这两类最常见的问题。其次检查规则的“持续时间”是不是设得太长比如设了30分钟实际上只持续了10分钟自然不会触发。然后是状态检查在告警事件列表里看规则最近有没有尝试生成事件如果规则状态异常页面上会有提示。最后才是通知渠道有时告警生成了但没发出来其实事件列表里能找到而通知没送达纯粹是Webhook地址失效或被企业微信频控限制。这里分享一个我踩过的真实坑我曾经写了一条CPU告警PromQL看起来没问题数据也有但就是不触发。查了半天发现我把标签写成了hostweb-01而实际上categraf上报的标签是identweb-01这是夜莺体系里机器标识的特殊字段。PromQL里写了一个不存在的标签查询结果永远为空告警自然永远不触发。所以配规则前在即时查询里验一遍PromQL真的是血泪教训换来的习惯。7.3 磁盘、时区、进程消失等细节坑磁盘监控的问题集中在挂载点过滤上。默认配置如果不加过滤会把/proc、/sys这些特殊文件系统也采集进来导致告警规则里disk_used_percent 90这样的PromQL永远匹配到一堆不该看的分区。我的做法是在disk配置里显式列出要监控的挂载点比如mount_points [/, /data]一劳永逸。进程监控的一个隐蔽问题当一个进程名下带了多个worker进程时比如Nginx的master和worker同名进程插件会把数量、CPU、内存指标聚合在一起。如果写告警只关心进程是否存在问题不大但如果关心进程CPU占用率要注意聚合后的含义。另外某些Java应用在启动脚本里会把进程名重写成别的字符串用原来的服务名匹配不到这时候用pattern正则匹配启动参数里的特征字符串更可靠。进程莫名其妙消失这个问题我在几台机器上遇到过。排查下来主要是机器内存紧张categraf进程被OOM killer干掉。建议在categraf的systemd服务文件里加上OOMScoreAdjust-900降低它被选为OOM牺牲品的概率同时保证监控系统本身不能被轻易杀掉。还有一个容易忽略的点categraf升级后旧版本的conf目录配置跟新版本二进制不兼容这种行为通常不会报错但采集的数据某些字段会变。升级前一定要备份conf目录升级后立刻跑一遍--test对比指标输出。8. 上线后的优化习惯和维护经验8.1 采集频率与性能的平衡categraf默认15秒的采集间隔对绝大多数场景来说是合理的。低于这个频率会明显增加服务端写入压力而我们的实践经验是CPU、内存这些指标哪怕间隔到30-60秒对看趋势影响也不大。真正需要更短间隔的只有端口探活和进程存活这类业务连续性指标可以单独将对应插件的interval设成10秒其他保持默认即可。采集器本身的资源占用很轻一台普通虚拟机跑categrafCPU占用几乎常年是0%内存占用基本在50-100MB之间。这个数据让我对“多装一个agent会不会拖累业务机器”的顾虑完全打消了。服务端这边要关注的是数据目录的磁盘使用量建议每天看一次du -sh /opt/n9e/data按写入速率估算还能扛多久别等磁盘写满了再慌。8.2 上线前务必做的几件小事几件小事虽然琐碎但从我的经验来看能帮你后续省掉大量麻烦。第一统一主机命名规范。categraf的[global] hostname建议按业务用途命名比如web-nginx-01、db-mysql-master。散乱的主机名在后端大数据量排查时会让你在机器列表里翻半天。第二利用labels打环境标签。在[global] labels里加上envprod、regionbj之类告警和查询都能按环境区分。第三备份夜莺服务端的MySQL数据库。告警规则、用户、大盘这些元数据都在MySQL里用一个crontab每天凌晨导出一次SQL就行数据量很小但真到服务重新搭建时就知道这步多重要。第四升级采集器前备份conf目录用版本管理工具记录下来每次改动方便回溯。8.3 这套方案往后扩展的几个方向如果后续机器规模上来了这套方案的扩展路径也比较清晰。categraf天然支持多台机器部署新机器装好包、改好服务端地址、启动服务自动化流程几分钟就能搞定配合Ansible这类工具可以在几十台机器上批量下发。夜莺服务端这边当机器数量到几千台后如果内置TSDB压力偏大可以对接外部时序存储夜莺支持把remote write转发给Prometheus或VictoriaMetrics架构上留有扩展口。另外告警规则也建议按团队和业务拆分不要所有人都用同一个全局规则。夜莺支持用户分组和权限隔离可以让不同团队管理自己那部分机器的监控和告警互不干扰。我目前也在把告警通知进一步精细化管理把不同级别告警分流到不同群里P0级直接电话P2级发企业微信这样团队响应的节奏会清晰很多。最后说个我自己的体会。监控系统这个东西真正重要的不是监控面板画得有多漂亮而是告警准、通知及时、排查链路短。夜莺categraf这套组合帮我实现了这三点而且整个过程几乎没有遇到什么需要花长时间研究才能过去的坎。如果你也正在Linux服务器监控这个方向上折腾希望这份配置记录能给你节省一点时间。