Linux服务器监控方案
核心理念与目标
在开始实施监控之前,首先要明确监控的目的：
（图片来源网络，侵删）
- 预防性维护：在问题发生前发现潜在风险（如磁盘空间即将写满、内存泄漏），避免业务中断。
- 快速故障定位：当故障发生时，能够迅速定位问题根源（是CPU、内存、网络还是应用本身），缩短故障恢复时间。
- 性能优化：通过分析历史数据，了解系统负载瓶颈，为硬件升级或应用调优提供数据支持。
- 容量规划：预测资源使用趋势，为未来的业务增长提前做好资源准备。
- 安全审计：监控异常登录、高危命令执行等行为，保障服务器安全。
核心监控指标
一个完善的监控方案需要覆盖从底层硬件到上层应用的各个层面。
操作系统层
| 指标类别 | 具体指标 | 说明 | 阈值建议 |
|---|---|---|---|
| CPU | 使用率 | 整体CPU使用情况，持续高于80%需要关注。 | > 80% (告警), > 90% (严重告警) |
| 负载 | 1分钟、5分钟、15分钟的平均负载，核心指标，反映CPU繁忙程度。 | > CPU核心数 * 0.7 (告警), > CPU核心数 * 1.0 (严重告警) |
|
| 僵尸进程 | 数量过多可能表示应用有bug。 | > 5 |
|
| 等待I/O的进程 | iowait高，说明CPU在等待磁盘或网络，可能是磁盘瓶颈。 |
持续 > 30% |
|
| 内存 | 已用内存 | 应用实际使用的内存量。 | - |
| 空闲内存 | 系统可立即使用的内存。 | < 200MB (告警) |
|
| 可用内存 | free + buffers + cached，更真实的可用内存。 |
< 500MB (告警) |
|
| 缓冲/缓存 | 用于提升I/O性能，被占用是正常的。 | - | |
| 交换分区使用率 | 使用swap说明物理内存不足，会严重影响性能。 | > 20% (告警), > 50% (严重告警) |
|
| 磁盘 | 磁盘空间使用率 | 根目录 , /var, /home等分区的使用情况。 |
> 80% (告警), > 90% (严重告警) |
| 磁盘I/O | 每秒读写次数，读写带宽，用于判断磁盘是否繁忙。 | 根据磁盘类型（SSD/HDD）设定基线，突增或持续高位告警 | |
| 磁盘I/O等待时间 | await指标，越高说明I/O响应越慢。 |
> 100ms (告警) |
|
| 网络 | 网络流量 | 入站/出站带宽使用率，防止流量跑满影响业务。 | > 80% (告警) |
| 连接数 | ESTABLISHED连接数，TIME_WAIT连接数，高并发服务需关注。 |
根据业务设定基线 | |
| 网络包错误/丢弃 | rx_errors, tx_errors, rx_dropped, tx_dropped，网络硬件或驱动问题。 |
> 0 (持续出现则告警) |
|
| 进程 | 关键进程存活 | 如Nginx, MySQL, Redis等。 | 进程不存在 (严重告警) |
| 进程CPU/内存占用 | 单个进程资源使用过高。 | 根据业务设定基线 | |
| 系统 | 系统负载/运行时间 | uptime，了解系统是否重启过。 |
- |
| 登录用户/失败登录 | last命令，发现异常登录行为。 |
有非常规IP登录 (安全告警) |
|
| 系统日志 | /var/log/messages, /var/log/secure等，监控关键词，如"error", "failed", "denied"。 |
日志中出现错误关键词 (告警) |
应用服务层
- Web服务器 (Nginx/Apache):
- Nginx: 活跃连接数、连接总数、请求数/秒、后端服务器响应时间、5xx错误率。
- Apache: 访问量、并发连接数、服务器响应时间、CPU/内存使用率。
- 数据库:
- MySQL: 查询QPS/TPS、慢查询数、连接数、InnoDB缓冲池命中率、主从复制延迟。
- Redis: 连接数、内存使用量、键值对数量、命令执行数/秒、持久化耗时。
- 中间件:
- Kafka: 消息堆积量、分区Leader选举频率。
- RabbitMQ: 队列深度、消息投递速率。
业务层
- API响应时间: 核心接口的平均响应时间和P95/P99响应时间。
- 业务成功率: 如订单创建成功率、支付成功率。
- 核心业务指标: 如日活用户数、在线用户数。
监控工具选型与方案
根据复杂度和成本,监控方案可以分为三个层次。
轻量级方案 - 单机/小规模团队
适合少量服务器,追求快速部署和简单使用。
- 工具组合:
- 数据采集:
node_exporter(Prometheus官方组件，采集服务器指标) - 数据存储与展示:
Prometheus+Grafana- Prometheus: 负责从
node_exporter拉取数据，并存储在时序数据库中。 - Grafana: 从Prometheus读取数据，并通过强大的仪表盘进行可视化展示。
- Prometheus: 负责从
- 数据采集:
- 优点:
- 开源免费,社区活跃。
- 部署相对简单,学习曲线平缓。
- 可视化效果出色,模板丰富。
- 缺点:
- 自身不告警,需配合Alertmanager实现告警。
- 对大规模集群的自动发现和配置管理稍显复杂。
- 部署:
- 在每台Linux服务器上安装并运行
node_exporter。 - 部署一台
Prometheus服务器，配置其scrape_configs，指向所有node_exporter的地址。 - 部署一台
Grafana服务器，连接到Prometheus数据源。 - 在Grafana中导入官方或社区提供的Linux服务器监控Dashboard模板。
- 在每台Linux服务器上安装并运行
中大型方案 - 企业级/自动化
适合几十到几百台服务器,需要自动化、高可用和完善的告警体系。
（图片来源网络，侵删）
- 工具组合:
- 数据采集:
node_exporter(服务器),mysqld_exporter(MySQL),redis_exporter(Redis) 等。 - 数据存储:
Prometheus(核心时序数据库) +VictoriaMetrics(作为长期存储或Prometheus的远程存储，性能更高)。 - 服务发现:
Consul或Kubernetes(自动发现新增的服务器或Pod)。 - 告警:
Alertmanager(处理Prometheus发来的告警，进行路由、去重、分组后发送到邮件、钉钉、企业微信、Slack等)。 - 可视化:
Grafana。 - 日志监控:
Loki+Promtail(Prometheus生态的日志解决方案，轻量级)。
- 数据采集:
- 优点:
- 功能全面,覆盖指标、日志、告警。
- 高可用架构,可横向扩展。
- 强大的自动化能力（服务发现）。
- 完善的告警生命周期管理。
- 缺点:
组件多,架构复杂，部署和维护成本较高。
商业云方案 - 开箱即用/免运维
适合不想投入精力维护监控系统,追求稳定和快速迭代的团队。
- 主流产品:
- Datadog: 功能强大，APM、基础设施、日志、安全一体化，SaaS模式。
- New Relic: 同样是APM领域的佼佼者，基础设施监控也很完善。
（图片来源网络，侵删）
