基于 DataKit promsd 动态采集主机业务 Prometheus 指标

业务背景与痛点

在企业业务系统可观测建设过程中，除主机、容器、数据库、中间件等基础设施指标外，业务系统通常还会暴露大量自定义业务指标，例如订单量、支付成功率、接口耗时、业务处理队列长度、JVM 线程数等。这类指标通常以 Prometheus 格式通过 HTTP Endpoint 暴露，例如 /actuator/prometheus、/metrics 或带有应用上下文路径的 /app/actuator/prometheus。

在传统 Prometheus 体系中，业务服务实例可能并不是通过静态 IP 列表维护，而是由 Nacos、注册中心、CMDB 或自研服务目录维护实例信息，再通过 HTTP SD 方式向 Prometheus 提供动态 target 列表。Prometheus 根据 target 列表和 relabel 规则拼接最终采集地址，并定期拉取业务指标。

如果在观测云接入过程中仍采用静态 URL 方式维护这些业务指标，会带来以下问题：

1. 业务实例数量多，手工维护成本高；
2. 服务发布、扩容、缩容、迁移后 IP 变化频繁；
3. 不同业务服务可能存在不同的上下文路径；
4. 静态配置容易遗漏实例，导致指标采集不完整；
5. 与客户现有 Prometheus / Nacos 服务发现体系不一致。

因此，本方案采用 DataKit promsd + HTTP SD + Prometheus Exporter Endpoint 的方式，实现主机业务指标的动态发现与主动采集，使观测云能够对齐客户现有 Prometheus HTTP SD 采集模型，避免人工维护大量 IP:Port 列表。

该方案的核心目标是：复用客户现有服务发现结果，由 DataKit 自动获取业务实例列表，并按 Prometheus Pull 模型采集业务指标，最终统一进入观测云指标体系。

核心原理说明

本方案的核心设计思想是将“服务发现”和“指标采集”解耦。

整体职责可以拆分为四部分：

在该模型中，DataKit 不是被动接收业务指标，也不是接收 Prometheus 推送，而是与 Prometheus 类似，采用主动拉取模式：

该逻辑的核心是：IP:Port 的动态变化由 HTTP SD 服务负责维护，DataKit 只消费最新 target 列表并执行指标采集。

整体架构

主机业务指标采集链路

该链路中，HTTP SD 服务负责提供“当前有哪些实例需要采集”，业务服务负责提供“每个实例暴露哪些指标”，DataKit 负责执行“动态发现 + 主动采集”，观测云负责后续的指标查询、分析、可视化和告警。

HTTP SD 与最终采集地址的关系

HTTP SD 返回的 target 通常只包含 IP:Port，例如：

[
  {
    "targets": ["10.64.1.10:8413"],
    "labels": {
      "context_path": "/ai-dm",
      "app": "ai-dm-service",
      "env": "dev"
    }
  }
]

如果业务服务最终暴露路径为：

/ai-dm/actuator/prometheus

则最终采集地址应为：

http://10.64.1.10:8413/ai-dm/actuator/prometheus

在 Prometheus 中，通常通过 relabel 将 context_path 拼接为 metrics_path。在 DataKit promsd 接入时，推荐由 HTTP SD 返回结果直接提供最终路径：

"__metrics_path__": "/ai-dm/actuator/prometheus"

这样可以降低 DataKit 侧配置复杂度，使采集路径更加明确、稳定。

实战方案

本方案由以下组件组成：

本次验证采用主机 Demo 模拟客户现有架构：

mock HTTP SD 服务
  ↓
返回 targets + labels + __metrics_path__
  ↓
DataKit promsd
  ↓
采集 mock exporter
  ↓
观测云生成 demo 指标集

验证结果显示，DataKit 已成功识别 promsd.demo-promsd 输入源，并在观测云指标管理中生成 demo 指标集，包含以下 3 个指标：

business_total
jvm_threads
request_latency_seconds

这说明主机侧 HTTP SD 动态发现 + DataKit 主动采集链路已经验证通过。

HTTP SD 返回结构设计

HTTP SD 返回结构需要符合 Prometheus HTTP SD 标准格式。固定结构如下：

[
  {
    "targets": [
      "127.0.0.1:8413"
    ],
    "labels": {
      "context_path": "/demo",
      "app": "demo-app",
      "env": "dev",
      "__metrics_path__": "/demo/actuator/prometheus",
      "__scheme__": "http"
    }
  }
]

字段说明如下：

该设计的核心是：HTTP SD 不只返回实例地址，还应尽可能返回足够的上下文标签，尤其是最终采集路径 metrics_path****。

DataKit promsd 配置方案

DataKit 通过 promsd 采集器读取 HTTP SD 服务，并对返回的 target 执行 scrape。

示例配置如下：

[[inputs.promsd]]
  source = "demo-promsd"

  [inputs.promsd.http_sd_config]
    service_url = "http://127.0.0.1:8848/nacos/prometheus/namespaceId/demo"
    refresh_interval = "30s"

  [inputs.promsd.scrape]
    scheme = "http"
    metrics_path = "/actuator/prometheus"
    interval = "15s"

  [inputs.promsd.tags]
    test = "promsd-demo"
    layer = "vm"

配置说明：

生产环境中，如果 HTTP SD 返回中已经包含 metrics_path，则 DataKit 可以使用每个 target 对应的最终路径进行采集；如果没有返回 metrics_path，则会依赖默认 metrics_path，这可能无法覆盖带有不同 context path 的业务服务。

该阶段的目标是：让 DataKit 不再依赖静态 URL 配置，而是通过 HTTP SD 动态获取业务实例并主动采集指标。

采集处理流程

HTTP SD 发现流程

DataKit promsd 启动
  ↓
读取 promsd.conf
  ↓
访问 service_url
  ↓
获取 HTTP SD JSON
  ↓
解析 targets 和 labels
  ↓
生成采集目标

指标采集流程

DataKit 获取 target
  ↓
读取 __scheme__ / scheme
  ↓
读取 __metrics_path__ / metrics_path
  ↓
拼接最终 URL
  ↓
HTTP GET 采集指标
  ↓
解析 Prometheus 格式文本
  ↓
转换为观测云指标数据

指标入库流程

Prometheus 指标文本
  ↓
DataKit 解析 metric name / labels / value
  ↓
转换为观测云指标集和指标字段
  ↓
上报观测云
  ↓
指标管理中生成指标集

在本次 Demo 中，Exporter 暴露的指标为：

demo_business_total
demo_jvm_threads
demo_request_latency_seconds

进入观测云后，指标集显示为：

指标集：demo
来源：dk.promsd
指标：
- business_total
- jvm_threads
- request_latency_seconds

这说明 DataKit 已成功完成 Prometheus 指标解析和指标集归类。

验证步骤

验证 HTTP SD 服务

执行：

curl -s http://127.0.0.1:8848/nacos/prometheus/namespaceId/demo

预期返回：

[
  {
    "targets": ["127.0.0.1:8413"],
    "labels": {
      "context_path": "/demo",
      "app_context_path": "/demo",
      "app": "demo-app",
      "env": "dev",
      "__metrics_path__": "/demo/actuator/prometheus",
      "__scheme__": "http"
    }
  }
]

验证业务指标接口

执行：

curl -s http://127.0.0.1:8413/demo/actuator/prometheus

预期返回：

# HELP demo_business_total Demo business counter
# TYPE demo_business_total counter
demo_business_total{app="demo-app",env="dev"} 1782744960

# HELP demo_jvm_threads Demo JVM thread count
# TYPE demo_jvm_threads gauge
demo_jvm_threads{app="demo-app",env="dev"} 12

# HELP demo_request_latency_seconds Demo request latency
# TYPE demo_request_latency_seconds gauge
demo_request_latency_seconds{app="demo-app",env="dev"} 0.123

验证 DataKit 输入源

在 DataKit 运行状态中确认存在：

promsd.demo-promsd

本次验证中，DataKit 状态显示：

这说明 DataKit 已经成功采集到 3 个指标点。

验证观测云指标管理

在观测云「指标管理」中搜索：

demo

预期结果：

指标包括：

business_total
jvm_threads
request_latency_seconds

总结

通过本方案，可以将客户现有 Prometheus HTTP SD 服务发现机制与观测云 DataKit 采集能力进行对齐。主机业务服务继续通过 Prometheus 标准 Endpoint 暴露指标，HTTP SD 服务继续维护动态实例列表，DataKit promsd 定期获取 targets 并主动 scrape 指标接口，最终将业务指标统一接入观测云指标体系。该方案避免了静态维护大量 IP:Port 的问题，实现了“服务发现由注册中心负责、指标暴露由业务服务负责、指标采集由 DataKit 负责、指标分析与告警由观测云负责”的职责解耦架构，适合在主机业务系统、Nacos 服务发现、Prometheus 指标标准化场景下生产落地。