[
https://issues.apache.org/jira/browse/HBASE-20603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489124#comment-16489124
]
Josh Elser commented on HBASE-20603:
------------------------------------
{quote}Makes thresholded alerting on min or max measured values over the
reporting interval possible. Otherwise the alarm cannot be deasserted until the
process restarts. It is definitely a change in semantics but debatable if what
was originally intended.
{quote}
Ah, good point. I was going to ask why not have a separate metric which tracks
min/max as its currently done, but you already covered that :)
I think instead I want to ask: is there a larger time-bound which would be
useful to monitor min/max on? e.g. 4 or 8hr windows? I think we could easily
hide this behind the metrics-api as an implementation detail (not force our
hbase-server code to write to yet another metric object.
+1 on the idea.
My only concern is extra garbage creation (and I'm not sure if it needs to be a
concern). Do you think creating a new FastLongHistogram on every metrics
snapshot (and all of the stuff inside of it) a concern, [~apurtell]?
> Histogram metrics should reset min and max
> ------------------------------------------
>
> Key: HBASE-20603
> URL: https://issues.apache.org/jira/browse/HBASE-20603
> Project: HBase
> Issue Type: Bug
> Components: metrics
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Priority: Minor
> Attachments: HBASE-20603-branch-1-WIP.patch
>
>
> It's weird that the bins are reset at every monitoring interval but min and
> max are tracked over the lifetime of the process. Makes it impossible to set
> alarms on max value as they'll never shut off unless the process is
> restarted. Histogram metrics should reset min and max at snapshot time too.
> For discussion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
