Creating and Using Netsil Maps


Application maps are an easy way to see all application components and understand their dependencies. The Netsil Application Operations Center (AOC) delivers an auto-discovered application map without requiring any code change. Using the AOC 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. multi-level-maps

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


We will be using the sock-shop app running on a Kubernetes cluster as our target application for mapping and monitoring. The AOC is installed as a pod and the collectors are installed as DaemonSets on each of the Kubernetes worker nodes (see figure below). You can easily get this setup going in your Kubernetes cluster using our installer.


Discovering Your Application Using Default Map

Once the AOC and collectors are installed, login to the webapp and switch to the Map Sandbox. This will load the Default Map. The Default Map uses an internal algorithm (AutoGroup) to identify services based on the protocol and attributes of the protocol such as HTTP URIs, DB queries, etc.

For example, in the picture below you see the auto-discovered HTTP, DNS, and MySQL services. auto

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. search


  • Login to Netsil 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. Netsil 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. pod-map


  • 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 Netsil 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! deploy


  • Use dependency chains in Netsil 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. Netsil maps greatly accelerate root cause analysis, thereby saving time, money and best of all, delivering extra sleep for your on-call teams! incident