[
https://issues.apache.org/jira/browse/HBASE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600767#action_12600767
]
Jean-Daniel Cryans commented on HBASE-533:
------------------------------------------
bq. I also wonder about listing parent events in the daughters. A daughter from
a good family who can trace her roots all the ways back to the pilgrims will
have a long line in the table above. I think listing just the immediate parent
is sufficient, at least for the first version.
Or we can put the depth of history to keep as a parameter? Static or dynamic?
For the moment, I think it could just be a new conf in hbase-defaults.xml with
value at 1.
bq. What about listing the event source? Most edits will be by the master but
the splits will be done by the splitting regionserver.
If it's constant eg splits always on regionserver and creation always by
master, I don't think we need it. I see a case where this would be a problem.
For example, a user that never saw the code and for some reason uses this
information, he would need to know that. But since this feature is for devs
purpose and we know how it works, it shouldn't be a problem. Your opinion?
bq. Regards double creations, I'd guess its not two creations - just two
invocations of the HRegion constructor. Opening and creating both call new
HRegion. You might move our call to addRegionCreation out of the HRegion
constructor and instead put it into HRegion.createHRegion (if this is
appropriately called in all places a region is initially created).
I'll debug that.
bq. Dynamic would be nice - like log level? Tying it to loglevel would make
your flag easy to implement: e.g. send compaction/flush notice when at DEBUG.
Bad thing about tying it to loglevel doesn't have sufficient granularity.
There's effectively INFO and DEBUG. What you think?
Good idea, for the first version I'll do it like that. We'll see if we need
more in the future.
Good stuff.
> Region Historian
> ----------------
>
> Key: HBASE-533
> URL: https://issues.apache.org/jira/browse/HBASE-533
> Project: Hadoop HBase
> Issue Type: Wish
> Reporter: Bryan Duxbury
> Assignee: Jean-Daniel Cryans
> Priority: Minor
> Attachments: hbase-533-v1-fix.patch, hbase-533-v1.patch
>
>
> Whenever we try to debug region splitting, assignment, compaction, etc.
> issues, we always end up having to look in 1-20 different log files for
> cryptic names of regions and try to piece together the chain of events
> ourselves. This is a challenging at best effort most of the time.
> What would be very useful would be a new utility I've nicknamed the Region
> Historian. You give it the text name of a region, and it will track down the
> log messages relevant to it in the master and regionserver logs. Then, it
> will interleave the messages in such a way that the timestamps correctly list
> the order of events. The result is a log summary that accurately describes
> what happened to a region during it's lifetime, making it much easier to try
> and figure out where something went wrong.
> Other things it could do would be replace cryptic log messages with simple
> events like "the region was split into a and b", "the region was assigned to
> server x", and trace the lineage of a region backwards to its parent before
> it came into existence.
> I'm sure there are other things we would think up that would be useful as
> well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
