Is there anybody in there? Is there anyone home? I’m reminded of these lines from Pink Floyd’s “Comfortably Numb” when I think of application monitoring. It may sound odd, but bear with me. The nuances around quickly delivering secure applications that meet business needs introduce a lot of potential trouble points to a network and an application portfolio. Add to the equation the growing diversity in deployment options—SaaS, cloud, on-prem, and hybrid, just to name the popular ones—and these trouble spots each have their own areas that can break down, be misconfigured, or become attack vectors, each with their own blast radius and root causes. Being the responsible app and network stewards we are, we need a bird’s-eye-view of how traffic is moving around our network infrastructure. So, how can you manage this risk when applications are critical to your business functionality? How do you understand app availability and your users’ experience accessing them? How do you know if your applications are even there?
Monitoring applications is crucial to a successful app security and delivery strategy because understanding how traffic is able to reach an application means more insight to address issues before they become problems for users. Roughly one-third of companies we surveyed for last year’s State of Application Strategy Report lack a baseline for app performance. An even smaller percentage detect app issues and outages before their end users do. And when we consider the fact that 40% of mobile users will depart for a competitor after one bad application experience, we see how vital it can be for a business to monitor its applications’ health. Now, it is important to note here that BIG-IP Local Traffic Manager’s (LTM) health monitors check the availability of an application while its performance monitors check performance and load. But, in many ways, this approach to monitoring an application gives a more realistic look at how, from a client’s perspective, an application behaves.
So, let’s talk about three of the ways BIG-IP LTM can help keep tabs on your applications.
Simple Monitoring – Like the name states, simple monitoring is simple. This method of monitoring basically asks, “Hey, is there something there?” and will only establish the “up” or “down” status of an LTM node, a BIG-IP DNS server, virtual server, pool, pool member, or link. Simple monitors contain three monitor types—Gateway ICMP, ICMP, and TCP_ECHO—and only monitor the node itself, not pool members, individual protocols, services, or applications on a node.
Put another way: Like playing “Marco Polo” in a pool with your friends. One of you shouts “Marco,” and the rest of the pool members reply with “Polo.” You know they’re out there in the pool, but you don’t know much beyond that.
Passive Monitoring – As part of a client request, passive monitoring checks the health of a pool member based on admin-defined parameters like the number of attempted data or connection requests that occur within a certain period. If the system cannot connect to the server or receive a response after that number of attempts within the timeframe, or if the system receives a bad response, the system marks the pool member as “down.”
This method does not create additional network traffic beyond the client request and server response and can mark a pool member as “down” quickly, given that there is network traffic. Since a passive monitor effectively piggybacks on a client request, it cannot check for specific responses and can be slow to mark a pool member as “up.”
Put another way: Like a hall monitor back in grade school. They’re watching the other students traverse the halls, reporting on whether or not those students are getting to class, but only reporting if there is traffic.
Active Monitoring – When you need to know about the status of traffic to or from an application beyond “Is there something there?” this type of monitor sends periodic status checks. If there is no response within a specified period, or if the node status shows degraded performance, BIG-IP can redirect traffic to another pool member or node. It can also simulate a user session as a health check against app servers, monitoring applications with an HTTP health check, checking for specific responses from the server.
An active monitor can be slow to mark a pool member as “down” since active monitors create network traffic beyond the client request and server response; with more traffic comes the potential for more latency.
Put another way: Like driving your car down a road to judge traffic. You get a detailed look at how traffic is moving or where there may be a jam, but doing so adds to the traffic you’re monitoring.
You wouldn’t want to drive your car without being able to monitor your speed, engine temperature, or fuel consumption; why attempt to deliver a business-critical application without monitoring how your users are able to access it, especially when so much is contingent on them having a good experience? Remember to ask your apps: “Is there anyone home?”
For more information on monitoring abilities in BIG-IP, check out the resources below, or connect with your F5 account team to find out how BIG-IP app health monitors can apply to your specific use case.