Operations Management Suite (OMS): Service Map and Wire Data 2.0

Introduction

In OMS Log Analytics, there are several solutions that are designed to assist you with monitoring your on-premises infrastructure and Azure public cloud from the network level. Two of these solutions collect data from the TCP/IP stack on the Windows and Linux agents. In this chapter, we will look into these two solutions because they have many things in common and most likely you will use them together. These two solutions are:

  • Service Map
  • Wire Data 2.0

By analyzing the packets on the TCP/IP stack, you can gain a deeper insight into which end points your OMS agent computers are communicating with, if there are any potential security breaches, as well as dynamically drawing a dependency map between different nodes in a distributed application.

Microsoft Dependency Agent

In addition to having the Microsoft Monitoring Agent (MMA) installed on the computers managed by OMS, if you wish to enable the Service Map and the Wire Data 2.0 solutions on the agent computers, you will also need to install the Microsoft Dependency Agent.

The Microsoft Dependency Agent does not support 32-bit operating systems and it only supports a subset of operating systems that are supported by the OMS agent (MMA). You can find the full list of Windows and Linux operating system versions supported by the Microsoft Dependency Agent in the Service Map official documentation here: https://docs.microsoft.com/en-us/azure/operations-management-suite/operations-management-suite-service-map-configure.

The Microsoft Dependency Agent can be downloaded from the configuration pages of either the Service Map or Wire Data 2.0 solutions as shown in Figure 1.

FIGURE 1. DOWNLOADING THE MICROSOFT DEPENDENCY AGENT FROM THE SERVICE MAP & WIRE DATA SOLUTION CONFIGURATION PAGE

Installing the Microsoft Dependency Agent

The Microsoft Dependency Agent does not transmit data itself, instead it relies on the OMS agent to transmit data to OMS. Therefore, no additional firewall ports need to be opened for the Microsoft Dependency Agent as long as the OMS agent firewall requirements are met. To install the Microsoft Dependency Agent, you will need to make sure the OMS agent is installed first.

If you are enrolling agent computers to OMS via System Center Operations Manager (SCOM) management groups, you can simply install the Microsoft Dependency Agent on the computers that are using the SCOM version of the Microsoft Monitoring Agent.

If your agent computers cannot access the internet and you are using the OMS Gateway Server, this scenario is also supported for the Microsoft Dependency Agent.

The Microsoft Dependency Agent installation instructions for both Windows and Linux computers are documented in the Service Map official documentation here: https://docs.microsoft.com/en-us/azure/operations-management-suite/operations-management-suite-service-map-configure.

Note: The Microsoft Dependency Agent is used by both the Service Map solution and the Wire Data 2.0 solution and although its documentation falls under the Service Map section of the OMS documentation, it also applies to the Wire Data 2.0 solution.

Once the Microsoft Dependency Agent is installed, you should be able to see the associated service running on your computer as shown in Figure 2 (Windows) and Figure 3 (Linux).

FIGURE 2. MICROSOFT DEPENDENCY AGENT SERVICE ON WINDOWS COMPUTER

FIGURE 3. MICROSOFT DEPENDENCY AGENT SERVICE ON LINUX COMPUTER

Service Map Solution

In June 2015, Microsoft announced the acquisition of a company named BlueStripe Software. BlueStripe's FactFinder tool helped make them one of the market leaders in dynamic application dependency mapping, and Microsoft acquired BlueStripe with the primary goal of integrating the FactFinder capabilities into OMS as a cloud-based offering.

In early 2017, the OMS Service Map solution became generally available to the public.

This solution offering is based on the BlueStripe FactFinder tool.

Note: during the development phase, the original name for the Service Map solution was called "Application Dependency Monitor" (ADM). If you see anyone uses this name or abbreviation, most likely he/she is referring to the Service Map solution.

The OMS Service Map solution automatically discovers the dependencies and relationships between OMS managed agent computers. Once you have gained insight into the application dependencies on your computers using the Service Map solution, the data generated by the Service Map solution should help you make better decisions when working in the following areas:

  • Application Migration. When migrating an application to another platform or to the cloud, the first task is typically identifying the application components. Often the application has been evolved over the years and it is not the same as what is described in the original design document. Service Map can help you to identify the application components programmatically and therefore reduce the risks of migration projects.
  • Disaster Recovery (DR) Planning. Similar to Application Migration, when planning for DR, it is crucial that all the components of the application are accurately identified. Therefore, this is a perfect use case for Service Map.
  • Patch Management. When patching servers, often you will need to patch them in a certain order to ensure the maximum availability of the application (i.e. patching Failover Cluster nodes or NLB cluster nodes separately). Service Map helps to identify the dependencies of servers when you are developing your patching plans.
  • Incident and Problem Management. When an incident or problem is raised for a server or an application, Service Map can help your organization to determine the real impact of the outage.

Enabling and Configuring Service Map Solution

The Service Map solution can be enabled individually or as part of the Insight & Analytics Solution Offer, as shown in Figure 4.

FIGURE 4. SERVICE MAP SOLUTION IN THE OMS SOLUTIONS GALLERY

Since the Service Map solution is one of the "premium" offerings in OMS Log Analytics, your OMS workspace must be configured to use either the OMS (Per Node) or Free pricing tiers. The Standalone pricing tier is not supported. When trying to enable the Service Map Solution in a workspace that is using the Standalone pricing tier, you will be prompted to change the pricing tier for your workspace, as shown in Figures 5 and 6.

FIGURE 5. ENABLING SERVICE MAP SOLUTION IN A WORKSPACE WITH STANDALONE PRICING TIER

FIGURE 6. CONFIGURING WORKSPACE PRICING TIER

When the OMS workspace is configured to use the OMS (Per Node) pricing tier, you will see the four solution offers: Insight & Analytics; Automation & Control; Security & Compliance and Protection & Recovery (shown earlier in Figure 4). As you can see from Figure 7, the Service Map solution comes as part of the Insight & Analytics solution offer.

FIGURE 7. ADDING INSIGHT & ANALYTICS SOLUTION OFFER

Once the Service Map solution is added to your workspace, you will see its tile on the overview page of the OMS portal.

Note: The solution tile may initially show that the solution requires additional configuration. This is because your OMS workspace has not received any data from the Microsoft Dependency Agents. After you have deployed the Microsoft Dependency Agent on one or more OMS managed computers, you should be able to see the agent count on the solution tile shortly (as shown in Figure 8).

FIGURE 8. SERVICE MAP SOLUTION TILE

Using Service Map Solution

The Service Map solution visualizes the inbound and outbound TCP/IP connections of the OMS agent computers that have the Microsoft Dependency Agent installed. As shown in Figure 9, when you have selected a computer from the list on the left, a map is displayed that maps:

  • Inbound connections to the local process
  • Outbound connections from the local process to the remote computer
  • Various other related information about the selected agent (from data collected by other solutions)

FIGURE 9. OMS SERVICE MAP SOLUTION

In our example shown in Figure 9, from the list on the left, there are three Windows and one Linux active computers over the last 10 minutes. With the outbound connections to remote computers, the computer names or IP addresses, as well as the port numbers of the remote computers are displayed on the map. For some of the well-known port numbers such as HTTP, HTTPS, DNS, LDAP, SCOM SDK, etc., the associated protocol/application name is also displayed next to the port number.

If the Remote computer is also an OMS agent that is reporting to the Service Map solution, you will see either a Windows or Linux icon. In this scenario, you can also expand the remote node and see which remote process applies to a particular connection, as shown in Figure 10.

FIGURE 10. REMOTE COMPUTERS THAT ARE ALSO REPORTING TO THE SERVICE MAP SOLUTION

By default, the TCP/IP connections between different processes within an agent (SelfLinks) are not displayed on the map. You can configure the map to show Self-Links by selecting the "Show Self-Links" option on an agent computer, as shown in Figures 11 and 12.

FIGURE 11. SELECTING "SHOW SELF-LINKS" OPTION

FIGURE 12. SERVICE MAP WITH SELF-LINKS

You can view the map legend by clicking on the "Map Legend" link (as shown in Figure 13).

FIGURE 13. MAP LEGEND OF THE SERVICE MAP SOLUTION

Using the "Map Legend" link, we can see that failed connections are displayed using a red dotted line so they can be easily identified from the map and in Figure 14 we can see an example of two failed connections.

FIGURE 14. FAILED CONNECTIONS

There are a number of panels available on the right-hand side of the Service Map page that you can interact with for more information. These panels are detailed as follows:

  • Summary – High-level overview of the agent computer
  • Properties - OS, hardware information of the agent computer
  • Alerts – Number of OMS alerts associated to the agent computer
  • Log Events – Overview of event types and count generated by the agent computer.
  • Changes – Changes detected by the Change Tracking solution (Services, Daemons, Software, and File changes).
  • Performance – Key Operating System performance counters, as well as the bytes sent and received by processes.
  • Security – Security issues detected by the Security and Audit solution
  • Updates – Missing updates detected by the Update Management solution.

There are several badges at the bottom of the computer in the map. These badges represent the Alerts, Changes, Security, and Updates status of the computer. If any issues are identified in these areas, the border of the computer node will change color similar to our example shown in Figure 15.

FIGURE 15. AGENT COMPUTER IN A CRITICAL STATE

In addition to using the interactive map, you can access the Service Map computer and process inventory data via Log Search. The Service Map solution produces two log types. You can access the computer information by using the ServiceMapComputer_CL log (i.e. Type=ServiceMapComputer_CL), and the process inventory data using the ServiceMapProcess_CL log (i.e. Type=ServiceMapProcess_CL).

The Service Map solution also provides a REST API that enables you to query Service Map dependency data programmatically. The Service Map REST API is documented on the Microsoft documentation site here: https://docs.microsoft.com/en-us/rest/api/servicemap/. This API is discussed in detail in this book in "Chapter 17 Custom OMS Solutions".

Wired Data 2.0 Solution

The OMS Wire Data 2.0 solution collects network data from computers with the OMS agent (MMA) deployed. Like other OMS solutions, the Wire Data 2.0 solution works with both Operations Manager (SCOM) managed and directly connected agents. Network data is combined with the log data collected by other OMS solutions, enabling you to correlate data from multiple solutions through the search functionality.

Note: At the time of writing, the Wire Data solution available is version 2.0. It is different than the original version 1.0 release as the older version did not leverage the Microsoft Dependency Agent to collect data.

Similar to the Service Map solution discussed earlier in this chapter, the Wire Data 2.0 solution relies on the Microsoft Dependency Agent to attach to the Windows network stack so it can poll and extract statistical data on network communication between managed Windows computers. This is applicable for both SCOM and direct attached agents. Like other solutions, data sent to OMS is near real time.

Note: Data collected for the Wire Data solution is sent directly from the agent to OMS, even for SCOM managed agents.

In the following sections, we will review the features of the Wire Data 2.0 solution and how they extend the native capabilities of System Center in identifying network traffic patterns for gaining better insight into specific network events.

Overview of the Wire Data 2.0 Solution

You can enable the Wire Data 2.0 solution in the Solutions Gallery, which is accessible from the OMS home page in your subscription. To do this, click on Wire Data in the solutions gallery, then click the Add button, as shown in Figure 16.

FIGURE 16. ENABLING WIRE DATA 2.0 SOLUTION

Note: As is the case with the Service Map Solution, the Wire Data 2.0 solution is also a premium solution that is only available in the Free and OMS (Per Node) pricing tiers. You cannot enable this solution in a workspace that is using the Standalone pricing tier.

When you search using wire data, you can filter and group data using the OMS query language, pivoting on any of the available metrics collected by the Wire Data 2.0 solution.

You can use this data to provide visibility into a number of scenarios, including:

  • Viewing information about the top agents and top protocols
  • Examining when certain computers (IP addresses/MAC addresses) communicated with each other, for how long, and how much data was sent
  • Identifying communication initiated by external IP addresses
  • Identifying traffic spawned by a specific process on a Windows computer or multiple Windows computers

At first glance, this data may seem similar to performing a capture of network data with WireShark or other similar network packet capture and analysis tools. However, an important distinction of the Wire Data 2.0 solution exposes metadata about traffic on your network, which is easily searchable. Therefore, it lacks much of the detail of a full capture of network data and as such, is not intended for packet-level analysis.

The advantage of network data provided in the Wire Data 2.0 solution, however, is that it can provide insight into overall network communication patterns and significant events without reconfiguring switch ports, installing appliances and performing and analyzing network packet captures. The Wire Data 2.0 solution only requires the Microsoft Monitoring Agent and the Microsoft Dependency Agent, which is a huge advantage in scenarios where you do not own the actual network fabric, such as hosted data centers or public cloud platforms, like Microsoft Azure.

The caveat though is that to achieve complete visibility with the Wire Data 2.0 solution, you must install both the Microsoft Monitoring Agent and Dependency Agent on all of your managed systems. As mentioned previously in this chapter, the Microsoft Dependency Agent does not support 32-bit operating systems and it only supports a subset of Windows and Linux operating systems. Since the Wire Data 2.0 solution depends on the Microsoft Dependency Agent, the visibility of the communication across your full environment may not be possible.

Search Collected Wire Data

You get a number of built-in searches bundled with the Wire Data 2.0 solution and these are shown in Figure 17.

FIGURE 17. WIRE DATA 2.0 BUILT-IN SEARCH QUERIES

As you have seen in previous chapters, you can leverage these queries in conjunction with recommendations and menus within query results to build more complex queries while you gain familiarity with the OMS query syntax.

  1. On the Overview page, click the Wire Data 2.0 tile.
  2. In the list of Common WireData Queries, click Amount of Network Traffic (in Bytes) by Process to see the list of returned processes, by Process Name as shown in Figure 18.

Type:WireData | measure Sum(TotalBytes) by ProcessName

FIGURE 18 SEARCH RESULT FOR "AMOUNT OF NETWORK TRAFFIC (IN BYTES) BY PROCESS" QUERY

  1. You can then click on a specific process to drill down into its event detail.
  2. Using the "…" menu next to the data fields in the search results, you can add additional filters, such as filtering on the network port, as shown in Figure 19.

FIGURE 19. APPLYING ADDITIONAL FILETER ON THE SEARCH RESULT

As you can see, you can use the OMS user interface to build queries that are more complex while you familiarize yourself with the full capabilities of the language.

Combining Wire Data with Other Solutions

Although using data returned from the built-in "Common Wiredata Queries" might be interesting by itself, it is possible to use the search interface of OMS to correlate data from other OMS solutions to provide greater context and insight for your monitored workloads. For example, the Security and Audit solution is designed to detect security issues which include any threats within your network environment. It uses data collected by other solutions such as the Wired Data 2.0 solution. As shown in Figure 20, the Network Security dashboard in the Security and Audit solution uses the wire data to detect network related threats.

FIGURE 20. NETWORK SECURITY DASHBOARD IN THE SECURITY AND AUDIT SOLUTION

Note: In order to use the following example, you will need to enable the Security and Audit solution. However, you can use data from other solutions to combine with wire data to achieve similar results.

Correlating security data with wire data

If the Security and Audit solution is installed, you can correlate security related data such as malicious IP and other log types such as wire data together, as shown in this example:

MaliciousIP=* AND (RemoteIPCountry=* OR MaliciousIPCountry=*) AND (((Type=WireData AND Direction=Outbound) OR (Type=WindowsFirewall AND CommunicationDirection=SEND) OR (Type=CommonSecurityLog AND CommunicationDirection=Outbound)) OR (Type=W3CIISLog OR Type=DnsEvents OR (Type = WireData AND Direction!= Outbound) OR (Type=WindowsFirewall AND CommunicationDirection!=SEND) OR (Type = CommonSecurityLog AND CommunicationDirection!= Outbound))) (RemoteIPCountry="People's Republic of China" OR MaliciousIPCountry="People's Republic of China")

This query lists all the malicious IPs from the People's Republic of China that have attempted to access your network. The query correlates data from a number of data sources including the Wire Data 2.0 solution, IIS logs, DDI solution, Windows Firewall logs, etc. The results of the query are shown in Figure 21.

FIGURE 21. SEARCHING MALICIOUS IPS FROM CHINA THAT HAVE ATTEMPTED TO ACCESS YOUR NETWORK

At the time of writing, the Security and Audit solution is the most meaningful source of data for correlation with the Wire Data 2.0 solution. This may change over time as new OMS solutions become available.

Summary

In this chapter, you have learned about the capabilities of the Service Map solution and the Wire Data 2.0 solution in extending the native networking monitoring capabilities of System Center. Additionally, you learned how to leverage OMS search not only to draw insights from wire data, but to provide deeper insight by correlating wire data with data from the Security and Audit solution.

Additional insight into network data via OMS is available with the Azure Network Security Group Analytics solution and the Network Performance Monitoring solution, which are both available in the OMS Solutions Gallery.