Monitoring a Microservices-Based Application

Riverbed Technology November 16, 2017

Using a microservices-based architecture adds a lot of benefits but also adds some interesting challenges, especially when it comes to monitoring and troubleshooting problems. SteelCentral AppInternals can help!

Microservices add a lot of “noise”

In a previous blog, I talked about the challenges of Monitoring Application Performance in a Docker World. One remark that I got was that the blog could have been named “Application Performance Monitoring in a Microservices World.” While Docker is one type of architecture, the challenges with application performance monitoring in a microservices environment are similar:

  • Large number of objects
  • Complexity
  • Elasticity
  • Mobility
  • Transience

If you monitor a microservices-based environment without taking these challenges into account you may end up with a very confusing (and sometimes overwhelming) dependency map that shows current and old objects with dependencies between them that may not even be relevant anymore.


Displaying all this information is great, but is it helpful? If you had to look at that dependency map and try to understand where the bottlenecks are, how easy will it be?  What do you do in an even larger, more dynamic environment?


The dependency map starts looking like a lot of “noise.”

Eliminate the “noise”

There are multiple features in SteelCentral AppInternals that help you eliminate the noise:

  • Performance Graph: An application or dependency map is nice, but there is another more useful set of dependencies we can illustrate. If we look at transactions on one hand, and at the places where time is consumed (methods, SQL remote calls etc.) on the other hand, we can easily see the bottleneck while eliminating the “noise”. The number of microservices grow and shrink, they live and die, they can move around, connect/disconnect to other microservices, but that does not impact the logical dependencies. The logical dependencies between transactions and the calls that consume the time continue to tell us where the problems are at and where we need to invest our efforts.

performance graph processing time

  • Server Delays: This view is built by running analysis on multiple levels (System, Application, Transaction, Server, Instance, Geography) and shows you where the delays are coming from. It greatly simplifies the process of searching for  bottlenecks.


server delays

  • Time Filters: SteelCentral AppInternals shows cards and views with information only for objects that existed in the selected time frame, not old or new objects that did not exist in that time frame. This way, when you investigate a problem you don’t get distracted by ghost objects.
  • Global Filters: When you use a global filter for an application or a transaction, you will only see what is relevant for that application or transaction. The cards and views on the screen (Application Map, Performance Graph, Server Delays, TruePlot) update to show only what it relevant for the selected application or transaction.
  • ACTUAL Transaction Path: When looking at a single transaction we only show the information and the objects that were a part of that specific transaction, not an aggregated view from multiple transactions. SteelCentral AppInternals traces ALL transactions for ALL users ALL the time and each trace displays the map with the information, path and objects for that specific transaction. This gives us the ability to see the hosts/instances that were involved in a specific transaction for any user and see their resources usage when they ran the transaction.

Having challenges in monitoring a microservices-based environment? Try out SteelCentral AppInternals for free today!

Read more about Riverbed’s application performance monitoring solution here >

Special thanks to Jon Hodgson for the inspiration and letting me use images from his fantastic presentation.