lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-8785) Use Metrics library for core metrics
Date Wed, 23 Nov 2016 17:51:59 GMT

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

ASF subversion and git services commented on SOLR-8785:
-------------------------------------------------------

Commit f8fa2e998d094223702e12d7bd8a84985859a747 in lucene-solr's branch refs/heads/master
from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f8fa2e9 ]

SOLR-8785: Use per-second rates for consistency in all stats outputs


> 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
>            Assignee: Shalin Shekhar Mangar
>              Labels: patch, patch-available
>             Fix For: master (7.0), 6.4
>
>         Attachments: SOLR-8785-increment.patch, SOLR-8785.patch, SOLR-8785.patch, SOLR-8785.patch,
SOLR_8775_rates_per_minute_fix.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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message