技术精进

0成本搭建监控：别让服务器在凌晨3点叫醒你

你有没有过这样的经历：接到老板电话问“为什么网站打不开了”，你却还在一脸懵地回答“我看看”？或者，系统突然变慢，你只能靠 top 命令盯着跳动的数字，凭感觉猜测是数据库锁了还是内存漏了？

配图

我曾经也是这样。直到三年前的一个凌晨3点，我们的支付服务因为磁盘写满而挂机，而我是在客户投诉两小时后才被电话轰炸醒的。那天之后，我意识到：没有监控的系统，就像在高速公路上闭眼开车。

很多人觉得搭建监控系统很重、很贵、很复杂。其实，对于中小团队或个人开发者，用 Prometheus + Grafana 这一套“黄金搭档”，15分钟就能搭建起一套可视化的监控大屏。

今天我就把这套我用了两年、改了无数个版本的“保姆级”方案分享给你。

一、 为什么选 Prometheus？别被“推”和“拉”绕晕了

在讲怎么做之前，得先解决一个认知误区。很多运维新人还在纠结 Zabbix 和 Prometheus 谁更好。

我曾在一个拥有50台服务器的项目中强推 Zabbix，结果光是配置 Agent 主动推送和复杂的模板，就耗费了我整整一周。后来切换到 Prometheus，才发现它的Pull（拉取）模式有多香。

简单来说，Prometheus 就像一个勤劳的“查表员”，每隔几秒钟去各个服务（Exporter）那里抄一次水表（数据），然后存起来。这带来两个巨大的好处：

  1. 服务解耦：被监控的服务不需要知道监控中心在哪里，只管暴露接口就行。
  2. 极简部署：只要网络通，配一行 IP 就能抓数据。

实操建议：对于刚起步的团队，不要搞复杂的二进制安装，Docker 是唯一的真理。

下面这份 docker-compose.yml 是我目前生产环境在用的精简版，直接复制就能跑：

version: '3.8'

services:
  # 监控核心：Prometheus
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"
    restart: always

  # 数据展示：Grafana
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana-storage:/var/lib/grafana
    restart: always

  # 采集本机数据：Node Exporter
  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    ports:
      - "9100:9100"
    restart: always

volumes:
  grafana-storage:

把这个文件保存，并在同级目录下创建一个基础的 prometheus.yml 配置文件：

global:
  scrape_interval: 15s # 每15秒抄一次表

scrape_configs:
  - job_name: 'my-server'
    static_configs:
      - targets: ['node-exporter:9100'] # 告诉它去哪里抄表

在终端敲下 docker-compose up -d，你的监控系统就已经活了。

二、 数据采集：让服务器“开口说话”

系统跑起来了，但现在的 Prometheus 还是个瞎子。我们需要给服务器装上“传感器”，也就是 Exporter。

还记得我上面配置里的 node-exporter 吗？它就是负责采集服务器基础指标（CPU、内存、磁盘、网络）的传感器。

真实案例： 上个月，我们的测试环境每到下午4点就卡顿。开发说是网络问题，运维说是代码问题。

我打开 Prometheus 的数据面板，发现 node_memory_MemAvailable_bytes 指标在每天下午3点55分呈断崖式下跌。结合时间点，我们发现是一个定时跑批任务把内存吃光了。

如果没有这个数据支撑，我们可能还在无休止的“甩锅”会议中。

这里的核心逻辑是：不要猜，看数据。

配图

除了基础的 Node Exporter，你还需要关注你的业务组件：

  • 数据库：用 mysqld_exporter 监控慢查询、连接数。
  • 容器：用 cAdvisor 监控 Docker 容器的资源使用。
  • 应用：如果是 Spring Boot，直接开启 Actuator；如果是 Go，用官方 SDK 埋点。

思考题：你现在的系统里，有没有哪个核心指标是完全黑盒的？如果它现在挂了，你多久能发现？

三、 颜值即正义：用 Grafana 讲故事

Prometheus 自带的界面非常简陋，简直是“程序员审美”的巅峰。这时候 Grafana 就登场了。

Grafana 的强大之处不在于它能画图，而在于它的社区生态。你根本不需要自己从零开始设计图表。

我刚开始用 Grafana 时，花了一整天时间去研究怎么写 PromQL（查询语言）来画一个 CPU 使用率的饼图，结果丑得没法看。后来我发现了 Dashboard ID 这个神器。

实操步骤：

  1. 登录 Grafana (默认账号密码都是 admin)。
  2. 点击左侧菜单 Dashboards -> Import。
  3. 输入 ID 1860（这是一个经典的 Linux 主机监控模板，备受好评）。
  4. 点击 Load，选择你的 Prometheus 数据源。

瞬间，一个包含 CPU 负载、内存水位、磁盘 IO、网络流量的专业大屏就呈现在你面前。

避坑指南： 不要迷恋那种“看起来很酷炫但没啥用”的3D图表。 我曾经为了在大屏上展示一个旋转的地球模型浪费了大量资源，结果排查故障时，最有用还是那几条简单的折线图。监控是为了发现问题，不是为了做科幻电影特效。

每逢周五下午发版前，我都会习惯性地把 Grafana 的时间范围调成 Last 1 hour，盯着那个错误率的红线。只要它不动，我就能安心过周末。

四、 告警配置：狼来了的故事别重演

最后，也是最重要的一环：告警。

监控大屏做得再好看，你也无法24小时盯着它。你需要 Prometheus 在出问题时主动通知你。但这里有一个巨大的坑——告警风暴。

我见过一个团队的运维群，每天几百条告警信息：“CPU 使用率超过 80%”、“内存使用率超过 70%”。刚开始大家还紧张一下，后来发现大部分都是短暂的波动，根本不需要处理。

结果有一天，数据库真的挂了，告警混在那几百条垃圾信息里，没人看见。

我的血泪经验总结出三条原则：

  1. 少即是多：只告警需要立刻介入的问题。磁盘快满了？告警。CPU 飙高但服务没挂？记录日志就行，别发短信。
  2. 分级处理：把告警分为 P0（宕机，打电话）、P1（性能下降，发钉钉/企业微信）、P2（资源预测，发邮件）。
  3. 附带上下文：告警信息里别只发“CPU 高”，要带上“当前值 95%，持续时间 5分钟，涉及主机 xxx”。

配置告警并不难，Prometheus 配合 Alertmanager 可以轻松实现对接钉钉、飞书或 Slack 机器人。

# 一个简单的告警规则示例
groups:
- name: host-monitor
  rules:
  - alert: HostDown
    expr: up == 0
    for: 1m # 只有挂了超过1分钟才叫，防止网络抖动误报
    labels:
      severity: critical
    annotations:
      summary: "服务器  挂了！"

写在最后

搭建一套监控系统，技术上真的不难，难的是从被动救火到主动预防的思维转变。

当你看着 Grafana 面板上那条平稳的绿色曲线，或者在用户投诉前就收到了磁盘预警并处理完毕时，那种掌控感会让你觉得，所有的折腾都是值得的。

现在，给自己定个小目标：

  1. 本周内，找一台测试服务器，用 Docker 跑起 Prometheus 和 Grafana。
  2. 导入 ID 为 1860 的模板，看看你的服务器到底在忙什么。
  3. 设置一条最简单的规则：当机器关机时，给你的飞书/钉钉发一条“救命”。

别等到服务器再次在凌晨叫醒你，才后悔没有早点迈出这一步。

© 2026 SelfTechHub