Show
Service Map automatically discovers application components on Windows and Linux systems and maps the communication between services. With Service Map, you can view your servers as interconnected systems that deliver critical services. Service Map shows connections between servers, processes, inbound and outbound connection latency, and ports across any TCP-connected architecture. No configuration is required other than the installation of an agent.
Important Service Map will be retired on September 30, 2025. To monitor connections between servers, processes, inbound and outbound connection latency, and ports across any TCP-connected architecture, make sure to migrate to Azure Monitor VM insights before this date. This article describes how to deploy and use Service Map. The prerequisites of the solution are:
Note If you've already deployed Service Map, you can now also view your maps in VM insights, which includes more features to monitor VM health and performance. To learn more, see VM insights overview. To learn about the differences between the Service Map solution and the VM insights Map feature, see this FAQ. Sign in to AzureSign in to the Azure portal. Enable Service MapUse cases: Make your IT processes dependency awareDiscoveryService Map automatically builds a common reference map of dependencies across your servers, processes, and third-party services. It discovers and maps all TCP dependencies. It identifies surprise connections, remote third-party systems you depend on, and dependencies to traditional dark areas of your network, such as Active Directory. Service Map discovers failed network connections that your managed systems are attempting to make. This information helps you identify potential server misconfiguration, service outage, and network issues. Incident managementService Map helps eliminate the guesswork of problem isolation by showing you how systems are connected and affect each other. Along with identifying failed connections, it helps identify misconfigured load balancers, surprising or excessive load on critical services, and rogue clients, such as developer machines talking to production systems. By using integrated workflows with Change Tracking, you can also see whether a change event on a back-end machine or service explains the root cause of an incident. Migration assuranceBy using Service Map, you can effectively plan, accelerate, and validate Azure migrations to help ensure that nothing is left behind and surprise outages don't occur. You can:
After the move is complete, you can check the client load and identity to verify that test systems and customers are connecting. If your subnet planning and firewall definitions have issues, failed connections in maps in Service Map point you to the systems that need connectivity. Business continuityIf you're using Azure Site Recovery and need help with defining the recovery sequence for your application environment, Service Map can automatically show you how systems rely on each other. This information helps to ensure that your recovery plan is reliable. By choosing a critical server or group and viewing its clients, you can identify which front-end systems to recover after the server is restored and available. Conversely, by looking at critical servers' back-end dependencies, you can identify which systems to recover before your focus systems are restored. Patch managementService Map enhances your use of the System Update Assessment by showing you which other teams and servers depend on your service. This way, you can notify them in advance before you take down your systems for patching. Service Map also enhances patch management by showing you whether your services are available and properly connected after they're patched and restarted. Mapping overviewService Map agents gather information about all TCP-connected processes on the server where they're installed. They also collect details about the inbound and outbound connections for each process. From the list in the left pane, you can select machines or groups that have Service Map agents to visualize their dependencies over a specified time range. Machine dependency maps focus on a specific machine. They show all the machines that are direct TCP clients or servers of that machine. Machine group maps show sets of servers and their dependencies. Machines can be expanded in the map to show the running process groups and processes with active network connections during the selected time range. When a remote machine with a Service Map agent is expanded to show process details, only those processes that communicate with the focus machine are shown. The count of agentless front-end machines that connect into the focus machine is indicated on the left side of the processes they connect to. If the focus machine is making a connection to a back-end machine that has no agent, the back-end server is included in a server port group. This group also includes other connections to the same port number. By default, maps in Service Map show the last 30 minutes of dependency information. You can use the time controls at the upper left to query maps for historical time ranges of up to one hour to see how dependencies looked in the past. For example, you might want to see how they looked during an incident or before a change occurred. Service Map data is stored for 30 days in paid workspaces and for 7 days in free workspaces. Status badges and border coloringAt the bottom of each server in the map, a list of status badges that convey status information about the server might appear. The badges indicate there's relevant information for the server from one of the solution integrations. Selecting a badge takes you directly to the details of the status in the right pane. The currently available status badges include Alerts, Service Desk, Changes, Security, and Updates. Depending on the severity of the status badges, machine node borders can be colored red (critical), yellow (warning), or blue (informational). The color represents the most severe status of any of the status badges. A gray border indicates a node that has no status indicators. Process groupsProcess groups combine processes that are associated with a common product or service into a process group. When a machine node is expanded, it will display standalone processes along with process groups. If an inbound or outbound connection to a process within a process group has failed, the connection is shown as failed for the entire process group. Machine groupsMachine groups allow you to see maps centered around a set of servers, not just one. In this way, you can see all the members of a multi-tier application or server cluster in one map. Users select which servers belong in a group together and choose a name for the group. You can then choose to view the group with all its processes and connections. You can also view it with only the processes and connections that directly relate to the other members of the group. Create a machine groupTo create a group:
Note Machine groups are limited to 10 servers. View a groupAfter you've created some groups, you can view them.
Filter by processesYou can toggle the map view to show all processes and connections in the group or only the ones that directly relate to the machine group. The default view shows all processes.
Add machines to a groupTo add machines to an existing group, select the checkboxes next to the machines you want and select Add to group. Then choose the group you want to add the machines to. In the Groups list, expand the group name to list the machines in the machine group. Select the ellipsis menu next to the machine you want to remove and select Remove. Select the ellipsis menu next to the group name in the Groups list. Role iconsCertain processes serve particular roles on machines, such as web servers, application servers, and databases. Service Map annotates process and machine boxes with role icons to help identify at a glance the role a process or server plays.
Failed connectionsIn Service Map, failed connections are shown in maps for processes and computers. A dashed red line indicates that a client system is failing to reach a process or port. Failed connections are reported from any system with a deployed Service Map agent if that system is the one attempting the failed connection. Service Map measures this process by observing TCP sockets that fail to establish a connection. This failure could result from a firewall, a misconfiguration in the client or server, or a remote service being unavailable. Understanding failed connections can help with troubleshooting, migration validation, security analysis, and overall architectural understanding. Failed connections are sometimes harmless, but they often point directly to a problem. A failover environment might suddenly become unreachable or two application tiers might be unable to talk after a cloud migration. Client groupsClient groups are boxes on the map that represent client machines that don't have Dependency agents. A single client group represents the clients for an individual process or machine. To see the IP addresses of the servers in a client group, select the group. The contents of the group are listed in the Client Group Properties pane. Server port groupsServer port groups are boxes that represent server ports on servers that don't have Dependency agents. The box contains the server port and a count of the number of servers with connections to that port. Expand the box to see the individual servers and connections. If there's only one server in the box, the name or IP address is listed. Select the ellipsis (...) at the top right of any server to display the context menu for that server. Load server mapSelect Load Server Map to go to a new map with the selected server as the new focus machine. Select Show Self-Links to redraw the server node, including any self-links, which are TCP connections that start and end on processes within the server. If self-links are shown, the menu command changes to Hide Self-Links so that you can turn them off. The Machine Summary pane includes an overview of a server's operating system, dependency counts, and data from other solutions. Such data includes performance metrics, service desk tickets, change tracking, security, and updates. Computer and process propertiesWhen you navigate a map in Service Map, you can select machines and processes to gain more context about their properties. Machines provide information about DNS name, IPv4 addresses, CPU and memory capacity, VM type, operating system and version, last reboot time, and the IDs of their OMS and Service Map agents. You can gather process details from operating-system metadata about running processes. Details include process name, process description, user name and domain (on Windows), company name, product name, product version, working directory, command line, and process start time. The Process Summary pane provides more information about the process's connectivity, including its bound ports, inbound and outbound connections, and failed connections. Alerts integrationService Map integrates with Azure Alerts to show fired alerts for the selected server in the selected time range. The server displays an icon if there are current alerts, and the Machine Alerts pane lists the alerts. To enable Service Map to display relevant alerts, create an alert rule that fires for a specific computer. To create proper alerts:
Log events integrationService Map integrates with Log Search to show a count of all available log events for the selected server during the selected time range. You can select any row in the list of event counts to jump to Log Search and see the individual log events. Service Desk integrationService Map integration with the IT Service Management Connector is automatic when both solutions are enabled and configured in your Log Analytics workspace. The integration in Service Map is labeled "Service Desk." For more information, see Centrally manage ITSM work items using IT Service Management Connector. The Machine Service Desk pane lists all IT Service Management events for the selected server in the selected time range. The server displays an icon if there are current items and the Machine Service Desk pane lists them. To open the item in your connected ITSM solution, select View Work Item. To view the details of the item in Log Search, select Show in Log Search. Connection metrics are written to two new tables in Log Analytics. Change Tracking integrationService Map integration with Change Tracking is automatic when both solutions are enabled and configured in your Log Analytics workspace. The Machine Change Tracking pane lists all changes, with the most recent first, along with a link to drill down to Log Search for more details. The following image is a detailed view of a ConfigurationChange event that you might see after you select Show in Log Analytics. Performance integrationThe Machine Performance pane displays standard performance metrics for the selected server. The metrics include CPU utilization, memory utilization, network bytes sent and received, and a list of the top processes by network bytes sent and received. To see performance data, you might need to enable the appropriate Log Analytics performance counters. The counters you'll want to enable: Windows:
Linux:
Security integrationService Map integration with Security and Audit is automatic when both solutions are enabled and configured in your Log Analytics workspace. The Machine Security pane shows data from the Security and Audit solution for the selected server. The pane lists a summary of any outstanding security issues for the server during the selected time range. Selecting any of the security issues drills down into a log search for details about them. Service Map integration with Update Management is automatic when both solutions are enabled and configured in your Log Analytics workspace. The Machine Updates pane displays data from the Update Management solution for the selected server. The pane lists a summary of any missing updates for the server during the selected time range. Log Analytics recordsService Map computer and process inventory data is available for search in Log Analytics. You can apply this data to scenarios that include migration planning, capacity analysis, discovery, and on-demand performance troubleshooting. One record is generated per hour for each unique computer and process, in addition to the records that are generated when a process or computer starts or is on-boarded to Service Map. These records have the properties in the following tables. The fields and values in the ServiceMapComputer_CL events map to fields of the Machine resource in the ServiceMap Azure Resource Manager API. The fields and values in the ServiceMapProcess_CL events map to the fields of the Process resource in the ServiceMap Azure Resource Manager API. The ResourceName_s field matches the name field in the corresponding Resource Manager resource.
Note As Service Map features grow, these fields are subject to change. You can use internally generated properties to identify unique processes and computers:
Because multiple records can exist for a specified process and computer in a specified time range, queries can return more than one record for the same computer or process. To include only the most recent record, add "| dedup ResourceId" to the query. ConnectionsConnection metrics are written to a new table in Log Analytics named VMConnection. This table provides information about the inbound and outbound connections for a machine. Connection Metrics are also exposed with APIs that provide the means to obtain a specific metric during a time window. TCP connections resulting from accepting on a listening socket are inbound. Those connections created by connecting to a given IP and port are outbound. The direction of a connection is represented by the Direction property, which can be set to either inbound or outbound. Records in these tables are generated from data reported by the Dependency agent. Every record represents an observation over a one-minute time interval. The TimeGenerated property indicates the start of the time interval. Each record contains information to identify the respective entity, that is, the connection or port, and the metrics associated with that entity. Currently, only network activity that occurs by using TCP over IPv4 is reported. To manage cost and complexity, connection records don't represent individual physical network connections. Multiple physical network connections are grouped into a logical connection, which is then reflected in the respective table. So records in the VMConnection table represent a logical grouping and not the individual physical connections that are being observed. Physical network connections that share the same value for the following attributes during a given one-minute interval are aggregated into a single logical record in VMConnection.
To account for the impact of grouping, information about the number of grouped physical connections is provided in the following properties of the record.
MetricsIn addition to connection count metrics, information about the volume of data sent and received on a specific logical connection or network port is also included in the following properties of the record.
The third type of data being reported is response time. How long does a caller spend waiting for a request sent over a connection to be processed and responded to by the remote endpoint? The response time reported is an estimation of the true response time of the underlying application protocol. It's computed by using heuristics based on the observation of the flow of data between the source and destination end of a physical network connection. Conceptually, response time is the difference between the time the last byte of a request leaves the sender and the time when the last byte of the response arrives back to it. These two timestamps are used to delineate request and response events on a specific physical connection. The difference between them represents the response time of a single request. In this first release of this feature, our algorithm is an approximation that might work with varying degrees of success depending on the actual application protocol used for a specific network connection. For example, the current approach works well for request-response-based protocols, such as HTTP/HTTPS. But this approach doesn't work with one-way or message queue-based protocols. Here are some important points to consider:
Naming and classificationFor convenience, the IP address of the remote end of a connection is included in the RemoteIp property. For inbound connections, RemoteIp is the same as SourceIp, while for outbound connections, it's the same as DestinationIp. The RemoteDnsCanonicalNames property represents the DNS canonical names reported by the machine for RemoteIp. The RemoteDnsQuestions and RemoteClassification properties are reserved for future use. GeolocationVMConnection also includes geolocation information for the remote end of each connection record in the following properties of the record.
Malicious IPEvery RemoteIp property in the VMConnection table is checked against a set of IPs with known malicious activity. If the RemoteIp is identified as malicious, the following properties will be populated (they're empty when the IP isn't considered malicious) in the following properties of the record.
ServiceMapComputer_CL recordsRecords with a type of ServiceMapComputer_CL have inventory data for servers with Service Map agents. These records have the properties in the following table.
ServiceMapProcess_CL Type recordsRecords with a type of ServiceMapProcess_CL have inventory data for TCP-connected processes on servers with Service Map agents. These records have the properties in the following table.
Sample log searchesThis section lists log search samples. List all known machinesServiceMapComputer_CL | summarize arg_max(TimeGenerated, *) by ResourceId List the physical memory capacity of all managed computersServiceMapComputer_CL | summarize arg_max(TimeGenerated, *) by ResourceId | project PhysicalMemory_d, ComputerName_s List computer name, DNS, IP, and OSServiceMapComputer_CL | summarize arg_max(TimeGenerated, *) by ResourceId | project ComputerName_s, OperatingSystemFullName_s, DnsNames_s, Ipv4Addresses_s Find all processes with "sql" in the command lineServiceMapProcess_CL | where CommandLine_s contains_cs "sql" | summarize arg_max(TimeGenerated, *) by ResourceId Find a machine (most recent record) by resource namesearch in (ServiceMapComputer_CL) "m-4b9c93f9-bc37-46df-b43c-899ba829e07b" | summarize arg_max(TimeGenerated, *) by ResourceId Find a machine (most recent record) by IP addresssearch in (ServiceMapComputer_CL) "10.229.243.232" | summarize arg_max(TimeGenerated, *) by ResourceId List all known processes on a specified machineServiceMapProcess_CL | where MachineResourceName_s == "m-559dbcd8-3130-454d-8d1d-f624e57961bc" | summarize arg_max(TimeGenerated, *) by ResourceId List all computers running SQLServiceMapComputer_CL | where ResourceName_s in ((search in (ServiceMapProcess_CL) "\*sql\*" | distinct MachineResourceName_s)) | distinct ComputerName_s List all unique product versions of curl in my datacenterServiceMapProcess_CL | where ExecutableName_s == "curl" | distinct ProductVersion_s Create a computer group of all computers running CentOSServiceMapComputer_CL | where OperatingSystemFullName_s contains_cs "CentOS" | distinct ComputerName_s Summarize the outbound connections from a group of machines// the machines of interest let machines = datatable(m: string) ["m-82412a7a-6a32-45a9-a8d6-538354224a25"]; // map of ip to monitored machine in the environment let ips=materialize(ServiceMapComputer_CL | summarize ips=makeset(todynamic(Ipv4Addresses_s)) by MonitoredMachine=ResourceName_s | mvexpand ips to typeof(string)); // all connections to/from the machines of interest let out=materialize(VMConnection | where Machine in (machines) | summarize arg_max(TimeGenerated, *) by ConnectionId); // connections to localhost augmented with RemoteMachine let local=out | where RemoteIp startswith "127." | project ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp, DestinationPort, Protocol, RemoteIp, RemoteMachine=Machine; // connections not to localhost augmented with RemoteMachine let remote=materialize(out | where RemoteIp !startswith "127." | join kind=leftouter (ips) on $left.RemoteIp == $right.ips | summarize by ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp, DestinationPort, Protocol, RemoteIp, RemoteMachine=MonitoredMachine); // the remote machines to/from which we have connections let remoteMachines = remote | summarize by RemoteMachine; // all augmented connections (local) | union (remote) //Take all outbound records but only inbound records that come from either //unmonitored machines or monitored machines not in the set for which we are computing dependencies. | where Direction == 'outbound' or (Direction == 'inbound' and RemoteMachine !in (machines)) | summarize by ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp, DestinationPort, Protocol, RemoteIp, RemoteMachine // identify the remote port | extend RemotePort=iff(Direction == 'outbound', DestinationPort, 0) // construct the join key we'll use to find a matching port | extend JoinKey=strcat_delim(':', RemoteMachine, RemoteIp, RemotePort, Protocol) // find a matching port | join kind=leftouter (VMBoundPort | where Machine in (remoteMachines) | summarize arg_max(TimeGenerated, *) by PortId | extend JoinKey=strcat_delim(':', Machine, Ip, Port, Protocol)) on JoinKey // aggregate the remote information | summarize Remote=makeset(iff(isempty(RemoteMachine), todynamic('{}'), pack('Machine', RemoteMachine, 'Process', Process1, 'ProcessName', ProcessName1))) by ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp, DestinationPort, ProtocolREST APIAll the server, process, and dependency data in Service Map is available via the Service Map REST API. Diagnostic and usage dataMicrosoft automatically collects usage and performance data through your use of Service Map. Microsoft uses this data to provide and improve the quality, security, and integrity of Service Map. To provide accurate and efficient troubleshooting capabilities, the data includes information about the configuration of your software. This information can be the operating system and version, IP address, DNS name, and workstation name. Microsoft doesn't collect names, addresses, or other contact information. For more information about data collection and usage, see the Microsoft Online Services Privacy Statement. Next stepsLearn more about log searches in Log Analytics to retrieve data that's collected by Service Map. TroubleshootingIf you have any problems installing or running Service Map, this section can help you. If you still can't resolve your problem, contact Microsoft Support. Dependency agent installation problemsThis section addresses issues with Dependency agent installation. Installer prompts for a rebootThe Dependency agent generally doesn't require a reboot upon installation or removal. In certain rare cases, Windows Server requires a reboot to continue with an installation. This issue happens when a dependency, usually the Microsoft Visual C++ Redistributable library, requires a reboot because of a locked file. Message "Unable to install Dependency agent: Visual Studio Runtime libraries failed to install (code = [code_number])" appearsThe Microsoft Dependency agent is built on the Microsoft Visual Studio runtime libraries. You'll get a message if there's a problem during installation of the libraries. The runtime library installers create logs in the %LOCALAPPDATA%\temp folder. The file is dd_vcredist_arch_yyyymmddhhmmss.log, where arch is x86 or amd64 and yyyymmddhhmmss is the date and time (based on a 24-hour clock) when the log was created. The log provides details about the problem that's blocking installation. It might be useful to install the latest runtime libraries first. The following table lists code numbers and suggested resolutions.
Post-installation issuesThis section addresses post-installation issues. Server doesn't appear in Service MapIf your Dependency agent installation succeeded, but you don't see your machine in the Service Map solution:
Did you get a variety of events in the results? Is the data recent? If so, your Log Analytics agent is operating correctly and communicating with the workspace. If not, check the agent on your machine. See Log Analytics agent for Windows troubleshooting or Log Analytics agent for Linux troubleshooting. Server appears in Service Map but has no processesYou see your machine in Service Map, but it has no process or connection data. That behavior indicates the Dependency agent is installed and running but the kernel driver didn't load. Check C:\Program Files\Microsoft Dependency Agent\logs\wrapper.log file for Windows or /var/opt/microsoft/dependency-agent/log/service.log file for Linux. The last lines of the file should indicate why the kernel didn't load. For example, the kernel might not be supported on Linux if you updated your kernel. SuggestionsDo you have any feedback for us about Service Map or this documentation? See our User Voice page where you can suggest features or vote up existing suggestions. |