如何做好服务器监控

做好服务器监控，核心目标是在问题影响业务之前发现并定位它。下面从体系设计、指标选型、工具选型、告警策略、可视化与运维闭环几个层面系统讲一下。

一、先明确监控目标与层级

服务器监控不是“装个 agent 就完事”，建议按层级拆开：

1. 基础设施层
   • CPU、内存、磁盘、网络、负载
2. 系统与服务层
   • 进程状态、端口、服务可用性
   • 系统日志（syslog / journald）
3. 应用层
   • API 响应时间、错误率、QPS
   • 中间件（MySQL、Redis、Nginx 等）
4. 业务层
   • 订单量、登录数、支付成功率等

原则：底层保可用，上层保体验

二、关键监控指标（必须覆盖）

1. 资源类

• CPU：使用率、iowait、负载（load average）
• 内存：used / cached / available，避免只看 used
• 磁盘：
  • 使用率（≥85% 预警）
  • inode 使用率
  • 磁盘 IO（await、util）
• 网络：
  • 带宽、丢包、错包、TCP 重传

2. 可用性类

• ping / tcp 端口
• 服务进程是否存在
• 健康检查接口（/health）

3. 异常类

• 系统日志中的 error / OOM / kernel panic
• 重启次数
• 时间漂移（NTP）

三、监控架构建议

常见成熟方案

• Prometheus + Node Exporter + Grafana（最主流）
• Zabbix（传统、功能全）
• OpenTelemetry（未来趋势，偏可观测性）

推荐结构

服务器
  └─ Node Exporter / Agent
        └─ Prometheus（拉取）
              └─ Alertmanager（告警）
              └─ Grafana（展示）

四、告警设计（最重要也最容易做错）

告警原则

• 少而准：宁可漏报，不可轰炸
• 有级别：
  • P0：业务中断
  • P1：资源即将耗尽
  • P2：异常但可控
• 有阈值 + 持续时间
  • 如：CPU > 90% 持续 5 分钟

常见错误

• 只告警不处理
• 所有指标都告警
• 告警无责任人

五、可视化与巡检

• Grafana 面板分组：
  • 概览（一屏看全）
  • 单机详情
  • 历史对比
• 每日/周巡检报告
• 大促前做容量评估

六、进阶：从“监控”到“可观测性”

当服务器变多后，建议补充：

• 日志（Loki / ELK）
• 链路追踪（Trace）
• 容量预测（趋势告警）

七、落地建议（实用顺序）

1. 先装 Node Exporter + Prometheus
2. 配 10 个核心告警
3. 做一屏 Grafana
4. 每月复盘误报/漏报
5. 再逐步加业务指标

如果你愿意，我可以：

• 给你一套 Prometheus 监控服务器的最小配置
• 或按 Linux / 云服务器 / K8s 场景具体讲
• 或帮你设计 告警阈值模板

你目前是单机、集群，还是云环境？