OpenTelemetry-First Model
Summary
Keymate uses OpenTelemetry (OTel) as its single telemetry standard. Every platform component emits logs, metrics, and traces through the OpenTelemetry protocol. This architectural choice means you are never locked into a specific monitoring vendor — telemetry data can be routed to any OTel-compatible backend, including the built-in observability stack, your existing enterprise monitoring tools, or both at the same time.
Why It Exists
Enterprise organizations invest heavily in monitoring infrastructure. Mandating a specific observability vendor as a condition of deploying Keymate would create friction, duplicate costs, and force teams to maintain two separate monitoring systems.
By standardizing on OpenTelemetry — a vendor-neutral, CNCF-backed industry standard — Keymate integrates with whatever monitoring tools the customer already uses rather than replacing them.
Where It Fits in Keymate
The OpenTelemetry-first model is the architectural foundation underneath the entire Observability section. It determines:
- How telemetry is collected (OTel SDK in every service)
- How telemetry is transported (OTel Collector as the routing layer)
- How telemetry is exported (OTLP protocol to any compatible backend)
- Why the built-in observability stack can be replaced or supplemented
Boundaries
This page covers:
- What OpenTelemetry is and why Keymate adopted it
- The benefits of a vendor-agnostic telemetry architecture
- How the OTel Collector fits into the platform
- Supported export protocols and destinations
This page does not cover:
- Configuring specific export destinations (see Export and Tooling Portability)
- Using logs, metrics, or traces in the built-in dashboards (see Logs, Metrics, Traces)
How It Works
What is OpenTelemetry?
OpenTelemetry is an open-source observability framework maintained by the Cloud Native Computing Foundation (CNCF). It provides a single set of APIs, SDKs, and tools for collecting telemetry data from cloud-native applications. OTel is supported by every major monitoring vendor and has become the industry standard for telemetry in Kubernetes environments.
Keymate's OTel Architecture
Keymate instruments every component with the OpenTelemetry SDK. Telemetry data flows through three stages:
- Emit — Each service emits logs, metrics, and traces using the OTel SDK. You do not need custom instrumentation.
- Collect — The OTel Collector receives all signals and processes them (batching, filtering, enrichment).
- Export — The Collector sends data to one or more backends using standard protocols.
Supported Export Protocols
| Protocol | Use case | Destinations |
|---|---|---|
| OTLP (gRPC/HTTP) | Universal OTel protocol | Any OTLP-compatible observability platform or backend |
| metrics remote write | Metric export | Metrics backend, metrics storage backend |
| Trace protocol | Trace export | Trace backends |
| Zipkin | Trace export | Zipkin backends |
What This Means in Practice
| Scenario | What happens |
|---|---|
| You want to use the built-in stack only | Default configuration — no changes needed |
| You want to use your own observability platform instead | Configure the OTel Collector to export via OTLP. Remove or keep the built-in stack |
| You want both the built-in stack and an external metrics dashboard | Configure dual export in the Collector. Both receive the same telemetry data |
| You want to switch observability platforms later | Change the Collector export configuration. No service changes, no re-instrumentation |
Example Scenario
Scenario
Acme Corp already runs a centralized observability platform for all production monitoring. They deploy Keymate and want authorization telemetry visible in their existing dashboards alongside their other services.
Input
- Actor: Platform Engineer
- Existing monitoring: Centralized observability platform
- Requirement: Keymate telemetry in the existing platform, no separate monitoring silo
Expected Outcome
- The OTel Collector is configured to export all Keymate telemetry (logs, metrics, traces) to the observability platform via OTLP
- Keymate services appear in the platform's service map, APM traces, and log explorer
- The platform engineer uses the same dashboards and alerts they already know
- No custom instrumentation was added to any Keymate service
Common Misunderstandings
- "OpenTelemetry is a monitoring tool." OTel is a telemetry standard and collection framework, not a storage or visualization tool. It collects and routes data — backends like the built-in stack or your preferred observability platform provide storage and dashboards.
- "Switching monitoring tools requires re-instrumenting services." With OTel, switching backends is a Collector configuration change. Services are instrumented once and never need to change.
- "OTel adds performance overhead." The OTel SDK and Collector target production use with minimal overhead. Batching and sampling controls handle high-throughput environments.
- "I need to choose between the built-in stack and my own tools." You can run both simultaneously. The Collector supports multiple export destinations with no conflict.
Do not disable telemetry collection to reduce resource usage. The overhead is minimal, and the operational cost of troubleshooting without telemetry far exceeds the resource cost of collecting it.
Design Notes
- Keymate chose OpenTelemetry specifically for its vendor-neutral, CNCF-governed nature. This protects customers from vendor lock-in at the observability layer.
- The OTel Collector acts as a decoupling layer between services and backends. Services never communicate directly with monitoring tools — the Collector handles all routing, transformation, and export.
- All three telemetry signals (logs, metrics, traces) use the same pipeline. This enables cross-signal correlation: you can navigate from a metric spike to related traces to the specific log lines that explain the issue.
If your organization mandates a specific monitoring tool, configure Keymate's OTel Collector to export to that tool from day one. You get full telemetry visibility in your existing platform without maintaining a separate monitoring stack.