Discovery

Download this manual as a PDF file

The following sections describe how to discover Microsoft Azure resources for monitoring by SL1 using the Microsoft: Azure PowerPack.

Microsoft Azure Guided Discovery

You can use the Universal Discovery Framework process in SL1 that guides you through a variety of existing discovery types in addition to traditional SNMP discovery. This process, which is also called "guided discovery", lets you pick a discovery type based on the type of devices you want to monitor. The Universal Discovery workflow includes a button for Microsoft Azure.

To run a guided or Universal Discovery:

  1. On the Devices page () or the Discovery Sessions page (Devices > Discovery Sessions), click the Add Devices button. The Select page appears.

Image of the Discovery start page

  1. Select the Microsoft Azure button. Additional information about the requirements for device discovery appears in the General Information pane to the right.

  1. Click Select. The Credential Selection page appears.

Image of the Credential Selection page

During the guided discovery process, you cannot click Next until the required fields are filled on the page, nor can you skip to future steps. However, you can revisit previous steps that you have already completed.

  1. On the Credential Selection page of the guided discovery process, select the Azure credential that you configured, and then click Next. The Root Device Details page appears.

Image of the Root Device Details page

  1. Complete the following fields:
  • Root Device Name. Type the name of the root device for the Microsoft Azure root device you want to monitor.
  • Select the organization to add discovered devices to. Select the name of the organization to which you want to add the discovered device.
  • Collector Group Name. Select an existing collector group to communicate with the discovered device. This field is required.

  1. Click Next. SL1 creates the Microsoft Azure root device with the appropriate Device Class assigned to it and aligns the relevant Dynamic Applications. The Final Summary page appears.

Image of the Final Summary page

  1. Click Close.

The results of a guided discovery do not display on the Discovery Sessions page (Devices > Discovery Sessions).

Creating an Azure Virtual Device for Discovery in the SL1 Classic User Interface

Because the Azure service does not have a static IP address, you cannot discover an Azure device using discovery. Instead, you must create a virtual device that represents the Azure service. A virtual device is a user-defined container that represents a device or service that cannot be discovered by SL1. You can use the virtual device to store information gathered by policies or Dynamic Applications.

To create a virtual device that represents your Azure service:

  1. Go to the Device Manager page (Devices > Device Manager, or Registry > Devices > Device Manager in the classic SL1 user interface).

  1. Click the Actions button and select Create Virtual Device from the menu. The Virtual Device modal page appears.

  1. Enter values in the following fields:

  • Device Name. Enter a name for the device. For example, "Azure Cloud".

  • Organization. Select the organization for this device. The organization you associate with the device limits the users that will be able to view and edit the device. Typically, only members of the organization will be able to view and edit the device.
  • Device Class. Select Microsoft | Azure Services.
  • Collector. Select the collector group that will monitor the device.

When monitoring an account with multiple child subscriptions, you can load-balance how SL1 monitors your Azure components by discovering groups of subscriptions and their components across multiple collectors. For details, see the section on Load-Balancing an Account with Multiple Subscriptions.

  1. Click Add to create the virtual device.

Aligning the Azure Dynamic Applications

The Dynamic Applications in the Microsoft: Azure PowerPack are divided into the following types:

  • Discovery. These Dynamic Applications poll Azure for new instances of services or changes to existing instances of services.
  • Configuration. These Dynamic Applications retrieve configuration information about each service instance and retrieve any changes to that configuration information.
  • Performance. These Dynamic Applications poll Azure for performance metrics.

When configuring SL1 to monitor Azure services, you can manually align Dynamic Applications to discover Azure component devices.

Discovering Azure Component Devices

To discover all the components of your Azure platform, you must manually align the "Microsoft: Azure Account Discovery" Dynamic Application with the Azure virtual device.

When monitoring an account with multiple child subscriptions, ScienceLogic recommends that you first review your device capacity and load limits to determine the best method for implementation prior to discovery. For details, see the section on Load-Balancing an Account with Multiple Subscriptions.

To manually align the "Microsoft: Azure Account Discovery" Dynamic Application:

  1. Go to the Device Manager page (Devices > Device Manager, or Registry > Devices > Device Manager in the classic SL1 user interface).

  1. Click the wrench icon () for your Azure virtual device.
  2. In the Device Administration panel, click the Collections tab. The Dynamic Application Collections page appears.
  3. Click the Actions button and select Add Dynamic Application from the menu.

  1. In the Dynamic Application Alignment modal:

  • In the Dynamic Applications field, select Microsoft: Azure Account Discovery.
  • In the Credentials field, select the credential you created for your Azure service.

  1. Click Save to align the Dynamic Application with the Azure virtual device.

When you align the "Microsoft: Azure Account Discovery" Dynamic Application with the Azure virtual device, SL1 does one of the following, depending on your subscription model:

  • If you are monitoring an account with multiple child subscriptions, SL1 creates a root component device representing the Azure account and one or more child component devices representing all of your Azure subscriptions.
  • If you are monitoring a single subscription, SL1 creates a root component device representing your Azure subscription.

When monitoring an account with multiple child subscriptions, you can load-balance how SL1 monitors your Azure components by discovering groups of subscriptions and their components across multiple collectors. For details, see the section on Load-Balancing an Account with Multiple Subscriptions.

SL1 then automatically aligns several other Dynamic Applications to the subscription component devices. These additional Dynamic Applications discover and create component devices for Active Directory tenants, Traffic Manager profiles, and each location used by the Azure account. Under each location, SL1 then discovers component devices relevant to Azure service.

SL1 might take several minutes to align these Dynamic Applications and create the component devices in your Azure service.

When discovering a large number of component devices, such as when discovering an account with multiple child subscriptions, the discovery process can cause the appearance of numerous critical events with the message, "Large backlog of asynchronous jobs detected". This will occur only during the initial discovery session.

Viewing Azure Component Devices

In addition to the Devices page, you can view the Azure service and all associated component devices in the following places in the user interface:

  • The Device Investigator Map page (click Map in the Device Investigator page) displays a map of a particular device and all of the devices with which it has parent-child relationships. Double-clicking any of the listed devices reloads the page to make the selected device the primary device.

  • The Device Components page (Devices > Device Components) displays a list of all root devices and component devices discovered by SL1. The Device Components page displays all root devices and component devices in an indented view, so you can easily view the hierarchy and relationships between child devices, parent devices, and root devices. To view the component devices associated with an Azure service, find the Azure service and click its plus icon (+).

  • The Component Map page (Classic Maps > Device Maps > Components) allows you to view devices by root node and view the relationships between root nodes, parent components, and child components in a map. This makes it easy to visualize and manage root nodes and their components. SL1 automatically updates the Component Map as new component devices are discovered. The platform also updates each map with the latest status and event information. To view the map for an Azure service, go to the Component Map page and select the map from the list in the left NavBar. To learn more about the Component Map page, see the section on Maps.

Relationships Between Component Devices

In addition to parent/child relationships between component devices, SL1 also creates relationships between the following component devices:

  • API Apps and Resource Groups
  • API Management and System Topics
  • App Configuration and System Topics
  • App Service and System Topics
  • Apps and Resource Groups
  • Application Gateways and Resource Groups

  • Application Gateways and Virtual Network Subnets
  • Azure Automation and Resources Groups
  • Azure CosmosDB and Resource Groups
  • Azure CosmosDB and Virtual Networks
  • Azure CosmosDB and Virtual Network Subnets
  • Azure Maps and System Topics
  • Azure Policies and System Topics
  • Azure Subscriptions and System Topics
  • Azure Traffic Managers and Traffic Managers
  • Batch Accounts and Key Vaults
  • Batch Accounts and Resource Groups
  • Batch Accounts and Storage Groups
  • Blob Storage and System Topics
  • CDN Profiles and Resource Groups
  • Communication Services and System Topics
  • Container Instances and Resource Groups
  • Container Registries and Resource Groups
  • Container Registries and System Topics
  • Data Lakes and Resource Groups
  • Data Lakes and Storage Accounts
  • Databricks and Resource Groups
  • Databricks and Storage Accounts
  • Event Grids and Resource Groups
  • Event Hubs and System Topics
  • HDInsight Clusters and Storage Groups
  • HDInsight Clusters and Virtual Networks
  • HDInsight Clusters and Resource Groups
  • Health Data Services and System Topics
  • Host Pool sand Resource Groups
  • Host Pools and Virtual Machines
  • IoT Hubs and System Topics
  • Key Vaults and Resource Groups
  • Key Vaults and System Topics
  • Key Vaults and Virtual Networks
  • Key Vault Rules and Subnets
  • Kubernetes Agent Pools and Subnets
  • Kubernetes Services and System Topics
  • Load Balancers and Resource Groups
  • Logic Apps and Resource Groups
  • Machine Learning Services and System Topics
  • Managed Disks and Resource Groups
  • Managed Disks and Virtual Machines
  • Media Services and System Topics
  • Network Security Groups and Resource Groups
  • Network Security Groups and Virtual Network Subnets
  • PostgreSQL Servers and Resource Groups
  • PostgreSQL Servers and Subnets
  • PostgreSQL Servers and PostgreSQL Server Replicas
  • PostgreSQL Servers and Virtual Networks
  • Recovery Service Vaults and Resource Groups
  • Redis Cache Servers and Redis Cache Servers
  • Redis Caches and Resource Groups
  • Redis Caches and Subnets
  • Redis Caches and System Topics
  • Redis Caches and Virtual Networks
  • Resource Groups and System Topics
  • Service Bus Namespaces and Resource Groups
  • Service Bus Namespaces and Service Bus Namespaces
  • Service Bus Namespaces and Subnets
  • Service Bus Namespaces and System Topics
  • Service Bus Namespaces and Virtual Networks
  • SignalR and System Topics
  • SQL Databases and Resource Groups
  • SQL Servers and Resource Groups
  • SQL Servers and Server Replicas
  • SQL Servers and Subnets
  • SQL Servers and Virtual Networks
  • SQL Servers and Virtual Network Subnets
  • Storage Accounts and Resource Groups
  • Traffic Manager Profiles and Resource Groups
  • Virtual Machines and Network Security Groups
  • Virtual Machines and Resource Groups
  • Virtual Machines and Storage Accounts
  • Virtual Machines and Virtual Networks
  • Virtual Machines and Virtual Network Subnets
  • Virtual Machine Scale Sets and Load Balancers
  • Virtual Machine Scale Sets and Resource Groups
  • Virtual Machine Scale Sets and Virtual Network Subnets
  • Virtual Machine Scale Set Virtual Machines and Resource Groups
  • Virtual Networks and Resource Groups
  • VPN Gateways and Resource Groups
  • VPN Gateways and Virtual Network Subnets
  • WAF CDN Policies and Endpoints
  • WAF CDN Policies and Resource Groups
  • WAF Gateway Policies and Application Gateways
  • WAF Gateway Policies and Resource Groups

Additionally, the platform can automatically build relationships between Azure component devices and other associated devices:

  • If you discover Cisco Cloud Center devices using the Dynamic Applications in the Cisco: CloudCenter PowerPack version 103 or later, SL1 will automatically create relationships between Azure Virtual Machines and Cisco Cloud Center applications.

  • If you discover Dynatrace environments using the Dynamic Applications in the Dynatrace PowerPack, SL1 will automatically create relationships between the following device types:
  • Azure Virtual Machines and Dynatrace Hosts
  • Azure Virtual Machine Scale Sets and Dynatrace Hosts

  • If you discover Office 365 services using the Dynamic Applications in the Microsoft: Office 365 PowerPack version 101 or later, SL1 will automatically create relationships between Azure Active Directory tenants and Office 365 Active Directory tenants.