[java-bigquerystorage] Accept an OpenTelemetry instance per stream writer instead of the cached GlobalOpenTelemetry

未关闭
  • 哪里不对？
#14,765 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
java
领域
observability

调研方向

Start with StreamWriter.Builder and the TelemetryMetrics and Singletons files linked in the issue; trace how each writer obtains its MeterProvider. Check the builders for JsonStreamWriter and SchemaAwareStreamWriter too, since the request asks for the same option there. Done means each builder can accept its own OpenTelemetry instance while an unset option retains the current global behavior.

由索引模型根据 Issue 内容生成。

描述

Is your feature request related to a problem? Please describe.

The Storage Write client's OpenTelemetry metrics (StreamWriter.Builder.setEnableOpenTelemetry(true)) can only be sent to the process-wide GlobalOpenTelemetry.
TelemetryMetrics takes its MeterProvider from Singletons.getOpenTelemetry(), which caches GlobalOpenTelemetry.get() in a static field on first use and has no setter:

https://github.com/googleapis/google-cloud-java/blob/165f02ec20bc3db5eb8ca0b6ba09af6f6590be71/java-bigquerystorage/google-cloud-bigquerystorage/src/main/java/com/google/cloud/bigquery/storage/v1/Singletons.java#L30-L36

https://github.com/googleapis/google-cloud-java/blob/165f02ec20bc3db5eb8ca0b6ba09af6f6590be71/java-bigquerystorage/google-cloud-bigquerystorage/src/main/java/com/google/cloud/bigquery/storage/v1/TelemetryMetrics.java#L136-L139

This makes the metrics hard to use from a framework that hosts many writers in one JVM.
We maintain an Apache Flink connector for BigQuery (flink-gcp/flink-connector-gcp) and want to forward each writer's metrics into Flink's own metric system, which then exports them to whatever reporter the deployment uses (Prometheus, Datadog, OTLP).
With only the global instance:

  • several jobs or subtasks share one TaskManager JVM, so their writers cannot report to separate meter providers;
  • a library cannot call GlobalOpenTelemetry.set(...) without taking that global over from the application;
  • when the client is shaded into a connector jar, io.opentelemetry is relocated, so the relocated global is not one the application or a Java agent can set at all.

Describe the solution you'd like

An optional per-writer OpenTelemetry (or MeterProvider) on the writer builders, for example StreamWriter.Builder.setOpenTelemetry(OpenTelemetry), with the same setter on JsonStreamWriter.Builder and SchemaAwareStreamWriter.Builder.
When it is unset, the current GlobalOpenTelemetry behaviour would stay as it is.

Other clients in this repository already offer this:

  • Spanner: SpannerOptions.Builder.setClientMetricsProvider(MetricsProvider) (#13741).
  • Bigtable: BigtableDataSettings.Builder.setMetricsProvider(MetricsProvider), which accepts a CustomOpenTelemetryMetricsProvider.

Describe alternatives you've considered

  • GlobalOpenTelemetry.set(...) once per JVM: it cannot separate the writers of different jobs, and it does not reach a relocated copy of the client.
  • Reading the meters reflectively, or replacing Singletons: neither is a supported surface.

Additional context

  • Libraries-Bom: 26.90.0
    • google-cloud-bigquerystorage 3.35.0
  • The same code is on main at 165f02ec20bc3db5eb8ca0b6ba09af6f6590be71.
主要语言
Java
星标
2.1k
派生
1.2k
平均合并
2 天 14 小时
30 天内合并 PR
192

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

googleapis/google-cloud-java 的其他 Issue

查看 googleapis/google-cloud-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。