menu

Monitoring a Microservices-Based Application

Golan Shem-Tov
SHARE ON:

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.

microservices

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?

micoreservices_x4

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 Graphs: an application or dependency map is nice, but there is a more a more useful set of dependencies we can use. 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 telling us where the problems are at and where we need to invest our efforts.

performance graph processing time

  • Analysis on Server Delays: this view is built on 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

  • Show the Relevant Information: SteelCentral AppInternals shows cards and views with information for objects that existed in the selected time frame,  not old or new objects that did not exist in the time frame. This way, when you investigate a problem you don’t get distracted by ghost objects.
  • Global Filters: when we use global filter for an application or a transaction, we only see what is relevant for that application or transaction. The cards and views on the screen, application map, performance graphs, server delays, true plot show only what it relevant for the selected application or transaction.
  • Show the Real 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 display 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.

No Responses to “Monitoring a Microservices-Based Application”

Leave a Reply

Your email address will not be published. Required fields are marked *