Welcome to part 2 of the What’s New series for VMware vRealize Network Insight 4.1. In this post, I will dive deep into the new capability called Application Discovery using details directly from the infrastructure. Using vCenter Custom Attributes & AWS tags and the VM & AWS EC2 instance naming schema. In the next post (coming soon) in this series, I’ll cover importing applications from the ServiceNow CMDB and the application troubleshooting dashboard.
If you’d rather watch a demo instead of reading, have a look at this video!
Application Discovery
The application is what it’s all about. It’s what drives the business and generates revenue and lets us, the people in IT, keep our jobs. The infrastructure that drives it should Just Work ™. This is why Network Insight is focusing more and more on the application and correlating the infrastructure components directly to the application for a holistic overview of the entire landscape.
Before 4.1, application constructs had to be created manually or via the API. With the new application discovery capabilities in 4.1, we can automate that process and discover application constructs using vCenter custom attributes, AWS tags, the VM or EC2 instance naming convention, or retrieving the applications from a CMDB (ServiceNow).
These discovery methods can be part of an initial discovery for a brownfield (after which automation could take care of the new applications) or it could be used in a continuous fashion, where application discovery is run periodically to make sure all application constructs are present in Network Insight. It’s also important to know that these discovery methods can be run simultaneously and multiple times.
If 1 discovery method is not enough to discover all your applications (because you have multiple ways of documenting apps), just run several discoveries!
Before I get into the weeds, know that Network Insight 4.1 introduced the concept of Saved Applications and Discovered Applications. The saved applications are the application constructs that can be used in the rest of Network Insight for security and migration planning, troubleshooting and more. The discovered applications page is the new capability which I’ll be describing in the rest of this post.
Let’s get into some details and examples of each discovery method.
Using Custom Attributes or Tags
When your workloads have been tagged with the application and tier names, Network Insight can pick up the values of those tags and use them to discover the application constructs. This will work with vCenter custom attributes and AWS EC2 instance tags.
During the discovery process, you can limit the scope of the discovery to a specific data center, AWS VPC, vSphere cluster or any of the other logical objects within the compute environment (vCenter or AWS).
There are 2 tags or attributes required for this discovery method: a tag for the application name and a tag for the tier name.
Example – vCenter Custom Attributes
Using the custom attributes inside vCenter, Network Insight can form the right application constructs. This is done by defining a global custom attribute with a name for both the application name and the tier, in this case; Application-Name and Application-Tier to keep it obvious:
After defining these global custom attributes, you can attach them to VMs and input values on each VM. Here we have 2 VMs that are part of two different applications and in different tiers:
These VMs belong to an application that has 3 tiers (Web, App, and DB) and it has 5 VMs each. To discover these apps, use the following options:
Take note of how I selected the All VMs scope and the application and tier tag names. You will instantly see how many applications have been discovered on the right. Perhaps more important, you’ll also see how much VMs have not been classified by this search. In this case, the unclassified VMs are VMs that do not have the right tags.
There’s also the option to limit the tag values to a specific set of values. If you select “and Values matching” next to the actual tag, there’s the option to use wildcards or specific values to limit the tag values.
Using the options above, these will be the discovery results:
The discovery output is a list of applications with their definitions. In this case, 2 different applications, with 3 tiers and 5 VMs each. If the apps already exist in a brownfield environment and NSX is used to protect them (using the Distributed Firewall), you will also see the protected and dropped network flow count.
Oh, and let’s not forget the awesome honeycomb widget that is generated by the discovery! This widget can be used to easily navigate through the discovered apps and quickly make sure you save the right application constructs.
In the above screenshot, the green pop outs are there as a guide. The blue pop out is to be used to actually save the application construct to Network Insight and will add the app to the saved applications.
Using a Naming Convention
When your workloads have a consistent naming convention, Network Insight can also pick out the application and tier name from the name of the VM or EC2 instance itself, using a regular expression (or regexp).
For example, let’s say there are VMs named as following: CustomerCare-App-VM01, CustomerCare-DB-VM01, CustomerCare-Web-VM01
We can run the application discovery and create an application construct named CustomerCare and have 3 tiers named App, DB, and Web, with the right VMs in those tiers.
Example – Based on Naming Convention
This regular expression uses the Elastic Search backend, meaning it is possible to get really advanced with matching and retrieving the names. Before I go into the more advanced uses, let’s see how it looks when we’re just using the dash (“-“) as a separator between the application and tier name.
The above example lists the regexp to capture both the application and the tier name from these CustomerCare VMs. To break this down, let’s have a look at the rules for this expression:
- Everything between the ( ) characters is being captured as the application or tier name.
- .* is a wildcard, which means to capture everything. This can be more limited by looking for something consisting only of digits, only letters, a specific length, and more. Have a look at the Elastic Search syntax for more options.
- This expression works because of the dash separators in between the wildcards. It looks specifically for these separators and matches anything in between them.
In the interface, this is how it should look:
Take notice of the way the input box shows you which parts of a VM is matched, while you’re typing. It takes the real-time inventory of your VMs and EC2 instances and matches the regular expression you’re typing to them, in order to validate it, whilst you’re typing!
Also, notice the unclassified VMs at the bottom right of each section. This list of VMs do not match the regular expression and would need a different expression in order to be discovered.
When you hit the Discover button, you will be taken to the same honeycomb widget as I showed before, in order to quickly figure out which applications you want to save.
Conclusion
Application Discovery based on tags and/or a naming convention will bring in application context into Network Insight to provide correlating between the virtual and physical infrastructure components and the actual application themselves. Doing so will allow you to monitor and troubleshoot the environment a lot more efficient, centered on the application.
One more thing…There is a 3rd way of discovering applications, and that is by pulling in data from the ServiceNow CMDB. I’ll cover that integration in the next post in this series.
Post Series
- What’s New for vRealize Network Insight 4.1 and Network Insight Cloud Service
- Application Discovery with Network Insight – Using Tags & Naming Conventions
