|
Key Takeaways
|
|
You may have seen a menu item or heard one of my colleagues talk about universes in DX APM or DX Operational Intelligence. But what are universes and how can they help you work with DX APM?
In short: Universes filter APM data and implement role-based access control (RBAC). Compared to domains, they allow you to assign metrics and topology components to one or more universes.
Classic CA APM: Domains
If you have been working with classic CA APM 8, 9, or 10, you might be familiar with the concept of domains. Domains were used to split all the data that agents report into CA APM into distinct sets. A domain could stand for an application, a business service, a group or division within the company, or a technology.
A day in the life: Alex and CA APM domains
Alex is responsible for IBM MQ. His job is to make sure that all servers and queue managers are up and running and don’t have performance issues, such as backed up queues. The whole MQ environment at his company is monitored by DX APM. But he does not care about all the other stuff that is also monitored by APM. He wants to focus solely on his MQ environment.
In classic CA APM, Alex (or an APM admin) can define a domain using regular expressions that match only the agents monitoring IBM MQ. As hostnames are arbitrarily assigned in his company, Alex makes sure that the “process name” of all the APM agents monitoring MQ start with “mq”. He has established a naming convention.
Alex then defines the MQ domain with <agent mapping=”.*\|mq.*\|.*”/>. The APM agent name consists of three parts separated by a “|” character:
- The hostname, usually read directly from the operating system
- The process name
- The agent name
These are also the first three levels that you open in the metric tree. The process name and agent name can be defined in properties of the IntroscopeAgent.profile or via environment variables. They can and should be used to implement a naming convention.
In classic CA APM, users and groups can be assigned to a domain with read or write roles. Only people assigned to a domain can see the agents, their metrics, and traces. Domains are mutually exclusive and first come, first serve: An agent is assigned to the first domain in the domains.xml file, where its agent name triplet matches the regex. If there is no catch-all domain at the end, an agent might not be visible at all.
DX APM: Universes
Universes in DX APM are the successor to domains. In the definition of a universe (in Settings/Universes), you can also use regular expressions to assign agents (“metric sources”) to a universe. You can also manually select agents from the list of all agents. I would strongly recommend to use regex because they are generic and work for every new agent as long as it matches the regex.
Unlike domains, universes can overlap. An agent belongs to every universe in which its agent name triplet matches the regex. If you want to give Alex access to two universes, you can either add his user account (or group) to the “Access” section of both universes or you can create a third universe that combines the regular expressions from both universes. In DX APM, you can assign AD or SAML groups to universes. Or, you can allow access to all APM data and use universes to filter to the task at hand.
Universes in DX APM unlock even more power! For example, they allow you to assign distinct management modules to a universe and you can filter the (topology) map components shown in a universe. A topic for another day!
Günter Grossberger
As a member of the Customer Engagement team, Günter solves customers' problems by implementing both processes and technology. He employs knowledge gathered from years of experience helping Enterprise customers improve the performance of their business-critical applications.
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.