结论: 服务器监控工具的主流选择是六类:中小团队且要长期演进首选 Prometheus + Node Exporter + Grafana(资源占用约 500MB 内存起,告警由 Alertmanager 负责);传统 IT 与网络设备多选 Zabbix(自带完整告警与图形,较重);想要五分钟开箱即用选 Netdata(单节点 1~2% CPU 开销);纯探活选 Uptime Kuma(Docker 一行命令,百余 MB);已有阿里云/腾讯云则先用云监控再补自建。截至 2026 年,这套组合仍是业界事实标准。
为什么服务器必须有监控工具
没有监控的服务器运维,本质上是"出事后才知道出事了"。用户投诉网站打不开的时候,你既不知道问题从几点开始,也不知道当时的 CPU、内存、磁盘 IO 与连接数是多少,只能凭空猜测。而监控工具解决的是三件事:把过去的曲线存下来用于回溯、把当前的异常及时通知到人、把未来的容量趋势提前暴露。
一个常见的误解是"我用云厂商自带的监控就够了"。云监控确实覆盖了 CPU、带宽、磁盘这类宿主机层面的指标,但它看不到机器内部:Nginx 的活跃连接数、MySQL 的慢查询、Redis 的命中率、某个 Java 进程的堆内存、某个日志目录的增长速度,这些都必须靠安装代理(Agent)或导出器(Exporter)才能采集。所以正确的做法是云监控兜底 + 自建监控补充,两者重叠是正常的。
选型的第一个分水岭是规模。5 台以内服务器,追求"今晚就能装上"优先;5 到 50 台,指标统一和时间序列数据库的价值开始显现,Prometheus 优势明显;50 台以上或涉及交换机、存储、UPS 等传统 IT 资产,Zabbix 的设备模板与自动发现会更省事。第二个分水岭是告警渠道,如果团队用飞书/钉钉/企业微信,需要考虑工具的 Webhook 支持度。
六大工具横向对比
结论先行:下表把你最该关心的四个维度列清楚——部署难度、资源占用、告警能力、适用场景,按这张表选型基本不会错。
| 工具 | 部署难度 | 资源占用(采集端) | 告警能力 | 适用场景 |
|---|---|---|---|---|
| Prometheus + Grafana | 中(需配 exporter、rule 文件) | Node Exporter 约 20MB 内存、<1% CPU;服务端 2GB 内存起 | Alertmanager 支持分组、抑制、静默,规则用 PromQL 编写 | 5 台以上、容器/K8s 环境、要做长期趋势分析 |
| Zabbix | 中高(需建库、配模板、调 agent) | Agent 约 30MB 内存;Server 端 4GB 内存 + MySQL 起步 | 内置触发器、依赖、升级通知,功能最完整 | 传统 IT、混合了交换机/存储/Windows 的环境 |
| Netdata | 极低(一行脚本) | 单节点约 100MB 内存、1~2% CPU | 内置 300+ 告警规则,支持 20+ 通知渠道 | 单机快速排障、临时诊断、微小团队 |
| Node Exporter | 低(二进制直跑) | 15~25MB 内存,几乎不计 | 本身不告警,只暴露 :9100/metrics | 作为 Prometheus 的标准采集端,必配 |
| 云厂商监控 | 极低(控制台开启) | 采集插件约 50MB 内存 | 支持短信/电话/机器人,与工单体系打通 | 云服务器基础设施层监控的兜底底盘 |
| Uptime Kuma | 极低(Docker 一条命令) | 约 150MB 内存 | 支持 HTTP/TCP/Ping/关键字检测的存活告警 | 站点可用性探活、SSL 证书到期提醒、状态页 |
补充两点容易被忽略的性能数据:一是 Prometheus 的本地存储约为每百万时间序列每秒 1~2 字节,单台服务器 1000 个指标、30 天留存大约需要数 GB 空间,留存时间越长成本越高,可通过 remote_write 接入 VictoriaMetrics 或 Thanos 降低成本;二是 Netdata 虽然轻,但默认开启 per-second 采集,一台机器上装了多实例时要注意 19999 端口冲突。
Prometheus + Node Exporter + Grafana 部署
结论先行:这是最值得投入的一套组合,一次部署长期受益。安装顺序固定为 Node Exporter(采集)→ Prometheus(存储与告警)→ Alertmanager(通知)→ Grafana(展示)。
第一步,在所有被监控机器上安装 Node Exporter(截至 2026 年稳定版本为 1.8.x):
# 下载并解压 Node Exporter 1.8.2
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar xf node_exporter-1.8.2.linux-amd64.tar.gz
sudo mv node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/
# 创建 systemd 服务
sudo tee /etc/systemd/system/node_exporter.service > /dev/null <<'EOF'
[Unit]
Description=Prometheus Node Exporter
After=network.target
[Service]
User=nobody
ExecStart=/usr/local/bin/node_exporter \
--web.listen-address=:9100 \
--collector.systemd \
--collector.processes \
--no-collector.wifi
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
curl -s localhost:9100/metrics | grep node_load1第二步,在监控机安装 Prometheus 并接入被监控节点:
wget https://github.com/prometheus/prometheus/releases/download/v2.54.1/prometheus-2.54.1.linux-amd64.tar.gz
tar xf prometheus-2.54.1.linux-amd64.tar.gz
sudo mv prometheus-2.54.1.linux-amd64 /opt/prometheus
sudo tee /opt/prometheus/prometheus.yml > /dev/null <<'EOF'
global:
scrape_interval: 15s
evaluation_interval: 15s
alerting:
alertmanagers:
- static_configs:
- targets: ['localhost:9093']
rule_files:
- /opt/prometheus/rules/*.yml
scrape_configs:
- job_name: 'node'
static_configs:
- targets:
- '10.0.0.11:9100'
- '10.0.0.12:9100'
labels:
env: production
EOF
sudo tee /etc/systemd/system/prometheus.service > /dev/null <<'EOF'
[Unit]
Description=Prometheus Server
After=network.target
[Service]
ExecStart=/opt/prometheus/prometheus \
--config.file=/opt/prometheus/prometheus.yml \
--storage.tsdb.path=/opt/prometheus/data \
--storage.tsdb.retention.time=30d \
--web.listen-address=:9090
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable --now prometheus第三步,配置告警规则(PromQL 示例):
# /opt/prometheus/rules/node.yml
groups:
- name: node-health
rules:
- alert: NodeDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "实例 {{ $labels.instance }} 已失联 1 分钟"
- alert: HighCPUUsage
expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
for: 5m
labels:
severity: warning
annotations:
summary: "{{ $labels.instance }} CPU 使用率持续 5 分钟高于 85%"
- alert: DiskWillFillIn4Hours
expr: predict_linear(node_filesystem_free_bytes{fstype!~"tmpfs"}[6h], 4*3600) < 0
for: 10m
labels:
severity: critical
annotations:
summary: "{{ $labels.mountpoint }} 按当前增速 4 小时内将写满"最后安装 Grafana 并导入 Node Exporter 官方仪表盘(Dashboard ID 1860):
sudo apt install -y grafana
sudo systemctl enable --now grafana-server
# 默认监听 :3000,初始账号 admin / admin,登录后立即改密码
# 添加数据源:http://localhost:9090,然后 Import 面板 ID 1860Netdata 与 Uptime Kuma 的极简方案
结论先行:如果你只想要"五分钟内看到这台机器的所有指标",Netdata 是唯一答案;如果你只想知道"我的网站有没有挂",Uptime Kuma 是唯一答案。两者资源开销都很小,完全可以和 Prometheus 并存。
Netdata 一行装完,自带 Web 面板与每秒级刷新:
# 官方一键脚本(推荐用 --stable-channel)
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry
sudo systemctl enable --now netdata
# 仅本机访问时改为监听回环,需要用 SSH 隧道访问
sudo sed -i 's/# bind to = \*/bind to = 127.0.0.1/' /etc/netdata/netdata.conf
sudo systemctl restart netdata
curl -s localhost:19999/api/v1/info | head -5Uptime Kuma 用 Docker 部署最省事,适合做对外探活与状态页:
docker run -d --restart=always -p 3001:3001 \
-v uptime-kuma:/app/data \
--name uptime-kuma \
louislam/uptime-kuma:1
# 或 docker compose
cat > docker-compose.yml <<'EOF'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
restart: always
ports:
- "3001:3001"
volumes:
- /opt/uptime-kuma/data:/app/data
- /var/run/docker.sock:/var/run/docker.sock
EOF
docker compose up -d关键提醒:Uptime Kuma 绝对不要只装在被监控的同一台机器上——本机挂了探活也跟着挂,等于没有探活。建议部署在异地的一台廉价 VPS 上,监测间隔设 60 秒,连续失败 2 次才告警,避免网络抖动造成误报。
Zabbix 与云厂商监控的定位
结论先行:Zabbix 适合"要监控的不只是 Linux 服务器"的场景,云厂商监控适合拿来兜底基础设施层,二者不是替代关系。
Zabbix 6.4/7.0 LTS 的典型安装(Server + MySQL + Agent2):
# Rocky Linux 9 / RHEL 9,Zabbix 7.0
rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm
dnf clean all
dnf install -y zabbix-server-mysql zabbix-web-mysql zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2
# 建库(MySQL 8.4)
mysql -uroot -p -e "create database zabbix character set utf8mb4 collate utf8mb4_bin;
create user zabbix@localhost identified by '<你的密码>';
grant all privileges on zabbix.* to zabbix@localhost;"
zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix
sed -i 's/^# DBPassword=/DBPassword=<你的密码>/' /etc/zabbix/zabbix_server.conf
systemctl enable --now zabbix-server zabbix-agent2 nginx php-fpm云监控(阿里云云监控 / 腾讯云可观测平台 / 华为云 CES)的使用要点:
- 安装 Agent 才能拿到内存、磁盘等内部指标:不开插件只有 CPU、带宽、网络包量三项宿主机数据。
- 默认告警粒度多为 5 分钟,对瞬时毛刺不敏感,重要业务要自建补充 15 秒级采集。
- 务必配置超额/异常账单告警:一旦机器被用作肉鸡发包,账单往往先于指标异常出现。
- 利用事件通知:宿主机计划迁移、云盘性能降级等事件只有控制台能推送,要接出来。
一个值得采纳的组合策略是用云监控做"底线"(机器是否活着、是否欠费),用 Prometheus 做"深度"(业务与中间件指标),用 Uptime Kuma 做"外部视角"(用户能不能访问),三层互相校验,任何单点失真都会被另外两层发现。
常见误区 / 排错提示
- Node Exporter 起不来,日志报 permission denied:多数是
--collector.systemd需要访问 D-Bus,改为用 root 或去掉该 collector;另外--collector.filesystem在容器里会因挂载命名空间报错,需要加--path.procfs=/host/proc --path.sysfs=/host/sys并把 host 目录挂载进容器。 - Prometheus 9090 端口起不来,报 "address already in use":检查是否被其他服务占用;若是配置文件错误则会直接退出,用
/opt/prometheus/promtool check config prometheus.yml先校验语法。 - Grafana 面板无数据但 Prometheus 能查到:九成是数据源 URL 写成了
https或没加端口;剩下一成是时间范围选错。在 Grafana 的 Explore 里先跑通 PromQL 再去面板里排错。 - Grafana 用 admin/admin 长期不改:这是最常见的入侵入口。装完立刻改密码,并禁止 3000 端口对公网开放,用 Nginx 反代加 HTTPS 和认证。
- 告警规则写成"CPU > 80% 立即告警":瞬时峰值会造成大量噪音告警,团队很快会麻木到忽略所有通知。必须加
for: 5m这类持续时间条件,并区分 warning 与 critical 两个级别。 - Zabbix Server 跑几个月后数据库暴涨:未配置历史数据清理(Housekeeping),history 表会达到几十 GB。应在安装时就开启分区或设置
HistoryStorageDateIndex,把趋势数据保留 90 天、详细历史保留 7~14 天。 - 只监控不演练:告警配完从不测试,等真出事发现 Webhook 早就失效了。建议每月手动触发一次测试告警,验证整条通知链路。
常见问题(FAQ)
只有一两台服务器,需要上 Prometheus 吗?
不必。1~2 台机器用 Netdata 单机版加 Uptime Kuma 探活就够了,10 分钟装完,资源开销不到 200MB。超过 3 台且需要历史趋势回溯、或者开始用 Docker/K8s 时,再迁移到 Prometheus 才划算,届时 Node Exporter 已经装好,迁移成本很低。
Prometheus 和 Zabbix 应该选哪个?
看监控对象:如果主要是 Linux 服务器 + 容器 + 中间件指标、需要灵活查询,选 Prometheus;如果需要一并监控交换机、存储、UPS、Windows 域控等传统设备,且希望有成熟模板和自动发现,选 Zabbix。两者都能覆盖彼此的基本场景,但对各自优势场景的支持深度差距很大。
监控工具本身会不会拖慢服务器?
会,但量级很小。Node Exporter 常驻约 20MB 内存、CPU 占用通常低于 1%;Netdata 单节点约 100MB 内存、1~2% CPU(取决于采集频率)。真正的风险是误配:把 scrape_interval 设成 1 秒、开启大量高基数指标(如按 URL 或用户 ID 打标签),会让时间序列数量爆炸,反而拖垮 Prometheus 服务端。
告警应该设置几个才合适?
遵循"宁少勿多"原则。建议每个角色只配 5~8 条核心告警:实例失联、CPU 持续高、磁盘将满、内存不足、服务端口探活失败、证书 30 天内到期、备份失败、错误日志激增。超过 20 条告警的规则文件,通常意味着把监控指标误当成了告警规则,应设置分级与静默。
免费的服务器监控工具够用吗?
对绝大多数中小企业完全够用。Prometheus、Grafana、Zabbix、Netdata、Uptime Kuma 均为开源免费,功能覆盖磁盘预测(predict_linear)、可用性探活、多渠通知道等核心需求。商业版主要补足的是托管运维、长期存储、安全合规报表,按团队精力而非功能缺口决定是否付费。
告警应该发到哪里才不会被忽略?
关键告警(宕机、磁盘将满)必须能触达手机且要升级机制——比如企业微信/钉钉机器人加电话告警双通道,10 分钟未响应自动升级到负责人。日常警告类只推送到群即可。务必区分级别,否则关键告警会被普通告警淹没。
企业QQ咨询




