SUSE Observability

SUSE Observability is an enterprise observability platform for Kubernetes and cloud-native infrastructure. It unifies metrics, logs, traces, and topology into a single platform, built around a unique 4T data model (Topology, Telemetry, Traces, Time) that correlates all observability signals against a real-time dependency map of your infrastructure. The current version is v2.8.1 (released 17 March 2026).

The product was originally developed by StackState, a Dutch observability company founded in 2015 by Mark Bakker and Lodewijk Bogaards (with Remco Beckers joining as a third co-founder). StackState was built around the insight that traditional monitoring creates data silos, and that mapping IT topology — the relationships and dependencies between components — is essential for understanding complex distributed systems.

Deployment Models

• SUSE Observability (Self-Hosted) — deployed on your own Kubernetes cluster via Helm. Included with SUSE Rancher Prime subscriptions. Full control over data and infrastructure.
• SUSE Cloud Observability (SaaS) — fully managed SaaS platform launched November 2024. Available on AWS Marketplace. Setup in under 5 minutes. Supports EKS, on-premises, and Rancher-managed clusters. This was SUSE's first SaaS-based product.

The core differentiator of SUSE Observability is the 4T data model, introduced in StackState v4.6. Traditional observability tools treat metrics, logs, and traces as separate concerns. SUSE Observability correlates Topology, Telemetry, and Traces at every moment in Time, providing a unified context for troubleshooting that no individual signal can offer alone.

Why Topology Changes Everything

In traditional monitoring (Prometheus + Grafana), you have metrics and dashboards but no automatic understanding of what depends on what. When a database goes down, you see the database alert, but you have to manually figure out which applications are affected. With the 4T model:

• Context is automatic — every metric, log, and trace is tied to a component in the topology map
• Impact analysis is built-in — if a component becomes unhealthy, you instantly see all dependent components that are affected via health propagation
• Root cause analysis follows the graph — problems propagate through the dependency chain, and SUSE Observability identifies the unhealthy component at the bottom of the chain as the probable root cause
• Ephemeral resources are preserved — even after a pod is deleted, you can travel back in time and see how it was connected, its logs, events, and related resources

SUSE Observability consists of three primary architectural components: the Server (on-premises or SaaS), the Agent (deployed on observed clusters), and the optional Rancher Prime UI Extension.

Server Components (Distributed Mode)

In HA production deployments, the server runs in distributed mode with separate pods for each function. In non-HA setups, all functions consolidate into a single suse-observability-server pod.

SUSE Observability runs six major backing services, all deployed as part of the Helm chart. There is no external dependency on managed databases — everything runs inside the Kubernetes cluster.

Backup Architecture

Backups are handled through a MinIO gateway that supports three storage backends: AWS S3, Azure Blob Storage, or Kubernetes PersistentVolumes.

The SUSE Observability Agent is deployed on each observed cluster (not the server cluster) via Helm. It consists of four components that work together to collect topology, metrics, events, logs, traces, and network data.

Request Tracing (Cross-Service)

For tracing requests across service boundaries, load balancers, and service meshes, SUSE Observability can inject a sidecar proxy via a mutating webhook. The sidecar injects an X-Request-ID header into all HTTP traffic. This header is observed at both client and server endpoints, allowing SUSE Observability to map service dependencies across cluster boundaries.

• Supported protocols: HTTP/1.0, HTTP/1.1 with keepAlive, unencrypted traffic, OpenSSL-encrypted traffic
• Supported integrations: LinkerD service mesh, Envoy proxy, Istio EnvoyFilters
• Resource overhead: 25–40 MB memory per pod for the sidecar proxy, plus variable CPU based on request volume
• Annotation: http-header-injector.stackstate.io/inject: enabled

Supported Container Runtimes

• ContainerD
• CRI-O

The topology-based health model is how SUSE Observability turns raw observability data into actionable insights. Every component in your infrastructure has a health state, and health propagates through the dependency graph to enable automatic root cause analysis.

Components & Relations

• Component — any discrete element in your infrastructure: a pod, a node, a service, a deployment, a namespace, a PV, etc. Each has properties, telemetry bindings, and a health state.
• Relation — a directed dependency between two components. The arrow indicates dependency direction: app → db means "app depends on db."

Health States

Each component has a computed health state based on monitors that evaluate metrics, topology, and metadata:

• CLEAR (green) — component is healthy, all monitors pass
• DEVIATING (orange) — component is deviating from expected behavior
• CRITICAL (red) — component has a critical issue
• UNKNOWN (gray) — no health data available

Health Propagation & Root Cause Analysis

Health propagates in the opposite direction to dependency arrows. If app → db and the database turns red, the app component's outer color turns red to indicate potential impact from an upstream dependency. The inner color shows the component's own health; the outer color shows propagated health from its dependencies.

Out-of-the-Box Monitors

SUSE Observability ships with pre-configured monitors for common Kubernetes failure modes. Each monitor includes remediation guides that appear directly in the UI with step-by-step troubleshooting instructions. Monitors can be:

• Metric-based — threshold and dynamic threshold monitors on metrics
• Topology-based — validate topology structure and component properties (unique to SUSE Observability's 4T Monitors)
• Derived state — monitors that derive health from related components
• Custom — user-defined monitors via the UI or CLI, can target Prometheus metrics ingested via remote_write

Time-travel is SUSE Observability's signature capability, built on the versioned graph database that preserves every topology state change. It operates on two independent time dimensions that can be controlled separately.

How It Works in Practice

1. Incident occurs at 2:00 AM — you arrive at 9:00 AM to investigate
2. Set topology time to 2:00 AM — the topology perspective reconstructs the exact state of your infrastructure at that time, including pods that may have been killed and restarted since then
3. Set telemetry interval around 2:00 AM — see metrics, logs, events, and traces from that window
4. Navigate the topology — follow the dependency graph from affected services to the root cause, seeing all associated telemetry for each component at that point in time
5. Scrub through time — use the timeline at the bottom of the UI to move forward and backward, watching how the topology and health states changed

SUSE Observability is deployed via Helm charts to a dedicated Kubernetes cluster (or namespace on an existing cluster). Installation takes approximately 30 minutes. Helm v3.13.1 or higher is required.

Step 1: Add Helm Repository

# Add the SUSE Observability Helm repo
helm repo add suse-observability \
  https://charts.rancher.com/server-charts/prime/suse-observability
helm repo update

Step 2: Create Namespace

kubectl create namespace suse-observability

Step 3: Create values.yaml

# values.yaml - Core configuration
global:
  suseObservability:
    license: "YOUR-LICENSE-KEY"          # From SUSE Customer Center
    baseUrl: "https://observability.example.com"  # External access URL
    adminPassword: "your-admin-password"  # Plain text or bcrypt hash
    sizing:
      profile: "150-ha"                  # See sizing profiles below
  # imageRegistry: "registry.example.com" # Optional: custom registry
  # storageClass: "gp3"                   # Optional: override default

Step 4: Deploy

# Install SUSE Observability
helm upgrade --install \
  --namespace suse-observability \
  --values values.yaml \
  suse-observability \
  suse-observability/suse-observability

# Verify installation
helm list --namespace suse-observability
kubectl get pods --namespace suse-observability

# Port-forward for local access
kubectl port-forward \
  service/suse-observability-suse-observability-router 8080:8080 \
  --namespace suse-observability

Step 5: Deploy Agent on Observed Clusters

After the server is running, navigate to StackPacks > Integrations > Kubernetes in the SUSE Observability UI. Create a new instance with a cluster identifier. The UI will generate a Helm command with pre-filled configuration:

# Generated by SUSE Observability UI (example)
helm upgrade --install \
  --namespace suse-observability \
  --create-namespace \
  --set-string 'stackstate.apiKey=YOUR-API-KEY' \
  --set-string 'stackstate.cluster.name=my-cluster' \
  --set-string 'stackstate.url=https://observability.example.com/receiver/stsAgent' \
  suse-observability-agent \
  suse-observability/suse-observability-agent

Sizing Profiles

Air-Gapped Installation

For disconnected environments, pull all container images to a local registry and provide a local-docker-registry.yaml with global.imageRegistry set to your internal registry.

helm upgrade --install \
  --namespace suse-observability \
  --values local-docker-registry.yaml \
  --values values.yaml \
  suse-observability \
  suse-observability/suse-observability

Compute Requirements (Server Cluster)

Minimum Node Specifications

Kubernetes Compatibility

Supported Kubernetes Distributions

• Cloud managed: Amazon EKS, Azure AKS, Google GKE, Alibaba Cloud ACK
• On-premises: RKE2, K3s, vanilla Kubernetes
• Enterprise: OpenShift (4.14–4.19)

Data Retention Defaults

• Trial: 3 days
• Production profiles: 30 days
• SaaS (Cloud Observability): ~1 day for events/logs/metrics, ~12 hours for traces (default tier)

Other Requirements

• Helm: v3.13.1 or higher (Helm 4 supported as of v2.8.0)
• Ingress: An ingress controller or load balancer for external HTTPS access
• Browsers: Chrome and Firefox
• Authentication: OIDC, KeyCloak, Microsoft Entra ID, LDAP, file-based, or single-password

SUSE Observability extends its functionality through StackPacks — plugin packages that provide automated integration with external systems. StackPacks come in two types: Add-ons (extend platform capabilities) and Integrations (connect to external data sources).

OpenTelemetry (Native)

SUSE Observability is OpenTelemetry-native. It includes an OpenTelemetry Collector (v0.108.0-stackstate.21) as a built-in component and accepts OTLP data (traces, metrics, logs) at dedicated API endpoints. The recommended architecture:

1. Instrument applications with OpenTelemetry SDKs
2. Deploy the OpenTelemetry Collector near instrumented applications to preprocess data (enrich with K8s labels, implement sampling)
3. Forward to SUSE Observability's OTLP endpoints

Out-of-the-box capabilities include monitors for span error rates and duration metrics, metric bindings for span metrics, .NET and JVM memory metrics, and service overview pages.

Prometheus Integration

SUSE Observability exposes a Prometheus remote_write endpoint to mirror metrics from existing Prometheus instances:

# Add to your Prometheus config
remote_write:
  - url: https://<base-url>/receiver/prometheus/api/v1/write
    headers:
      sts-api-key: "<API-KEY>"
    # Or use basic_auth:
    # basic_auth:
    #   username: apikey
    #   password: "<API-KEY>"

This enables using existing Prometheus metrics in SUSE Observability's monitors and topology context without replacing your existing Prometheus setup.

Kubernetes StackPack

The core integration. Provides auto-discovery of all Kubernetes topology (clusters, nodes, namespaces, workloads, pods, services, etc.), pre-built monitors for common Kubernetes issues, and the agent deployment configuration. Multi-instance support allows monitoring multiple clusters from a single SUSE Observability server.

Other Integrations

• Cloud providers: AWS StackPack (supports multiple AWS accounts), Azure, GCP
• Alerting: Slack, Jira, custom webhooks
• CI/CD: Integration with CI/CD pipelines for deployment correlation
• Custom: StackPacks can be extended or new ones created for custom data sources
• Splunk: Integration for log forwarding (v2.8.0 added improvements)
• 40+ prebuilt dashboards for common Kubernetes monitoring scenarios

SUSE Observability is tightly integrated with SUSE Rancher Prime through a UI extension and shared RBAC. The observability license is included with Rancher Prime subscriptions.

Rancher Prime UI Extension

A Rancher Manager extension that integrates SUSE Observability health signals directly into the Rancher UI. Installation:

1. Enable UI extensions from the Rancher UI
2. Navigate to Extensions > Available
3. Install the Observability extension
4. Navigate to SUSE Observability > Configurations in the left panel
5. Add the SUSE Observability server URL and credentials

Once configured, Rancher displays health indicators on every resource (cluster, node, workload, pod). Clicking a health indicator provides a direct link to SUSE Observability's detailed investigation view for that resource.

RBAC Integration

SUSE Observability supports Rancher RBAC, allowing you to map Rancher roles and permissions to SUSE Observability access levels. This means Rancher users see only the clusters and resources they have permission to view.

Complementing Existing Prometheus + Grafana

SUSE Observability does not replace Rancher's built-in Prometheus + Grafana monitoring stack. Instead, it complements it:

• Prometheus + Grafana (Rancher Monitoring) — provides detailed metrics dashboards, PromQL queries, and alerting rules for specific metrics
• SUSE Observability — adds topology awareness, cross-cluster correlation, root cause analysis, time-travel debugging, and the 4T data model
• Connect them via Prometheus remote_write to feed Prometheus metrics into SUSE Observability's topology-correlated view

SUSE Observability vs. Alternatives

Unique Selling Points

• Versioned topology — the only platform with a custom-built versioned graph database that stores every topology state change, enabling true time-travel debugging of infrastructure
• 4T Monitors — monitors that can validate topology structure and properties, not just metric thresholds
• Rancher-native — deep integration with the Rancher ecosystem, shared RBAC, included in Rancher Prime subscription
• Self-hosted option — full on-premises deployment for organizations with data sovereignty requirements, unlike SaaS-only competitors
• Open-source commitment — SUSE has committed to open-sourcing the platform

Licensing & Pricing