Translated from the Korean original. Some screenshots show the original Korean interface.
Multi-cloud has become the standard
Multi-cloud is no longer optional. It has become an essential strategy. According to Fortinet's 2026 State of Cloud Security Report, 88% of companies run hybrid or multi-cloud environments. Hybrid IT, which mixes several public clouds (AWS, Azure, GCP) with on-premises infrastructure to reduce dependence on a single cloud vendor and secure service availability and scalability, has become the norm. In theory, it is a more stable structure, because you can route around a failure when an incident occurs.
In real operations, though, a different problem shows up. It is not so much that incidents have spiked. It is that the time and difficulty of finding their cause have grown significantly. Even for the same incident, more people and more time go into finding the cause, again and again.
This shift is not simply a question of operational skill. It is the inevitable result of the system architecture itself changing. Multi-cloud made systems more flexible, but it also added complexity in ways that make problems harder to understand. So the problem today is not preventing incidents. It is that incidents have become harder to explain.
1. Operational incidents happen in the "flow," not in a system
In the past, the scope of an operational incident was relatively clear. A problem occurred in a specific area such as the DB, application server, or network, and analyzing that system was enough to pin down the cause. Put simply, an incident was closer to an event inside a single system.
In a multi-cloud environment, however, a single service runs across several environments. It is common for the frontend to sit on AWS, the backend on Azure, some features on external SaaS APIs, and the data in an on-premises DB. In this setup, incidents often occur at the connection points between systems rather than inside a particular system.
Add a microservices architecture and things get even more complicated. A small delay propagates to other services through API calls, leads to increased thread occupancy in applications and DB connection shortages, and spreads into a service-wide incident. By the time an operator first notices, the incident has usually already surfaced, meaning they are looking at symptoms far removed from the root cause.
Operational incidents are no longer single events. They have become structural phenomena that spread along the service flow.
2. More data, murkier causes
In a multi-cloud environment, the amount of data to monitor grows dramatically. Each cloud provides its own monitoring tools, and APM, logging systems, and DB monitoring solutions all generate data too. On the surface, you have far more information than before.
The problem is that this data does not connect into a single flow. Cloud-specific tools, application monitoring, and DB analysis systems each run independently and present data on different screens with different criteria. Operators have to jump between tools and piece the information together, and in the process it is easy to miss important causal relationships.
In container-based environments in particular, a failing Pod is automatically terminated and restarted, so by the time you need to do a post-incident analysis, the instance that caused the incident is often already gone. In VM or physical server environments, the affected system stays put after an incident, so post-incident analysis is possible. In container environments, logs and execution context disappear with the restart, and data continuity breaks easily. As a result, troubleshooting increasingly depends on the experience and intuition of particular senior engineers, which creates a structural risk: when those people change, the organization's incident response capability itself is shaken.
This goes beyond the limits of a monitoring tool. It is a problem caused by a lack of observability, the inability to accurately understand a system's internal state. The result is a huge amount of data, but not enough context to explain why an incident happened.
3. The limits of traditional monitoring
Many organizations still run monitoring centered on resource metrics such as CPU, memory, and network. This works for understanding the state of a specific system, but it falls short of explaining complex problems in a multi-cloud environment.
For example, service response can slow down even when resource metrics on every system are within normal ranges. That is because factors that infrastructure resource metrics alone do not reveal, such as external API delays, DB slow queries, and network latency, affect actual service quality. When a delay in one segment ripples through the entire request flow like this, individual system metrics alone make the cause hard to identify.
Also, when an incident results from interactions between multiple systems, monitoring any single system cannot reveal the whole problem. Traditional monitoring is good at showing anomalies, but it cannot explain why an incident happened or which path its impact spread along.
What we need now is to analyze problems along the full path a user request travels, not system by system.
4. Incident analysis starts with looking at the connection points
Category | Traditional environment | Multi-cloud |
Where incidents occur | A single system | Connections between systems |
Data | Limited | Excessive + scattered |
Analysis approach | System-centered | Flow-centered |
Identifying the cause | Relatively clear | Very complex |
As we have seen, analyzing operational incidents effectively in a multi-cloud environment means you have to connect the DB, applications, and infrastructure and understand them as one flow, rather than looking at each separately. You need an integrated view of which path a user request takes, where delays occur, and what is causing bottlenecks.
One approach that meets these needs is an integrated performance management solution. exemONE provides an integrated performance management system that connects and analyzes the entire service flow, based on performance data that spans from the database to applications and infrastructure. The point is to go beyond collecting metrics and help you reach the root cause quickly, even after an incident has occurred.
💻 Key features of exemONE
- Transaction flow tracing and analysis (EtoE)
- Multi-DBMS monitoring
- Cluster topology visualization
- AI anomaly detection and LLM-based predictive analysis
Now that multi-cloud is widespread, what matters is not eliminating incidents completely, but the ability to understand incidents quickly and interpret their causes accurately. The starting point is integrated performance management that connects scattered data into a single flow.
Want to pinpoint the causes of incidents in your multi-cloud environment faster?
Sources
Fortinet: "Cloud security is vulnerable"... maturity still at an early stage - ZDNet Korea (2026.01.22)
Related articles
