Three pillars of observability

Logs

Collect application, host, container and cloud logs in one place. Use structured fields, Trace IDs and alert context to investigate the causes of anomalies.

Metrics

Monitor host, container, service, database and business metrics. Use trends, thresholds and anomaly detection to identify capacity risks and performance degradation.

Traces

Follow a request through services, dependencies and timings with APM traces to locate slow endpoints, failing dependencies and cross-service bottlenecks.

Integrate your data in one platform

Preserve service, environment, version, resource, and business context across collection, storage, queries, alerts, and collaboration so responders can move from a symptom to impact, cause, and owner.
What you can do

Follow alerts, slow requests, Pod restarts, API timeouts or slow pages to the relevant evidence.

Use shared context to assess impact, ownership and the next action.

Visualization ready for investigation

Help development, QA and operations work together

Connect development, QA, operations, SRE and business teams with objective data. Investigate alerts, releases, changes and incidents using shared evidence to reduce tool switching and disputes about ownership.

Spending too much time maintaining open-source tools?

Looking for the right observability platform?

Build a unified observability platform
Two foundations of observable systems

Connected resources: relate services, hosts, containers, databases, cloud resources and business processes.

Connected data: query and analyze metrics, logs, traces, RUM, profiles and events together.

Full-stack observability for the AI era

Connect supported technologies and cloud services

Unified collection, storage, queries and visualization

Connect APM, logs, RUM, Kubernetes and business data

Explore product capabilities

Frequently asked questions

What is full-stack observability?

Full-stack observability connects metrics, logs, traces, RUM, profiles, Kubernetes, cloud resources, events, and business data so teams can explain why a system changed and who or what was affected.

How is full-stack monitoring different from full-stack observability?

Full-stack monitoring emphasises coverage across technology layers. Full-stack observability also preserves identity, time, and resource relationships so teams can ask new questions during an unknown failure.

Does full-stack observability require OpenTelemetry?

Not exclusively. OpenTelemetry provides open standards for telemetry generation, semantics, and collection, while a platform may also receive existing log pipelines, Prometheus, cloud APIs, RUM, and other supported sources.

Explore further

References