|
Key Takeaways
|
|
Hubs and the communication architecture of DX UIM: Simplified
In DX Unified Infrastructure Management (DX UIM), there are multiple elements that need to work in harmony to achieve a high level of observability. Understanding the architecture of DX UIM can help you make configuration decisions that minimize resource consumption, without sacrificing the volume and granularity of observability data collected. In addition, using static hubs is a simple and particularly powerful option for specific situations.
To begin, here is a refresher on the core components and communication protocols of DX UIM. If you’re familiar with this information, you can skip ahead to the section on using static hubs.
Hubs
Hubs bind observability data (direct monitoring data and metadata such as relationships) into logical groups. They also share this information with each other, such as details on which robots are connected to which hubs (explained below). If a monitoring component attached to one hub needs to contact another component attached to a different hub, it will use the hub connectivity and routing tables to establish the communication.
Robots
Robots are lightweight agents that are installed on servers to manage probes (explained in the next section) that are deployed in an environment monitored by DX UIM. A robot starts and stops probes at the required times, and collects, queues, and communicates monitoring data from probes to hubs via the message bus.
Probes
Probes provide the intelligence to monitor and manage specific components on a device. With more than 140 probes available for DX UIM, teams can manage the entire IT infrastructure, including servers, network devices, applications, and databases as well as usage metering and data center power consumption.
Communication protocols within DX UIM
DX UIM utilizes two primary communication protocols—making use of the strengths of each protocol for better performance, availability, and security. In increasingly connected IT estates where organizations are more inclined to monitor everything, how data is communicated can have an outsized effect on resource consumption. (See this separate blog series on Observability and Monitoring Governance.)
Let’s briefly discuss the basic features of each protocol.
User Datagram Protocol (UDP)
- Connectionless: No handshake is required; data is sent as independent packets.
- Faster: Due to the lack of overhead, UDP is faster than TCP.
- Not reliable: Does not guarantee delivery or order of packets, and does not check for errors.
Transaction Control Protocol (TCP)
- Connection-oriented: Requires a handshake process to establish a connection before data transfer begins. This ensures both sender and receiver are ready.
- Reliable: Guarantees delivery of data packets in the correct order and without errors.
- Error-checked: Includes mechanisms to detect and correct errors in data transmission.
- Slower: The overhead of connection establishment and error checking makes it slower than UDP.
So why are both protocols used, and in which scenarios?
The broadcast feature for hubs in DX UIM
By default, each hub broadcasts its metadata for other hubs to pick up. This enables the hub intelligence layer to build a picture of which hubs are communicating with each other, and which robots are connected to each hub. As this feature is enabled when a hub is deployed, UDP is an ideal protocol to use, as it’s lightweight and less expensive than TCP. However, the one downside of UDP is that it has reduced reliability.
Static hubs: When and how to use, and their benefits
There are situations where auto-discovery via broadcast data is not feasible. When hubs are on different subnets or separated by networking devices, they might not be able to discover each other automatically. For these situations, DX UIM allows teams to configure static hubs.
A static hub is a shorthand way of saying “A hub that has a static route defined.” If you open up a command prompt on a Windows server and run “route print” there will be a Persistent Routes section. Static hubs are the DX UIM version of this.
By configuring a static hub, you are giving the hub the information it needs to find the other hubs. This is especially vital if the broadcast option has been disabled. More information about configuring static hubs and broadcast settings can be found here.
Below is a screenshot of the static hubs section of a hub.
DX UIM Hub Probe: Name Services Tab
Note: To ensure secure delivery of information, do not connect hubs with both a tunnel and a static route. Doing so could cause data to be transmitted over the insecure static route rather than over the secure tunnel. When creating a tunnel between two hubs, delete any existing static routes.
Persistent sessions
Why this focus on static hubs? An important benefit of configuring static hubs is that a persistent TCP session is established between the two hubs. A persistent session is one that is left open after the initial data payload transfer. Keep-alive packets are sent to maintain the connection and prevent it from timing out.
To verify the session type, open the hub probe utility (Ctrl + P with the hub probe highlighted), selecting get_info and clicking the green Play button. This will return information about the hub. Scroll down to the bottom of this page and you’ll see the “sessions” section.
Highlighted in the image below is the persistent session between this hub, and the hub on the domain with the IP listed.
Hub—Probe Utility
Having a static hub entry within your hub (and having it synchronize) gives you the ability to disable the broadcast feature. This will reduce the load on your network as each hub on your environment won’t be broadcasting its details and availability to the domain. Although the resource demands of this traffic aren’t significant, it is a consideration. This should be done with care as no further auto-discovery can happen for that hub.
By adding some static hubs in your environment, you will have persistent TCP sessions through the DX UIM domain. When else might this be a benefit to the everyday user?
UIMAPI response time
The UIMAPI is an add-on to the Operator Console, and it gives you the ability to GET or POST data to and from the UIM environment. This functionality could be initiated by a person or a system.
Some more complex API calls can take a significant amount of time to complete. If too much time elapses, the temporary TCP session that an API call has created, times out and is ended. If there is a response required from the remote agent/endpoint, it typically won’t have a route back to the user or system after this timeout has occurred. Adding a static hub, and therefore a persistent session, gives the API call a route to the remote endpoint and back to the user.
Conclusion
If timeout or routing errors are common in your DX UIM environment, consider adding static hubs to at least the Primary Hub so it has knowledge of the environment, especially if hub broadcast has been disabled. Adding a static hub is conceptually similar to adding a static route or editing the hosts file. Be aware: If you change details of a hub, such as its name or IP address, don’t forget to edit the static hub entry also!
Additional resources:
- Technical Documentation
- Knowledge Base Article to help monitor hubs themselves
Scott Pieter
As a Client Service Consulting supporting Broadcom’s AIOps and Observability customers, Scott applies his expertise in monitoring and observability to help organizations maximize their utility –from initial concept through final implementation and adoption. Having previously been a customer of Broadcom, he naturally...
Other resources you might be interested in
Nobody Cares About Your MTTR
This post outlines why IT metrics like MTTR are irrelevant to business leaders, and it emphasizes that IT teams need network observability to bridge this gap.
Tag(ging)—You’re It: How to Leverage AppNeta Monitoring Data for Maximum Insights
Find out about tagging capabilities in AppNeta. Get strategies for making the most of tagging and see how it can be a game-changer for your operations teams.
Rally Office Hours: October 2, 2025
The Rally Model Context Protocol (MCP) Server acts as a standardized interface for AI models and developer tools. Learn about this exciting new feature then follow the weekly Q&A session with Rally...
Why 1% Packet Loss Is the New 100% Outage
In an era of real-time apps and multiple clouds, the old rules about 'acceptable' network errors no longer apply. See why you need end-to-end observability.
Rally Office Hours: September 25, 2025
Rally Office Hours delivers an essential product tip: Learn to transition from Legacy Custom Pages to powerful Custom Views. Plus, Q&A insights.
Defining the Network Engineer of Tomorrow
Read this post and see why the most important investment isn't in new hardware, but in transforming your team from device managers to service delivery experts.
Harnessing AppNeta’s Browser- and HTTP-based Workflows to Track User Experience
AppNeta’s browser- and HTTP-based workflows let you see what users actually experience. Preempt issues before they become headaches for your end users.
“Rego U” Recap: Why SPM Is Still Hot
Rego Consulting’s Annual Conference underscored why strategic portfolio management (SPM) is still essential. Leverage SPM to bridge strategy and execution.
What's New in AutoSys 24.1: Built for the Modern Automation Landscape
See how AutoSys 24.1 is designed to streamline your daily tasks, accelerate troubleshooting, and simplify how you integrate with the latest technologies.