
NEED HELP?
Visit our FAQ if you run into problems downloading our eBooks. If you are wondering why all of the chapters aren't available for some of the eBooks, we'll explain it here!
PAGE FEEDBACK

|
|
In the beginning, data centers were giant buildings housing a single, vacuum tube-driven computer, tended to by people in white lab coats whose main job was changing the tubes as they burned out. Today's data centers are so much more complicated that it's like a completely different industry: We not only have dozens or hundreds or even thousands of servers to worry about, but now we're starting to outsource specific services-like email, spam filtering, or customer relationship management (CRM)-to Web-based companies selling "Software as a Service (SaaS)" in "the cloud." How do we manage it all, to ensure that all of our IT assets are delivering the performance and service that our businesses need?
This chapter provides an introduction to the goals and challenges you face as you evolve your IT services to a hybrid IT model. It outlines the evolution from today's IT models to the future's super-distributed, hybrid model, and covers key concerns and problems you're likely to face as you move along that path.
Those of us in the IT world think we know monitoring. After all, we've been doing it, in various ways and using various tools, for decades. We collect performance data, we look at charts, and…well, that's monitoring. Sadly, that kind of monitoring just doesn't meet today's business needs.
How You're Probably Monitoring Today
IT monitoring has evolved over the past few decades, but that evolution has pretty much consisted of continuing refinements to a basic model. Today's monitoring techniques evolved more out of what was possible and less out of what the business actually needed. Let's take some time to look at the monitoring techniques of today, because we'll want to carefully consider which techniques we need to keep—and which ones we should ditch.
I've already presented the End User Experience (EUE) as the ultimate metric for an application's overall performance, whether that application lives entirely in your data center, entirely in the cloud, or in some combination of the two. In this chapter, I'll explore the EUE in greater detail: How do you actually measure it? What, specifically, are you looking at? What contributes to a good—or poor—EUE in an application? If you see your EUE metric starting to head toward "poor," what can you do about it? I'll also examine some of the reasons companies traditionally haven't measured the EUE—and why doing so can still be tremendously difficult, especially in newer, highly-distributed applications that involve elements of cloud computing.
Why the EUE Matters
First, however, let's really pin down why the EUE is so important. As I outlined in the previous chapter, businesses have typically measured application performance solely from technical measurements—database response times, for example. What does the EUE really offer that the more traditional measurements don't?
The EUE is your ultimate metric for whether an application is performing well. It's what you should base SLAs upon, and it's certainly your ultimate measure of success or failure with an application. The EUE isn't, however, very useful at helping you troubleshoot problems when they occur. For that, you'll need a deeper, more detailed level of monitoring. In this chapter, I want to compare and contrast two approaches for that moredetailed kind of monitoring: the traditional, multi‐tool monitoring stack, and a more modern approach that focuses on getting everything into a single view.
Traditional, Multi‐Tool Monitoring
In a traditional monitoring environment, IT experts tend to rely on single‐discipline tools to troubleshoot the application stack. That's an approach that has served for years, although as applications become more complex and distributed, we've needed a wider number and variety of tools to get insight into everything. Typically, separate tools exist for each major layer of the application. Consider the example in Figure 4.1, which illustrates the application stack I'll be using for this section of this chapter.
This diagram is more hardware‐centric, as it is intended to represent the major physical elements of the application: client application, network infrastructure, application server (which might be a Web server, for example), and a back‐end database. Notice that this example—in keeping with the "traditional" approach—does not incorporate any cloudbased elements; we'll come to the cloud issue shortly, though.
In the previous chapters of this book, I've covered a lot of the "why" and "how" of unified monitoring. In this chapter, I want to start focusing specifically on the "what:" What capabilities you need to bring into your environment to successfully manage and monitor a hybrid IT infrastructure and its applications. Think of this chapter as an instructional guide for building a shopping list. I'll cover not only features but also some of the finer, easilyoverlooked details that can make all the difference in a successful implementation.
First, though, let's clearly define some of the major business and technical goals for this kind of evolved, hybrid IT monitoring. As I do so, I want to re‐introduce the works from World Coffee, the case study I introduced in Chapter 1.
Business Goals for Evolved Monitoring
I want to cover the business' goals for monitoring first because in reality the business' goals are the only ones that matter. The business is paying for not only the monitoring solution but also the applications and infrastructure being monitored; meeting the goals of the business is really the whole point of all of this. So what might a business hope to gain from a more evolved form of monitoring?
I've spent a lot of time in this book explaining the capabilities and technologies you need to add to your environment in order to enable truly hybrid, data center-to-the-cloud application and service monitoring. But all of that monitoring is useless without output. One of the end goals of this entire effort is to provide your managers and executives with effective reports-whether they are internal "customers" or external customers. Dashboards and other elements that show a manager that the environment is healthy and on budget or that show them which service (not IT component) isn't doing well. The goal of this final chapter is to focus on these reports, what they should look like, and what value you can expect to derive from them.
Sign up for our Realtime Nexus newsletters and book alerts and discover when new books on your favorite IT topics are available!

By sponsoring a book with Realtime Publishers, you will connect your technology company with thousands of IT professionals who need information on the technology topic of your choice. Realtime Publishers works with only the best authors in the IT field to produce expert-level publications that appeal to and educate the IT professional audience.
Visit sponsorships.realtimepublishers.com to learn more about our wide array of sponsorship and content marketing opportunities.
