Export & Tooling Portability
Summary
Keymate's OpenTelemetry-first architecture enables full telemetry portability. You can export all observability data — logs, metrics, and traces — to your existing monitoring tools without changing any Keymate service. The OpenTelemetry Collector supports multiple simultaneous export destinations, so you can use the built-in observability stack, your own tools, or both at the same time.
Why It Exists
Most enterprises already operate monitoring infrastructure. Requiring customers to adopt a new observability tool as a condition of deploying Keymate creates operational overhead and duplicate costs. Telemetry export eliminates this friction by routing Keymate's observability data into whatever tools the customer already uses.
Where It Fits in Keymate
This capability is a direct consequence of the OpenTelemetry-first model. The OTel Collector is the routing layer that makes export possible. This page focuses on the practical export options and deployment patterns — the architectural rationale is covered in the OTel-first model page.
Boundaries
This page covers:
- Supported export destinations and protocols
- Common deployment patterns (built-in only, external only, dual-export)
- How to decide which pattern fits your organization
- What data is exported and what stays local
This page does not cover:
- Step-by-step Collector configuration (deployment-specific, varies by target tool)
- Built-in dashboard and alerting setup (see Observability Overview)
- Individual signal deep dives (see Logs, Metrics, Traces)
How It Works
Export Destinations
The OTel Collector can export to any backend that supports standard telemetry protocols:
| Monitoring Tool | Protocol | Signals Supported |
|---|---|---|
| Observability platform (OTLP-compatible) | OTLP (gRPC/HTTP) | Logs, metrics, traces |
| Observability stack (log aggregation backend, metrics storage backend, trace backend) | OTLP, metrics remote write | Logs, metrics, traces |
| Log management platform | OTLP or HEC | Logs, metrics, traces |
| Any OTLP backend | OTLP (gRPC/HTTP) | Logs, metrics, traces |
| Metrics backend | metrics remote write | Metrics |
| Trace backend | trace protocol | Traces |
Deployment Patterns
Three common patterns for how organizations use Keymate observability:
Pattern 1: Built-in only (default)
Use this when:
- You do not have existing monitoring infrastructure
- You want the fastest path to full observability
- You prefer a self-contained deployment
Pattern 2: External tool only
Use this when:
- Your organization mandates a specific monitoring tool
- You want Keymate telemetry in the same dashboards as all other services
- You do not want to operate an additional observability stack
Pattern 3: Dual-export (both)
Use this when:
- You want the built-in dashboards for Keymate-specific monitoring
- You also want Keymate data visible in your organization-wide monitoring
- You are evaluating whether to fully transition to external tooling
What Gets Exported
All three telemetry signals are exported:
| Signal | Data included |
|---|---|
| Logs | Structured application logs, error logs, audit events from all platform components |
| Metrics | Infrastructure metrics (CPU, memory, network), application metrics (request rate, latency, error rate), custom business metrics |
| Traces | Distributed traces with full span hierarchy, timing, attributes, and service dependencies |
Export delivers the same data that appears in the built-in dashboards. No data is exclusive to the built-in stack.
Choosing a Pattern
| Factor | Built-in only | External only | Dual-export |
|---|---|---|---|
| Setup effort | None (deployed with platform) | Collector configuration needed | Collector configuration needed |
| Operational overhead | Maintain the built-in stack | Maintain your own tool only | Maintain both |
| Cross-service visibility | Keymate only | All services in one place | Both views available |
| Cost | Included with platform | Your tool's licensing | Both costs |
| Migration path | Start here, add export later | Requires existing tool | Transition path between the other two |
Example Scenario
Scenario
A financial services company deploys Keymate and needs all telemetry in Splunk due to compliance requirements. Their security team monitors all production systems through Splunk dashboards and cannot accept a separate monitoring tool.
Input
- Actor: Platform Engineer
- Requirement: All Keymate telemetry must appear in Splunk
- Constraint: Compliance mandates a single monitoring platform for all production systems
Expected Outcome
- The OTel Collector is configured to export logs, metrics, and traces to Splunk
- The built-in observability stack is either disabled or kept as a secondary debugging tool
- Keymate telemetry appears alongside all other production systems in the existing Splunk dashboards
- No Keymate service was modified — only the Collector configuration changed
Common Misunderstandings
- "Export means losing data from the built-in stack." In dual-export mode, both destinations receive the same data. You lose nothing.
- "I need to configure each Keymate service for export." You configure export at the OTel Collector level, not per service. One configuration change routes all telemetry to any destination.
- "External export adds significant latency." The Collector batches and sends data asynchronously. Export performance does not affect platform services.
- "I cannot export only specific signals." You can configure the Collector to export only metrics, only traces, or any combination per destination.
Design Notes
- The OTel Collector is the only integration point between Keymate and external monitoring. This keeps the platform clean — no vendor-specific SDKs or agents are installed in any Keymate service.
- Export configuration is a deployment-time decision, not a code change. Your team switches monitoring tools as an operational task, not a development task.
- We recommend dual-export as the starting pattern for organizations with existing monitoring. It provides immediate value in both the built-in and external dashboards while keeping the option to simplify later.
If your organization requires all production telemetry in a central monitoring tool, configure export during initial deployment. This is easier than migrating later and ensures compliance from day one.