服务器监控这套东西，到底该自己搭还是买现成的？
机器上线的头一个月，多数人靠 SSH 上去敲 top 和 df 就能过日子。等到业务跑起来，半夜磁盘写满、内存被某个进程慢慢吃光、带宽被爬虫跑满，这些事不会挑你醒着的时候发生。真正让人难受的不是故障本身，是故障发生时你最后一个知道。监控要解决的就是这件事：让机器出问题的时候，先通知你，而不是等用户来投诉。
下面按「先决定要不要自建、再决定装什么、最后决定告警怎么发」的顺序讲，中间会说到几个具体的取舍点。
先算一笔账：自建监控省下的钱够不够折腾
自建监控的成本不只是那台机器的钱。Zabbix 这类传统方案，服务端加数据库，一台 4 核 8G 的机器跑几十个节点还算轻松，节点上百之后数据库的写入压力就上来了，通常得把 MySQL 单独拆出去。Prometheus 走的是拉取模型，单机在 4 核 8G 上监控几十到一百多个 target 问题不大，但它的本地 TSDB 对磁盘 IO 有要求，机械盘上跑久了查询会明显变慢。
如果业务本身就跑在香港服务器上，再单独开一台低配机器放监控是最省心的做法。监控机和被监控机分开，机器挂了监控也跟着挂，这种自建等于白搭。
商用 SaaS 监控的账要反过来算。按主机数收费，一台机器一个月几美元到十几美元不等，一百台机器一年下来是笔不小的开销。好处是告警通道、历史数据、面板全都不用你管，出问题直接找厂商。节点少的时候，商用方案反而更划算；节点上了规模，自建的成本优势才体现出来。
- 节点数在 10 台以内：直接用商用，省下的时间比省下的钱值钱
- 节点数 30 到 100 台：自建 Prometheus 加 Grafana，一台 4 核 8G 够用
- 节点数上百：要么上分布式方案，要么接受商用按量付费
采集层选什么，取决于你要看的是机器还是业务
机器层面的指标，CPU、内存、磁盘、网络这四项是底线，node_exporter 装上去就有。这里有个坑：默认采集间隔 15 秒，很多人图省事改成 5 秒，结果磁盘写入量翻三倍，监控数据把机器自己的 IO 吃掉了。除非你在排查短时抖动，否则 15 秒到 30 秒的间隔够用。
业务层面的监控是另一回事。接口响应时间、队列积压、连接池占用，这些指标得自己在代码里埋点，或者用中间件自带的 exporter。我一般建议先把机器指标跑稳两周，再动业务指标，不然一上来铺得太开，告警噪音会把真正的问题淹掉。
日志和指标是两套东西。指标看趋势，日志查原因。有人想用一套系统全包，最后往往是两边都不好用。指标用 Prometheus 或 Zabbix，日志另找方案，这个分工别混。
告警阈值怎么定，这一步最容易把人折腾烦
监控装完只是开始，告警设置才是决定这套东西有没有用的地方。阈值定太松，问题来了不响；定太紧，一天收几十条通知，过几天你就把通知静音了，等于没装。
按我的经验，磁盘和内存这类缓慢变化的指标，用「持续 N 分钟超过阈值」来触发，比瞬时超限触发靠谱得多。磁盘使用率到 85% 连续 10 分钟再报，能过滤掉大量日志轮转造成的瞬时尖峰。CPU 负载反过来，短时间的毛刺不用管，持续 5 分钟高于核数才值得看一眼。
告警通道建议至少配两条。一条即时通讯工具，一条短信或者电话。即时通讯工具免费但容易被淹没，真正紧急的故障得靠能把你叫醒的通道。分级也简单：能自愈的走低优先级，需要人介入的走高优先级，别所有告警都往一个群里丢。
监控机本身的配置不用追求高。如果业务主体是香港的服务器，监控机放在同一机房能省掉跨区域网络抖动带来的误报。像 香港服务器10 这种 Platinum-8168*2 / 64G 的配置，拿来跑监控加日志收集绰绰有余，20M 带宽也够指标上报用。真到要监控几百个节点，再考虑把存储单独拆出去。
至于监控哪些机器，一个原则：核心业务的机器全上，测试机看情况。测试机经常重启、经常改配置，指标波动大，全接进来只会增加噪音。
收尾：按节点数对号入座就行
十台以内的机器，买商用监控，一个月几十美元，别自己折腾。三十到一百台，自建 Prometheus 加 Grafana，配一台 4 核 8G 的独立机器专门跑监控，别和业务挤在一起。上百台的话，先想清楚是继续自建还是接受商用按量计费，这个规模下运维人力本身就是成本。
告警阈值从宽到严慢慢调，第一次装完别急着把所有指标都开告警。跑两周，看哪些告警是误报，把阈值往上抬，剩下的才是真正需要你半夜爬起来处理的。