Monitoring Hadoop beyond Ganglia

Over the last couple of months I have been talking to more and more customers who are either bringing their Hadoop clusters into production or that have already done so and are now getting serious about operations. This leads to some interesting discussions about how to monitor Hadoop properly and one thing pops up quite often: Do they need anything beyond Ganglia? If yes, what should they do beyond it?

The Basics

Like in every other system, monitoring in a Hadoop environment starts with the basics: System Metrics – CPU, Disk, Memory you know the drill. Of special importance in a Hadoop system is a well-balanced cluster; you do not want to have some nodes being much more (or less) utilized then others. Besides CPU and memory utilization, Disk utilization and of course I/O throughput is of high importance. After all the most likely bottleneck in a big data system is I/O – either with ingress (network and disk), moving data around (e.g. MapReduce shuffle on the network) and straight forward read/write to disk.

The problem in a Hadoop system is of course its size. Nothing new for us, some of our customers monitor well beyond 1000+ JVMs with CompuwareAPM. The “advantage” in a Hadoop system is its relative conformity – every node looks pretty much like the other. This is what Ganglia leverages!

Cluster Monitoring with Ganglia

What Ganglia is very good at is to provide an overview over how a cluster is utilized. The load chart is particular interesting:

This chart shows the CPU load on a 1000 Server cluster that has roughly 15.000 CPUs

It tells us the number of available cores in the system and the number of running processes (in theory a core can never handle more than one process at a time) and the 1-min load average. If the system is getting fully utilized the 1-min load average would approach the total number of CPUs. Another view on this is the well-known CPU utilization chart:

CPU Utilization over the last day. While the utilization stays well below 10% we see a lot of I/O wait spikes.

While the load chart gives a good overall impression of usage, the utilization tells us the story of how the CPUs are used. While typical CPU charts show a single server, Ganglia specializes in showing whole clusters (the picture shows CPU usage of a 1000 machine cluster). In the case of the depicted chart we see that the CPUs are experiencing a lot of I/O wait spikes, which points towards heavy disk I/O. Basically it seem the disk I/O is the reason that we cannot utilize our CPU better at these times. But in general our cluster is well underutilized in terms of CPU.

Trends are also easy to understand, as can be seen in this memory chart over a year.

Memory capacity and usage over a year

All this looks pretty good, so what is missing? The “so what” and “why” is what is missing  . If my memory demand is growing, I have no way of knowing why it is growing. If the CPU chart tells me that I spend a lot of time waiting, it does not tell what to do, or why that is so? These questions are beyond the scope of Ganglia.

What about Hadoop specifics?

Ganglia also has a Hadoop plugin, which basically give’s you access to all the usual Hadoop metrics (unfortunately a comprehensive list of Hadoop metrics is really hard to find, appreciate if somebody commented the link). There is a good explanation on what is interesting on Edward Caproli’s page: JoinTheGrid. Basically you can use those metrics to monitor the capacity and usage trends of HDFS and the NameNodes and also how many jobs, mappers and reducers are running.

Capacity of the DataNodes over time

Capacity of the Name Nodes over time

The DataNode Operations give me an impression of I/O pressure on the Hadoop cluster

All these charts can of course easily be built in any modern monitoring or APM solution like CompuwareAPM, but Ganglia gives you a simple starting point; and it’s Free as in Beer.

What is missing again, is the so what? If my jobs are running a lot longer than yesterday, what should I do? Why do they run longer? A Hadoop expert might dig into 10 different charts around I/O and Network, spilling; look a log files among other things and try an educated guess as to what might be the problem. But we aren’t all Experts, neither do we have the time to dig into all of these metrics and log files all the time.

This is the reason that we and our customers are moving beyond Ganglia - to solve the “Why” and “So What”  within time constraints.

Beyond the Basics #1 – Understanding Cluster Utilization

A use case that we get from customers is that they want to know which users or which pools (in case of the fair scheduler) are responsible for how much of the cluster utilization. LinkedIn just released White Elephant, a tool that parses MapReduce logs and builds some nice dashboards and shows you which of your users occupy how much of your cluster. This is of course based on log file analysis and thus ok for analysis but not for monitoring. With proper tools in place we can do the same thing in near real time.

The CPU Usage in the Hadoop Cluster on per User basis

In this example I wanted to monitor which user consumed how much of my Amazon EMR cluster. If we see a user or pool that occupies a lot of the cluster we can course also see which jobs are running and how much of the cluster they occupy.

The CPU Usage in the Hadoop Cluster on per Job basis

And this will also tell us if that job has always been there, and just uses a lot more resources now. This would be our cue to start analyzing what has changed.

Beyond the Basics #2 – Understanding why my jobs are slow(er)

If we want to understand why a job is slow we need to look at a high level break down first.

In which phase of the map reduce to we spend the most time, or do we spend more time than yesterday? Understanding these timings in context with the respective job counters, like Map Input or Spilled Records will gives an understanding why the phase took longer.

Overview of the time spent in different phases and the respective input/output counters

At this point we will already have a pretty good idea as to what happened. We either simply have more data to crunch (more input data) or a portion of the MapReduce job consumes more CPU (code change?) or we spill more records to disk (code change or Hadoop config change?). We might also detect an unbalanced cluster in the performance breakdown.

This job is executing nearly exclusively on a single node instead of distributing

In this case we want to check wether all the involved nodes processed the same amount of data

Here we see that there is a wide range from minimum, average to maximum on mapped input and output records. the data is not balanced

or if the difference can again be found in the code (different kinds of computations). If we are running against HBase we might of course have an issue with HBase performance or distribution

At the beginning of the job only a single HBase region Server consumes CPU while all others remain idle

On the other hand, if a lot of mapping time is spent in the garbage collector then you should maybe invest in larger JVMs.

The Performance Breakdown of this particular job shows considerable time in GC suspension

If spilling data to disk is where we spend our time on we should take a closer look at that phase. It might turn out that all of our time is spent on disk wait

If the Disk were the bottleneck we would see it on disk I/O here

Now if disk write is our bottleneck then really the only thing that we can do is reducing the map output records. Adding a combiner will not reduce disk write (it will actually increase it, read here). In other words combining only optimizes the shuffle phase, thus the amount of data sent over the network, but not spill time!!

And at the very detailed level we can look at single task executions and understand in detail what is really going on

The detailed data about each Map, Reduce Task Atttempt as well as the spills and shuffles

Conclusion

Ganglia is a great tool for high level monitoring of your Hadoop cluster utilization, but it is not enough. The fact that everybody is working on additional means to understand the Hadoop cluster (Hortonworks with Ambari, Cloudera with their Manager, LinkedIn with White Elephant, the Star Fish project…) shows that there is a lot more needed beyond simple monitoring. Even those more advanced monitoring tools are not always answering the “why” though, which is what we really need to do. This is where the Performance Management discipline can add a lot of value and really help you get the best out of your Hadoop cluster. In other words don’t just run Hadoop jobs at scale, run them efficiently and at scale!