David Smiley created SOLR-18471:
-----------------------------------
Summary: MetricExporterFactory should use the standard OTEL env
vars
Key: SOLR-18471
URL: https://issues.apache.org/jira/browse/SOLR-18471
Project: Solr
Issue Type: Improvement
Components: metrics
Affects Versions: 10.0
Reporter: David Smiley
h2. Problem
Solr's OTLP metrics exporter is configured with Solr-invented properties, while
tracing uses the standard OpenTelemetry environment variables. Pointing both
signals at the same collector means configuring the same endpoint twice, in two
naming schemes:
|| Signal || Endpoint || Protocol || Interval ||
| Traces | {{OTEL_EXPORTER_OTLP_ENDPOINT}} | {{OTEL_EXPORTER_OTLP_PROTOCOL}} |
n/a |
| Metrics | {{solr.metrics.otlpHttpExporterEndpoint}} /
{{solr.metrics.otlpGrpcExporterEndpoint}} |
{{solr.metrics.otlpExporterProtocol}} | {{solr.metrics.otlpExporterInterval}} |
The protocol values differ too: OTEL spells it {{http/protobuf}}, Solr spells
it {{http}}.
Users already know the OTEL variables, and every other OTLP producer in their
pipeline honors them.
h2. Proposal
Have {{MetricExporterFactory}} use the standard OTEL variables when the
Solr-specific property is not set. The EnvUtils properties tracks legacy
properties -- so add to it the properties we are doing away with here.
* {{solr.metrics.otlpHttpExporterEndpoint}} /
{{solr.metrics.otlpGrpcExporterEndpoint}} ->
{{OTEL_EXPORTER_OTLP_METRICS_ENDPOINT}}, then {{OTEL_EXPORTER_OTLP_ENDPOINT}}
* {{solr.metrics.otlpExporterProtocol}} ->
{{OTEL_EXPORTER_OTLP_METRICS_PROTOCOL}}, then {{OTEL_EXPORTER_OTLP_PROTOCOL}}
(accept {{http/protobuf}} as a synonym for {{http}})
* {{solr.metrics.otlpExporterInterval}} -> {{OTEL_METRIC_EXPORT_INTERVAL}}
Mind the endpoint semantics: {{OTEL_EXPORTER_OTLP_ENDPOINT}} is a base URL to
which the signal path is appended, whereas
{{OTEL_EXPORTER_OTLP_METRICS_ENDPOINT}} is the full URL. Solr's current
default, {{http://localhost:4318/v1/metrics}}, is the latter form.
h2. Explicitly out of scope
This does *not* make an OpenTelemetry Java agent export Solr's metrics. Metric
instruments come from {{SdkMeterProvider}}s that {{SolrMetricManager}} builds
and owns, because the {{/metrics}} pull endpoint needs a readable
{{FilterablePrometheusMetricReader}} attached at build time. They never pass
through {{GlobalOpenTelemetry}}, so an agent cannot see them. Routing metrics
through the global meter provider is a larger trade-off (it would sacrifice the
pull endpoint) and belongs in its own issue.
Enabling stays on {{solr.metrics.otlpExporterEnabled}} rather than
{{OTEL_METRICS_EXPORTER}}, since the {{opentelemetry}} module deliberately
forces {{otel.metrics.exporter=none}} to keep the autoconfigured SDK from
exporting metrics as well. Worth confirming that is still the behavior we want.
🤖 This description was drafted with AI assistance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
