[ https://issues.apache.org/jira/browse/SOLR-8785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684725#comment-15684725 ]
Jeff Wartes commented on SOLR-8785: ----------------------------------- Understood, I'm all for incremental change, and I don't see "how to make a Reporter" as part of this issue. I will be slightly disappointed though, if we convert to the library without also providing a recommended access path for the use of that library. Gathering metrics you can't report on is useless, and one of the things I liked about the original patch was this: {code} if(this.pluginInfo==null) { // if a request handler has a name, use a persistent, reportable timer under that name if (pluginInfo.name != null) requestTimes = Metrics.namedTimer(Metrics.mkName(this.getClass(), pluginInfo.name), REGISTRY_NAME); this.pluginInfo = pluginInfo; } {code} This meant that I automatically got access to all the relevant metrics for any named request handler, using any Reporters (Log, JMX, Graphite, whatever) I cared to attach. This, in turn, was only possible because all those metrics were in a well-defined and accessible location. > 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, > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org