小微企业一体化监控实战：Prometheus + node_exporter + Grafana 监控主机、服务与设备并微信告警

摘要： 门店和工厂的服务器、工控机、网络设备往往“出事才知道”。用 Prometheus 拉取指标、Grafana 出图、Alertmanager 发微信，给小企业搭一套低成本、可扩张的指标监控与告警体系。

为什么小企业也需要指标监控

很多小微企业只在系统宕机、监控画面黑掉时才发现异常，此时损失已经发生。此前我们讲过 Uptime Kuma 做存活探测、ThingsBoard 做设备遥测，但它们都偏“黑盒”或“设备侧”。真正能提前发现“磁盘快满”“内存泄漏”“接口变慢”的，是基于指标的趋势监控，而 Prometheus 正是这一领域的开源事实标准。

它的核心思路是“拉模型”：Prometheus 主动去各被监控节点抓指标，存进自带的时间序列数据库（TSDB），再用 PromQL 查询，Grafana 负责把查询结果画成图，Alertmanager 在规则命中时发告警。整套栈都能用 Docker 跑在一台两核四 G 的小服务器甚至 NAS 上。

用 Docker Compose 起一套

核心组件是三个容器：prometheus、node_exporter、grafana。prometheus 的配置文件 prometheus.yml 里用 scrape_configs 声明抓取目标，例如抓取本机 node_exporter 的 9100 端口、抓取业务侧自定义的 exporter。node_exporter 需要装在被监控的主机上：Linux 直接下载二进制用 systemd 托管，Windows 则改用 wmi_exporter；它们把 CPU、内存、磁盘、网络、温度等系统指标以 HTTP 接口暴露出来。

Grafana 容器启动后，添加 Prometheus 为数据源（填 http://prometheus:9090），再导入官方 node_exporter 仪表盘模板（ID 1860）就能立刻看到主机曲线。所有端口只对内网开放，如需外网访问，走 Nginx Proxy Manager 反代并加 Basic Auth 或 SSO，切勿把 9090、3000 直接暴露公网。

到底监控什么

主机层面最该盯的是磁盘剩余、内存压力、CPU 负载和开机时长。一条实用的告警规则是：当某分区可用空间低于 10% 并持续 5 分钟就报警——这能避免“日志写满根分区导致服务崩掉”这类经典事故。

网络与服务层面，用 blackbox_exporter 对门店的官网、内部接口做 HTTP 探针，同时做 ICMP 探测判断链路通断，还能顺带监控 SSL 证书剩余天数，提前一周提醒续签。业务层面则可以自己写 exporter，把“在线设备数”“MQTT 消息速率”“今日订单数”等营业指标也纳入同一套看板，老板和运维看同一份数据。

告警路由与企业微信通知

告警规则写在 alert.rules 里，例如磁盘表达式 100 * (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) > 90，配合 for: 5m 防止抖动误报。Alertmanager 负责把触发的告警路由出去：邮件发运维，企业微信机器人 webhook（markdown 类型）发到值班群，并按 warning、critical 分级——只有 critical 才在半夜打电话或 @ 到人。

为了避免告警轰炸，一定要配置“静默”和分组：同一台机器同时触发三条规则，合并成一条消息；维护窗口期提前静默。很多团队一开始不设分组，半夜被几十条重复消息吵醒后直接关掉告警，反而失去了监控意义。

常见坑与边界

TSDB 的磁盘占用随采样间隔和保留期线性增长，小环境把 retention 设成 15 到 30 天足够，长期存储可留到以后上 Thanos。最需要警惕的是“标签基数爆炸”：如果把用户 ID、订单号这类高基数的值做成标签，TSDB 会瞬间被拖垮，正确做法是把这类信息放在样本值而不是标签上。最后，所有被监控主机务必统一走 NTP 时间同步，否则时序对账和告警时间会错乱。

小结

Prometheus + Grafana 这套组合，让小企业用极低的成本获得原本只有大厂才有的指标可观测能力。它和已有的 Uptime Kuma、ThingsBoard 互补：一个管“活着没”，一个管“设备数据”，一个管“趋势与根因”，三者合起来才是完整的运维防线。