Service Map is a solution that you can enable in Operations Management Suite (OMS) able to automatically carry out the discovery of application components, on both Windows and Linux systems, and to create a map that shows almost real-time communications between the various services. All this allows you to view the servers as interconnected systems that deliver services.
In System Center Operations Manager (SCOM) there is the possibility to define Distributed Application to provide an overall view of the health status of an application consists of different objects. The Distributed Application does not provide additional monitor functionality, but merely to relate the state of the objects in the system monitor, to provide the overall health status of the application.
Through integration between Service Map and System Center Operations Manager, you can automatically create in SCOM diagrams that represent the Distributed Application based on the detected dependencies from the Service Map solution.
This article will examine the procedure to be followed to activate this integration bringing back the main features.
Prerequisites
This kind of integration is possible if the following requirements are verified:
- Environment System Center Operations Manager 2012 R2 or later.
- Workspace OMS with Service Map solution enabled.
- The presence of a Service Principal with access to the Azure subscription that contains the OMS workspace.
- Operations Manager-managed servers and that send data to Service Map.
Supports both Windows and Linux systems, but with one important distinction.
For Windows systems you can evaluate the use of the scenario of integration between SCOM and OMS, as described in the article Integration between System Center Operations Manager and OMS Log Analytics and simply add the Dependencing Agent of Service Map on the various servers.
For Linux systems you cannot collect directly data of agents managed by Operations Manager in Log Analytics. It will therefore always required the presence of both the SCOM agent and the OMS agent. At the moment, in a Linux environment, the two agents share some binaries, but these are distinct agents that can coexist on the same machine as long as the SCOM agent is at least version 2012 R2. OMS agent installation on a Linux system managed by Operations Manager updates the OMI and the SCX SCX. We recommend that you always install the SCOM agent first and then the OMS agent, otherwise you need to edit the configuration file of OMI (/etc/opt/omi/conf/omiserver.conf) by adding the parameter httpsport=1270. After the editing you must restart the OMI Server component using the following command: sudo /opt/omi/bin/service_control restart.
The process for activating the integration
The first step required is the import, using the System Center Operations Manager console, of the following management packs (now in Public Preview), contained within the bundle that you can download to this link:
- Microsoft Service Map Application Views.
- Microsoft System Center Service Map Internal.
- Microsoft System Center Service Map Override.
- Microsoft System Center Service Map.
After completing the installation of the management pack you will display the new node Service Map, in the workspace Administration, within the section Operations Management Suite. From this node you can start the integration configuration wizard:
At the moment you can configure the integration with a single OMS workspace.
The wizard prompts you to specify a Service Principal for read access to the Azure subscription that contains the OMS workspace, with the Service Map solution enabled. To create the Service Principal you can follow the procedure in Microsoft's official documentation.
Based on the permissions assigned to the Service Principal the wizard shows the Azure subscriptions and its associated OMS workspaces:
At this point you are prompted to select which groups of machines in Service Map you want to synchronize in Operations Manager:
On the next screen you are prompted to select which servers in SCOM synchronize with information retrieved from Service Map.
In this regard, in order to make sure that this integration is able to create the diagram of the Distributed Application for a server, this must be managed by SCOM, by Service Map and must be present within the Service Map group previously selected .
Then you are prompted to select an optional Management Server Resource Pool for communication with OMS and if necessary a proxy server:
Registration takes few seconds after which the following screen appears and Operations Manager performs the first synchronization of Service Map, by taking the data from the OMS workspace.
The synchronization of Service Map data occurs by default every 60 minutes, but you can change this frequency going to act with an override on a rule named Microsoft.SystemCenter.ServiceMapImport.Rule.
Result of the integration between Service Map and SCOM
The result of this integration is visible from the Operations Manager console in the dashboard Monitoring. It is in fact created a new Service Map folder that contains :
- Active Alerts: any active alert regarding communication between SCOM and Service Map.
- Servers: list of servers under the monitor for which the information is synchronized from Service Map.
- Machine Group Dependency Views: Displays a Distributed Application for each Service Map group selected for the synchronization.
- Server Dependency Views: shows a Distributed Application for each server that synchronizes information from Service Map.
Conclusions
Many reality that they are going to use, or have already implemented the Service Map solution also have on-premises an environment with System Center Operations Manager (SCOM). This integration will enrich the information in SCOM allowing you to have full visibility of applications and dependencies of the various systems. This is an example of how you can use the power provided by OMS actually even with SCOM, without renouncing to investments made on the instrument, such as the possible integration with IT service management solutions (ITSM).