Observability is not a tool: it is a new way to operate

In the article “Detecting an incident is easy. The hard part is building the context to find the root cause.”, I explored a question I consider central to modern IT operations. Today we can quickly identify that something is wrong. The problem begins when we need to understand what happened, where the failure really originated, and how the different signals produced by the environment relate to one another.

This discussion naturally leads us to observability.

In recent years, few words have gained as much space in the vocabulary of IT operations. New platforms, architectures, methodologies, and features associated with the topic have emerged. Metrics, logs, and traces have taken an increasingly important place in monitoring strategies, especially in distributed environments, modern applications, microservices, containers, and cloud infrastructures.

That evolution was necessary. As systems became more dynamic and interdependent, simply checking whether a server was available or whether a given metric had crossed a threshold stopped being enough.

But there is a risk when an important idea quickly gains ground in the market.

It may end up being reduced to the tool used to implement it.

I have seen this happen with observability. In some conversations, the question “does your company have observability?” ends up being answered simply with the name of a platform.

The answer may make sense from a technological point of view, but it leaves aside a far more important question.

Is the organization able to use the available information to quickly understand how its services are really behaving?

That difference is fundamental.

Observability should not be treated only as a new generation of tools. It represents a change in the way we see technology environments. Instead of asking only whether a given component is working, we start asking why the service is behaving that way, which relationships may explain that behavior, and what it means for users and for the business.

And the more complex environments become, the more important this change of perspective becomes.

Monitoring components is different from understanding services

Imagine a company that offers a critical application to thousands of users.

The architecture is modern. The application uses microservices, APIs, containers, and cloud services. Part of the data stays on its own infrastructure, while other components run on external providers. There are shared authentication mechanisms, third-party integrations, and different network layers connecting this entire ecosystem.

At some point, users start to notice slowness. The operation detects the problem quickly.

The servers are available. The containers are still running. The database responds. The network shows no widespread outage. Even so, the users’ experience has worsened significantly.

A traditional monitoring approach could lead the team to check component by component, looking for some indicator clearly outside the expected limits. In a relatively simple architecture, that process might be enough.

In modern environments, however, the problem may lie precisely in the relationships between those components.

An API started responding a few seconds slower. That small delay increased the execution time of another service, which began to accumulate requests. A microservice started consuming more resources. The number of connections to the database increased. Other dependent services began to degrade and, some time later, users noticed the impact.

No component necessarily stopped working. The service, however, stopped working properly.

This difference helps us understand why observability has gained so much importance.

Traditional monitoring remains indispensable. We need to know whether equipment is available, track resource utilization, identify deviations, and receive alerts when certain behaviors cross defined thresholds.

But that mainly answers questions we already know.

Observability expands that capability by making it possible to investigate behaviors that were not always anticipated. Metrics show how certain variables evolved. Logs record relevant events inside the systems. Traces make it possible to follow a transaction as it travels across different components of a distributed architecture.

When this information is analyzed together, we start moving from a view based exclusively on components to an understanding closer to the behavior of services.

That is an important advance. But it also creates a new question.

The more deeply we can observe one part of the environment, the clearer it becomes that many relevant incidents do not respect the boundaries of a single platform, technology, or team.

Let us go back to the example.

After some time investigating the application’s degradation, the team responsible for observability notices that a given service began to show an increase in response time at around 10:17 AM. The traces show that several transactions started waiting longer for an external call.

That is extremely valuable information. But it still does not explain why this started happening. The answer may be in another source.

Perhaps a route change occurred a few minutes earlier in a network component. Perhaps an external service began to degrade. Perhaps a security policy was modified. Perhaps a new version of some component was deployed. Or perhaps the origin is in an infrastructure element that is not even part of the universe observed by the same platform.

Observability helped bring the team closer to the problem.

The complete context of the incident, however, may remain distributed across the environment. This distinction will be increasingly important.

Depth of observation and breadth of context are not the same thing.

A platform can offer an extraordinarily deep view of applications, infrastructure, or digital experience and still hold only part of the evidence needed to explain an incident that crosses different technology domains.

There is no contradiction in that. There is complementarity.

The more tools see the environment, the greater the challenge of connecting perspectives

This may be one of the ironies of modern operations.

We invested for years to expand our ability to see infrastructure and services. We built specialization, deployed better tools, and significantly increased the quantity and quality of available data.

And we succeeded.

Today a large operation may use specific platforms for infrastructure, applications, networks, digital experience, logs, security, cloud, containers, ITSM, and several other domains. Each of these solutions can be excellent at the problem it sets out to solve.

The result, however, is that a single incident is observed simultaneously from many perspectives.

Consider the application degradation again.

The observability platform identifies an increase in the response time of certain services. Network monitoring records growing latency on some links. The cloud environment reports a change in the behavior of certain instances. The digital experience system shows an increase in the time needed to complete a journey. ITSM starts recording tickets from users. The logs show errors that did not exist before, and an automation platform holds the record of a change made shortly before the incident began.

Separately, each of these pieces of information tells a story. Together, they may tell another.

This is exactly where the concept of operational context, discussed in the previous article, regains importance.

The challenge is no longer just obtaining detailed information. It is correlating information from multiple sources to understand how they relate.

In the example, knowing that an application became slow is important. Knowing that network latency increased in the same period is also important. Discovering that there was a configuration change a few minutes earlier adds another piece of evidence. Identifying that all the affected applications depend on the same communication path begins to significantly narrow the universe of hypotheses.

None of these pieces of information, on its own, needs to reveal the cause. It is the relationship between them that begins to explain the incident.

This also changes how we should think about data volume.

For some time, it seemed reasonable to imagine that the more data an operation collected, the greater its ability to understand problems.

In practice, there is a limit to that logic.

More metrics can mean more visibility, but also more information to interpret. More logs increase investigative capability, but can generate millions of records within a few minutes of operation. More specialized tools expand the depth of analysis, but also create new sources that need to be queried and related during an incident.

The challenge gradually moves from collection to interpretation. This can be seen clearly in so-called war rooms.

When a critical incident occurs, different specialists are brought together because each one knows a part of the environment deeply. The applications team consults its platform. Infrastructure checks its indicators. Networking analyzes its events. The database team looks for anomalies. Security checks changes. The Service Desk reports the behavior of tickets.

Everyone has data.

The meeting exists precisely because the context still needs to be built.

People start comparing times, looking for dependencies, discarding hypotheses, and reconstructing the sequence of events. Often, a piece of information that seemed of little relevance in one tool becomes decisive when compared with an event observed in another.

This process can work very well, especially when experienced professionals are involved. But it also reveals an important limitation.

The greater the number of sources and the greater the volume of information they produce, the harder it becomes to build this context manually at the speed the business demands.

This is not a problem caused by the tools. It is a natural consequence of complexity.

That is why I believe the evolution of observability needs to be accompanied by an equally important evolution in how we integrate and interpret what we observe.

Observability needs to lead to understanding, not just more data

This is the point at which, in my perception, observability stops being only a technological discussion and becomes a discussion about the way of operating itself.

An organization can acquire an excellent observability platform and keep working in a fragmented way.

It can have extremely detailed traces but analyze them separately from infrastructure events.

It can collect millions of logs but not relate them automatically to recent changes.

It can know an application’s behavior deeply and still take a long time to discover that the origin of its degradation was in an external component.

Technology creates the possibility of understanding better. The operation needs to turn that possibility into real decision-making capability.

This requires a change of perspective.

Instead of organizing the investigation only around the tools, we need to organize it around the incident. It seems like a small difference, but it is not.

When the investigation starts with the tool, each team asks: “what is my platform showing?”.

When it starts with the incident, the question becomes: “which information, regardless of where it lives, helps explain what is happening?”.

This second question naturally crosses boundaries.

It may require data from observability, monitoring, network, cloud, ITSM, digital experience, topology, changes, automation, or any other source relevant to that incident.

In this model, no platform loses importance. On the contrary.

The better the information produced by each one, the better the context the operation will be able to build.

This is an important distinction because there is a natural tendency to imagine technological evolution as a succession of replacements.

A new tool replaces the previous one. A new category makes the previous one obsolete. A more comprehensive platform eliminates the need for the others.

The reality of large operations is usually different.

Complex environments accumulate technologies because different problems demand different levels of specialization. An observability tool can coexist with infrastructure monitoring, ITSM, network solutions, digital experience, and vendor-specific platforms because each one has an important function.

The question stops being which of them holds the whole truth. Probably none of them does.

The more relevant question becomes how to turn the different perspectives produced by this ecosystem into a shared understanding of the incident.

This change also helps explain why some organizations, even when using similar platforms, show very different levels of operational efficiency.

The difference may not lie in the amount of data collected or in the sophistication of the tools.

It may lie in how fast they can connect the available information and turn it into context.

Let us return one last time to the application incident.

Imagine two companies with similar architectures and practically the same tools.

In both, observability quickly detects the degradation.

In the first, each team starts its own investigation. Applications analyzes traces. Networking checks latency. Infrastructure tracks resources. The Service Desk consolidates tickets. A meeting is called and, over the next forty minutes, the specialists compare information until they realize that a change made in the network shortly before the incident altered the behavior of a path used by several services.

In the second company, that same information is related from the first minutes. The increase in response time is associated in time with the change. The affected services share the same dependency. The network events appear within the same time window, and user tickets confirm the impact.

Both companies had practically the same data. Both detected the problem. Both had qualified professionals.

What changed was the time needed to turn scattered information into understanding.

That difference can represent tens of minutes of downtime, hundreds of affected users, and, depending on the service, significant financial impact.

That is why I believe the discussion about observability needs to move forward.

The next leap will not come simply from the ability to collect even more data. It will come from the ability to make better use of what we can already observe.

This means combining depth with breadth. We need to see the behavior of components deeply, but also understand the relationships that cross different technologies, platforms, and operational domains.

In other words, observability generates even more value when it stops being an island of information and starts contributing to building a broader operational context.

This view also changes the question managers should ask when evaluating the maturity of their operations.

Perhaps it is not enough to ask:

“Do we have observability?”

A more interesting question would be:

“When a critical incident occurs, can we quickly connect what our different platforms are telling us?”

The answer reveals much more about the real capability of the operation.

In the next article in the series, “MTTR starts before the incident is resolved”, I intend to move forward on exactly this question. We will analyze how much of an incident’s total time is really spent fixing the problem and how much is consumed trying to understand it, locate its origin, mobilize the right teams, and decide which action should be taken.

Because reducing MTTR may depend less on executing the solution faster and much more on reaching the right decision sooner.

Food for thought

When looking at your operation, it is worth analyzing whether observability represents only a new source of information or whether it has really changed the way incidents are understood.

When an application shows degradation, can teams quickly relate observability data to events from infrastructure, network, ITSM, digital experience, changes, and other relevant sources?

During a critical incident, do professionals work on a shared view of the problem, or does each team continue investigating mainly what its own platform can see?

And, perhaps the most important question: when all these tools produce information at the same time, who builds the context that makes it possible to understand the incident as a whole?

The answers may reveal that the next step for observability is not necessarily to observe more.

It may be to better connect what we can already see.

About the author

Paulo Florêncio de Menezes is an entrepreneur, partner, and co-founder of companies such as Target Solutions, BiPTT, and ARGUS.

He holds a degree in Data Processing from the Federal University of Amazonas (UFAM), an MBA in Business Management from Fundação Dom Cabral (FDC), and a Professional Master’s in Economics from Fundação Getulio Vargas (FGV).

In his Master’s research, he developed the IBEOP-IA (Brazilian Index of Potential Occupational Exposure to Artificial Intelligence), investigating the potential exposure of Brazilian occupations to AI capabilities by combining occupational data, artificial intelligence patents, and natural language processing techniques.