Get a better angle on your network monitoring with application management

With any new network monitoring and management software, the first step is to assess your existing inventory. Do this by allowing the software to discover all your devices. Your new software may alert you to things you didn’t know you had. Network monitoring and management tooling may be smart enough to propose ways to improve your system: it might suggest new configurations or highlight bottlenecks. Your last step is to let the Simple Network Management Protocol (SNMP) traps flow and inform you about day-to-day network usage.

One blessing of the OSI model is that it has enabled innovation at the individual layers. These layers are abstracted from one another, which prevents accidentally injecting dependencies into other layers. The curse of the OSI model is that it has socially separated the people who work at the individual layers from one another—someone working at one layer may never think of someone else working at a different layer. It’s a recurring problem in network monitoring and management, in general.

While looking at the network layout and the packet flows are important, doing so without the context of the applications running on top of the network is limiting. It’s like trying to analyze your energy consumption by looking at an electrical wiring diagram at your home, without considering the appliances plugged into it. Without examining the stresses that applications place on a network at Layer 7, you have an incomplete picture of Layers 2 and 3. Application management gives you a better angle, and these services are in high demand. The network monitoring sector is experiencing explosive growth. Here’s a rundown on how the systems work:

Agent vs. agentless

The first question to ask when evaluating an application management and monitoring platform is, “How is it collecting data?” There are two formats to consider: agentless and agent-based.

Agentless system: Developers add lines of code at different intervals that explicitly collect data and send it off to another part of the application management platform for storage and analysis.

• Fun fact: developers hate this approach because it creates dependency on their code and that typically slows them down. For a group of people that are measured by how quickly they can get software out into the hands of customers as part of a feedback loop, slow is bad.

Agent-based system: In this kind of system, a little daemon runs alongside the main application component and collects data, unbeknownst to that component. For application monitoring platforms, the daemon binds to a language runtime. From that language runtime, the system collects data and sends it to other parts of the application management platform for storage and analysis.

• Developers prefer this approach because there’s no dependency creation. Remember, slow is bad.

Agent-based systems divert resources away from the main components of an application, so some IT folks may find them a little evil. But is that resource-suck such a big deal? If agents syphoned off 10 percent of resources (usually it’s less than 2 percent), you would be running 11 containers or VMs of functionality behind your load balancer instead of 10. In the past, when we thought of compute resources as pets, that number was a big deal. But in the cattle-based microservices world we live in now, it’s trivial.

Getting the bigger picture

Whether your platform takes an agent-based or agentless approach, these systems add a transactional identifier to the network headers. This way, different components of the application—like databases, queues and application servers—communicate with each other, allowing the system to form a larger picture of the interactions once it collects all the data.

The result of this larger picture is an application architecture diagram that shows the interactions among the different components. Just as a network monitoring and management platform is guilty of ignoring Layer 7, an application monitoring platform is guilty of ignoring Layers 2 and 3. The generated diagrams will therefore not contain routers, switches, and other network components that are invisible at Layer 7.  Networking diagrams can be tricky to maintain manually, and application diagrams are similarly difficult. This automation not only makes the developer’s life easier, it provides a map within each network and application engineers can have constructive conversations.

Transactional tracing

Processes become streamlined with an application architecture diagram in place based on data collection approaches. Application monitoring and management platforms will be able to use that diagram to show individual and aggregate transactional flow between the components. This is where the combination of application and network tools synergizes.

Here’s a real-life example:

• As load increases during a busy time of day, an e-commerce application sees an increase in transactions.
• As the load increases, the application adds more VMs or containers in response. Eventually this latency creates a bottleneck between a web server and a database server.
• Without an application monitoring and management platform in place, the development team might point the finger at the networking team. IT would then propose physically adding more bandwidth to the system.
• But wait—an application monitoring and management platform would be able to discover whether or not the business logic components are responsible for using up the existing network bandwidth and causing the bottleneck. The platform could analyze the memory those servers are using during peak load, and it would be able to indicate whether data is being cached effectively at that layer. It could stop an application glitch from unnecessarily putting stress on the network.

When used in conjunction with a network monitoring and management tool, application monitoring and management tools can paint a broader picture of usage, spanning more layers of the OSI model. This can help remove the social barriers that the OSI model accidentally creates between people that populate teams.

Classic network management and monitoring tools remain vital, but using them exclusively places you in a vacuum. Instead, using network and application management and monitoring tools together better utilizes resources, optimizes applications and reduces friction between different sets of employees.