Instana U

A microservice architecture is flexible and dynamic but has the challenge of increasing complexity. For example, the picture below is an actual environment where hundreds of services collaborate with each other (a circle is a service). It is clearly a challenge to monitor and analyze a microservice environment. An additional level of complexity is that there are more monitoring combinations than there are services. Monitor by zone or cluster? By technology? By business transaction or user journey? By deployment engine? By service version or release label? Of course, these can be combined together for even more monitoring variants. Even a handful of services is challenging to monitor and analyze. How can this complexity be tamed?



A proven problem-solving algorithm is to “divide and conquer.” But how can this be applied when there is continuous change, many technologies, a polyglot of languages, multiple locales, different points of interest, etc.? Instana has a field proven approach to answer this question. It avoids a one-size-fits-all approach by providing a toolbox to define a dynamic scope of interest; one that fits your perspective. This toolbox is called an “Application Perspective” (AP) where you define: (i) what makes up an application and (ii) can narrow the scope further for the services you are most interested in. It is a uniquely powerful concept for teams of developers, SRE/operations, business leaders, or architects. This is the first in a series or articles exploring this toolbox. There are two obvious questions to answer next.

1. What can Application Perspectives do to make my job easier? A lot, because an AP is a set of power tools for monitoring, alerting, and analysis. Each AP auto-generates a feature rich monitoring dashboard for the golden signals and more (see figure below). It organizes a team so they stay focused on the services they are interested in and aren’t distracted. Smart Alerts can be created for an AP so that alerts are only sent to the team interested in those services. From a security perspective, an organization can use an AP to limit visibility to infrastructure and services.

2. Do Application Perspectives apply to my role? Yes, because there are many field proven use cases for several personas. The table below contains a one-line description of actual use cases per role (persona). Have a look to see which are your favorites! These will be covered in detail in follow-up articles.

The rest of this article introduces the key terms and concepts of Application Perspectives, the “divide and conquer” toolbox.

How an Application Perspective is Like Building a House

Analogies are helpful when dealing with new concepts, so we’ll use an analogy of building a house to explain an AP and its elements. There is some basis for doing this because an AP is like a building: it contains things at multiple levels; it is fit to personal tastes; some forethought is needed about what to build; and it can always be renovated to be bigger or smaller. So let’s dig in.



A house is constructed in a hierarchical fashion such as, rooms, walls, timber, and nails. Similarly, the construction materials of an AP are: services, endpoints, calls, and tags. They relate as follows. There is the house (or AP) which is the whole thing. Just like the rooms of a house form the entire house, the services in an AP form the entire AP. Each room is itself made of walls like a service is made up of endpoints. Walls are formed using lumber like endpoints are formed from calls. But what joins and holds the lumber together? Nails join the timber just like tags join calls together (a tag is a name/value pair). The tiniest house has a single room. in the same way the tiniest AP has a single service with one endpoint that receives one call.

A simpler AP is formed as a collection of related services. This is like discussing a subset of rooms in a mansion, such as: the “East Wing”, “Guest House”, “Shed”, or “Third Floor.” This subset has a common property that includes the room and the AP would have a common set of tags to select its services.

An AP can be built using cross-cutting information. This is like grouping rooms from multiple houses together and doing the analysis on the group. The analogy is grouping all the kitchens in several houses together to analyze how quickly they can cook a meal for a banquet. A similar cross-cutting AP is formed by grouping all the external API services together and monitoring the aggregated throughput call rate for drops or spikes.

An AP can be tailored to the specialty of a user community. Just like different construction trades have their own focus (e.g., electricians care about wiring but not plumbing) and want to ignore the other trades, an AP can focus a community of practice. Examples are a specific technology (e..g, an AP for all the MongoDB services), framework (e.g., all Spring Boot application), or location (e.g., us-east), etc.

What is a call?

Although the final product (house or AP) is considered top down, the reality is that it is built from the bottom up. This is an important thing to remember because APs are reverse engineered using calls as the building block (i.e., bottom up) but we can mistakenly assume they are built from services or endpoints (i.e., top down). A benefit of this approach is that the services and endpoints in an AP are always up to date because it continuously adjusts to the dynamics of a microservice environment by looking at the call information.

A call is a key concept in an Application Perspective It is exactly what it sounds like. When a source service makes a request to a destination service, a call object is created with this information. That call object is annotated with meta-data (i.e., tags) which is compared with the query that defines the AP and, if there is a match, the call belongs to the AP. This meta-data is derived from both the source and destination processes, as well as information about the message itself.
You now have enough information to be able to define an AP so let’s do just that.

Example APs – Dividing the Microservices

The simplest AP is a single service. This is defined using the service.name tag as shown below.



Perhaps it is not all of the endpoints that you are interested in but just a single endpoint. To accomplish this both the service name and endpoint name tag are needed. This is shown below where multiple tags are combined using the Boolean AND operator.



But what if you need multiple services or endpoints. This can be accomplished using the Boolean OR operator to join the query together. This is done in the query below. You may notice that the Boolean operators need to be visually shifted to line up with the tags (e.g., the first AND operator is over the first two tags). Particular care is needed because the order of Boolean operator precedence is that the AND operators are evaluated first and then the OR operators are evaluated. So, the query below is equivalent to:

(destination service.name=’cart’ && destination endpoint.name=’Get /cart/:id’)
OR
(destination service.name=shipping’ && destination endpoint.name=’Get /cities)

Those are the basics of declaratively defining an AP using a query. As you can see, it is really easy. So, let’s take a little quiz to consider a variety of AP queries. Take a look at the following queries and see if you can understand what services or endpoints will be included in the AP. The answers are found at the end of this article.


Query 1

Query 2

Query 3

Query 4

Query 5

Query 6

Summary

An Application Perspective is an always up to date group of services or endpoints that you are interested in. It is declaratively defined as a query that is evaluated every second. This allows you to focus on monitoring and analyzing the services of interest to you.

The next article in the series will be most relevant to developers and SREs. It outlines how an AP, as well as its parts, relate to the software and infrastructure in the system.
As promised, here are the answers to the example queries provided in the prior section.