Observability Overview

Summary

Keymate provides built-in observability covering all three telemetry signals: logs, metrics, and traces. The platform collects telemetry from every component automatically using OpenTelemetry, stores it in an integrated observability stack, and presents it through unified dashboards. You do not need to instrument Keymate services yourself — the platform includes telemetry out of the box.

Critically, Keymate does not lock you into its built-in observability tooling. Because all telemetry flows through OpenTelemetry, you can export data to your own monitoring tools (any OTLP-compatible backend), use both the built-in stack and your own tools simultaneously, or replace the built-in stack entirely.

Why It Exists

Operating a multi-component IAM platform in production requires visibility into what is happening across all services. Without observability, troubleshooting authorization failures, diagnosing performance bottlenecks, or detecting security anomalies requires guesswork and manual log searching across dozens of services.

Keymate treats observability as a first-class platform capability rather than an afterthought. The platform deploys it as a core layer, not as a later addition.

Where It Fits in Keymate

Observability is the fourth deployment layer (see Platform Components). You deploy it after the infrastructure, data, and application layers are running, and it immediately begins collecting telemetry from all previously deployed components.

Within the Operations section, Observability connects to:

• Runtime — scaling decisions and performance tuning are informed by metrics
• Security — audit events and anomaly detection rely on log and trace collection
• Deployment — deployment health is validated through observability dashboards

Boundaries

This section covers:

• The three telemetry signals (logs, metrics, traces) and how Keymate collects them
• The built-in observability stack and what it provides
• How to export telemetry to external tools
• The OpenTelemetry-first architecture and its benefits

This section does not cover:

• Application-level custom instrumentation for services built on top of Keymate (see Developer Guides)
• Alert rule authoring and notification channel configuration (platform-specific, varies by deployment)

How It Works

Three Signals, One Pipeline

Keymate collects three types of telemetry, all through the same OpenTelemetry pipeline:

Signal	What it captures	Use cases
Logs	Pod logs, application logs, infrastructure events	Error investigation, audit trail, operational debugging
Metrics	CPU, memory, request rate, latency, error rate, custom business metrics	Performance monitoring, capacity planning, alerting
Traces	Distributed request flows across services, span timing, service dependencies	Root cause analysis, latency diagnosis, service dependency mapping

Collection Architecture

Every Keymate component emits telemetry through OpenTelemetry. The OpenTelemetry Collector receives all signals and routes them to one or more destinations:

• Built-in observability platform — the default destination, deployed as part of the platform
• External tools — optional, configured through telemetry export (see Export and Tooling Portability)
• Both simultaneously — the collector supports sending the same data to multiple destinations

Built-in Observability Stack

The built-in observability platform provides:

• Unified dashboards for infrastructure and application metrics
• Log search and correlation across all platform components
• Distributed trace visualization with span details and service maps
• Alerting based on metric thresholds, log patterns, and trace anomalies

The platform deploys this stack automatically as part of the observability layer during installation. You need no additional setup to start seeing telemetry data.

No Vendor Lock-in

The most important architectural decision in Keymate's observability model is the OpenTelemetry-first approach. Because all telemetry uses the OpenTelemetry standard:

• You can replace the built-in observability platform with any OTLP-compatible backend
• You can run the built-in platform alongside your existing tools
• You can switch monitoring tools without re-instrumenting any Keymate services
• Your investment in monitoring dashboards and alerts is portable across backends

See Export and Tooling Portability for details on how to configure export destinations.

Diagram

Example Scenario

Scenario

An operator at Acme Corp notices elevated API response times. They need to identify the root cause across the Keymate platform.

Input

• Actor: Operator
• Symptom: API latency increased from 50ms to 500ms
• Tools: Built-in observability dashboards

Expected Outcome

1. The operator opens the metrics dashboard and identifies which service shows increased latency
2. They switch to the trace view and find a specific slow span in the authorization engine
3. They correlate the trace with logs from the same time window and discover a database query performing a full table scan
4. They resolve the issue by identifying the root cause within minutes, not hours

Common Misunderstandings

• "I must use the built-in observability platform." The built-in stack is included for convenience, but you can export all telemetry to your own tools. See Export and Tooling Portability.
• "I need to instrument Keymate services myself." All Keymate components ship pre-instrumented with OpenTelemetry. Telemetry collection starts automatically after deployment.
• "Logs, metrics, and traces are separate systems." In Keymate, all three signals flow through the same OpenTelemetry pipeline, enabling cross-signal correlation (e.g., jump from a metric spike to related traces and logs).

warning

Do not skip the observability layer during initial deployment. Troubleshooting platform issues without logs, metrics, and traces is significantly harder. If you prefer your own tools, configure telemetry export rather than disabling collection entirely.

Design Notes

• The Cloud Native Computing Foundation (CNCF) maintains OpenTelemetry as an industry standard. Choosing OTel as the telemetry foundation means Keymate's observability model benefits from a large ecosystem of exporters, processors, and integrations.
• The telemetry collector acts as a routing layer. Adding a new export destination does not require changes to any Keymate service — only a collector configuration update.
• Each telemetry signal has its own dedicated guide for deeper operational details: Logs, Metrics, Traces and Root Cause Analysis.
• Observability covers platform telemetry (logs, metrics, traces). For authorization decision event recording, see the Audit Collector component.

tip

Start with the built-in observability platform to get immediate visibility. Add external tool export later as your monitoring requirements evolve. Both can run simultaneously with no performance impact on the platform itself.

Related Docs

Logs

Log collection, search, and correlation

Metrics

Dashboards, alerting, and performance monitoring

Traces & Root Cause Analysis

Distributed tracing and latency diagnosis

OpenTelemetry-First Model

Why Keymate uses OTel as the telemetry standard

Export & Tooling Portability

Send telemetry to your own monitoring tools