janhoy opened a new pull request, #5245: URL: https://github.com/apache/solr/pull/5245
https://issues.apache.org/jira/browse/SOLR-18594 Solr's metrics carried no OpenTelemetry resource: `SolrMetricManager` built every `SdkMeterProvider` without `setResource()`, so everything reported under the SDK placeholder `unknown_service:java` — visible today as `target_info{service_name="unknown_service:java",…}` on `/solr/admin/metrics`. Tracing follows the conventions, but resolves them inside the autoconfigured SDK that the metrics side never reads, so `OTEL_SERVICE_NAME` and `OTEL_RESOURCE_ATTRIBUTES` had no effect on metrics. Over OTLP every node therefore arrived as `job="unknown_service:java"` with no `instance`. ## Changes - `OpenTelemetryConfigurator` resolves one resource for the node, shared by both signals. It adopts whatever the configurator's SDK resolved (new `getResource()` hook, implemented in the module via `addResourceCustomizer`), so traces and metrics cannot disagree and operator-added `ResourceProvider`s are included; where no configurator runs — no module, or a Java agent owning tracing — it builds the same resource from `OTEL_SERVICE_NAME` / `OTEL_RESOURCE_ATTRIBUTES`. - Solr fills in only what is unset: `service.name=solr`, `service.instance.id=<host>:<port>`, `host.name`. `host:port` rather than a UUID because Prometheus derives `instance` from it, which is what makes a pushed series match a direct scrape of the same node. - `SolrMetricManager.meterProvider()` sets that resource. - The module's `host.name` injection moves to core, so there is one source of truth; its "does not support METRICS" warning goes, since `OTEL_METRICS_EXPORTER` now does something. - `MetricExporterFactory` accepts the standard exporter variables as alternatives to `solr.metrics.otlp*`, which keep precedence: `OTEL_METRICS_EXPORTER` (when it includes `otlp`), `OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` / `OTEL_EXPORTER_OTLP_ENDPOINT`, the matching `*_PROTOCOL` pair, `OTEL_METRIC_EXPORT_INTERVAL`. The operator's `OTEL_METRICS_EXPORTER` is captured at class init, before the module overwrites that system property with `none` to stop the SDK exporting metrics Solr already owns. - Ref guide: new `Resource Attributes` section in `opentelemetry.adoc` covering both signals; standard-equivalents table in `metrics-reporting.adoc`. ## Validation `TestOtelResourceAttributes` (7 tests) covers the defaults, operator precedence, `OTEL_SERVICE_NAME` outranking a `service.name` attribute, malformed input, and the configurator-supplied resource. `TestPrometheusResponseWriter.testTargetInfoCarriesSolrResource` asserts a running node serves `target_info` with `service_name="solr"` and a `service_instance_id`. End-to-end on a locally built image, pushing OTLP through an OpenTelemetry Collector into Prometheus (the SOLR-18536 dev stack, `--metrics-scrape=otel`): ``` target_info{host_name="solr1",instance="solr1:8983",job="solr",...} 1 target_info{host_name="solr2",instance="solr2:8983",job="solr",...} 1 sum by (instance)(rate(solr_core_requests_total{job="solr"}[5m])) solr1:8983 1.2506 solr2:8983 1.1133 ``` That is the shipped dashboard's own expression, returning one series per node under the same labels a direct scrape produces; previously it returned a single merged series labelled with the Collector's address. Also green: `TestTracerConfigurator`, `SolrMetricManagerTest`, `SolrMetricsContextTest`, `MetricsHandlerTest`, the full `opentelemetry` module suite, and `check -x test`. ## Notes - Behaviour change for traces too: spans now carry `host.name` and `service.instance.id` by default. Intended, and documented. - Resource detectors (`host.*`, `os.*`, `process.*`, `container.id`) are deliberately not shipped; the ref guide says to add the `opentelemetry-resources` JAR to the module's lib directory if wanted. - Independent of [SOLR-18536](https://issues.apache.org/jira/browse/SOLR-18536) (#5244), which this completes: that PR's Collector config has to substitute `service.name` itself and cannot produce a per-node `instance` at all. - Unrelated and pre-existing: with OTLP push enabled, `/solr/admin/metrics` returns HTTP 500 ([SOLR-18595](https://issues.apache.org/jira/browse/SOLR-18595)), so only the push route is exercisable on a current build. 🤖 Coded by Claude Code, reviewed by me 🤖 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
