[
https://issues.apache.org/jira/browse/SOLR-8785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-8785:
--------------------------------------
Attachment: SOLR-8785-increment.patch
Hi [~jwartes] and [~shalinmangar],
in our team one of my colleagues (Kelvin Wong) is currently also working on
metrics stuff i.e. we share your interest in this.
The attached SOLR-8785-increment.patch takes your SOLR-8785.patch from earlier
today and adds an adapted version of Kelvin's changes on top of it; summary of
the differences:
* TimerUtils.java as alternative to Metrics.java class
* TimerUtilsTest to tie metric names to snapshot accessors
* one import reorder (com before org) in RequestHandlerBase.java
* observation: existing code uses both {{thPcRequestTime}} and
{{thPctlRequestTime}}
** TimerUtils.java favours the
[RequestHandlerBase|https://github.com/apache/lucene-solr/blob/53981795fd73e85aae1892c3c72344af7c57083a/solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java#L285-L288]
variant and thus changes the
[OverseerStatusCmd|https://github.com/apache/lucene-solr/blob/53981795fd73e85aae1892c3c72344af7c57083a/solr/core/src/java/org/apache/solr/cloud/OverseerStatusCmd.java#L110-L113]
variant since the former seems more widely used.
> Use Metrics library for core metrics
> ------------------------------------
>
> Key: SOLR-8785
> URL: https://issues.apache.org/jira/browse/SOLR-8785
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.1
> Reporter: Jeff Wartes
> Labels: patch, patch-available
> Attachments: SOLR-8785-increment.patch, SOLR-8785.patch
>
>
> The Metrics library (https://dropwizard.github.io/metrics/3.1.0/) is a
> well-known way to track metrics about applications.
> In SOLR-1972, latency percentile tracking was added. The comment list is
> long, so here’s my synopsis:
> 1. An attempt was made to use the Metrics library
> 2. That attempt failed due to a memory leak in Metrics v2.1.1
> 3. Large parts of Metrics were then copied wholesale into the
> org.apache.solr.util.stats package space and that was used instead.
> Copy/pasting Metrics code into Solr may have been the correct solution at the
> time, but I submit that it isn’t correct any more.
> The leak in Metrics was fixed even before SOLR-1972 was released, and by
> copy/pasting a subset of the functionality, we miss access to other important
> things that the Metrics library provides, particularly the concept of a
> Reporter. (https://dropwizard.github.io/metrics/3.1.0/manual/core/#reporters)
> Further, Metrics v3.0.2 is already packaged with Solr anyway, because it’s
> used in two contrib modules. (map-reduce and morphines-core)
> I’m proposing that:
> 1. Metrics as bundled with Solr be upgraded to the current v3.1.2
> 2. Most of the org.apache.solr.util.stats package space be deleted outright,
> or gutted and replaced with simple calls to Metrics. Due to the copy/paste
> origin, the concepts should mostly map 1:1.
> I’d further recommend a usage pattern like:
> SharedMetricRegistries.getOrCreate(System.getProperty(“solr.metrics.registry”,
> “solr-registry”))
> There are all kinds of areas in Solr that could benefit from metrics tracking
> and reporting. This pattern allows diverse areas of code to track metrics
> within a single, named registry. This well-known-name then becomes a handle
> you can use to easily attach a Reporter and ship all of those metrics off-box.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
