核心是Prometheus主动拉取各服务/metrics端点数据，需统一接口标准、容器打标、prometheus.yml多job配置+relabeling清洗标签，并在Grafana中按标签聚合查询。
用 Docker Compose 集成 Prometheus 实现多服务指标集中采集，核心不是“让每个服务自己上报”，而是由一个中心化的 Prometheus 实例，主动从各服务暴露的 /metrics 端点拉取数据。关键在于统一暴露、正确打标、合理调度，而非靠 Composer 或 PHP 库自动干活。
1. 多服务必须统一暴露标准 metrics 接口
每个被监控的服务（如 API、MySQL、Redis、自研 PHP 服务）需提供符合 Prometheus 文本格式的 /metrics HTTP 接口。这不是可选功能，是前提：
-
标准 Exporter 直接复用：MySQL 用
mysqld_exporter，服务器硬件用node_exporter，Docker 容器用cadvisor，它们开箱即暴露:9100/metrics、:9104/metrics等 -
自研服务需手动集成：PHP 项目不能只
composer require prometheus/client_php就完事——要写采集逻辑（读/proc/meminfo、sys_getloadavg()）、调$gauge->set($value)、注册路由返回PrometheusRenderer::render($collectorRegistry) -
端口与路径保持一致：避免有的服务用
:8080/metrics，有的用:9000/prom；统一为:端口/metrics可大幅降低 Prometheus 配置复杂度
2. docker-compose.yml 中定义所有目标服务并打标
在单个 docker-compose.yml 中声明所有 exporter 和 Prometheus，用 labels 注入语义信息，避免后期 Grafana 分不清哪条曲线来自哪类机器：
- 给
node_exporter加labels: { role: "backend", env: "prod" } - 给
mysqld_exporter加labels: { service: "mysql-main", cluster: "shard-01" } - 自研服务容器也加
labels: { app: "user-api", version: "v2.3" } - 确保各服务网络互通（同个自定义 network），Prometheus 才能通过容器名（如
http://node-exporter:9100/metrics）稳定抓取
3. prometheus.yml 配置多 job + relabeling 去重归一
一份配置管所有，不拆不散。重点用 static_configs 列出全部 targets，并用 relabel_configs 清洗标签：
- 用
source_labels: [__address__]把原始 IP:port 替换为更稳定的标识，例如target_label: instance→regex: "(.*?)-(\d+)\.local"→ 值变成api-01 - 用
replacement: "$1"从主机名提取区域，注入region标签，方便 Grafana 按地域聚合 - 禁用默认
instance标签冲突：加action: labeldrop删除可能重复的原始标签 - 对非核心指标（如磁盘 inodes），单独设
scrape_interval: 60s，减轻存储压力
4. Grafana 查询必须带维度聚合，不裸查原始指标
多服务场景下，原始指标量级极易爆炸。看板里不能直接写 node_memory_MemAvailable_bytes，而应分组聚合：
- 查整体内存使用率：
100 - avg by(instance, env, role) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100 - 查某类服务平均延迟：
avg by(app, version) (histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, app, version))) - 告警规则也按标签分组，例如只对
env="prod"的app="payment"设置 CPU > 90% 告警，避免测试机误触发
