hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Appy (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16800) Support for smart querying of our published jmx per server over http+json
Date Mon, 10 Oct 2016 21:13:20 GMT

    [ https://issues.apache.org/jira/browse/HBASE-16800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563522#comment-15563522

Appy commented on HBASE-16800:

To give more idea about numbers:
RS /jmx response is ~350kb (~200-300ms). Without server-side filtering, collecting metrics
for dashboard for a 1000node cluster will be 350M. Won't be possible to refresh dashboard
every 30sec.

With filtering (?qry=Hadoop:service=HBase,name=RegionServer,sub=Replication), it's just ~1kb
which totally makes it possible to have a dashboard which can be refreshed with a good cadence.
Thank [~stack] for figuring this out.

> Support for smart querying of our published jmx per server over http+json
> -------------------------------------------------------------------------
>                 Key: HBASE-16800
>                 URL: https://issues.apache.org/jira/browse/HBASE-16800
>             Project: HBase
>          Issue Type: Improvement
>          Components: metrics
>            Reporter: stack
>            Assignee: stack
>         Attachments: HBASE-16800.master.001.patch, HBASE-16800.master.002.patch
> We currently expose our jmx metrics via a json dump in a servlet at /jmx. You get all
or nothing (You can add a '?description=true' to get a description for each metric published
but that is it).
> A means of being able to query by metric or by a set of metrics would make graphing easier
to do, especially over http dumping json. In particular, our [~appy] is trying to put up pages
that give insight into current state of replication.
> Related, HBASE-11747 ClusterStatus is too bulky, is about how whenever we need a metric
'exposed', our only means is by bulking out the heartbeat adding payload on each message we
send the server (In the issue, w/ 1M regions, each RS is sending 100MB of 'status' every second).
We need to undo metrics collection from clusterstatus function
> Bonus if able to compress/cache payloads, security, etc.

This message was sent by Atlassian JIRA

View raw message