[
https://issues.apache.org/jira/browse/SOLR-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-16073.
---------------------------------
Resolution: Invalid
_(Palm-to-face)_ Seeing NanoTimeTimerImpl.elapsed iml now, I see it's in
milliseconds already. Ugh; there begs to be javadocs on some of these methods
-- just a one liner, at least! I thought I had seen something suspicious but
perhaps not? Shrug.
Can you point to a specific example where we have a metric in nanoseconds?
I can see in SOLR-10226 that this totalTime was wanted by a user along with the
count to compute the average (aka "mean") without relying on the metric
published by Solr for this because Codahale puts an exponential decay on it.
[According to the Prometheus documentation on writing
exporters|https://prometheus.io/docs/instrumenting/writing_exporters/#drop-less-useful-statistics],
this "mean" and 1m, 5m, 15m rates should be dropped.
{quote}
Drop less useful statistics
Some instrumentation systems expose 1m, 5m, 15m rates, average rates since
application start (these are called mean in Dropwizard metrics for example) in
addition to minimums, maximums and standard deviations.
These should all be dropped, as they’re not very useful and add clutter.
Prometheus can calculate rates itself, and usually more accurately as the
averages exposed are usually exponentially decaying. You don’t know what time
the min or max were calculated over, and the standard deviation is
statistically useless and you can always expose sum of squares, _sum and _count
if you ever need to calculate it.
Quantiles have related issues, you may choose to drop them or put them in a
Summary.
{quote}
WDYT? (CC [~houston] [~matmarie])
> totalTime metric should be milliseconds (not nano)
> --------------------------------------------------
>
> Key: SOLR-16073
> URL: https://issues.apache.org/jira/browse/SOLR-16073
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
> Reporter: David Smiley
> Priority: Minor
>
> I observed that the "totalTime" metric has been a nanosecond number in recent
> years, yet once upon a time it was milliseconds. This change was very likely
> inadvertent. Our prometheus solr-exporter-config.xml shows that it thinks
> it's milliseconds. It's not; RequestHandlerBase increments this counter by
> "elapsed", the response of timer.stop() -- nanoseconds. Years ago it had
> invoked {{MetricUtils.nsToMs}} but it appears [~ab] removed this as a part of
> other changes in 2017 sometime --
> https://github.com/apache/solr/commit/d8df9f8c9963c2fc1718fd471316bf5d964125ba
> Also, I question the value/purpose of this metric. Is it so useful that it
> deserves to be among our relatively few metrics exported in our default
> prometheus exporter config? It's been there since the initial config but I
> wonder why anyone wants it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
