What does observability look like once it goes beyond metrics, logs and traces?

Additional signals — events, profiling, user-experience data, infrastructure metrics and business metrics — are correlated with the technical pillars so that a business question can be traced down to a technical cause.

The extra data sources:

• Events — discrete facts about changes: a deployment, a configuration change, a scaling action. Overlaying these on a metric graph answers "what changed at 14:03?" faster than any query.
• Profiling — where the CPU time or memory inside a process actually goes, one level below a span.
• User-experience data — what real browsers and devices measured (page load, interaction delay), not what the server thinks it delivered.
• Infrastructure metrics — the resource layer underneath.
• Business metrics — orders, sign-ups, revenue.

The point of adding the last one is the ability to answer a question like "why did revenue drop 20%?" by connecting user behaviour → application performance → back-end services. That chain is what turns observability from an engineering tool into something the business funds: the 20% drop is traced to a checkout service whose p95 latency doubled after a deployment at 14:03, rather than being attributed to the weather.

Go deeper:

• Martin Fowler: Domain-Oriented Observability — the argument for instrumenting business-meaningful events rather than only technical ones.