If you’re like most people, when you notice something really odd about your body, the first thought to enter your brain is not “I need to call the doctor.” Of course let me clarify, if you look down after a fall, and think “My arm really shouldn’t bend like that”, then yeah, you call a doctor right away. But if you didn’t fall and go “there’s this tingle in my right arm”, the first thing you do is attempt to analyze. Then, if you want to know all of the really worst things in the world it might be, you research online at a site like WebMD. If, after reasonable thought and possible research, you cannot place a reason for your problem, you might go see your doctor. Or you might try some aspirin, depending upon the problem, and your level of discomfort.

If you decide to go see a doctor, you don’t want him to take an XRay, glance at a blurry image, and pronounce that you have two days to live. You’re going to want him to do a thorough job of examining anything more than “you slept on it wrong, it’ll be better tomorrow”. Because you want to – and you want your doctor to – work from an informed position.

But do you give your hardware the same opportunity?

Just like your body shows odd symptoms or even has a system failure, so too for the hardware in your datacenter. While it would be wonderful if a device could last forever, see my Mean Time Between Failures post in the Bare Metal Series for more reasonable expectations.

<Disclaimer> As always, I am an F5 employee, and I know F5 gear better than other vendors. From here on, I will talk primarily about what is available to diagnose problems on an F5 device. Vendor support for these tools varies, check with your vendor to find out if/how you can achieve the same ends. </Disclaimer>

It’s about hardware.
Somewhere on the system, there is going to be a hardware diagnostics tool. In the case of F5 gear, it is called End User Diagnostics (EUD), and it provides you with a solid battery of self-diagnostics that can be used to see if the hardware is functioning well. Here is the main menu from the tool:

Notice that it can test the RAM, the LCD display, SFPs, the indicator lights on the chassis, overall system, and system sensors (like temperature). But it can go beyond these tests, checking the internal path packets traverse through the hardware, the hardware-used memory (PVA), SSL processing (since SSL is offloaded to specialized hardware), FIPS processing, compression, disk drives, file systems on the drives… It’s a pretty solid picture of what might be wrong with the system. While we hope you never need it, reality is that hardware wears down, gets dirty power, or on occasion fails in spite of burn-in. So for those times, you have the tool available.

Notice that EUD doesn’t have an option to quit without rebooting, and that’s not the only caveat. While I could give you the other details, like you need to disconnect network cables while running EUD, I’ll just point out that http://ask.f5.com has a lot of information about the tool if you have an account, and F5 offers training in using it also. Again, we do our best to make sure you’ll never need it but know it does happen, so want you prepared. It is strongly recommended that you download the latest version and read the release notes also.

But it’s software too!
No complex piece of computing machinery runs on straight hardware anymore. Whether you recognize it as software or not, all computer systems – including all ADCs – use software to accomplish some goals. In F5 gear, a fair share of processing is either shared hardware/software or straight software, and as you might imagine, the software can have issues from configuration on that can cause odd behavior.

For that bit of the puzzle, F5 has long had the tool for the job… QKView* runs on the machine and collects a ton of data. The results of QKView can be sent to technical support upon request, but also can be uploaded to a user diagnostics site. More on that in a moment. qkview runs across the system, picking up important (but non security-related) information and puts it all together in a tarball. “What good is that?” a bunch of you must be asking. And that’s the great part, since normally that would be a valid question. The logs, configs, error dumps are all available to you on the device, so what use is making them less available in a tarball? That’s where the next part comes in…

I cannot stress strongly enough, if you are an F5 customer considering using qkview, please go to ask.f5.com and download the latest version. Improvements in performance, what data is gathered, even organization of data inside the tarball are happening pretty regularly, and using the newest version will help insure that you have the most relevant data in the most efficient form.

But it’s really complex software…
F5 gear is a marriage of blazingly fast, bullet proof hardware with highly optimized software. To create a system that is not only that complex, but adds in features like the ability to store multiple versions of the software and boot the one of choice at any given time, and pluggable software modules that do a variety of application delivery and application security functions for you, well, that takes a lot of software. Never fear, all of our software has rigorous QC applied, just like our hardware does, but there’s a lot of it interacting, and I have never met the device whose designers knew before hand the array of uses that customers will find to put it to. Every network is different, every application architecture is different, and thus the usage of every single ADC deployed is different. Well, not every single one, since most customers use clustering sooner or later, but more than half of them, for certain.

That is why QkView output is a tar file There’s a bunch of information about how all the various software and hardware parts are communicating in those files, what’s gone wrong, how the device is configured… Just a ton of information. In fact, with versioning differences (if software changed, often what it reports changes), it was difficult to offer up a cohesive application on the BIG-IP to analyze these files.

Enter iHealth, a free (registration required to keep it to people with legitimate uses) qkview analyzer.  There are a large variety of reasons that F5 chose to go to a centralized online analyzer over a standalone tool. I’ll hit on a couple of them for you, they’re the ones I think you’ll care the most about.

1. The online tool offers manipulable graphical output. In short, you can navigate data organized in a natural way, look at what’s important to you, and get back to fixing problems faster. Generated charts are also great tools for management presentation to point out problem areas or talk up how much traffic the device is handling.

2.  The online tool can utilize the information from thousands of deployed devices to show you where you’ve made common configuration errors or point out potential future problems. It’s like chatting with thousands of your widespread peers about qkview output and getting free advice.

3.  The heuristics database that checks configurations and offers advice/tells you how to resolve issues is always up to date. You don’t have to update it before checking a qkview file.

But as always, a picture is worth a thousand words, so I’ll offer you a couple thousand words’ worth.

When the qkview file is uploaded and analyzed, you get the iHealth summary page:

This serves as a starting point to explore in more detail, and offers totals for how many devices have been defined, what add-on modules are licensed, version information, etc.

Next let’s take a look at the diagnostics section, the one that will interest most users (some users utilize iHealth to performance tune their network, and for those customers, diagnostics is far less used):

Notice how it' has issues divided up by severity? And it offers links to how to fix them. Useful when there’s trouble and you’re in a hurry.

It builds this handy list from information stored in the online app – information that can be updated as needed. That means the app is more responsive to your needs than an on-device tool might be.

In the end, it’s about serving traffic. Reliably.

All of these tools – End User Diagnostics, qkview, and iHealth are out to help with one thing… Helping you (and F5 tech support when necessary) figure out what’s really wrong and fix it, and helping you proactively fix things that might be wrong for the future. And all of that is to simply support the need to keep applications on-line and performing well. While they are not much use if your ADC is a doorstop, they’re invaluable if the ADC is a cornerstone of your datacenter, and cut hours, in some cases days off of troubleshooting and repair timelines.

And remember, all are free tools for you to use, just one part of the overall quality plan at F5.