Sergey Nivens - Fotolia
Gone are the days when a ping to a server would tell you whether a particular application worked. Applications have moved from the monolithic design to a distributed design, one that spans physical and virtual hardware and may well include public and private cloud resources. This shift in application design upends the more traditional methods of IT monitoring.
Monitoring is now driven by applications rather than infrastructure, and this is an important change. Think of it this way: A host is a critical piece of infrastructure, but if it fails, VMs and workloads restart on the remaining hosts. So, while the host is still important, it is not as important as it used to be -- assuming that it's properly designed for what an organization asks it to do.
It's in the application stack where you see traditional, preventive and real-time application monitoring interact in new ways. Traditional monitoring sought to answer a simple question: Is something alive? Ping the servers, VMs and switches, and then look at the board to see what's red and what's green. This method is easy and normally cheap, and we continue to use it. That doesn't mean it is ideal.
Finding value in real-time data
Real-time monitoring and proactive monitoring give IT teams powerful insights into their apps. Real-time application monitoring can tell you in the moment if an application experiences a problem. With this information, admins can make appropriate adjustments.
Proactive monitoring, meanwhile, uses real-time information to forecast problems that might occur. This capability gives staff members time to prevent problems or at least react swiftly enough to minimize the extent of the trouble.
The ability to reduce disruptions is valuable, especially when customers are involved. These real-time powers, however, require someone to act on the information provided when it is provided. Automation and self-healing systems are getting better, but they often still need human involvement. And what, after all, is the value of real-time monitoring if no one is watching?
An organization that's ready to invest in a real-time monitoring system should think about how to staff that system around the clock. Sure, you can put people on call to respond to an alert. That arrangement, however, requires time to get the right people to take the right action. In the overnight hours, these delays can be significant. Real-time monitoring isn't really real time unless your IT team is able to react in real time. That can be expensive.
The right time for real time
An organization interested in real-time monitoring should look at how that tool will be used. If most of your business activity occurs in the 9-to-5 workday window, then staff members will be ready to react. In those situations, real-time monitoring makes a lot of sense. If you apply the 80/20 rule, real-time monitoring could be beneficial during the busiest hours of the day, justifying the cost of the product. That is part of the equation with real-time monitoring.
The trending/predictive aspect is another big piece of that puzzle. Being able to somewhat see into the future for resource needs and to take preventive steps are actions that customers will never see, but those capabilities can have huge impacts on a company's reputation and customer service.
To make preventive monitoring a reality, an organization will need to implement real-time monitoring. Otherwise, the preventive technologies won't have access to the right data and, therefore, won't be able to prevent much of anything. And that takes us back to the application stack.
Monitor at the app layer
To be successful, real-time monitoring needs to be viewed and conducted from the customer's viewpoint. Monitoring must take place at the application layer that correlates to the infrastructure -- and not the other way around. A distributed application can have various servers or infrastructure pieces go offline, but failover and load balancing will keep that app up and running.
Focusing on the infrastructure, however, won't show you everything. With application-specific, real-time monitoring, you see what your customers see. This knowledge helps you become aware of delays and complications faced by users and enables you to make appropriate adjustments.
This capability is new for many IT organizations, especially those coming from a monolithic design to the distributed approach. Applications, though, require this change in thinking and focus. This can help an organization whose apps split time among multiple environments, including the public and private cloud, where you can focus on the delivery aspect but otherwise have limited information into the cloud operations aspects.
Real-time monitoring's real costs
Monitoring products from Quest Software and SolarWinds are among the top choices in this market. Costs vary, and some tools are more advanced than others.
Many businesses with more traditional monitoring tools in place will decide they have an outdated tool set. That may be the case, but not all hope is lost. Many monitoring products are built on frameworks that can have additional modules added into them, which extends the functionality to application-specific monitoring. These new modules are not free, but look closely at existing agents and the things you monitor today. It might make sense to reduce some of those agents so that you can shift current spending into agents that monitor applications.
A shift from infrastructure monitoring to application monitoring might not always be ideal. Still, when funds are limited, a gradual transition enables an organization to begin that move into real-time application monitoring in ways that make sense for your customers and your budget. It also helps to prevent IT staff from suffering from monitoring overload. People are still the key to any monitoring plan. Overwhelming them with information is almost as bad as not providing them enough information.