Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

feat(observability): define gateway-to-exporter extension contract

Offen
#3,224 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
30/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Aktiv
Bereich
observability

Rechercherichtung

Es werden keine Implementierungsdateien, Tests oder Einstiegspunkte genannt. Beginne mit der Durchsicht der Architekturdokumentation und der zugehörigen Issues #1055, #2745 und #2762; abgeschlossen bedeutet ein vereinbarter, dokumentierter gateway-to-exporter-Vertrag, der Datensätze, Lücken, Isolation, Installation, Konfiguration und Health Checks abdeckt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

state:triage-needed
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
  • I've reviewed existing issues and the architecture docs
  • This is a design proposal, not a "please build this" request
Vorherrschende Sprache
Rust
Sterne
15.4k
Forks
1.7k
Ø Merge
1 T. 19 Std.
Gemergte PRs (30 T.)
347

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus NVIDIA/OpenShell

Alle Issues in NVIDIA/OpenShell

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.