As aLTeReGo mentioned in Orion Platform 2018.2 Improvements - Chapter One , we have lots of exciting things packed into this release. It is my pleasure to present to you, the first step in the next generation of Orion mapping. Now let me begin by prefacing that this is a MASSIVE project. The functionality that you see here is an iteration of a new generation of mapping technology, and is not intended to be feature by feature replacement of any of our tools that provide mapping functionality today, for example, Network Atlas. Our goal as we take on this endeavor is to find methods for building upon our dream of one mapping tool to rule them all, but provide you significant chunks of value along the way. We need to first build the framework to accomplish this goal, yet we don't want to hold back something you may find useful in the interim.
Intelligent Mapping - What is it?
As environments grow in complexity, identifying a problem's root cause and impact tends to be just as complex. Many of you are looking for a more intuitive way to aggregate and visualize that data in a simple manner that is meaningful for your environment. A function such as intelligent mapping in a monitoring tool can help alleviate much of the pain derived from combing through pages of data, and reviewing the details provided through individual resources piece by piece. Understanding your needs and the problems you are trying to solve is fundamental in everything we do. A major theme that emerged from our community is that everyone loves the idea of maps and sleek visualizations, the problem was, maintaining them. Spending time in Network Atlas can yield some significant results, but time is not a luxury that many of us have. If something changes, which it does constantly, you are forced to set aside more time to go mimic those changes in the map. This presents and interesting challenge for SolarWinds, but also gave us a potential entry point....
With this project, we needed to first conceptualize what will be needed across all iterations, and where our starting point should be. As alluded to before, tons of functionality exists today in tools like Network Atlas, the WorldMaps widget, and even through AppStack, that allow users to "visualize" their environments. While these tools all have their unique capabilities inside the platform, we want to begin down the path of advancing those capabilities even further, and allow the power of the platform to shine.
The first step that needed to be taken was to obviously visualize the entities within Orion. When I say entities, I am referring to any object monitored by Orion such as network devices, servers, interfaces, volumes, and so on... The second similarly important factor is that we needed to visualize the connections between those entities. Whether these connections are based on physical or logical relationships, this data is just as critical to quickly reflecting points of concern in your environment.
Orion Intelligent Mapping is an advanced troubleshooting tool that provides a contextual and graphical portrayal of an entity and its critical relationships. In other words, this functionality will be available out-of-the-box for entities like your routers, switches, servers, interfaces, volumes, and even groups. It visualizes the physical and logical relationships between them, leveraging data from Network Performance Monitor's Topology, Server & Application Monitor's Application Dependencies, and other relationship information, to quickly isolate and identify critical health and performance issues.
In this version, maps are made available by drilling into an entity details page as shown below. What this means, is that when you upgrade to any product containing the 2018.2 Core, and drill into an entity details page, there will be a sub-view that is provided for you called "Map". Clicking on that view will obviously generate... wait for it... a map!
Our number one goal was that maps require absolutely no user intervention, and are updated automatically as changes are made in the Orion environment. The list of entities that are supported for this version are as follows: Nodes, Interfaces, Volumes, Virtual Machine, Virtual Host, Virtual Clusters, Virtual Datacenter, VCenter, Hyper-V Hosts, Hyper-V Cluster, WPM Step, WPM Transaction, WPM Player Location, and Groups.
Map Canvas
There are two key components to this feature. The section that contains the visualization and the actual graph is what we refer to as the canvas. In the example provided, selecting an entity's map view pulls up a detailed graphical representation, with the map centered on the "seed" object (see Figure 1). Everything else drawn on the map, stems from that seed. Anything not immediately connected to the seed entity is opaqued in order to differentiate and provide a point of focus. This comes in especially handy with larger maps that could have excessive elements on them. The goal here is to draw attention to problems associated to the entity you are investigating, but also extend that investigation to related connections or neighboring devices(Figure 2).
| Figure 1 | Figure 2 |
|---|---|
 |
 |
We needed to incorporate some creative design strategies as well. For example, at times there may be multiple connections between two entities. Whether those represent a simple relationship or actual data flow, we have to be conscious of the way that data is represented in the map. Too much data, and the map becomes unusable. Too little, and it doesn't really prove to be the powerful troubleshooting aid intended. Any entity or connection that has breached a threshold will be automatically surfaced in the context of the map. This way you are not sifting through data to identify areas of concern.
This is also the area that allows you to interact with the map through controls such as zoom and pan options. You may also target specific areas of the map through hovering, or selecting a device or connection. In the bottom right hand corner, we do provide controls so that you can toggle layouts, click to zoom in or zoom out, center the map on a selected entity, or even launch into full screen mode to have as much real estate as possible for viewing the map.
The Inspector Panel
The second core component of the map is what we refer to as the inspector panel. The inspector panel is like a mini data warehouse for the entities and connections on the map. In this version, selecting an entity such as a node will pop open the inspector panel from the right, which will show the name of the device, IP, Vendor, and Machine Type, along with a list of all that entity's "children" or "decedents". The list generated will be in context to the entity selected. For example, a server may have interfaces, volumes, and applications that would be considered children/decedent's of this node. If drilling into the application however, its children or decedents would be the components that make up that application. This list has controls such as "Sort" that allows you to control ascending and descending formatting of the list either via status or name, and "Show" which provides filters based on entity type such as hardware or interface. We also provide a "type ahead" search feature for those long lists that extend beyond a single view-able page.
Selecting a connection between entities on the canvas will provide you an inherently different view of the inspector panel. As previously mentioned, there are obviously multiple types of connections which could be represented and we need to ensure this is easily interpreted through our tool. In order to provide you the ability to distinguish between these distinct types of connections, we have managed to include unique behavior for each connection type. The following connection types will be visible in the map sub-view.
Orion Dependency Connection
The dependency connections do not represent any kind of data traversing between the two entities, but rather easily convey that a relationship exists between them. It could be an administratively defined dependency, or perhaps a dependency identified through its ancestry. In the screenshot below I selected a virtual machine, and can see this VM has a relationship to its host, which has a relationship to its cluster, to the datacenter, and the finally, the VCenter.
The inspector panel view of these connections would look as follows:
Application Dependency Connection
For those of you unfamiliar with the ADM Connections, this was a feature introduced in Server & Application Monitor 6.6 which allows you to quickly see which applications or systems are communicating to each other. You can learn more about that feature here Announcing General Availability of Server & Application (SAM) 6.6. Since Orion Maps is a feature of the platform, we don't want to leave anyone out, so of course this type of communication is captured and also mapped automatically as a distinct connection type. There are two possible visualizations you may notice depending on how you adjusted Application Connection Settings. With Connection Quality Polling enabled, the connections will highlight additional data pertaining to TCP latency and packet loss between the two entities.
Selecting an ADM Connection will provide a list of the processes communicating between the two systems and allow for additional detail by drilling into the Connection Details page.
If you have not enabled Connection Quality polling, we will represent the relationship on the canvas by a light blue line with no metric pill. This connection is still automatically identified, and therefore mapped within the canvas. You will also have access to the Connection Details page.
Topology Connection
Topology Connections are generated through NPM's topology engine and meant to provide a unique representation of your network infrastructure. Emanating from community feedback, the design illustrates how a ton of detail can be depicted in a single, simple connection, and even has a Network Weather-map type feel. First, the width of the topology connections will be based on interface bandwidth. This means whether you have a 10 GB link, a 1 GB link, or a 100 Mb link, you should easily be able to determine differences across the map. This is useful for quickly identifying if bandwidth is properly set and distributed across the environment. Hovering over a topology connection will provide a tool-tip for the metric pills similar to what you see in the screenshot.
By default, the metric pills highlight outbound traffic and utilization details on either side of the connection. Based on thresholds set in NPM, these links will change to yellow for warning, or red to critical, if a threshold is breached. The link may also change to highlight something else entirely. Below you can see a specific interface which has hit a critical threshold for errors & discards.
The inspector panel will contain all the connections between two entities. In the example below, the map is surfacing the problem link and indicating a threshold has been met, while the inspector panel displays all the data between each connection. On either side of the panel will be the interfaces, which can be associated to the parent device situated above. In an easy to read table, all the most recent polled data for traffic, errors & discards, utilization, and the maximum bandwidth will be presented.
Maps in Groups
The new map sub-view is also automatically generated within groups. Groups are treated as an entity just like an interface, volume, node, or any other object in Orion. However, behavior of maps within groups is slightly different. When creating groups, you are specifying particular members that are the focus for that group. In this context, we don't want to show "related" entities on a group map, or conversely roll entities up to a parent, if that was not your overall intent. Therefore, drilling into a map sub-view for a group will show group members only and any connections that exist between the member objects in the group. This allows a bit of control in this version, as here you have the opportunity to decide what objects are included in a map. Many of you may already leverage groups today in unique ways, and this could provide some additional visibility for those views. The great thing is that you could leverage dynamic queries to speed up the building of groups, which will then auto-add new members to the map. This means there is little to no maintenance for the maps being built through this process. Guess I am going to have to retire my post for how to do this today: Custom Maps for Group Details Page
Here is an example in which I mapped out the entire virtual infrastructure in my lab.
 |
 |
We are excited to take this step and anxious to hear your feedback. We feel that this tool will allow you to see massive amounts of data in a single comprehensive view, and mitigate having to jump from page to page to isolate problems. The best part is that you don't have to do anything! We hope to continue to build on this within the platform as we have a very long list of feature requests from our community, and I promise we are listening. Stay tuned for more. serena still has more great things from the platform in her post: Orion Platform 2018.2 Improvements - Chapter Three
I am very excited to announce a NEW VERSION of ORION MAPS: Orion Platform Improvements - Intelligent Mapping Enhancements
