Creating and Using Epoch Maps

Overview

Application maps are an easy way to see all application components and understand their dependencies. The AOC delivers an auto-discovered application map without requiring any code change. Using maps, users can visualize and understand the applications from multiple perspectives.

For example, the below maps show a kubernetes cluster grouped at the host, namespace or pod level.

In this tutorial, we will walk through steps of creating and using maps. Better yet, we will highlight specific use cases for leveraging the dependency chains in maps to help with incident response and production deployments.

The zoom and pan features of the map help you move around and visualize the discovered services. Additionally, you can search for specific services, which will highlight those services on the map. The picture below searches for MySQL services in the application. In addition to discovering services, the Default Map also captures dependencies and key performance metrics (latency and throughput) for services.

Summary:

• Login to Epoch webapp
• Select Map Sandbox from left navigation
• Use Default Map to discover and understand services in your application
• Use search to locate HTTP, DNS, MySQL, etc. services on the map

Creating Your First Map

The Default Map offers quick, immediate visibility into all of the services that compose your application. However, if you are responsible for a specific subset of services, you can create a map containing just the information relevant to those services.

In this example, assume we are responsible for the sock-shop application, and we want a map for sock-shop consisting of all its pods and their dependencies. Epoch automatically collects the kubernetes metadata such as pod names, namespaces, service names, etc. Thus, we need only apply the correct filters and select the proper grouping rules to customize the map based on the relevant metadata. We can do so with the Filters and GroupBys features shown below.

Walkthrough of Creating a Map for sock-shop:

1. Start with the Map Sandbox in the left navigation. This will load the Default Map.
2. Apply a filter to restrict pods to the sock-shop namespace. Use the tags.kube_namespace attribute and set it to the sock-shop namespace.
3. Since we want sock-shop map to be at the pod-level, start by changing the grouping criteria to pod_name
4. Name the map and save it. That's it we are done!
   The figure below displays the sock-shop map at the pod-level.

Summary:

• Load a Default Map from Map Sandbox
• Change the GroupBy to pod_name
• Apply filter by using tags.kube_namespace attribute
• Name and save the map

Understanding Impact of Deployment

As a result of DevOps and microservices, the rate of production deployments has increased significantly. Unfortunately, deployment and code changes are also among the top causes for production issues. With Epoch maps, you can evaluate the impact of deployments in the complete application context and prevent costly incidents.

Let's use a concrete example of updating the shipping pod in our sock-shop application. In the figure below, (a) shows the sock-shop before and (b) shows the same map after deploying the new shipping pod. Even though the throughput, shown in requests per second (rps) remains roughly the same, there is an almost 2x jump in latency across all the pods in the dependency chain of front-end --> orders --> shipping. This is a good indicator to take a second look at the changes made to the shipping pod before it hits production!

Summary:

• Use dependency chains in Epoch maps, to evaluate the impact of deployments on other dependent services
• Ensure there are no performance drifts before the deployment hits production

Accelerating Root Cause Analysis in Dependency Chains

Another natural use case for maps is to expedite root cause analysis.

Let's say we are monitoring the latency for the front-end pod since that is the service exposed to end users. We have set an alert for latency spike on the front-end pod and the pager goes off. In the figure below, we can compare the before and after maps. A quick scan of dependencies reveals a spike in latency on the dependency chain leading up to the catalogue items database service. If metrics on other dependencies look normal, then the catalogue items service seems like a good candidate to diagnose further.

A very promising guidance for the root cause is revealed promptly using the maps. In the absence of maps, such analysis would involve correlation or chasing of tcpdumps across multiple machines. Epoch maps greatly accelerate root cause analysis, thereby saving time, money and best of all, delivering extra sleep for your on-call teams!