Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - HBASE-4089 & HBASE-4147 - on the topic of ops output


Copy link to this message
-
Re: HBASE-4089 & HBASE-4147 - on the topic of ops output
Fuad Efendi 2011-07-31, 22:10
What is it all about? HBase sucks. Too many problems to newcomers,
few-weeks-warm-up to begin with!!!!!!!!!!!!!!!! Is it really-really
supported by Microsoft employees?!


And, SEO of course:
==================

--
Fuad Efendi
416-993-2060
Tokenizer Inc., Canada
Data Mining, Search Engines
http://www.tokenizer.ca
On 11-07-29 7:49 PM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote:

>Hi,
>
>I'm for publishing all performance metrics in JMX (in addition to
>exposing it wherever else you guys decide).  That's because JMX is
>probably the easiest for our SPM for HBase [1] to get to HBase
>performance metrics and I suspect we are not alone.
>
>Otis
>[1] http://sematext.com/spm/hbase-performance-monitoring/index.html
>----
>Sematext :: http://sematext.com/ :: Solr - Lucene - Hadoop - HBase
>Hadoop ecosystem search :: http://search-hadoop.com/
>
>
>
>>________________________________
>>From: Andrew Purtell <[EMAIL PROTECTED]>
>>To: Doug Meil <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]"
>><[EMAIL PROTECTED]>
>>Sent: Friday, July 29, 2011 4:34 PM
>>Subject: Re: HBASE-4089 & HBASE-4147 - on the topic of ops output
>>
>>> I'd rather see this output being able to be captured by something the
>>>sink that Todd suggested, rather than focusing on shell access.
>>
>>
>>I don't agree.
>>
>>
>>Look at what we have existing and proposed:
>>
>>    - Java API access to server and region load information, that the
>>shell uses
>>
>>    - A proposal to dump some stats into log files, that then has to be
>>scraped
>>
>>    - A proposal (by the FB guys) to export some JSON via a HTTP servlet
>>
>>This is not good design, this is a bunch of random shit stuck together.
>>
>>Note that what Todd proposed does not preclude adding Java client API
>>support for retrieving it.
>>
>>At a minimum all of this information must be accessible via the Java
>>client API, to enable programmatic monitoring and analysis use cases.
>>I'll add the shell support if nobody else cares about it, that is a
>>relatively small detail, but one I think is important.
>>
>>Best regards,
>>
>>
>>    - Andy
>>
>>
>>Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>(via Tom White)
>>
>>
>>>________________________________
>>>From: Doug Meil <[EMAIL PROTECTED]>
>>>To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>;
>>>"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>>>Sent: Friday, July 29, 2011 11:39 AM
>>>Subject: Re: HBASE-4089 & HBASE-4147 - on the topic of ops output
>>>
>>>
>>>I'd rather see this output being able to be captured by something the
>>>sink
>>>that Todd suggested, rather than focusing on shell access.  HServerLoad
>>>is
>>>super-summary at the RS level, and both the items in 4089 and 4147 are
>>>proposed to be "summarized" but still have reasonable detail (e.g., even
>>>table/CF summary there could be dozens of entries given a reasonably
>>>complex system).
>>>
>>>
>>>
>>>
>>>On 7/29/11 1:15 PM, "Andrew Purtell" <[EMAIL PROTECTED]> wrote:
>>>
>>>>There is also the matter of HServerLoad and how that is used by the
>>>>shell
>>>>and master UI to report on cluster status.
>>>>
>>>>I'd like the shell to be able to let the user explore all of these
>>>>different reports interactively.
>>>>
>>>>At the very least, they should all be handled the same way.
>>>>
>>>>And then there is Riley's work over at FB on a slow query log. How does
>>>>that fit in?
>>>>
>>>>Best regards,
>>>>
>>>>
>>>>   - Andy
>>>>
>>>>Problems worthy of attack prove their worth by hitting back. - Piet
>>>>Hein
>>>>(via Tom White)
>>>>
>>>>
>>>>>________________________________
>>>>>From: Todd Lipcon <[EMAIL PROTECTED]>
>>>>>To: [EMAIL PROTECTED]
>>>>>Sent: Friday, July 29, 2011 9:58 AM
>>>>>Subject: Re: HBASE-4089 & HBASE-4147 - on the topic of ops output
>>>>>
>>>>>What I'd prefer is something like:
>>>>>
>>>>>interface BlockCacheReportSink {
>>>>>  public void reportStats(BlockCacheReport report);
>>>>>}
>>>>>
>>>>>class LoggingBlockCacheReportSink {