不使用Micrometer如何采集Java应用指标并上报至Prometheus

除了你已经了解的Micrometer方案外，目前生产环境经过验证的成熟实现方案主要有以下三类，同时补充你之前尝试Dropwizard Metrics对接的正确实现路径：

• Prometheus 官方原生Java客户端
  这是Prometheus官方维护的底层SDK，无任何额外框架依赖，JavaSE、JavaEE、任意自研框架的项目都可以直接接入。内置Counter、Gauge、Histogram、Summary四类Prometheus原生指标类型，自带HTTP服务组件，引入依赖后只需要几行代码就能启动暴露符合规范的metrics端点：

  // 示例：在9090端口启动指标暴露服务
  HTTPServer server = HTTPServer.create(9090, CollectorRegistry.defaultRegistry, true);
  

  这个方案的优势是性能高、依赖少、行为完全和Prometheus生态对齐，没有额外适配层的开销；缺点是没有和Spring Boot做自动装配，Spring生态下使用需要自己完成指标注册、端点暴露、公共指标（JVM、请求耗时等）的采集逻辑。
• OpenTelemetry Java SDK + Prometheus Exporter
  这是CNCF毕业的标准可观测实现，属于现在云原生场景下的主流选型，一套埋点API可以同时对接指标、链路、日志三类可观测数据，后续如果要切换监控后端不需要修改业务埋点代码。
  它自带的Prometheus导出器可以直接将采集到的所有指标转换成Prometheus兼容的文本格式对外暴露，性能损耗极低。Spring Boot从2.4版本开始已经内置了OpenTelemetry的适配支持，只需要引入对应依赖、简单配置就能完成自动埋点和端点暴露，适合后续有全链路可观测建设规划的场景。
• Dropwizard Metrics 对接Prometheus的稳定实现
  你检索不到足够参考资料的核心原因是早期大量第三方Dropwizard-Prometheus适配组件已经停止维护，目前稳定可用的对接方式是通过Prometheus官方提供的Dropwizard适配收集器实现，不需要自己手写指标格式转换逻辑。
  对接时注意不要直接使用Dropwizard自带的Metrics Servlet输出指标——它的输出格式不符合Prometheus的拉取规范，会直接导致抓取失败，这是绝大多数人对接时踩的共性坑。正确流程是：先正常在Dropwizard Metrics中完成业务埋点、维护MetricRegistry实例，将该实例传入官方适配收集器，由适配层自动完成Dropwizard指标类型（Meter、Timer、Histogram等）到Prometheus标准指标类型的映射，统一注册到Prometheus的CollectorRegistry后，再通过官方HTTP端点暴露即可。

选型参考：如果你的项目是Spring Boot技术栈，没有切换监控后端、建设统一可观测平台的规划，Micrometer依然是综合接入成本最低的方案；如果是无框架依赖的轻量Java应用，追求最小依赖和最高性能，选Prometheus官方原生客户端最稳妥；如果长期要做可观测体系建设，直接选OpenTelemetry方案可以避免后续重复埋点的成本。

内容的提问来源于stack exchange，提问作者gstackoverflow