|
Key Takeaways
|
|
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 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 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 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.
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)
Transaction Control Protocol (TCP)
So why are both protocols used, and in which scenarios?
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.
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.
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?
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.
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: