Why it matters
Every production HBase issue leaves a signature in metrics. Learning to read the metrics is what turns firefighting into forecasting. Slow reads announce themselves as increased read latency and dropped block cache hit rate before customers complain. GC pauses show up as long GC durations before they cause failovers.
Metric-driven ops also enables capacity planning. Growth trends across weeks tell you when to add nodes, split hot tables, or tighten TTL. Reactive scaling is expensive; forecasted scaling is cheap.
The architecture
HBase exposes JMX MBeans for every component. RegionServer MBeans include request count, request latency percentiles, memstore size, block cache hit/miss/eviction counts, WAL sync time, and per-region statistics. HMaster MBeans include regions-in-transition count, dead RegionServer count, and cluster load metrics.
The Hadoop metrics2 framework sinks these to various backends: file, Ganglia, Graphite. Modern deployments use a JMX exporter to feed Prometheus, or CloudWatch metrics for AWS-hosted clusters.
How it works end to end
Essential per-RegionServer metrics: request count and latency (know if traffic is normal), memstore size (know if flush pressure is normal), block cache hit rate (know if reads are hitting cache), GC pause count and duration (know if JVM is healthy), WAL sync latency (know if write path is healthy).
Essential per-region metrics: HFile count (leading indicator of compaction lag), region size (know if splits are due), read/write rates (know which regions are hot).
Essential cluster metrics: regions in transition (should be near zero), dead RegionServer count (should be zero), HMaster availability (should be 100 percent).