compose集成监控系统需网络互通、指标暴露、服务发现和配置协同四者配合：业务容器暴露/metrics端口并开放映射，prometheus通过docker_sd_configs动态发现容器，挂载docker.sock并共用自定义网络，利用标签和relabel实现精准采集与分组。
Compose 编排实现监控系统与业务容器的集成，核心在于让 Prometheus 等监控组件能自动发现、持续采集目标容器的指标，同时确保业务容器自身暴露可被拉取的监控数据。这不是简单地把几个服务写进 docker-compose.yml，而是需要网络互通、指标暴露、服务发现和配置协同四者配合。
让业务容器主动暴露监控指标
监控的前提是“有东西可采”。多数应用需集成 Prometheus 客户端库（如 Python 的 prometheus_client、Go 的 promhttp），在 HTTP 路径（如 /metrics）上暴露指标。
- 容器启动后，应监听容器内网地址（如
0.0.0.0:8000），而非仅127.0.0.1，否则外部无法访问 - 在
docker-compose.yml中为该服务显式开放端口（如- "8000:8000"），或通过自定义网络让 Prometheus 容器直连其内部端口 - 若业务容器依赖 Node Exporter 或 cAdvisor，则无需额外开发——它们已默认暴露主机或容器维度指标
用 Prometheus 配置实现自动服务发现
Prometheus 本身不感知 Docker Compose，但可通过 docker_sd_configs（Docker 服务发现）动态获取运行中的容器信息，无需手动维护 targets 列表。
- 在
prometheus.yml的scrape_configs中添加：
docker_sd_configs:
- host: unix:///var/run/docker.sock
role: containers
relabel_configs:
- source_labels: [__meta_docker_container_name]
regex: /(.*)
target_label: instance
- source_labels: [__meta_docker_container_port_number]
regex: (8000)|.*
action: keep
- 关键点：Prometheus 容器必须挂载宿主机的
/var/run/docker.sock，并具备读取权限；cAdvisor 通常更轻量、更常用，适合只看容器资源，而docker_sd_configs更适合按容器标签精细筛选业务实例
打通网络与权限，确保采集链路通达
常见失败原因不是配置错，而是网络不通或权限不足。
- Prometheus 容器需与业务容器处于同一自定义网络（推荐显式定义
networks），避免依赖默认 bridge 网络的 DNS 不稳定问题 - 若采集宿主机指标（如 CPU、磁盘），Node Exporter 必须以
host网络模式运行，或使用host.docker.internal（Docker Desktop）或--add-host=host.docker.internal:host-gateway（Linux）补全宿主机解析 - 挂载
/proc/sys/var/lib/docker等路径时，注意容器安全策略（如privileged: true仅在必要时启用）
用标签和 Relabel 实现灵活分组与过滤
Docker Compose 允许给服务打标签（labels），这些标签会被 docker_sd_configs 自动注入为元数据，再经 relabel_configs 转化为 Prometheus 的标签（如 jobenv），支撑多环境、多租户监控。
- 在业务服务中添加：
image: myapp:latest
labels:
- "monitoring/prometheus=true"
- "env=prod"
- 对应在 Prometheus 配置中用
__meta_docker_container_label_monitoring_prometheus做匹配，只拉取带该标签的服务，避免误采中间件或调试容器
