SOLR-18310: opentelemetry module should not ship Netty JARs

[dsmiley]

https://issues.apache.org/jira/browse/SOLR-18310

(READ THE JIRA)
Implemented with AI of course

I tested with claude using Jaeger to ensure this actually worked. It was useful to uncover a security manager config setting that was needed.

[epugh]

maybe the ticket should change to "opentelementry defaults to http instead of grpc communication"?

I know one of hte dirvers is to eliminate netty from default, but from a suer perspective the bigger end user change is that we are removing grpc protocol from defualt use. I dont' know otel enough to know if this is a issue for our operators of solr or not!

[epugh]

do we know that http is the default choice in the otel world? I guess in my head I thought grpc for performacne reasons? But I'm not an expert!

[dsmiley]

OTLP http/protobuf is widely supported OOTB on recipients AFAICT. I suspect users won't notice this change, but it's not something to withhold from a changelog.
I do expect a there would be a performance difference, albeit not much for a reasonably performant http stack (I think JDK HttpClient is such).

[mlbiscoc]

The default is grpc but I am ok with http.

[dsmiley]

Not a typical dependency_update usage (isn't an upgrade) but why not use it here.
CC @janhoy

[dsmiley]

OTLP http/protobuf is widely supported OOTB on recipients AFAICT. I suspect users won't notice this change, but it's not something to withhold from a changelog.
I do expect a there would be a performance difference, albeit not much for a reasonably performant http stack (I think JDK HttpClient is such).

[mlbiscoc]

In the metrics-reporting doc there is some parts that still say grpc is default. Those need changes.

Also in OtlpExporterFactory.java if we remove grpc we should more gracefully error if we want users to manually add the jars to use it. Maybe with a try?

[mlbiscoc]

The default is grpc but I am ok with http.

[dsmiley]

I think the DX is pretty good if someone chooses grpc:

java.lang.IllegalStateException: No GrpcSenderProvider found on classpath. Please add dependency on
opentelemetry-exporter-sender-okhttp or opentelemetry-exporter-sender-grpc-upstream

[dsmiley]

Sharing a prompt & response with AI with the wider audience here:

Context: Historically, metrics and tracing were backed by different mechanisms. Now it's basically all OpenTelemetry. Our documentation and configuration seems too bifurcated nowadays. Of course we still need to discuss metrics separately from tracing, but there's a need IMO for a documentation page just for OTEL, and perhaps configuration too. WDYT? (not acting on this now, just capturing the thought)

---

Agreed — this PR ends up duplicating the same gRPC-JARs caveat in both distributed-tracing.adoc and metrics-reporting.adoc, which is a symptom of the split. My take: don't fully merge them (tracing and metrics still have genuinely different audiences and mental models), but a single opentelemetry.adoc landing page covering the shared stuff once — module enablement, the JAR/dependency story, gRPC-vs-HTTP tradeoffs — with tracing and metrics as subsections or linked child pages, would kill the duplication without pretending they're the same feature.

The deeper wrinkle worth flagging: it's not just docs that are split, the configuration mechanisms are too — tracing goes through real OTEL SDK autoconfigure (OTEL_EXPORTER_OTLP_* env vars), while metrics uses bespoke Solr system properties (solr.metrics.otlpExporter*) that don't follow OTEL conventions at all. A unified doc page would make that inconsistency more visible, which might be a feature (motivates fixing it) or a distraction (raises scope) depending on appetite.