Ubuntu Overlay 监控与告警实现
一、监控目标与总体思路
- 覆盖三类关键对象：
- OverlayFS 行为：目录/文件的创建、删除、修改、移动等事件，用于发现异常写入、可疑覆盖等。
- 主机与容器资源：CPU、内存、I/O、网络、温度等，用于识别资源瓶颈对 Overlay 的影响。
- 服务与进程健康：关键进程存活、端口可达、日志异常等，用于业务可用性保障。
- 建议采用“采集 + 存储/可视化 + 告警路由”三层架构：事件采集（如 inotify）、指标采集（如 node_exporter/Prometheus）、可视化（如 Grafana）、告警路由（如 Alertmanager/邮件/企业微信/钉钉）。
二、快速落地方案 Prometheus + Alertmanager + Grafana
- 组件与职责
- node_exporter：暴露主机层指标（CPU、内存、磁盘 I/O、网络、温度等）。
- Prometheus：抓取指标与规则评估，配置告警规则文件。
- Alertmanager：去重、分组、静默与路由，对接邮件/Webhook。
- Grafana：构建 Overlay 相关仪表盘（如 Overlay 挂载点容量、I/O、事件计数等）。
- 关键配置示例
- Prometheus 抓取与告警规则
- /etc/prometheus/prometheus.yml
- global: scrape_interval: 15s
- rule_files: - “rules/overlay.rules.yml”
- alerting: alertmanagers: - static_configs: - targets: [‘localhost:9093’]
- /etc/prometheus/rules/overlay.rules.yml
- groups:
- name: overlay
rules:
- alert: OverlayHighIO
expr: rate(node_disk_read_seconds_total{device=~“.overlay.”}[5m]) > 0.5 or rate(node_disk_write_seconds_total{device=~“.overlay.”}[5m]) > 0.5
for: 5m
labels: severity: warning
annotations:
summary: “Overlay 设备 {{ $labels.device }} 读写等待偏高”
description: “5 分钟平均读写等待 {{ $value | humanize }} 超过阈值 0.5”
- alert: OverlayInodeUsageHigh
expr: 1 - node_filesystem_files_free{fstype=“overlay”, mountpoint=“/var/lib/docker/overlay2”} / node_filesystem_files{fstype=“overlay”, mountpoint=“/var/lib/docker/overlay2”} > 0.8
for: 10m
labels: severity: critical
annotations:
summary: “Overlay 挂载点 {{ $labels.mountpoint }} Inode 使用率 > 80%”
- Alertmanager 邮件路由
- /etc/alertmanager/alertmanager.yml
- global:
smtp_smarthost: ‘smtp.example.com:587’
smtp_from: ‘alertmanager@example.com’
smtp_auth_username: ‘alertmanager’
smtp_auth_password: ‘password’
smtp_require_tls: true
- route:
receiver: ‘email’
- receivers:
- name: ‘email’
email_configs:
- 启动与验证
- sudo systemctl start prometheus alertmanager
- 在 Prometheus Web（默认 :9090）检查 Targets 与 Alert 页面，Grafana（默认 :3000）添加 Prometheus 数据源并导入/构建仪表盘。
三、OverlayFS 事件监控与日志告警
- 基于 inotify 的文件事件监控
- 安装与最小脚本
- sudo apt-get install inotify-tools
- monitor_overlayfs.sh
- #!/bin/bash
WATCH_DIR=“/var/lib/docker/overlay2”
inotifywait -m -r -e create -e delete -e modify -e moved_to -e moved_from --format ‘%w%f %e’ “$WATCH_DIR”
- 建议做法
- 将脚本输出接入 rsyslog 或 Promtail+Loki，用 Grafana 做可视化与计数告警（如短时间内大量创建/删除）。
- 对敏感目录（如 /var/lib/docker/overlay2）监控时注意权限与性能，必要时采用采样或白名单路径。
- 基于 systemd 的服务健康与日志告警
- 服务存活：使用 systemd 的 Restart=always 与探针，结合 Prometheus 的 node_systemd_unit_state{state=“active”} 做存活告警。
- 日志异常：用 journalctl -u -f 或 Promtail+Loki 采集服务日志，在 Grafana 建立错误关键字（如 “panic”、“timeout”）的告警规则。
四、可选方案与对比
| 方案 |
适用场景 |
优点 |
局限 |
| Prometheus + Alertmanager + Grafana |
需要指标化、可视化与灵活路由的服务器/容器环境 |
生态成熟、告警强大、可横向扩展 |
部署与学习成本相对更高 |
| Nagios |
传统 IT 监控、需要快速邮件/短信告警 |
插件丰富、部署简单 |
界面与扩展现代化程度较弱 |
| Zabbix |
一体化平台、需要较强自动发现与资产管理 |
自带前端、告警与可视化一体 |
资源占用相对更高、复杂场景配置繁琐 |
| Monit |
单机/少量主机的轻量守护与告警 |
配置直观、易上手 |
不适合大规模与复杂依赖关系 |
以上方案均可在 Ubuntu 上部署，选择时以规模、可维护性与团队经验为准。
五、关键指标与阈值建议
- Overlay 设备 I/O 等待：rate(node_disk_read/write_seconds_total{device=~“.overlay.”}[5m]) 持续偏高（如 > 0.5）可能预示底层存储瓶颈或异常写入。
- Inode 使用率：1 - free/files 在 Overlay 挂载点（如 /var/lib/docker/overlay2）超过 80% 需尽快清理或扩容，避免容器/镜像无法创建。
- 实例存活：up == 0 持续 1m 触发 Pager/电话级别告警（InstanceDown）。
- 事件异常频率：短时间内大量 create/delete/modify 事件（来自 inotify/Loki）可提示异常行为或配置问题，建议结合基线设定阈值。
