prometheus server 镜像不应包含外置探针，而应独立运行 node exporter 等 exporter 容器；正确做法是构建含自定义 prometheus.yml 的 server 镜像，并通过 docker-compose 在同一网络中协同部署各组件，确保 targets 可被正常抓取。
直接用 Docker 构建“包含外置探针”的 Prometheus 镜像，这个说法容易误解——Prometheus 本身不打包探针（如 Node Exporter、cAdvisor），它只负责拉取指标。所谓“外置探针”，实际是独立运行的 Exporter 容器，通过网络被 Prometheus 主动抓取。因此，正确做法是：构建一个可复用的 Prometheus Server 镜像（含自定义配置），再配合独立部署的 Exporter 容器，形成松耦合、易维护的监控架构。
明确角色分工：Server 与探针分离
Prometheus Server 是中心采集器，不内置任何探针逻辑；Node Exporter、cAdvisor、MySQL Exporter 等都是标准的、单独的 Go 二进制服务，监听 /metrics 接口并返回文本格式指标。它们和 Prometheus 之间只有 HTTP 请求关系，没有进程级依赖。
- Prometheus 镜像只需专注加载配置、连接目标、存储和查询
- 每个 Exporter 应使用官方镜像（如
prom/node-exporter:v1.6.1），不建议强行塞进同一个镜像 - 探针是否“外置”，取决于你是否让它们运行在独立容器中——这是最佳实践，不是技术限制
构建可复用的 Prometheus Server 镜像
核心是把配置和启动逻辑固化，避免每次用 docker run -v 挂载。适合 CI/CD 或多环境分发：
- 准备
prometheus.yml，其中scrape_configs明确列出各探针地址，例如：- job_name: 'node'<br> static_configs:<br> - targets: ['node-exporter:9100']
- 编写 Dockerfile：
COPY prometheus.yml /etc/prometheus/prometheus.yml
EXPOSE 9090
- 构建并打标签：
docker build -t myorg/prometheus:2.45.0-node . - 该镜像已内置配置，启动时无需挂载配置文件，更稳定、更可审计
用 docker-compose 编排探针与 Server 协同工作
这才是“外置探针”的落地关键。所有组件跑在同一个自定义网络里，用服务名通信：
- 定义
docker-compose.yml，至少包含：prometheus、node-exporter、cadvisor - Node Exporter 启动时加
network_mode: host或privileged: true+ 挂载/proc//sys，才能获取真实主机指标 - cAdvisor 必须挂载
/var/run/docker.sock和/sys/fs/cgroup，否则无法读取容器数据 - Prometheus 容器中配置的 target 地址写成
http://node-exporter:9100，而非localhost或 IP
验证探针是否真正“可被拉取”
启动后别急着看 Grafana，先逐层确认连通性：
- 进入 Prometheus 容器：
docker exec -it prometheus sh - 用
wget -qO- http://node-exporter:9100/metrics | head -20查看能否拿到指标文本 - 访问
http://localhost:9090/targets，确认状态为 UP，且 Labels 中含job="node" - 执行查询
count(node_cpu_seconds_total)，有返回值即表示探针数据已入库
