To ascertain risk, national security and intelligence professionals have long used concepts such as known knowns, known unknowns, and unknown unknowns. The idea of unknown unknowns was created in 1955 by American psychologists Joseph Luft (1916–2014) and Harrington Ingham (1916–1995). This concept continues to be used today in risk assessments and is applicable to technology.
The unknown unknowns are the threats and potential problems that remain invisible until their impact manifests. When they do, they create consequences that can disrupt the status quo.
In business, and in particular in technology, the unknown unknowns pose a serious problem and often remain elusive to IT teams. As applications have become more complex, it’s become harder to track risks. Traditional application performance monitoring (APM) has focused on monitoring for known problems. You knew the performance baseline for an application, as well as expectations and performance indicators, and you’d set thresholds and static alerts to see if performance deviates. You were monitoring for known knowns. Today, this is no longer sufficient.
APM Needs to Address the Unknown Unknowns
Modern apps are extremely complex and multi-layered. You can no longer depend on monitoring for known problems. In the cloud, the application stack is so complex that issues can happen anywhere and disrupt app performance. These app disruptions can have a negative impact on the user experience, customer/user satisfaction, and even customer retention and business revenue.
But can an APM solution really monitor for unknown unknowns?
Yes, it can and here’s how. To monitor all the layers of the environment, and understand these layers and how they interact, an APM solution needs a topology model of dynamic and constantly changing environments.
Along with a topology model, a solution must have the intelligence needed to determine when a metric deviates from norms. A solution needs to be able to correlate events and anomalies and identify probable root causes, then automatically remediate the issue. An APM solution such as Broadcom’s DX APM SaaS does this with a rich topology based on our strengths in monitoring applications, infrastructures, and networks. We have a built-in, automated remediation engine that leverages the topology and helps customers automatically remediate issues when they occur.
DX APM SaaS is capable of dynamically monitoring for unknown unknowns, enabling businesses to elevate their level of observability and create confidence that they won’t run into surprises.
What does this look like? Here’s a scenario to illustrate. In this fictional scenario, we’ll demonstrate how John, an SRE/DevOps engineer, can use our DX APM SaaS solution to query across captured instrumentation data to examine, correlate, and derive insight or uncover unknown unknowns (observability) from this data.
1. John is notified of a performance problem with the ACME Business Service. It appears that several users are unable to log into the site. John logs into DX APM SaaS and opens up the experience view for service health and notices that the service is indeed “Red.” Next, he drills down into service health.
2. He sees that the activity service application is reporting a problem with several failed transactions. He sees that APM has already detected a problem and is reporting an issue with the authenticator service. He clicks on the problem to view the associated details in a problem analysis notebook view.
3. In the notebook view, John views the problem details and notices that there are issues reported with several different technology tiers of the application stack.
4. He notices that the system has identified the authenticator service as problematic and selects the service.
5. He opens up the traces tab to take a look at the automatically collected transactions and sees several error traces. He opens the first trace and sees that the request from the first service has timed out with a 400 error.
6. At the same time, he also observes that only some transactions are timing out while others are successful.
7. He wonders what could have changed with the application and brings up the timeline view to see change events. He notices a new version of the authenticator service was released to production last night. The new version was re-implemented as a microservice in a new technology stack. Furthermore, the specific team that developed the new service decided to instrument it with OpenTracing for their observability needs. Could there be an issue with the new service?
8. He turns his attention to the alarms. The system is reporting an abnormally high CPU utilization on the new service. In addition, the system has also detected a change in the deployment configuration, with the number of replicas going down from six to one. This is obviously not right: the new service was checked in with an incorrect deployment configuration. This error caused the service to be under-provisioned, resulting in performance issues.
As you can see, DX APM SaaS automatically detects issues via dynamic baselines and correlates these seemingly unrelated sets of events, both performance and change events, together in a unified topology. This helps John quickly diagnose the problem, down to the specific line of code. As a result, the solution converts unknown unknowns into known knowns.
Learn more about how DX APM SaaS can help you address unknown unknowns.
Nishant Kabra
Nishant is a Product Manager for Application Performance Management. He is passionate about releasing market-leading solutions covering full-stack observability for applications.
Other resources you might be interested in
AAI v26.0 - Linux Standalone Upgrade
Learn how to upgrade a standalone AAI installation on Linux from version 24.4.x to 26.0. Find out about updated configuration and log structures.
Automic Automation v26 Standard Administration – Agents
This course covers two agent administration topics in Automic Automation version 26 (Standard): Centralized Agent Upgrade (CAU) and Agent authentication.
Automic Automation V26 Standard Administration - General Topics
This course provides Automic Automation v26 administrators with a direct, technical breakdown of core system configuration and maintenance tasks.
Automic Automation V26 Standard Administration - Advanced Processes
This course covers the Automation Engine (AE) server processes in Automic Automation version 26 (Standard).
Automic Automation: Transition to SAP RISE with Confidence
Automic Automation safeguards Clean Core architecture, mitigates SAP RISE migration risks, and unifies enterprise scheduling from mainframe to cloud.
AutoSys Workload Automation: Transition to SAP RISE with Confidence
AutoSys safeguards Clean Core architecture, mitigates SAP RISE migration risks, and unifies enterprise workload scheduling from mainframe to cloud systems.
AppNeta: Manage Alarm Rules
Learn how to create and manage alarm rules in AppNeta. Detect, isolate, and present user-impacting issues to network operations center teams.
Rally Office Hours: October 8, 2026
Find out about a new “my notifications” widget and an enhanced planned/unplanned widget. Hear about diverging axis views and upcoming cycle time widgets.
Going Off-Road: How We Bulletproofed Automic's Zero Downtime Upgrades
To ensure absolute reliability at SaaS scale, Automic Automation recently evolved its ZDU strategy.