The concept of observability is a valuable one, but the way the term has been used is misleading and leaves some teams worse off because of limitations in what observability tools actually provide. Enterprises need to rethink what observability means and regard it as a practice rather than a catch-all product category that can serve every team member’s needs equally. 

There are several teams that can benefit from observability, and they each have needs specific to their roles and responsibilities. For example, key constituents include:

• SRE and infrastructure specialists
• Data engineers
• Developers
• Security specialists

What enterprises really need from observability

Each of these teams need actionable information to help them address the specific issues they confront in their roles. Crucially, this information must not just alert them that a problem exists but also provide the specific details and context to help address the problem quickly.

For example, in the context of security, observability tools must help security practitioners to quickly detect and mitigate threats and vulnerabilities. The tools should provide metrics to help explain why incidents occurred and suggest proactive measures to mitigate against threats in future.

For data engineering teams, observability tools should provide visibility across data pipelines and data products. Data practitioners need to know when the source of data in a pipeline changes, for example, and what action they need to take to maintain the integrity of their data applications.

For developers, observability tools need to know not just that an error or a performance issue occurred, but also direct them to the specific coding issue that caused the error. They also need information to help them prioritize errors and know which to address first, delivered in the context of their workflows, not in a separate tool.

Providing teams with actionable detail that’s specific to their roles creates greater ownership and accountability for each practice area, because specialists get the information they need delivered directly to them. In contrast, treating observability as a catch-all product area leads to multiple teams chasing after the latest problem, no matter the source of that issue. Observability has skewed too far towards solving cloud infrastructure challenges, and this approach doesn’t do enough for specialists in other areas.

Here are three myths of observability that have emerged as a result of this wrong-headed thinking:

Myth 1. Observability is a product. We need to stop thinking about observability as a product and start to regard it for what it actually is: a practice. When we view observability as a practice, we quickly realize that each practice area has its own needs that cannot be addressed with a single pane of glass. 

Myth 2. Observability is the same for every persona. Each practice area has its own distinct needs, and that means they need information that addresses their specific roles and objectives, delivered in the context of their usual workflow. What’s useful for an SRE will not be the same as what’s useful for a developer or a security specialist. 

Myth 3. More data solves everything. Data alone is not a silver bullet, and too much data can become a liability when it needs to be securely stored and managed at scale. One financial services firm was recently hit with an observability bill of $65 million, reportedly due to unpredictable spikes in the data collected.

An approach that targets specialists with just the data they need to solve the problem at hand is far more efficient than collecting all logs, metrics and trace data and trying to analyze it after the fact.

Technology specialists in areas like security, data and software development are far more effective — and happier — when they get the information they need to solve problems quickly and take ownership of their work. Observability is an important area, but treating it as a product rather than a practice can lead to higher costs and poorer outcomes for the business.

The post 3 Myths About Observability — And Why They’re Holding Back Your Teams appeared first on SD Times.