Anyway, for HBase, we'd better align our trace library with Hadoop, especially HDFS. A full trace from the hbase client down to the datanode will be really helpful for debugging and monitoring.
2018-07-31 6:06 GMT+08:00 Stack <st...@duboce.net>: > There is a healthy discussion going on over in HADOOP-15566 on tracing > in the Hadoop ecosystem. It would sit better on a mailing list than in > comments up on JIRA so here's an attempt at porting the chat here. > > Background/Context: Bits of Hadoop and HBase had Apache HTrace trace > points added. HTrace was formerly "incubating" at Apache but has since > been retired, moved to Apache Attic. HTrace and the efforts at > instrumenting Hadoop wilted for want of attention/resourcing. Our Todd > Lipcon noticed that the HTrace instrumentation can add friction on > some code paths so can actually be harmful even when disabled. The > natural follow-on is that we should rip out tracings of a "dead" > project. This then beggars the question, should something replace it > and if so what? This is where HADOOP-15566 is at currently. > > HTrace took two or three runs, led by various Heros, at building a > trace lib for Hadoop (first). It was trying to build the trace lib, a > store, and a visualizer. Always, it had a mechanism for dumping the > traces out to external systems for storage and viewing (e.g. Zipkin). > HTrace started when there was little else but the, you guessed it, > Google paper that described the Dapper system they had internally. > Since then, the world of tracing has come on in leaps and bounds with > healthy alternatives, communities, and even commercialization. > > If interested, take a read over HADOOP-15566. Will try and encourage > participants to move the chat here. > > Thanks, > St.Ack >
