User Story
As an OpenShell operator, I want a simple, supported way to send observability data to my existing tools without assembling separate collectors.
Problem Statement
The observability work under #1055 needs a shared boundary between OpenShell producing authoritative records and an exporter processing them for customer destinations.
Impact / Why This Matters
Destination-specific formats, credentials, storage, queues, and retries add work and dependencies to the gateway. An external exporter can handle that work and scale independently. The gateway still carries collection and relay costs.
Proposed Design
Supervisor → Gateway → External exporter → Customer tools
- Supervisor: emit structured signals and source-health information through its existing authenticated gateway connection. No additional exporter connection or heavy export processing.
- Gateway: expose an authenticated, read-only, scoped source that preserves native records, authoritative identity and context, and reports known gaps and recovery limits. Keep telemetry resource use bounded.
- Exporter: handle destination-specific transformations, additional redaction, buffering, retries, and delivery outside the gateway.
Make this a first-class integration with one documented installation, configuration, and health-check workflow. Operators should not need to assemble multiple collectors.
Operational delivery and optional evidence processing can be functions within the same exporter deployment. Ordinary observability must not require evidence infrastructure; detailed evidence behavior remains in #2745.
This proposal defines the shared integration boundary for work such as #2762. Transport and storage choices remain open.
Acceptance Criteria
- Structured records reach a configured destination without parsing human-readable shorthand.
- Recovery limits and known gaps are visible.
- Slow exporters or destinations do not block gateway control operations or sandbox enforcement.
- Installation, configuration, and health checks follow one supported workflow.
Alternatives Considered
Gateway-owned destination integrations reduce deployment components but expand gateway responsibilities. Independent collectors leave operators assembling the integration themselves.
Checklist
User Story
As an OpenShell operator, I want a simple, supported way to send observability data to my existing tools without assembling separate collectors.
Problem Statement
The observability work under #1055 needs a shared boundary between OpenShell producing authoritative records and an exporter processing them for customer destinations.
Impact / Why This Matters
Destination-specific formats, credentials, storage, queues, and retries add work and dependencies to the gateway. An external exporter can handle that work and scale independently. The gateway still carries collection and relay costs.
Proposed Design
Supervisor → Gateway → External exporter → Customer tools
Make this a first-class integration with one documented installation, configuration, and health-check workflow. Operators should not need to assemble multiple collectors.
Operational delivery and optional evidence processing can be functions within the same exporter deployment. Ordinary observability must not require evidence infrastructure; detailed evidence behavior remains in #2745.
This proposal defines the shared integration boundary for work such as #2762. Transport and storage choices remain open.
Acceptance Criteria
Alternatives Considered
Gateway-owned destination integrations reduce deployment components but expand gateway responsibilities. Independent collectors leave operators assembling the integration themselves.
Checklist