[
https://issues.apache.org/jira/browse/SOLR-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17941031#comment-17941031
]
Andrzej Bialecki edited comment on SOLR-17458 at 4/4/25 4:57 PM:
-----------------------------------------------------------------
This is going to be a lot of work, indeed, but perhaps it will be a rote
replacement in many places if you decide to keep the {{SolrMetricsContext}} -
most of the calls from Solr code don't go directly to the Dropwizard APIs but
use the limited SolrMetricsContext facade.
Agreed on the wholesale replacement, maintaining two different frameworks would
be messy. Although I'm not sure about completely dropping the other export
formats, so maybe a simple JSON shim would be useful (not necessarily
preserving the same exact format as the current handler).
I expect some constructs (e.g. {{{}MetricsMap{}}}) to be difficult or
impossible to port over 1:1. Suitable replacements should be found to be able
to report arbitrary (not pre-defined) metrics. Also, some complexity around the
way Gauge-s are registered (e.g. {{{}GaugeWrapper{}}}) comes from the fact that
gauge values were obtained from lambdas that were in turn referenced by
ephemeral objects, such as SolrIndexSearcher, or SolrCore instances, and would
frequently cause mem leaks (see the history for {{{}GaugeWrapper{}}}).
Metrics filtering is very important because it allows to drastically limit the
amount of data pulled from the nodes, which is crucial if you have hundreds of
nodes, hundreds of collections and thousands of replicas - so I would encourage
you to either preserve the current filtering functionality or provide something
equivalent.
was (Author: ab):
This is going to be a lot of work, indeed, but perhaps it will be a rote
replacement in many places if you decide to keep the {{SolrMetricsContext}} -
most of the calls from Solr code don't go directly to the Dropwizard APIs but
use the limited SolrMetricsContext facade.
Agreed on the wholesale replacement, maintaining two different frameworks would
be messy. Although I'm not sure about completely dropping the other export
formats, so maybe a simple JSON shim would be useful (not necessarily
preserving the same exact format as the current handler).
I expect some constructs (e.g. {{MetricsMap}}) to be difficult or impossible to
port over 1:1. Suitable replacements should be found to be able to report
arbitrary (not pre-defined) metrics. Also, some complexity around the way
Gauge-s are registered (e.g. {{GaugeWrapper}}) comes from the fact that gauge
values were obtained from lambdas that we in turn referenced by ephemeral
objects, such as SolrIndexSearcher, or SolrCore instances, and would frequently
cause mem leaks (see the history for {{GaugeWrapper}}).
Metrics filtering is very important because it allows to drastically limit the
amount of data pulled from the nodes, which is crucial if you have hundreds of
nodes, hundreds of collections and thousands of replicas - so I would encourage
you to either preserve the current filtering functionality or provide something
equivalent.
> Metrics: switch from DropWizard to OpenTelemetry
> ------------------------------------------------
>
> Key: SOLR-17458
> URL: https://issues.apache.org/jira/browse/SOLR-17458
> Project: Solr
> Issue Type: Improvement
> Reporter: Matthew Biscocho
> Priority: Major
>
> Solr currently captures metrics with Dropwizard 4. There was some limitations
> to Dropwizard, biggest one being metrics without tags/attributes making
> aggregation difficult and requires the Prometheus Exporter to work with
> Grafana.
> Creating this to track and explore integrating OpenTelemetry into Solr and
> possibly replace Dropwizard giving a larger exposure of observability tools.
--
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
