Dockerfile 中预置业务级监控埋点，要求构建时固化采集逻辑、暴露端点与运行约束，实现启动即监控：集成 Prometheus 客户端暴露 /metrics、内嵌 exporter、多进程管理、LABEL 声明元信息、结构化 JSON 日志、健康探针初始化、非 root 运行且权限预设。
直接在 Dockerfile 里定义性能监控埋点，不是加个工具就行，而是把采集逻辑、暴露端点、运行约束都固化进镜像本身。关键在于“构建时决定，运行时不依赖外部配置”。
Dockerfile 中预置业务级监控埋点
核心是让容器启动后，指标就可被拉取、健康状态就可被校验、日志就可被结构化解析——全部靠镜像自己带的能力，不靠运行时拼凑。
- 在应用代码中提前集成 Prometheus 客户端（如 Python 的
prometheus-client或 Go 的client_golang），暴露/metrics路径，并上报真实业务指标：请求量、P95 延迟、模型加载耗时、缓存命中率等，而不是只报 CPU 和内存； - 构建阶段就把 exporter 二进制（比如轻量版
node-exporter或自研业务 exporter）打进镜像，和主进程共存；用supervisord或dumb-init管理多进程，确保主服务与指标采集器同时就绪； - 用
LABEL显式声明监控元信息，例如：LABEL monitoring.metrics-path="/metrics" LABEL monitoring.health-path="/healthz" LABEL monitoring.scrape-interval="15s" LABEL org.opencontainers.image.revision="${GIT_COMMIT:-unknown}"这些 label 可被 Prometheus Operator、Kube-Prometheus 或 CI/CD 流水线自动读取，实现零配置接入；
- 禁用非结构化日志输出，强制使用 JSON 格式（如
loguru设置serialize=True），字段包含service,level,timestamp,request_id,duration_ms,status_code，避免后续日志解析失败； - 启动命令中嵌入健康探针初始化逻辑，例如在
CMD前加检查脚本，确认模型已加载、Redis 连通、GPU 显存可用后再真正启动服务，保证/healthz?full=1返回结果可信。
确保监控能力随镜像一起交付
- 不在
docker run时靠-e PROMETHEUS_ENABLE=true这类环境变量开关监控，而是在构建阶段就决定“这个镜像天生支持监控”； - 镜像内不跑完整 Prometheus Server，但必须能被外部 Prometheus 正常
scrape；验证方式很简单：docker run -p 8000:8000 your-image后访问http://localhost:8000/metrics，应返回合法文本格式指标； - 使用非 root 用户运行（
USER 1001），但提前在 Dockerfile 中用RUN chown -R 1001:1001 /app和chmod +x /app/exporter保证权限，避免因权限问题导致 exporter 启动失败或指标无法采集。
不复杂但容易忽略。
