用 docker compose 搭建真正感知集群异常的监控报警体系，关键在于打通“采集—分析—响应”闭环：通过 healthcheck 实现容器自检与自动恢复；cadvisor+prometheus 采集核心资源指标；grafana 可视化+alertmanager 分级告警；loki/fluentd 日志联动实现根因定位。
用 Docker Compose 搭建一套能真正感知集群异常的监控报警体系，关键不在堆组件，而在打通“采集—分析—响应”闭环。核心是让容器自己会“说话”，系统能“听懂”，告警不“乱叫”。
健康检查 + 自动恢复策略
这是最基础也最容易被忽略的一环。光靠外部轮询不够，容器得具备自检能力。
- 在
docker-compose.yml中为每个服务配置healthcheck，比如： -
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]—— 调用应用自身健康端点，比 ping 更可靠 -
interval: 10s、timeout: 5s、retries: 3—— 避免误判，也防止响应慢被过早剔除 -
start_period: 45s—— 给 Spring Boot 等启动慢的服务留出初始化时间 - 配合
restart: on-failure或restart: unless-stopped，让故障容器自动重建，缩短中断时间
Prometheus + cAdvisor 实时指标采集
要感知异常，得先看得见资源水位和行为变化。cAdvisor 是专为容器设计的指标探针，必须与 Prometheus 协同工作。
- cAdvisor 需挂载宿主机关键路径：
/proc、/sys、/var/lib/docker，否则无法读取容器内核级指标（如内存实际使用量、网络包丢弃数） - Prometheus 的
scrape_configs必须包含cadvisorjob，目标地址写cadvisor:8080（Docker 内部 DNS 可解析） - 推荐采集频率设为
15s，平衡实时性与存储压力；对关键服务可单独设更短周期 - 重点关注指标：
container_memory_usage_bytes / container_spec_memory_limit_bytes（内存超限）、container_cpu_usage_seconds_total（CPU 持续飙升）、container_network_receive_errors_total（网络异常）
Grafana 可视化 + Alertmanager 告警路由
可视化不是摆看板，而是把指标变成可操作的线索；告警不是发消息，而是分级分人精准触达。
- Grafana 中创建仪表盘时，避免只放单个容器指标。应叠加“同服务所有实例的 CPU 平均值 + P95 延迟 + 错误率”，一眼识别是否是局部问题还是服务整体退化
- Alertmanager 配置
route规则：开发环境错误告警发 Slack，生产环境 OOM 告警电话+短信+钉钉三通道，静默期避开发布窗口 - 告警规则写法示例（Prometheus rules）：
alert: ContainerOOMKilledexpr: kube_pod_container_status_restarts_total{namespace="prod"} > 0-
for: 1m—— 容器被 OOM Kill 后立即触发，不等“持续两分钟” annotations: {summary: "Pod {{ $labels.pod }} in {{ $labels.namespace }} was OOM killed"}
日志联动分析补全上下文
指标异常往往滞后于日志错误。把日志纳入监控链路，才能快速定位根因。
- 在服务级别统一配置日志驱动：
logging.driver: "json-file"，并启用max-size和max-file防止磁盘打满 - 用 Fluentd 或 Loki（轻量替代 ELK）收集日志，与 Prometheus 标签对齐（如通过
pod_name、namespace关联） - 在 Grafana 中配置 Loki 数据源，点击告警面板右上角 “Explore logs” 直接跳转到对应时间窗口的日志流，查错误堆栈
- 设置日志告警规则，例如：5 分钟内
"NullPointerException"出现 ≥10 次，或"503 Service Unavailable"错误率突增 300%
