Making Zero-Touch a Reality with DX Unified Infrastructure Management

There are many ways DX Unified Infrastructure Management (DX UIM) can support you in your zero-touch journey. In this post, we will look into how, by combining different elements, you can speed your time to value. We will discuss the following efforts:

• Using device discovery to do inventory on-boarding
• Establishing agent-based deployments and agentless monitoring
• Grouping monitoring policies
• Discovering and grouping applications
• Establishing alarm policies with default or custom thresholds

Just to be clear, you do have to do some “touching” to establish a zero-touch environment. However, with the correct setup, you will be able to automatically on-board new devices for monitoring and have alarm thresholds dynamically applied.

One more thing before I start: DX UIM has an extensive set of SDKs (software development kits) and almost everything I talk about here can be done using an API call.

On-boarding Devices

DX UIM requires an inventory of your devices to start the monitoring process. You can let the discovery server search for new devices by providing credentials and IP addresses or address ranges to search through. Alternatively, you can add devices through a configuration management data import, using XML data from an existing configuration management database (CMDB) you may have. Once discovered, devices are stored in the inventory so you can decide whether to apply agentless or agent-based monitoring. There is more monitoring flexibility when using the installed agent, which we call a robot.

Figure 1: In the Discover Devices Setup Wizard, you can add credentials (Windows, Unix, and SNMP) for the wizard to use and define the network scopes to search.

Deploying Robots

When using agents to monitor devices, robots can be deployed in a few different ways:

• Use the automated deployment agent
• Employ a third-party tool, such as Puppet
• Install as part of the build process

Using tools like Kickstart, some customers bundle the robot .rpm file into the device provisioning process, so the robot is pre-installed. Because the robot registers with its hub, no discovery is needed.

Figure 2: In the Inventory view, users select a device without a robot. The Robot Deployment option is available in the menu.

Monitoring Configuration Service

Once devices are discovered, zero-touch control is passed to the Monitoring Configuration Service (MCS). MCS offers a template-based way to install probes and configure monitoring. MCS templates break down the probe configuration into administrator and user sections. There are two types of templates: legacy and enhanced. Both types of templates configure probes but the enhanced templates pass the control of what is published on the message bus to the robot’s spooler probe. Having the spooler in control of the performance metrics and alarms allows you to have centralized alarm policies (discussed below), which update the spooler directly, regardless of the probe.

MCS associates monitoring policies with groups, and ensures devices in the group will have the appropriate monitoring profiles deployed. If a device is added to a group, profiles will be deployed dynamically. Similarly, when a device is removed from a group, the profiles are undeployed.

Figure 3: The Monitoring Configure page displays the profiles associated with the SQL Cluster group. Each of these profiles will be deployed to all devices in the group.

Operator Console Groups

Groups are defined in the DX UIM Operator Console. There are several different types of groups: container, dynamic, and static. A container group can only contain other groups (not devices) and is used to create layers within your group hierarchy. Devices can be grouped based on technology, geolocation, naming, device attributes, SQL, and more. DX UIM offers support for multi-tenancy, and groups can be specific to a single account. For any given account, only devices in that specific account will be visible.

Figure 4: In this Group tree view, Azure Monitoring is a container group because it has other groups below it. The other groups are either static or dynamic groups as they have devices in them.

Each group can have its own specific monitoring policies, which are a set of defined profiles for the devices in that group. All devices in that group will have the appropriate monitoring profiles deployed. With dynamic groups, devices are added and removed dynamically, along with the associated monitoring profiles. Devices can exist in multiple groups, so the group monitoring profiles have an associated group profile priority. If a device resides in multiple groups and the same profile exists, the group profile with the highest priority will be deployed.

You can also have groups of agentless devices but only the agentless profiles will be configured for these devices. These are known as remote profiles as they will configure a probe, but that probe will not reside on that agentless device. All probes that can monitor remote devices must be installed on a proxy robot before you can enable the remote monitoring. To do so, you will be asked to select the device from a dropdown menu, which is made up of robots that have at least the “Setup {probename}” profile installed.

Figure 5: The Remote Devices Group featured has a limited set of monitoring available as no robot is installed on the device in the group.

Application Discovery

Application Discovery is enabled in the UIM Settings -> Configure submenu. Simply select the applications you want to discover. In MCS, the application discovery group will be created with the sub-groups under discovered application systems based on the application discovery you enabled. Application Discovery is a set of small scripts/.bat files that MCS deploys to relevant devices (robots are required in this case). The scripts/.bat files search for known applications, and, if found, they create a device attribute for that application.

As mentioned above, dynamic groups can be defined using the values of the device attributes, so you can have a group set up with specific application monitoring and the devices can dynamically be added when the application is discovered.

Figure 6: Users can configure options from the Settings menu. In the example above, we have enabled the discovery of MS SQL Server.

Figure 7: By enabling Application Discovery of MS SQL Server, a MS SQL Server dynamic group is created. Once the application discovery scripts have been executed, devices found to have MS SQL Server are added to this group, and monitoring profiles will be configured and deployed.

Soon, we will publish a blog post on Application Discovery, which will offer guidance on how to write your own application discovery packages, so be sure to check back to learn more.

Alarm Policies

When using enhanced templates, alarm policies are created by default as you enable your monitoring policies. These policies establish default thresholds for your metrics. However, you can manage all aspects of alarm behavior in an alarm policy. For example, you can configure an alarm’s thresholds, timing, and messages. The alarm policies configure the spooler on each robot so when the spooler receives a metric it can determine if a threshold breach occurs and if an alarm should be created.

Figure 8: An example of a device alarm policy, displaying the Aggregated CPU Usage with two thresholds (static and dynamic).

Conclusion

To recap, here’s how zero-touch works in a nutshell:

• A new device is added to the inventory
• A robot is installed if needed
• The device is added to a group or groups
• Monitoring profiles are deployed to the device
• Metrics are gathered and thresholds are set

Then, all you have to do is put your feet up, wait for observability to kick in, and watch the magic happen.

For more infrastructure management resources, visit the DX UIM home page on Broadcom’s Enterprise Academy.