做运维这些年我越来越觉得“监控”是件挺反直觉的事情你搭它的时候总觉得“没多大必要”等线上真的出了事故、翻日志翻到怀疑人生的时候又开始后悔当时怎么没把指标体系建得再细一点。尤其是Linux服务器一多CPU飙了、磁盘满了、进程悄悄挂了这种事靠人肉盯根本盯不过来。所以我想把最近在用的这套方案——夜莺监控加categraf采集器——从头到尾梳理一遍包括部署、配置、常见问题排查和那些文档里不太会写的坑。如果你正准备给团队搭一套能用、不折腾、还看得住事的监控系统这篇文章应该能让你少走不少弯路。这套组合的核心逻辑其实很简单categraf负责从各个Linux节点上采数据夜莺监控Nightingale负责存储、展示、告警。categraf是夜莺生态下的采集器但它本身也支持Prometheus协议、influxdb协议采集能力并不局限于夜莺自家设备。你完全可以把它理解成一个更现代化的Telegraf或者node_exporter只不过配置方式、插件管理、数据上报方式都做了很多打磨。整条链路跑起来之后服务器的基础指标、中间件指标、业务自定义指标都能统一收口再配上告警规则谁出了问题一目了然。这篇文章主要面向两类人一是刚接触Linux系统监控、想从零搭一套监控体系的运维新人二是已经在用Prometheus或者其他采集器、但觉得维护成本偏高、想换一个更顺手方案的进阶玩家。我会把架构思路、安装步骤、配置项含义、故障排查方法都讲清楚尽量做到你是照着操作就能跑起来的程度。1. 监控体系总体设计与组件分工在动手部署之前先把整体架构捋清楚后面排错才能有方向。很多人搭监控喜欢“先装上再说”装上之后指标出不来就懵了其实就是没理解数据到底是怎么流动的。1.1 夜莺监控能做什么、和Prometheus有什么关系夜莺监控从产品形态上看是一个完整的可观测性平台覆盖了指标采集、数据存储、可视化、告警通知这几大块。它早期版本直接兼容Prometheus的配置和概念比如你可以把Prometheus里的scrape_config迁过来也可以用PromQL查询数据这就让很多原本在Prometheus生态里做监控的团队迁移成本很低。在v5之后的版本里夜莺逐步做了自己的数据模型和告警引擎但核心思路还是“类Prometheus”指标由采集器抓取或推送存储进时序数据库再通过统一的查询语言做展示和告警。和直接用Prometheus相比夜莺的优势主要体现在两端一是告警管理更贴近国内团队的使用习惯内置了值班、升级、静默、聚合等功能二是有原生的大盘管理和用户权限体系多人协作时不用自己再造一套。而且夜莺的部署方式是“中心化”的服务端只需要部署一套所有agent上报到同一套后端规模上来之后维护成本不会线性增长。当然这不是说夜莺能完全替代Prometheus如果你现有的生态里已经大量使用Prometheus Operator、各类exporter保留Prometheus做数据采集把夜莺作为统一展示和告警入口也是常见做法。1.2 categraf在整个链路里的位置categraf在链路里扮演的角色简单说就是“数据入口”。它跑在每一台需要监控的Linux机器上负责采集CPU、内存、磁盘、网络、进程、日志等指标然后通过HTTP上报给中心端的时序数据库。和传统Telegraf相比categraf最让我喜欢的一点是它原生支持多种上报格式既能以Prometheus格式暴露metrics端点又能直接推送到VictoriaMetrics、M3DB这类存储还能兼容夜莺自己的数据格式。这样设计的好处是你不需要在采集层做格式转换下游怎么方便就怎么接。categraf的插件体系也值得一提。它内置了大量input插件像cpu、mem、disk、net、system、procstat、exec等都在其中。每个插件对应一个配置文件放在conf目录下的input.xxx文件夹里默认都带了一份示例配置你只需要按需打开或修改。这种“一个插件一个目录”的设计比Telegraf那种集中式配置要直观不少排查问题的时候直接看对应插件的conf文件就行。1.3 这套组合适合什么场景我不是说所有监控需求都应该无脑上这一套但它确实很适合几类典型场景。第一种是中小团队机器规模在几十到几百台之间需要一个轻量、不依赖太多外部组件的监控方案。第二种是已经用了Prometheus、但告警和看盘管理比较痛苦、想让开发和运维都能方便地看到系统状态的团队。第三种是想把“采集、存储、告警、通知”完全打通不想在自己拼一堆开源组件之间做胶水层的团队。如果你们团队本身已经有成熟的Prometheus Grafana Alertmanager链路而且运行得很稳定那其实没有必要强行切换到夜莺。但如果你正在选型或者对现状不满意夜莺 categraf这套组合在易用性和完整度上确实是目前国内开源方案里很能打的一个。2. 环境准备与部署安装好了架构层面聊清楚了下面进入实操环节。这部分我会按照服务端和客户端分开讲服务端负责存储和展示客户端就是categraf采集器。2.1 服务端准备MySQL、Redis、VictoriaMetrics、n9e夜莺服务端依赖几个组件MySQL存元数据、Redis做缓存、VictoriaMetrics或M3DB等存时序数据最后是夜莺自身进程n9e。我这里以二进制部署为例因为这种方式最容易理解各组件之间的关系排查问题也更方便。首先是MySQL。版本建议选5.7或8.0装好之后创建一个独立的库比如数据库名可以让夜莺初始化脚本自动建也可以手动建好再导入。不论哪种方式都要保证字符集是utf8mb4不然有些告警内容或标签值会报编码错误。Redis用默认配置即可主要是给告警引擎和session用的如果服务端和Redis不在同一台机器记得bind地址要改成内网IP或者单独配置访问控制。然后是VictoriaMetrics。这个组件我强烈建议单独部署不要和夜莺进程混在一起跑因为时序数据的写入量比较大混在一起容易互相影响。VictoriaMetrics的单机版安装非常简单解压后执行带storageDataPath参数的启动命令即可。它默认监听8428端口categraf会上报到这个端口。这里有个细节夜莺是支持配置多个数据源的但默认情况下的时序库地址就是指VictoriaMetrics的写入和查询地址我一般会检查一下夜莺的etc/config.toml里Prometheus部分的配置是否和VictoriaMetrics实际端口一致。最后是n9e进程本身。解压安装包之后通常需要导入数据库表结构再修改config.toml里的MySQL、Redis、时序库连接信息最后启动n9e访问/health接口确认服务正常。夜莺服务端的初始化步骤官方文档写得很详细但有一个细节容易漏如果你用的是MySQL 8.0要注意默认认证插件是caching_sha2_password老版本的Go驱动可能不支持建议在创建用户时指定mysql_native_password。2.2 categraf客户端安装categraf安装就更直接了。从GitHub或网盘拉取对应CPU架构的二进制压缩包解压到指定目录比如/opt/categraf。目录里有两个核心部分一个是categraf可执行文件另一个是conf配置目录。conf目录下默认有config.toml全局配置和一个叫inputs的目录里面按插件名分了子目录每个子目录里放着相应插件的配置文件。安装完成后先别急着启动先改全局配置里的几个关键项一是上报地址也就是夜莺服务端或VictoriaMetrics的地址二是采集器自身的主机名和标签这决定了你之后在夜莺上看到这台机器叫什么名字、带哪些标签。我习惯上会把region、env这种通用标签打在全局配置里这样在多机房或多环境混部的时候筛选起来特别方便。改完配置之后可以先用单次模式启动一次验证配置是否正确。categraf支持直接运行categraf --test这样类似telegraf的测试模式它会采集一次数据并输出结果。看到stdout里有一行行数据打印出来就可以把categraf注册成systemd服务正式跑起来了。2.3 客户端到服务端的连通性验证虽然这一步看起来很简单但很多问题都出在这里。categraf启动后如果配置的上报地址是VictoriaMetrics可以直接在服务器上执行curl -s http://服务端IP:8428/api/v1/query?queryup来查一下有没有这个采集目标的数据。如果返回的结果是空的说明categraf的数据根本没进到存储里。这个时候需要排查三层网络通不通、端口通不通、数据格式对不对。网络和端口层面主要是查防火墙和selinux。很多云服务器默认安全组只放行了常用端口8428、17000这类监控端口容易被漏掉。另外categraf上报如果走的是独立agent端口还要确认agent监听端口有没有放行。数据格式层面的问题通常表现为categraf日志里报连接失败或者返回非200状态码。这时可以把categraf日志级别调到debug它会打印出完整的HTTP请求地址和响应码很快就能定位是URL拼错了还是鉴权没过。3. 采集器核心配置与指标接入安装跑通只是第一步真正的重头戏在于配置采集器让数据符合你的监控需求。这一部分我挑几个最重要的配置项和插件展开讲讲覆盖大部分人的日常所需。3.1 categraf全局配置详解categraf的全局配置在conf/config.toml里。你打开这个文件最先看到的会是一个[global]配置段里面有hostname、labels、interval等参数。interval是采集周期默认15秒如果你对实时性要求高可以改成10秒、5秒但要注意采集频率提高之后对机器和时序库的压力也会加大建议从默认值开始等需要时再调。接下来的[writer_opt]和[[writers]]配置段决定了数据往哪发。[[writers]]这里可以配置多个输出端每个输出端有url、basic_auth等字段。我们日常用到的场景有两种一种是直接把数据写到VictoriaMetrics的Prometheus协议接口另一种是写到夜莺的collector端再由夜莺统一转发。前者更直接后者多了一层缓冲和认证。如果你用前者写法类似[[writers]] url http://127.0.0.1:8428/api/v1/write # basic_auth [用户名, 密码]这里要特别提醒的是url末尾的路径别写错。VictoriaMetrics兼容Prometheus remote write的接口路径是/api/v1/write很多人习惯性写成/api/v1/prom/write或者/api/v1/import导致数据一直写不进去。这个坑我踩过不止一次排查的时候绕了大半天才发现是路径问题。另外全局配置里还有[log]段、[http]段、[aha]段。[log]控制日志输出路径和级别排错时建议把level改成debug正常运行时改成info或warn。[http]段可以开启一个本地HTTP端口用来暴露categraf自身的运行指标和pprof信息。我一般会开启这个端口后面排查采集器本身性能问题时非常有用。3.2 常用插件配置CPU、内存、磁盘、进程categraf的inputs目录下每个插件子目录里都有对应的配置文件。几个最常用的我分别说一下关键参数。CPU采集对应的目录是input.cpu主要配置是collect_per_cpu和collect_cpu_time这两个布尔值。如果你只关心整体CPU使用率collect_per_cpu可以设为false减少指标数量如果想看每个逻辑核的使用率就设为true。内存采集对应input.mem配置相对简单基本没有需要改的参数默认采集的就是能直接用于画图和告警的内存使用率、可用内存等指标。磁盘采集对应input.disk和input.diskio。这里的坑稍多一是mounted fs类型要选对比如你不需要采集proc、sysfs、tmpfs这类虚拟文件系统二是ignore_fs或者mount_point的过滤规则要配置好否则会有大量重复指标上报。我通常会把ignore_fs设成tmpfs|devtmpfs|overlay|squashfs避免出现一堆云主机里挂载的无意义文件系统。diskio那边默认采集所有块设备如果机器上有很多云盘或loop设备指标数量会偏大建议用devices过滤一下。进程监控是很多人会忽略、但实际很实用的一个插件对应input.procstat。它可以按进程名或者pid文件监控具体进程的运行状态、CPU、内存、线程数、文件句柄数等。配置里最关键的是pattern字段用来匹配进程名。例如监控nginx进程[[instances]] pattern nginx这个插件设置好了以后进程“活着但端口挂了”“进程起来了但CPU占用异常高”这类问题就能第一时间暴露出来。我还习惯配合一个exec插件做自定义脚本采集比如自定义采集某个日志文件大小、某个队列长度、某个API的响应时间categraf会定期执行脚本并把脚本输出的格式解析成指标。这种方式扩展性很强而且不需要重新编译采集器。3.3 数据上报与指标验证配置好插件之后重启categraf服务等待一个采集周期然后去查询数据确认。如果数据直接写到VictoriaMetrics可以用PromQL查询验证比如curl -g http://127.0.0.1:8428/api/v1/query?querymem_used_percent返回结果里应该能看到当前机器的内存使用率。这时再去夜莺的“指标查询”页面切到PromQL查询模式输入同样的表达式如果也能查到那就说明链路已经通了。如果夜莺页面查不到而VictoriaMetrics里能查到问题大概率在夜莺的数据源配置或者时序库地址不一致上如果两边都查不到回categraf日志里看是否有采集错误或上报错误。另外有一个小习惯我强烈建议养成给新增的采集指标都配上host标签或env标签。很多人刚开始搭监控时不注意标签规范化等机器多了以后查询和告警里写标签匹配规则时会特别痛苦。标签这玩意儿前期花半小时设计好后面能省无数个早晨。4. 告警规则与监控面板采集器把数据送进来只是基础监控系统真正产生价值的地方在告警和可视化。夜莺在这两块的体验做得比较贴近用户直觉我讲讲常用的配置思路。4.1 告警规则配置夜莺的告警规则配置入口在“告警管理”模块。新建告警规则时有几个关键字段需要理解清楚规则名称、PromQL、告警级别、执行频率、持续时间、通知组。PromQL是你首先要写对的东西。比如想告警CPU使用率超过90%持续5分钟表达式可以写成cpu_usage_idle 10注意categraf的CPU指标通常是cpu_usage_idle空闲率不是直接的usage率所以“使用率超过90%”要反过来写。这个细节很多人没注意直接写cpu_usage 90发现数据永远是空的其实是字段名或者语义反了。执行频率和持续时间要配合好。我一般建议执行频率设置成一分钟持续时间设置成5分钟。这样既不会因为瞬时抖动频繁报警也不会因为等待时间太长错过故障窗口。告警级别和通知渠道方面夜莺支持接入钉钉、企业微信、邮件、Webhook等每种渠道都能绑定到不同的告警级别。实际操作时我把P0级别的告警同时发到电话/IM和邮件P2级别只发到IM群这样可以让紧急问题尽快触达核心人员又不至于让普通故障把大家手机震麻。还有一个容易被忽略的点是“告警恢复通知”。夜莺默认会在告警恢复后发送恢复通知这一项建议保持开启。没有恢复通知的话值班同事经常得在告警群里猜“现在到底好了没有”体验很糟糕。4.2 内置大盘与自定义面板夜莺自带了一些官方大盘模板比如Linux主机监控、MySQL监控等。如果只是看基础指标直接用内置大盘就够了。但内置大盘的布局不一定符合你团队的习惯我一般会再复制一份做调整。夜莺的大盘编辑是所见即所得的模式新增图表时核心还是PromQL比如展示CPU使用率趋势100 - cpu_usage_idle变量面板功能也很有用比如给大盘设置一个host的变量然后图表里用$host去过滤。这样你一套大盘就能看所有机器不用每台机器建一个面板。面板类目比较多的时候建议按“主机监控、中间件监控、业务监控、告警统计”分组。分组清晰了新人上手找面板的成本会低很多。4.3 指标保留周期与存储策略存储策略这块很多人一开始不在乎等数据量大了才头疼。VictoriaMetrics单机版默认会保留所有数据如果不设置retentionPeriod参数磁盘会越用越多。建议在启动VictoriaMetrics时加上-retentionPeriod3或者6单位是月根据自己的实际需求设置保存时长。基础监控指标保留3个月一般够了如果要做趋势分析、容量规划可以保留更长时间但要确保磁盘容量足够。另外要注意存储目录的磁盘空间监控。时序数据在指标数量大、采集频率高的情况下增长很快如果磁盘满了VictoriaMetrics写入会报错categraf的数据就开始积压。我踩过一次磁盘写满的坑最后的教训是给监控存储单独挂一块盘并且把这块盘的磁盘使用率纳入基础告警规则里谁满了第一时间告警出来。5. 常见问题排查与实操避坑这一章我梳理一下实际操作里出现频率比较高的几类问题每个问题都按照“现象-排查思路-解决办法”的格式写方便你到时候直接对着查。5.1 启动失败与配置加载失败categraf启动时报错最常见的是配置文件格式不正确。TOML格式对缩进和引号的要求比较严格稍不注意就解析失败。启动时报错信息里一般会指向具体的行号你直接打开对应文件看那一行附近有没有多了或少了引号、方括号。还有可能是某插件配置文件里引用了不存在的模块名这时categraf会提示unknown input。解决办法是进入conf/inputs目录仔细核对插件目录名和配置文件里的type字段是否一致。另一种情况是systemd启动失败日志显示没有权限读取某配置文件。这通常是因为categraf运行的workdir配置不对它内部很多相对路径是相对于当前工作目录的。如果用了systemd托管在service文件里要显式指定WorkingDirectory/opt/categraf否则categraf会去当前的默认目录下找conf自然找不到。5.2 数据不显示从采集到查询逐层排查这个问题发生的频率排第一。一台机器加了监控结果夜莺大盘上一个指标都没有怎么排查按照数据流方向逐层确认第一步确认categraf进程正常。执行systemctl status categraf或者直接看进程列表。如果进程不在回看启动日志。第二步确认categraf有没有采集到数据。用--test模式手动跑一次插件看看是否有指标输出。第三步确认数据有没有上报。看categraf日志里有没有write error或者网络超时的记录或者到VictoriaMetrics的接口上查一下最近时间戳有没有新数据写入。第四步确认夜莺查询链路。在夜莺的指标查询页面用裸指标名查询查看是否返回数据。如果裸查询有数据但面板上没数据就检查面板的PromQL表达式和变量过滤是否正确。实际上很多“数据不显示”的问题最后定位出来都是标签过滤条件写多了面板的变量host选了A而指标上的host标签是B自然查不到。这种情况不是监控坏了是查询条件不一致。建议新手在排查这类问题时先不加任何过滤条件查原始指标等看到数据了再逐步添加条件一步步缩小范围。5.3 网络与防火墙问题导致的写不进去categraf日志里如果反复出现connection refused或者timed out多半是网络层面的问题。先ping一下服务端IP再telnet一下目标端口。如果是云主机除了系统防火墙还要检查安全组如果是物理机检查iptables规则。还有一个我经常踩的坑服务端VictoriaMetrics监听的是127.0.0.1而不是0.0.0.0导致客户端根本连不上。这个可以通过ss -lntp来确认确保监听地址是0.0.0.0或者内网IP。另外要注意HTTP代理的影响。有些服务器设置了http_proxy环境变量categraf的上报请求有可能走了代理而代理又不通内网地址。这种问题表现得很隐蔽日志里看着是网络超时但服务端和客户端本机网络都正常。解决办法是在启动categraf的systemd服务里取消代理环境变量或者在配置文件的网络相关部分明确不走代理。5.4 告警没有触发或者重复告警告警配置好了但不触发先检查PromQL在夜莺查询页面能不能查出数据。如果查询有数据检查告警规则里的“持续时间”设置持续时间是5分钟意味着指标连续5分钟都满足条件才告警中间任何一次恢复到正常都会重新计时这是很多新人困惑的地方。如果查询没数据那说明告警对象本身就没有指标需要回到数据采集层面排查。重复告警也很常见。夜莺默认会对同一规则的同一告警对象做去重但如果你配置了多个告警规则同时匹配同一指标或者通过夜莺的“内置指标”和自定义指标重复配置了相似的规则就会造成告警风暴。解决办法是定期梳理告警规则保持规则尽量精简。再补充一个告警静默的场景某台机器做计划内维护导致CPU持续飙高这时与其关掉告警规则不如给这台机器添加一个静默策略。夜莺支持按机器标签设置静默时间段时间到了自动恢复不会出现“维护了三天、忘了开告警第四天才能发现”的尴尬局面。6. 从量到质监控体系的优化心得平台跑起来、告警响起来之后工作还没完。我在实际运营这套系统的过程中慢慢总结出几条经验写在这里供你参考。6.1 资源占用与采集频率的平衡categraf本身用Go写的资源占用很小在普通2C4G的机器上默认配置下CPU占用通常在1%以内内存占用在100MB左右。但是当你启用了大量插件尤其是procstat、exec这类需要反复扫描系统信息的插件时资源占用会有明显上升。我建议在上线之前在测试机上看一下top输出确认categraf的CPU和内存占用是否符合预期。如果采集频率比较激进比如5秒一次而且同时开了很多插件可以考虑把频率放宽到10秒或15秒这通常不会对告警及时性造成明显影响但能显著降低负载。还有一个容易忽略的资源点是文件句柄数。categraf会打开很多设备文件、socket连接如果机器ulimit设置得过低运行时间长了可能报too many open files。建议在systemd服务文件里设置LimitNOFILE65535或者更大。6.2 资产梳理与标签规范随着机器数量增长你会发现标签规范化是监控系统后期最重要的资产。每一台机器上报的数据都应该带有固定的标签机房、环境、业务线、角色。比如一台Web服务器标签可以设计成idccn-east-1, envprod, serviceweb, rolenginx。这样在做聚合和过滤的时候一条PromQL就能快速圈定范围。标签规范建议在第一次部署时就定好并且要求所有新增机器严格遵循。我在实际工作中见到太多团队因为没有规范后面写告警筛选条件时只能靠机器名模糊匹配效率极低。还有一点categraf全局标签和插件独立标签不要互相覆盖改动标签时先想清楚会影响哪些存量告警规则避免一改标签告警全失效。6.3 最后一点个人经验说实话监控系统这个东西搭建只是开始后面大量的时间其实是花在“规则调优”和“数据质量治理”上。我的体会是不要追求一次把所有指标都采全、把所有告警都配上而是先铺一个最小可用集合CPU、内存、磁盘、网络、关键进程。跑一段时间观察哪些告警是有价值的、哪些是噪音再逐步增加更多的中间件和业务指标。先把链路弄通再慢慢做厚这个路径是最稳的。我还习惯在夜莺上建一块“告警统计”大盘用来汇总每天、每周的告警数量、Top告警对象、告警恢复耗时。通过这个大盘能比较直观地发现哪些机器总是出问题、哪些告警规则一直在吵但没人处理然后定期做一轮治理。监控不是用来“吓人”的它是帮你提前发现风险的信号系统。希望这套夜莺加categraf的方案能让你在遇到故障的时候少一点手忙脚乱多一点从容排查的底气。