爬起来远程连服务器第一件事就是敲docker ps -a，果不其然那三个支付容器全挂了，而且重启了一次两分钟又崩。排查下来才发现是我们之前临时加的Redis连接池扩容脚本有问题，没限制容器内的goroutine数量，加上预热流量上来，每个容器的进程数直接冲到了系统默认的4096上限，Docker本身的守护进程都卡得慢半拍，我们之前只加了CPU使用率和内存占用的基础邮件告警，进程数、进程健康探测这些完全没落地，相当于给容器装了“半扇窗户”，看不见死角里的致命问题。
说实话，入行6年，见过80%左右的中小团队监控都是“装了个样子”——要么只装了cAdvisor看实时状态，没配置持久化数据和告警；要么抄了个官方的Prometheus+Grafana yaml文件就不管了，阈值全是默认的，告警要么天天炸要么根本不响；要么就是嫌麻烦只依赖云厂商的基础Docker监控，但云厂商的监控延迟大多在10-30秒，而且对自定义指标、内部业务接口的支持要么收费要么有限。
今天整理了个2026年适配中小团队线上轻量场景的服务器Docker容器监控方法，不用太复杂的架构，不用花大价钱，就能轻松稳定地实时掌握容器状态，连我们公司新来的刚毕业半年的运维实习生，跟着做一遍都能直接上线。
第一个落地的是轻量持久化+实时面板，别一开始就上复杂的集群版Prometheus，单节点加个卷挂载就行，配置文件用现成的但要改几个关键参数。先拉取镜像，docker pull prom/prometheus:v2.55.0（这个是2026年初的稳定LTS版本，别用最新的开发版，踩过坑，内存占用偶尔会飘到离谱），然后拉取cAdvisor镜像做容器指标采集，docker pull gcr.io/cadvisor/cadvisor:v0.49.1（注意国内可能拉不动，换成阿里云的源就行，比如registry.cn-hangzhou.aliyuncs.com/google_containers/cadvisor:v0.49.1）。
接下来写个docker-compose.yml文件把这两个和Grafana拼起来，新手别自己手写，直接抄下面这个改本地挂载路径：
version: '3.8'
services:
cadvisor:
image: registry.cn-hangzhou.aliyuncs.com/google_containers/cadvisor:v0.49.1
container_name: cadvisor
restart: always
ports:
"8080:8080"
volumes:
/:/rootfs:ro
/var/run:/var/run:rw
/sys:/sys:ro
/var/lib/docker/:/var/lib/docker:ro
prometheus:
image: prom/prometheus:v2.55.0
container_name: prometheus
restart: always
ports:
"9090:9090"
volumes:
/data/prometheus/config:/etc/prometheus
/data/prometheus/data:/prometheus
command:
'config.file=/etc/prometheus/prometheus.yml'
'storage.tsdb.path=/prometheus'
'storage.tsdb.retention.time=15d' # 中小团队数据保留15天足够，省磁盘
grafana:
image: grafana/grafana:10.4.5
container_name: grafana
restart: always
ports:
"3000:3000"
volumes:
/data/grafana/data:/var/lib/grafana
environment:
GF_SECURITY_ADMIN_USER=admin
GF_SECURITY_ADMIN_PASSWORD=ChangeMe123! # 上线前一定要改这个密码！！
这里要敲黑板的第一个避坑提醒：挂载卷的权限必须给对，prometheus容器默认用的是nobody用户，所以要提前给/data/prometheus/data目录改权限，执行chmod 777 /data/prometheus/data（虽然777有点大，但中小团队单节点环境可以暂时这么用，想安全点可以改成nobody:nobody的权限），不然prometheus会启动失败，报“permission denied”的错。
然后写prometheus的配置文件，/data/prometheus/config目录下新建prometheus.yml：
global:
scrape_interval: 5s # 中小团队采集间隔5秒足够，实时性够好，内存压力也不大
evaluation_interval: 15s
scrape_configs:
job_name: 'prometheus'
static_configs:
targets: ['localhost:9090']
job_name: 'cadvisor'
static_configs:
targets: ['cadvisor:8080']
配置好之后直接执行docker-compose up -d就能启动了，启动后访问服务器的3000端口，用刚才设置的账号密码登录，然后添加数据源选Prometheus，地址填http://prometheus:9090，保存测试成功后，直接导入Grafana的官方模板14282，这个是2026年更新的专门适配cAdvisor v0.49的，界面清晰，覆盖了CPU、内存、磁盘、网络等核心容器指标，导入后就能实时看所有容器的运行状态了。
第二个落地的是精准的告警配置，别只抄默认阈值，要根据自己的业务场景来调。我们公司是本地生活小程序，高峰期流量波动大，所以CPU使用率的阈值设置的是80%持续1分钟告警，内存占用设置的是超过容器限制的90%持续30秒告警，进程数设置的是超过容器默认限制（或者自己给容器设的limit）的85%持续10秒告警，还有就是必须加容器健康探测的告警。
容器健康探测可以直接在docker-compose.yml里给业务容器加，比如我们的支付回调容器加的是：
payment-callback:
image: registry.cn-hangzhou.aliyuncs.com/our-company/payment-callback:v1.2.3
container_name: payment-callback
restart: always
ports:
"8081:8080"
mem_limit: 512m
cpus: 0.5
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
interval: 10s
timeout: 5s
retries: 3
start_period: 30s
这里的healthcheck就是定期检查业务接口的/health路径，如果连续3次检查失败，Docker本身会把容器标记为unhealthy，然后我们可以在Prometheus的alertmanager里加配置，当检测到有unhealthy的容器时就发告警。
alertmanager的配置我就不贴太长的了，中小团队用钉钉或者企业微信就行，这里要敲黑板的第二个避坑提醒：别只配置一种告警渠道，至少要配置两种，还要配置 escalation 机制，比如先发钉钉群，如果10分钟没人处理，就直接给运维负责人发企业微信的电话提醒，不然像我上周四那样，凌晨一点多没人看钉钉，损失就大了。
最后就是定期复盘告警，别装了监控就不管了，每周抽10分钟看看Grafana的面板和alertmanager的告警记录，把那些天天炸的“噪音告警”阈值调一下，比如我们公司一开始把容器的网络入站流量阈值调得太低，每天白天推广期都会炸好几次，后来改成了入站流量超过平时平均的5倍持续2分钟才告警，就安静多了。
你们在运维工作中有没有遇到过类似的监控漏报误报的坑？欢迎在评论区分享你的排查经验。
评论列表 (0条)：
加载更多评论 Loading...