本质是构建阶段固化探针路径、JVM参数、网络地址和基础配置，镜像启动即自动生效；SkyWalking需-javaagent挂载绝对路径jar并设service_name和backend_service，Exporter则作为独立进程监听/metrics端口。
直接在 Dockerfile 中注入监控探针，本质是把采集逻辑“ baked in”到镜像里——不是运行时挂载，也不是靠外部配置驱动，而是构建阶段就固化探针路径、JVM 参数、网络地址和基础配置。只要镜像一启动，监控就自动生效。
明确探针类型与嵌入方式
不同探针集成方式差异很大，不能套用同一套写法：
-
SkyWalking Java Agent：必须通过
-javaagent挂载 jar 文件，路径需绝对、参数需完整（service_name和backend_service不可省略） -
Prometheus Exporter（如 node-exporter、amprobe）：作为独立二进制进程运行，需监听端口、暴露
/metrics，与主应用共容器时要用supervisord或 shell 启动多进程 - eBPF 工具（如 bpftrace、libbpf 应用）：需 root 权限 + 内核模块支持，通常不放进业务镜像，而是在宿主机或专用 sidecar 镜像中部署
-
ARMS / OpenTelemetry Java Agent：类似 SkyWalking，但配置项命名不同（如
arms.licenseKey、otel.javaagent.configuration-file），需注意参数前缀和文件加载路径
Dockerfile 中完成探针固化
关键不是“复制进去”，而是让探针能被正确识别、加载、通信：
- 把 agent 文件夹（含
skywalking-agent.jar、config/、plugins/）放在项目根目录下，与 Dockerfile 同级，再用COPY agent /opt/skywalking/agent - JVM 启动命令统一用
ENTRYPOINT ["sh", "-c", "java -javaagent:..."]，避免因 shell 解析导致参数截断 - 路径全部用绝对路径：
-javaagent:/opt/skywalking/agent/skywalking-agent.jar，不依赖WORKDIR或相对位置 - 若需覆盖默认配置，提前修改好
agent.config再 COPY，或用-Dskywalking.agent.xxx=xxx覆盖关键项（如 namespace、sampling rate） - Exporter 类探针建议设为非 root 用户运行：
RUN addgroup -g 1001 -f monitor && adduser -S monitor -u 1001，再用USER monitor切换
适配运行时网络与服务发现
探针上报失败，90% 是因为地址写错了：
-
backend_service或collector.endpoint填的是服务名，不是localhost或127.0.0.1——Docker 容器内没有宿主机网络上下文 - 单机测试可用
host.docker.internal（Docker Desktop 支持），生产环境必须用 Kubernetes Service 名（如skywalking-oap.default.svc.cluster.local:11800） - 如果探针要访问宿主机端口（如 MySQL Exporter 连本地 DB），需用
network_mode: host或显式映射端口，并确保防火墙放行 - 多个探针共存时，端口不能冲突：Spring Boot Actuator 默认用
8080，Prometheus Exporter 建议改用9091，并在EXPOSE中声明
验证是否真正生效
别只看容器起来没，要看数据有没有真正流动：
- 启动后第一件事：查日志是否有
SkyWalking Agent vX.X.X started successfully或Starting Prometheus HTTP server - 进容器执行
curl http://localhost:9091/metrics（Exporter 端口），确认返回文本指标，无 404 或连接拒绝 - 在 SkyWalking UI 或 Prometheus Targets 页面，看对应实例状态是否为
UP，抓取间隔是否正常 - 发起一次真实调用（如 curl 接口），等待 10–30 秒，检查 Trace 列表或指标图表是否出现新数据
