[jira] [Comment Edited] (SOLR-16536) Replace OpenTracing instrumentation with OpenTelemetry

["Jan Høydahl (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-16536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17655736#comment-17655736 ] 

Jan Høydahl edited comment on SOLR-16536 at 1/8/23 12:48 AM:
-------------------------------------------------------------

Did some reading, and appears that e.g. DataDog do not provide a Java-agent with an OTEL Tracer implementation, in the same way they did for OpenTelemetry. Instead they recommend users to use OTEL collector and then push from there to DataDog, or to install the DataDog agent application on localhost and push traces to that agent (if you don't want the OTEL-collector). See [https://docs.datadoghq.com/opentelemetry/otel_tracing/]

So it looks like we won't have to handle any 3rd party otel tracer agent, and people will likely not use the opentelementry java-agent for auto-instrumenting Jetty, since Solr's instrumentation is likely higher quality.

So I believe this menans great simplification in v10.0
 * Remove the {{<tracerConfig>}} tag in solr.xml, and thus no need for {{TracerConfiguraor}} plugin class
 * {{OtelTracerConfigurator}} can self-register in a static{} contest, using {{{}GlobalOpenTelemetry.set(myOpenTelemetry){}}}. This means tracing is disabled until you register {{{}SOLR_MODULES=opentelemetry{}}}, which puts OtelTracerConfigurator on the classpath
 * Solr's OpenTracing instrumentation will be replaced with with OTEL instumentation, and we'll fetch the registered tracer from {{GlobalOpenTelemetry.get()}}

Any thoughts? Why would we still want an explicit solr.xml plugin for this?


was (Author: janhoy):
Did some reading, and appears that e.g. DataDog no longer provides a Java-agent with  a Tracer implementation the same way they did for OpenTelemetry. Instead they recommend users to use OTEL collector and then push from there to DataDog, or to install the DataDog agent application on localhost and push traces to that agent (if you don't want the OTEL-collector). See [https://docs.datadoghq.com/opentelemetry/otel_tracing/]

So it looks like we won't have to handle any 3rd party otel tracer agent, and people will likely not use the opentelementry java-agent for auto-instrumenting Jetty, since Solr's instrumentation is likely higher quality.

So I believe this menans great simplification in v10.0
 * Remove the {{<tracerConfig>}} tag in solr.xml, and thus no need for {{TracerConfiguraor}} plugin class
 * {{OtelTracerConfigurator}} can self-register in a static{} contest, using {{{}GlobalOpenTelemetry.set(myOpenTelemetry){}}}. This means tracing is disabled until you register {{{}SOLR_MODULES=opentelemetry{}}}, which puts OtelTracerConfigurator on the classpath
 * Solr's OpenTracing instrumentation will be replaced with with OTEL instumentation, and we'll fetch the registered tracer from {{GlobalOpenTelemetry.get()}}

Any thoughts? Why would we still want an explicit solr.xml plugin for this?

> Replace OpenTracing instrumentation with OpenTelemetry
> ------------------------------------------------------
>
>                 Key: SOLR-16536
>                 URL: https://issues.apache.org/jira/browse/SOLR-16536
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Jan Høydahl
>            Priority: Major
>
> After this, we do not have any traces (pun intended) of either OpenTracing or Jaegertracer libraries in Solr. We'll be using OTEL java sdk both for instrumentation and trace exporting.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org