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

Jan Høydahl commented on SOLR-16938:
------------------------------------

Frankly, it is a hassle in docker based systems to maintain a custom version of 
solr.xml just to enable tracing, which is in an optional module, and is 100% 
configurable through OTEL standard env.variables. Sure, I keep a custom Helm 
chart that templates the custom solr.xml into a ConfigMap and lets 
solr-operator know about it, but it's soo much more elegant to configure 
plugins without the need to mutate a large central xml file.

I can see that removing the tag removes the config-container for any 
solr-custom configuration for OTEL tracing, so I'm ok to settle on some 
existing on new location for such potential config need. What about an optional 
tag in solr.xml that, if it exists, can be consumed as a Map<String,Object> by 
the opentelemetry module? We have top-level tags <solrCloud>, 
<shardHandlerFactory> and <metrics>. What about a new <tracing> tag?

> Auto configure tracer without a <tracerConfig> tag in solr.xml
> --------------------------------------------------------------
>
>                 Key: SOLR-16938
>                 URL: https://issues.apache.org/jira/browse/SOLR-16938
>             Project: Solr
>          Issue Type: Sub-task
>          Components: tracing
>            Reporter: Jan Høydahl
>            Priority: Major
>
> Spinoff from SOLR-16536. It should now be possible to get rid of the explicit 
> {{<tracerConfig>}} config in solr.xml and the pluggable 
> {{TracerConfigurator}} class which is initialized in {{CoreContainer}}.
> Instead, the {{opentelemetry}} plugin can self-register statically to the 
> global OTEL instance.  This will make it sufficient to enable the 
> {{opentelemetry}} module to enable tracing. You can also 
> [enable/disable|https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/]
>  it with env {{OTEL_SDK_DISABLED}}.
> Alternatively, if we are getting away with global instance (SOLR-16937), then 
> SolrCore could discover the plugin using SPI or similar as opposed to 
> explicit editing of solr.xml.



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

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

Reply via email to