Git Product home page Git Product logo

hannibal's Introduction

Hannibal

Hannibal is a tool to help monitor and maintain HBase-Clusters that are configured for manual splitting.

While HBase provides metrics to monitor overall cluster health via JMX or Ganglia, it lacks the ability to monitor single regions in an easy way. This information is essential when your cluster is configured for manual splits, especially when the data growth is not uniform.

This tool tries to fill that gap by answering the following questions:

  • How well are regions balanced over the cluster?
  • How well are the regions split for each table?
  • How do regions evolve over time?

Requirements & Limitations

Java 6 JDK is required on the machine where this tool is built.

You will also need a browser with SVG-Support to display Hannibal's graphs.

HBase Compatibilty

Hannibal currently supports HBase versions 0.90 to 0.98. The Scala-sources are currently compiled with Apache HBase versions wherever possible, you can try to alter the version in project/Build.scala if you wish to.

Quickstart

Variant 1: From Binary Package

  1. Download and extract the package according to your HBase version. Grab the Download-URL for the correct HBase-Version from the Release-Page and extract it:

    $ wget <URL-TO-PACKAGE>
    $ tar -xf "hannibal-hbase*.tgz"
    $ cd hannibal
    
  2. Copy conf/hbase-site.template.xml to conf/hbase-site.xml and adjust it:

    $ cp conf/hbase-site.template.xml conf/hbase-site.xml
    $ vi conf/hbase-site.xml
    
  3. Run the start script inside the root folder of the project:

    $ ./start
    

When the application has started, you can access the web UI at: http://localhost:9000

Please note that history data about regions is only collected while the application is running, it will need to run for some time until the region detail graphs fill up.

For information about the usage, check out the Usage page on our Wiki.

Variant 2: From Source

  1. Grab the sources from github:

    $ git clone https://github.com/sentric/hannibal.git
    $ cd hannibal
    
  2. Set the Environmentvariable HANNIBAL_HBASE_VERSION according to your HBase version. For example for HBase 0.98 do:

    $ export HANNIBAL_HBASE_VERSION=0.98
    

    Other possible values are "0.90", "0.94", "0.96" or "0.98". Be sure to always have this environment-variable set before executing build or start scripts.

  3. Copy conf/hbase-site.template.xml to conf/hbase-site.xml and adjust it.

  4. Build the project using the build script inside the root folder of the project:

    $ ./build
    
  5. Run the start script inside the root folder of the project:

    $ ./start
    

The first time you build, sbt will fetch all dependencies needed to build and run the the application. It will take a few minutes to build.

When the application has started, you can access the web UI at: http://localhost:9000

Please note that history data about regions is only collected while the application is running, it will need to run for some time until the region detail graphs fill up.

For information about the usage, check out the Usage page on our Wiki.

There is also a tutorial video on [YouTube][yt], that shows how to install and use Hannibal for HBase 0.90. [yt]: http://www.youtube.com/watch?v=gu0lGAf7JO8

Hue Integration

There is also Hue App to integrate Hannibal into Hue. It is available here.

Hannibal Mobile

If you have an Android Device, you might be interested in the Mobile App. The App which can be downloaded from Google Play. Further details can be found in the Wiki.

Authentication

If you want to make Hannibal reachable from the Internet, it's recommended to put a web server in front of it that takes care of handling authentication. Instructions can be found in the Wiki.

How to display compactions

HBase 0.90.x's API doesn't allow you to query information on running compactions directly, so what we do is to parse the RegionServers' log files directly, which are available through the service interface. HBase 0.92 and up allows you to query compactions directly, but we still collect compactions using the logfile-parsing technique, because this way we don't miss any short running compactions. The downside is that this doesn't work out of the box for all HBase clusters because either, the path-pattern or the date-pattern can differ from system to system. Another problem can be, that the compaction-information isn't logged at all in your setup, because your LogLevel is set too high.

If you run into problems with the the compaction-metrics, you should check the following parameters in conf/application.conf.

1. logfile.path-pattern

The default of the logfile.path-pattern is

logfile.path-pattern = "(?i)\"/logs/(.*regionserver.*[.].*)\""

The defaults should work for most setups in distributed mode. For standalone mode you will need change the pattern to

logfile.path-pattern = (?i)\"/logs/(.*master.*[.].*)\"

If you are still unsure about the correct path-pattern, you can get a hint for the correct pattern by looking at your log-listing http://<<some-regionserver>>:60030/logs/.

2. logfile.date-format

The default logfile.date-format is

logfile.date-format = "yyyy-MM-dd HH:mm:ss,SSS"

You can figure out the correct date-format by looking inside a logfile within your log-listing at http://<<some-regionserver>>:60030/logs/

3. logfile.set-loglevels-on-startup

Informations about compactions are logged by HBase with INFO-Level, so the log-level for your HBase-Regionservers need to be set at least to INFO.

Hannibal can set the log level to INFO for you, just edit conf/application.conf and set

logfile.set-loglevels-on-startup = true

If this doesn't work for you, you should try to manually change the loglevel on your regionservers.

4. logfileParser.overrideCompactionRegexPattern

Hannibal has been already been configured to look for the INFO message containing compaction metrics (with some default regex patterns depending on the version of hbase.) Some times the INFO message logged might not match with the default regex pattern(maybe its different distribution of base), which would result in you not being able to see the compaction metrics.

if this is the case, you can set the regex pattern via this variable example: logfileParser.overrideCompactionRegexPattern="""^(.) INFO (.).CompactionRequest: completed compaction: regionName=(..), storeName=(.), fileCount=(.), fileSize=(.), priority=(.), time=(.); duration=(.*)$"""

Also set the positions of the date/region/duration groups in the above regex via the following parameters:

logfileParser.dateGroupPosition=1 logfileParser.regionGroupPosition=3 logfileParser.durationGroupPosition=9

i.e. date occurs as the first group, region as the third group and duration as the ninth group in the above example regex pattern

Tuning for large clusters

Hannibal is not yet ready to be used on large clusters (say about more than 100 machines), however some work has been done (thanks to Alexandre Normand and churrodog) to make it at least possible to run it without crashing on mid-sized clusters. If Hannibal's performance is not sufficient with your HBase setup, it may help to tune the following parameters in conf/application.conf.

metrics.logfile-fetch-interval

This defaults to 300 seconds and it defines how often logfiles are collected from the different region servers. This process is quite heavy and for big clusters you should consider either to increase the interval or to disable it altogether by setting it to 0

metrics.logfile-fetch-interval = 0 # Disables compaction-metrics

metrics.regions-fetch-interval

This defaults to 60 seconds and you usually want to keep the update-interval high, because this way the UI will present you the most recent values and also will the region-history graph. However if you have many regions and it takes long to update the region metrics you may set this one to a value up to about 1800 (= 30 Minutes).

metrics.regions-fetch-interval = 600 # 10 Minutes

metrics.clean-threshold and metrics.clean-interval

Old metrics are cleaned after one day by default and it makes sense since the region history graphs are presenting data up to one day. However if you have a very large number of regions and your H2 database just explodes you may consider to reduce them.

Deployment

If you intend to run Hannibal on a different host from where you want to build it, then you can run

./create_package

This script generates a tgz-package inside the target folder, which you can then deploy on your target server. The HBase version can be set with the HANNIBAL_HBASE_VERSION environment variable, as described in the quickstart section.

More Information

More information about the tool can be found in the Wiki

License

Hannibal is released under MIT License, see LICENSE for details.

Contact

If you need additional features or help please get in touch with us. Subscribe to the Hannibal mailing list or follow Hannibal App on Twitter.

Contributors

This tool was developed at Sentric by Nils Kübler and Jiayong Ou. Sentric has been acquired by YMC AG in May 2013.

With help from:

githalytics.com alpha

hannibal's People

Contributors

adrien-mogenet avatar alexandre-normand avatar dd-guo avatar jaihind213 avatar jou avatar meniku avatar vmorarian avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

hannibal's Issues

Handle different log file format across region servers

Current code assumes that the log file name format is same on all region servers. Typically on production clusters, log file have hostname in their names. In that case, the current code only fetches log files from the first region server it can find a match for.

For eg: In my test VM cluster, I have two region servers vm2 and vm3. Hannibal runs on vm1. The pattern matcher matches logfile.path-pattern: hbase-hbase-regionserver-vm2.log. Hannibal then correctly downloads log file for VM2: http://vm2.example.com:60030/logs/hbase-hbase-regionserver-vm2.log. But it failed trying to download the same file on VM3:
2015-04-16 16:24:42 -0400 - [ERROR] - from akka.actor.OneForOneStrategy in application-akka.actor.default-dispatcher-7 couldn't load Compaction Metrics from URL: 'http://vm3.example.com:60030/logs/hbase-hbase-regionserver-vm2.log (statusCode was: 404). For VM3, the file should have been http://vm3.example.com:60030/logs/hbase-hbase-regionserver-vm3.log.

The code should have a log file pattern per region server.

JdbcSQLException: Timeout trying to lock table "METRIC" when visiting /compactions

HBase version: 0.94.15

Hannibal has been running for several months. Today when I try to open the compactions page, the server returns an error page (The other pages like tables/regions are good).The logs/application.log file shows:

2015-01-31 03:31:14,741 - [ERROR] - from application in play-akka.actor.actions-dispatcher-1167 


! @6ieie9fjm - Internal server error, for request [GET /compactions] ->

play.core.ActionInvoker$$anonfun$receive$1$$anon$1: Execution exception [[JdbcSQLException: Timeout trying to lock table "METRIC"; SQL statement:
SELECT       id, target, name, last_value, last_update, target_desc     FROM       metric     WHERE       name=? [50200-158]]]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:134) [play_2.9.1-2.0.4.jar:2.0.4]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:115) [play_2.9.1-2.0.4.jar:2.0.4]
    at akka.actor.Actor$class.apply(Actor.scala:318) [akka-actor-2.0.2.jar:2.0.2]
    at play.core.ActionInvoker.apply(Invoker.scala:113) [play_2.9.1-2.0.4.jar:2.0.4]
    at akka.actor.ActorCell.invoke(ActorCell.scala:626) [akka-actor-2.0.2.jar:2.0.2]
    at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:197) [akka-actor-2.0.2.jar:2.0.2]
    at akka.dispatch.Mailbox.run(Mailbox.scala:179) [akka-actor-2.0.2.jar:2.0.2]
    at akka.dispatch.ForkJoinExecutorConfigurator$MailboxExecutionTask.exec(AbstractDispatcher.scala:516) [akka-actor-2.0.2.jar:2.0.2]
    at akka.jsr166y.ForkJoinTask.doExec(ForkJoinTask.java:259) [akka-actor-2.0.2.jar:2.0.2]
    at akka.jsr166y.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:975) [akka-actor-2.0.2.jar:2.0.2]
    at akka.jsr166y.ForkJoinPool.runWorker(ForkJoinPool.java:1479) [akka-actor-2.0.2.jar:2.0.2]
    at akka.jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:104) [akka-actor-2.0.2.jar:2.0.2]
Caused by: org.h2.jdbc.JdbcSQLException: Timeout trying to lock table "METRIC"; SQL statement:
SELECT       id, target, name, last_value, last_update, target_desc     FROM       metric     WHERE       name=? [50200-158]
    at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.message.DbException.get(DbException.java:169) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.message.DbException.get(DbException.java:146) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.table.RegularTable.doLock(RegularTable.java:506) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.table.RegularTable.lock(RegularTable.java:440) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.table.TableFilter.lock(TableFilter.java:142) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.command.dml.Select.queryWithoutCache(Select.java:590) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.command.dml.Query.query(Query.java:298) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.command.dml.Query.query(Query.java:268) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.command.dml.Query.query(Query.java:37) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.command.CommandContainer.query(CommandContainer.java:80) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.command.Command.executeQuery(Command.java:181) ~[h2-1.3.158.jar:1.3.158]
    at org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:96) ~[h2-1.3.158.jar:1.3.158]
    at com.jolbox.bonecp.PreparedStatementHandle.executeQuery(PreparedStatementHandle.java:172) ~[bonecp-0.7.1.RELEASE.jar:0.7.1.RELEASE]
    at anorm.Sql$class.resultSet(Anorm.scala:429) ~[anorm_2.9.1-2.0.4.jar:2.0.4]
    at anorm.SimpleSql.resultSet(Anorm.scala:359) ~[anorm_2.9.1-2.0.4.jar:2.0.4]
    at anorm.Sql$class.apply(Anorm.scala:427) ~[anorm_2.9.1-2.0.4.jar:2.0.4]
    at anorm.SimpleSql.apply(Anorm.scala:359) ~[anorm_2.9.1-2.0.4.jar:2.0.4]
    at models.MetricDef$$anonfun$findByName$1.apply(Metric.scala:73) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at models.MetricDef$$anonfun$findByName$1.apply(Metric.scala:72) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at play.api.db.DBApi$class.withConnection(DB.scala:79) ~[play_2.9.1-2.0.4.jar:2.0.4]
    at play.api.db.BoneCPApi.withConnection(DB.scala:273) ~[play_2.9.1-2.0.4.jar:2.0.4]
    at play.api.db.DB$$anonfun$withConnection$3.apply(DB.scala:158) ~[play_2.9.1-2.0.4.jar:2.0.4]
    at play.api.db.DB$$anonfun$withConnection$3.apply(DB.scala:158) ~[play_2.9.1-2.0.4.jar:2.0.4]
    at scala.Option.map(Option.scala:133) ~[scala-library.jar:na]
    at play.api.db.DB$.withConnection(DB.scala:158) ~[play_2.9.1-2.0.4.jar:2.0.4]
    at models.MetricDef$.findByName(Metric.scala:72) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at utils.MetricUtil$.findLongestCompactionInLastWeek(MetricUtil.scala:39) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at controllers.Compactions$$anonfun$index$1.apply(Compactions.scala:13) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at controllers.Compactions$$anonfun$index$1.apply(Compactions.scala:12) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at play.api.mvc.Action$$anon$1.apply(Action.scala:170) ~[play_2.9.1-2.0.4.jar:2.0.4]
    at play.core.ActionInvoker$$anonfun$receive$1$$anonfun$6.apply(Invoker.scala:126) ~[play_2.9.1-2.0.4.jar:2.0.4]
    at play.core.ActionInvoker$$anonfun$receive$1$$anonfun$6.apply(Invoker.scala:126) ~[play_2.9.1-2.0.4.jar:2.0.4]
    at play.utils.Threads$.withContextClassLoader(Threads.scala:17) ~[play_2.9.1-2.0.4.jar:2.0.4]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:125) [play_2.9.1-2.0.4.jar:2.0.4]
    ... 11 common frames omitted

Here are the files in data/ foder:

$ ls -lh data/
total 118M
-rw-r--r-- 1 user group  40M Sep 20 14:38 metrics.h2.h2.db
-rw-r--r-- 1 user group  9 09:42 metrics.h2.lock.db
-rw-r--r-- 1 user group 18M Jan 31 03:42 metrics.h2.trace.db
-rw-r--r-- 1 user group 65M Dec 24 04:38 metrics.h2.trace.db.old

Hannibal with HBase 1.0.0 version

Hi Guys,

I am trying to build Hannibal with HBase 1.0.0 version. Build is successful but while starting Hannibal below error is thrown in the console,

Play server process ID is 4559
[info] play - database [default] connected at jdbc:h2:data/metrics.h2
[error] application - Could not instanciate any api wrapper, Hannibal will now exit

Any help would be much appreciated.

Usability of Cluster screen

A list of usability issues:

  • List of tables is not sorted, making it very difficult to find a certain table
  • if table names are longer than allocated space the panel will grow to show the longest name, overrunning the graphs
  • deselecting tables needs to be done one by one. so if I am only interested in one table, i need to go over all of them, deselect, and then select only the one I'm interested in
  • after selecting only the tables i am interested in, if I 'drill down' into a table and return to the cluster screen, it is reset to 'all tables'

compaction history chart duration

hi, I'm using hannibal in a product environments, when I met a problem that in compaction history chart /compactions, the chart only show compactions of last 24 hour, I want that to be longer.
Is there any configurations that could help this problem?

ps: I already set "metrics.clean-threshold" to a week in conf/application.conf,
and "metrics.clean-interval" is default 43200.

Exception occurred while waiting for cluster table to show up

  • Started hannibal
  • pointed to localhost:9000
  • after ~4 minutes the following exception showed up in the logs, and the browser showed 'done with errors' and a blank page.
  • immediately after that i tried opening localhost:9000 from chrome and it opened fine

[info] application - start updating CompactionMetrics... (Fri Dec 14 17:55:12 IS
T 2012)
[ERROR] [12/14/2012 17:55:17.863] [application-akka.actor.default-dispatcher-11]
[akka://application/user/updateMetricsActor] Promise timed out after 5000 : MIL
LISECONDS
java.util.concurrent.TimeoutException: Promise timed out after 5000 : MILLISECON
DS
at play.api.libs.concurrent.STMPromise$$anonfun$await$1.apply(Promise.sc
ala:158)
at play.api.libs.concurrent.STMPromise$$anonfun$await$1.apply(Promise.sc
ala:154)
at scala.concurrent.stm.ccstm.InTxnImpl.runBlock(InTxnImpl.scala:538)
at scala.concurrent.stm.ccstm.InTxnImpl.topLevelAttempt(InTxnImpl.scala:
494)
at scala.concurrent.stm.ccstm.InTxnImpl.topLevelAtomicImpl(InTxnImpl.sca
la:365)
at scala.concurrent.stm.ccstm.InTxnImpl.atomic(InTxnImpl.scala:244)
at scala.concurrent.stm.ccstm.CCSTMExecutor.apply(CCSTMExecutor.scala:24
)
at play.api.libs.concurrent.STMPromise.await(Promise.scala:154)
at play.api.libs.concurrent.Promise$class.await(Promise.scala:55)
at play.api.libs.concurrent.STMPromise.await(Promise.scala:110)
at play.api.libs.concurrent.Promise$class.value(Promise.scala:53)
at play.api.libs.concurrent.STMPromise.value(Promise.scala:110)
at models.Compaction$$anonfun$all$1.apply(Compaction.scala:64)
at models.Compaction$$anonfun$all$1.apply(Compaction.scala:61)
at utils.HBaseConnection$$anonfun$eachServer$1$$anonfun$apply$2.apply(HB
aseConnection.scala:37)
at utils.HBaseConnection$$anonfun$eachServer$1$$anonfun$apply$2.apply(HB
aseConnection.scala:36)
at scala.collection.Iterator$class.foreach(Iterator.scala:660)
at scala.collection.JavaConversions$JIteratorWrapper.foreach(JavaConvers
ions.scala:573)
at scala.collection.IterableLike$class.foreach(IterableLike.scala:73)
at scala.collection.JavaConversions$JCollectionWrapper.foreach(JavaConve
rsions.scala:592)
at utils.HBaseConnection$$anonfun$eachServer$1.apply(HBaseConnection.sca
la:36)
at utils.HBaseConnection$$anonfun$eachServer$1.apply(HBaseConnection.sca
la:33)
at utils.HBaseConnection$class.withHBaseAdmin(HBaseConnection.scala:47)
at models.Compaction$.withHBaseAdmin(Compaction.scala:17)
at utils.HBaseConnection$class.eachServer(HBaseConnection.scala:33)
at models.Compaction$.eachServer(Compaction.scala:17)
at models.Compaction$.all(Compaction.scala:60)
at actors.UpdateMetricsActor$$anonfun$receive$1$$anonfun$apply$2.apply$m
cI$sp(UpdateMetricsActor.scala:44)
at actors.UpdateMetricsActor.updateMetrics(UpdateMetricsActor.scala:75)
at actors.UpdateMetricsActor$$anonfun$receive$1.apply(UpdateMetricsActor
.scala:42)
at actors.UpdateMetricsActor$$anonfun$receive$1.apply(UpdateMetricsActor
.scala:21)
at akka.actor.Actor$class.apply(Actor.scala:318)
at actors.UpdateMetricsActor.apply(UpdateMetricsActor.scala:20)
at akka.actor.ActorCell.invoke(ActorCell.scala:626)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:197)
at akka.dispatch.Mailbox.run(Mailbox.scala:179)
at akka.dispatch.ForkJoinExecutorConfigurator$MailboxExecutionTask.exec(
AbstractDispatcher.scala:516)
at akka.jsr166y.ForkJoinTask.doExec(ForkJoinTask.java:259)
at akka.jsr166y.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:975)
at akka.jsr166y.ForkJoinPool.runWorker(ForkJoinPool.java:1479)
at akka.jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:104)

@Gissues:{"order":20,"status":"backlog"}

Value too long for column

Hello,

I am attempting to use Hannibal to help me monitor my hbase cluster, 8 nodes. Our cluster is mainly used for opentsdb.

Hannibal was easy enough to compile and get working. As I tail the log file however I am seeing it complaining about the names of my regions being to long to insert into it's database.

[info] application - creating new metric for 91c9b9cb89499fb89d53bbfbe03f63ab : storefileSizeMB
[ERROR] [09/04/2013 10:49:33.669] [application-akka.actor.default-dispatcher-40] [akka://application/user/updateMetricsActor] Value too long for column "TARGET_DESC VARCHAR(255) DEFAULT '-unkown-' SELECTIVITY 25": "'tsdb,\x00\x00\x16Q\x12\x8C\x10\x00\x00\x01\x00\x19x\x00\x00\x02\x00\x00\x02\x00\x00\x03\x00\x19t\x00\x00\x04\x00\x00\x04\x00\x0... (261)"; SQL statement:
INSERT INTO metric(target, name, last_value, last_update, target_desc) VALUES (?, ?, 0.0, 0, ?) [22001-158]
org.h2.jdbc.JdbcSQLException: Value too long for column "TARGET_DESC VARCHAR(255) DEFAULT '-unkown-' SELECTIVITY 25": "'tsdb,\x00\x00\x16Q\x12\x8C\x10\x00\x00\x01\x00\x19x\x00\x00\x02\x00\x00\x02\x00\x00\x03\x00\x19t\x00\x00\x04\x00\x00\x04\x00\x0... (261)"; SQL statement:
INSERT INTO metric(target, name, last_value, last_update, target_desc) VALUES (?, ?, 0.0, 0, ?) [22001-158]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.table.Column.validateConvertUpdateSequence(Column.java:319)
at org.h2.table.Table.validateConvertUpdateSequence(Table.java:679)
at org.h2.command.dml.Insert.insertRows(Insert.java:120)
at org.h2.command.dml.Insert.update(Insert.java:84)
at org.h2.command.CommandContainer.update(CommandContainer.java:71)
at org.h2.command.Command.executeUpdate(Command.java:212)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:143)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:129)
at com.jolbox.bonecp.PreparedStatementHandle.executeUpdate(PreparedStatementHandle.java:203)
at anorm.Sql$class.execute1(Anorm.scala:447)
at anorm.SimpleSql.execute1(Anorm.scala:359)
at anorm.Sql$class.executeInsert(Anorm.scala:454)
at anorm.SimpleSql.executeInsert(Anorm.scala:359)
at models.MetricDef$$anonfun$find$1.apply(Metric.scala:41)
at models.MetricDef$$anonfun$find$1.apply(Metric.scala:36)
at play.api.db.DBApi$class.withConnection(DB.scala:79)
at play.api.db.BoneCPApi.withConnection(DB.scala:273)
at play.api.db.DB$$anonfun$withConnection$3.apply(DB.scala:158)
at play.api.db.DB$$anonfun$withConnection$3.apply(DB.scala:158)
at scala.Option.map(Option.scala:133)
at play.api.db.DB$.withConnection(DB.scala:158)
at models.MetricDef$.find(Metric.scala:36)
at models.MetricDef$.findRegionMetricDef(Metric.scala:33)
at models.MetricDef$.STOREFILE_SIZE_MB(Metric.scala:22)
at actors.UpdateMetricsActor$$anonfun$receive$1$$anonfun$apply$1$$anonfun$apply$mcI$sp$1.apply(UpdateMetricsActor.scala:30)
at actors.UpdateMetricsActor$$anonfun$receive$1$$anonfun$apply$1$$anonfun$apply$mcI$sp$1.apply(UpdateMetricsActor.scala:29)
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
at scala.collection.immutable.List.foreach(List.scala:45)
at actors.UpdateMetricsActor$$anonfun$receive$1$$anonfun$apply$1.apply$mcI$sp(UpdateMetricsActor.scala:29)
at actors.UpdateMetricsActor.updateMetrics(UpdateMetricsActor.scala:87)
at actors.UpdateMetricsActor$$anonfun$receive$1.apply(UpdateMetricsActor.scala:26)
at actors.UpdateMetricsActor$$anonfun$receive$1.apply(UpdateMetricsActor.scala:23)
at akka.actor.Actor$class.apply(Actor.scala:318)
at actors.UpdateMetricsActor.apply(UpdateMetricsActor.scala:22)
at akka.actor.ActorCell.invoke(ActorCell.scala:626)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:197)
at akka.dispatch.Mailbox.run(Mailbox.scala:179)
at akka.dispatch.ForkJoinExecutorConfigurator$MailboxExecutionTask.exec(AbstractDispatcher.scala:516)
at akka.jsr166y.ForkJoinTask.doExec(ForkJoinTask.java:259)
at akka.jsr166y.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:975)
at akka.jsr166y.ForkJoinPool.runWorker(ForkJoinPool.java:1479)
at akka.jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:104)

Thanks,

Jesus Orosco

Rotating LogFiles cause Http Status 416 Errors

When a HBase LogFile gets rotated, following attempts to collect new portions of the logfile cause Http Status 416 Errors:

[ERROR] [02/07/2013 00:00:49.464] [application-akka.actor.default-dispatcher-3] [akka://application/user/updateMetricsActor] couldn't load Compaction Metrics from URL: 'http://c1-s5.cluster:60030/logs/hbase-hbase-regionserver-c1-s5.log (statusCode was: 416) 

Wikipedia describes Http Status Errors 416 as:

416 Requested Range Not Satisfiable
The client has asked for a portion of the file, but the server cannot supply that portion.[2] For example, if the client asked for a part of the file that lies beyond the end of the file.[2]

We could add a check for code 416 to the LogFile class, reset the logOffsets and then try again to fetch the logfile. Would that work?

Does not work for large clusters

I built hannibal, changed the storage layer to mysql from h2 and we have around 1000 regionservers with around 300k regions in total. Because so much of the logic is done at the view layer it takes minutes to load. The response size for some of the requests is > 200 MB and too much of the logic in terms of sorting and combining is done at the view layer. Thus making hannibal which is an awesome tool unusable.

Make sorting of tables chart optional

When I view the regions for a table, it is sorted decreasing by region size. I would prefer if this sorting was optional so that I can view the regions sorted by keys.

This is useful for people who are manually managing the splits of a particular table, so that we can easily spot which regions to split/merge.

can not load page: MasterNotRunningException

I have setup conf/hbase-site.xml properly, but get MasterNotRunningException as follows. Any clues?

! @6e7mlmi15 - Internal server error, for request [GET /] ->

play.core.ActionInvoker$$anonfun$receive$1$$anon$1: Execution exception [[MasterNotRunningException: Retried 10 times]]
at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:134) [play_2.9.1-2.0.4.jar:2.0.4]
at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:115) [play_2.9.1-2.0.4.jar:2.0.4]
at akka.actor.Actor$class.apply(Actor.scala:318) [akka-actor-2.0.2.jar:2.0.2] at play.core.ActionInvoker.apply(Invoker.scala:113) [play_2.9.1-2.0.4.jar:2.0.4]
at akka.actor.ActorCell.invoke(ActorCell.scala:626) [akka-actor-2.0.2.jar:2.0.2]
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:197) [akka-actor-2.0.2.jar:2.0.2]
at akka.dispatch.Mailbox.run(Mailbox.scala:179) [akka-actor-2.0.2.jar:2.0.2]
at akka.dispatch.ForkJoinExecutorConfigurator$MailboxExecutionTask.exec(AbstractDispatcher.scala:516) [akka-actor-2.0.2.jar:2.0.2] at akka.jsr166y.ForkJoinTask.doExec(ForkJoinTask.java:259) [akka-actor-2.0.2.jar:2.0.2]
at akka.jsr166y.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:975) [akka-actor-2.0.2.jar:2.0.2]
at akka.jsr166y.ForkJoinPool.runWorker(ForkJoinPool.java:1479) [akka-actor-2.0.2.jar:2.0.2]
at akka.jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:104) [akka-actor-2.0.2.jar:2.0.2]
Caused by: org.apache.hadoop.hbase.MasterNotRunningException: Retried 10 times
at org.apache.hadoop.hbase.client.HBaseAdmin.(HBaseAdmin.java:120) ~[hbase-0.90.5.jar:0.90.5]
at models.HBase$class.withAdmin(HBase.scala:42) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
at models.hbase090.HBase090.withAdmin(HBase090.scala:9) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
at models.hbase090.HBase090.eachRegionServer(HBase090.scala:11) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
at models.Region$.all(Region.scala:71) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
at controllers.Application$$anonfun$index$1.apply(Application.scala:13) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
at controllers.Application$$anonfun$index$1.apply(Application.scala:12) ~[hannibal_2.9.1-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
at play.api.mvc.Action$$anon$1.apply(Action.scala:170) ~[play_2.9.1-2.0.4.jar:2.0.4]
at play.core.ActionInvoker$$anonfun$receive$1$$anonfun$6.apply(Invoker.scala:126) ~[play_2.9.1-2.0.4.jar:2.0.4]
at play.core.ActionInvoker$$anonfun$receive$1$$anonfun$6.apply(Invoker.scala:126) ~[play_2.9.1-2.0.4.jar:2.0.4]
at play.utils.Threads$.withContextClassLoader(Threads.scala:17) ~[play_2.9.1-2.0.4.jar:2.0.4]
at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:125) [play_2.9.1-2.0.4.jar:2.0.4]
... 11 common frames omitted

Region view doesn't show correct region when start/end keys are non-printable characters

We have tables that use a 1-byte hash prefix and we noticed that when navigating with hannibal and clicking on the regions that have non-printable characters in the start/end, the region displayed is not the correct one.

Here's a screenshot showing the problem. The region hover details showed the same region name as we can see in the URL but the region name in the page itself doesn't match the region name of the url.

bug with unreadable start keys

I haven't looked at the hannibal code in a while but it seems like there's a need for properly encoding/decoding values that can be bytes (not necessarily strings) and might get lost when formatted as strings.

Use username in compactions.logfile-url-pattern

The default compactions.logfile-url-pattern in conf/application.conf:

"http://%hostname%:%infoport%/logs/hbase-hbase-regionserver-%hostname%.log"

almost works 'out of the box.' However, not everyone runs hbase as the 'hbase' user. If the default became instead:

"http://%hostname%:%infoport%/logs/hbase-%username%-regionserver-%hostname%.log"

then this pattern would work for more people.

This change requires updating the model:

app/models/RegionServer.scala

to define a username field and to replace '%username%' in the URL string.

I am uncertain however if the username can easily be queried from HBase.

Update Compaction Patterns for HBase 0.96 ...

... or find an alternative way.

The pattern changed from 0.94 to 0.96.

Sample 1:

2014-07-01 14:25:00,291 INFO org.apache.hadoop.hbase.regionserver.HRegion: Starting compaction on info in region user,,1404208506577.e4983164a0c3affb94b84d16f8addb32.
2014-07-01 14:25:00,450 INFO org.apache.hadoop.hbase.regionserver.HStore: Starting compaction of 3 file(s) in info of user,,1404208506577.e4983164a0c3affb94b84d16f8addb32. into tmpdir=hdfs://nameservice1/hbase/data/default/user/e4983164a0c3affb94b84d16f8addb32/.tmp, totalSize=17.3 M
2014-07-01 14:25:01,852 INFO org.apache.hadoop.hbase.regionserver.HStore: Completed major compaction of 3 file(s) in info of user,,1404208506577.e4983164a0c3affb94b84d16f8addb32. into cf3b1be161044bea9f9d8652bc608aca(size=17.2 M), total size for store is 17.2 M. This selection was in queue for 0sec, and took 1sec to execute.
2014-07-01 14:25:01,853 INFO org.apache.hadoop.hbase.regionserver.CompactSplitThread: Completed compaction: Request = regionName=user,,1404208506577.e4983164a0c3affb94b84d16f8addb32., storeName=info, fileCount=3, fileSize=17.3 M, priority=7, time=839403076588278; duration=1sec

Sample 2:

2014-07-01 13:35:57,777 INFO  [RS:0;hbase096:53153-smallCompactions-1404221715909] regionserver.HStore: Starting compaction of 3 file(s) in cf1 of dolor,row-0.64,1404221420123.4108d3357f84adcdc59cde6a5f8283ce. into tmpdir=file:/tmp/hbase-hbase/hbase/data/default/dolor/4108d3357f84adcdc59cde6a5f8283ce/.tmp, totalSize=15.1m
2014-07-01 13:35:57,940 INFO  [RS:0;hbase096:53153-smallCompactions-1404221715909] regionserver.HStore: Completed major compaction of 3 file(s) in cf1 of dolor,row-0.64,1404221420123.4108d3357f84adcdc59cde6a5f8283ce. into 1dc96048b6724542bfd01f03a06c06e5(size=15.1m), total size for store is 15.1m. This selection was in queue for 0sec, and took 0sec to execute.

HBase 0.96 support

Hi, first of all, thanks for the project.
We've been using it for months and it has been really helpful. However, we recently deployed a new CDH5 cluster which runs HBase 0.96.1.1 and realized hannibal doesn't work there. Any plan to support HBase 0.96 or above?

Installation instructions in README.markdown links to old version

The database schema doesn't permit region names longer than 255 bytes.

Received the following exception:

[ERROR] [02/20/2014 02:57:44.125] [application-akka.actor.default-dispatcher-1] [akka://application/user/updateMetricsActor] Value too long for column "TARGET_DESC VARCHAR(255) DEFAULT '-unkown-' SELECTIVITY 33": "able,region-name-that-is-very-loong... (358)"; SQL statement:
INSERT INTO metric(target, name, last_value, last_update, target_desc) VALUES (?, ?, 0.0, 0, ?) [22001-158]
org.h2.jdbc.JdbcSQLException: Value too long for column "TARGET_DESC VARCHAR(255) DEFAULT '-unkown-' SELECTIVITY 33": "table,region-name-that-is-very-loong... (358)"; SQL statement:
INSERT INTO metric(target, name, last_value, last_update, target_desc) VALUES (?, ?, 0.0, 0, ?) [22001-158]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.table.Column.validateConvertUpdateSequence(Column.java:319)
at org.h2.table.Table.validateConvertUpdateSequence(Table.java:679)
at org.h2.command.dml.Insert.insertRows(Insert.java:120)
at org.h2.command.dml.Insert.update(Insert.java:84)
at org.h2.command.CommandContainer.update(CommandContainer.java:71)
at org.h2.command.Command.executeUpdate(Command.java:212)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:143)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:129)
at com.jolbox.bonecp.PreparedStatementHandle.executeUpdate(PreparedStatementHandle.java:203)
at anorm.Sql$class.execute1(Anorm.scala:447)
at anorm.SimpleSql.execute1(Anorm.scala:359)
at anorm.Sql$class.executeInsert(Anorm.scala:454)
at anorm.SimpleSql.executeInsert(Anorm.scala:359)
at models.MetricDef$$anonfun$find$1.apply(Metric.scala:41)
at models.MetricDef$$anonfun$find$1.apply(Metric.scala:36)
at play.api.db.DBApi$class.withConnection(DB.scala:79)
at play.api.db.BoneCPApi.withConnection(DB.scala:273)
at play.api.db.DB$$anonfun$withConnection$3.apply(DB.scala:158)
at play.api.db.DB$$anonfun$withConnection$3.apply(DB.scala:158)
at scala.Option.map(Option.scala:133)
at play.api.db.DB$.withConnection(DB.scala:158)
at models.MetricDef$.find(Metric.scala:36)
at models.MetricDef$.findRegionMetricDef(Metric.scala:33)
at models.MetricDef$.STOREFILE_SIZE_MB(Metric.scala:22)
at actors.UpdateMetricsActor$$anonfun$receive$1$$anonfun$apply$1$$anonfun$apply$mcI$sp$1.apply(UpdateMetricsActor.scala:30)
at actors.UpdateMetricsActor$$anonfun$receive$1$$anonfun$apply$1$$anonfun$apply$mcI$sp$1.apply(UpdateMetricsActor.scala:29)
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
at scala.collection.immutable.List.foreach(List.scala:45)
at actors.UpdateMetricsActor$$anonfun$receive$1$$anonfun$apply$1.apply$mcI$sp(UpdateMetricsActor.scala:29)
at actors.UpdateMetricsActor.updateMetrics(UpdateMetricsActor.scala:87)
at actors.UpdateMetricsActor$$anonfun$receive$1.apply(UpdateMetricsActor.scala:26)
at actors.UpdateMetricsActor$$anonfun$receive$1.apply(UpdateMetricsActor.scala:23)
at akka.actor.Actor$class.apply(Actor.scala:318)
at actors.UpdateMetricsActor.apply(UpdateMetricsActor.scala:22)
at akka.actor.ActorCell.invoke(ActorCell.scala:626)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:197)
at akka.dispatch.Mailbox.run(Mailbox.scala:179)
at akka.dispatch.ForkJoinExecutorConfigurator$MailboxExecutionTask.exec(AbstractDispatcher.scala:516)
at akka.jsr166y.ForkJoinTask.doExec(ForkJoinTask.java:259)
at akka.jsr166y.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:975)
at akka.jsr166y.ForkJoinPool.runWorker(ForkJoinPool.java:1479)
at akka.jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:104)

[RFE] Show "Region History" for whole cluster

Hi. Hannibal is beautiful, but there is one view I'm missing. I would like to see something like the "Region History" chart for the whole cluster, but of course only for short time intervals.

Then it could be used like a monitoring page for our cluster, especially showing:

  • which splits are on-going
  • how many compactions are happening
  • and pointing out when a compaction takes a long time

Region Distribution Chart Javascript Errors on empty Cluster

When there is no or few data yet, the Region Distribution Graph doesn't render:

[18:26:53.902] Unerwarteter Wert NaN beim Parsen des Attributs width. @ http://localhost:9000/assets/javascripts/d3.v2.js:387

The graph should not be displayed if it can't be rendered. The current behaviour confuses the user.
@Gissues:{"order":30,"status":"backlog"}

Easy way to deploy hannibal

There should be an easier way to deploy hannibal. An assembly(zip/tar.gz) seems like the best way. Compiling and rebuilding it for every node seems like a very tedious process. Also I wasn't unable to get it building on all my nodes.

Region Distribution graph not showing colors.

I checked in the latest version of Safari, Chrome, and Firefox but it only shows the graphs for my middle region server. When I hover over the region server sections I can see that each region server does in fact have around 333 regions assigned. As you can see from the screenshot, each table is checked, but it is only showing the .META. table.

Screen Shot 2012-12-14 at 5 42 51 PM

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.