Überblick

Audit & Logging in ZeroDDS hat zwei getrennte Schichten:

• Security-Audit (DDS-Security §8.6) — diskrete Events mit Severity, Participant-GUID und Kategorie. Pflicht-Surface des Standards. Jeder Auth-Handshake-Bruch, jede Permission-Verweigerung, jede Crypto-Mismatch landet hier.
• Observability-Telemetrie (OTLP) — kontinuierliche Spans, Histogramme und Events für Performance-Tracing und SLO-Monitoring. Optional, aber empfohlen für Produktions-Deployments. Geht an OpenTelemetry-Collector (Jaeger, Tempo, Honeycomb, …).

Die zwei Schichten sind orthogonal — Security-Audit ist die compliance-relevante Stream, OTLP ist die operative Telemetrie. Beide können parallel laufen ohne Interaktion.

Spec-Coverage: DDS-Security 1.2 Coverage →

LoggingPlugin Trait

Das SPI ist minimal — eine einzige Methode:

pub trait LoggingPlugin: Send + Sync {
    fn log(
        &self,
        level: LogLevel,
        participant: [u8; 16],   // Participant-GUID-Bytes
        category: &str,         // z.B. "auth.handshake.failed"
        message: &str,          // Free-form Detail
    );
}

▶ Runnable example: rust-audit-loggingplugin

Quelle: crates/security/src/logging.rs

LogLevel-Skala (RFC 5424)

ZeroDDS folgt der RFC-5424-Severity-Skala — 8 Stufen, niedrigerer Wert = höhere Priorität:

Sinks filtern: StderrLoggingPlugin::with_level(LogLevel::Warning) verwirft alles ≥ Notice (höherer Zahlwert). Default ist Warning — Emergency..Warning passieren, Notice..Debug werden gedroppt.

Event-Kategorien

Die category-Strings sind nicht standardisiert vom OMG; ZeroDDS verwendet eine konsistente Punkt-Notation:

Konvention: <subsystem>.<action>.<outcome> — z.B. auth.handshake.failed, access.endpoint.denied, crypto.sample.mac_mismatch. Filter-tauglich für JSON-Aggregator (jq, Loki LogQL).

Audit-Sinks (zerodds-security-logging)

Vier produktionsreife LoggingPlugin-Implementations. Alle Send + Sync, alle mit konfigurierbarem min_level.

NDJSON-Format (JsonLinesLoggingPlugin)

Jede Zeile ist ein self-contained JSON-Objekt — direkt jq-/Loki-/Splunk-tauglich:

{"ts":"2026-05-15T10:22:33Z","level":"CRITICAL","participant":"0102030405060708...","category":"auth.handshake.failed","message":"cert chain rejected: untrusted root"}
{"ts":"2026-05-15T10:22:34Z","level":"NOTICE","participant":"aabbccddeeff...","category":"access.endpoint.granted","message":"writer for topic 'Telemetry'"}

Felder: ts (UTC ISO-8601), level (RFC-5424 Name uppercase), participant (Hex-encoded 16-Byte-GUID), category (Dot-Notation), message (free-form, JSON-escaped). Schema ist stabil ab v1.0 — neue Felder werden additiv hinzugefügt.

OTLP-Telemetrie (zerodds-observability-otlp)

Separater Layer für strukturierte Telemetrie — Spans, Histogramme, Events. POSTet an OTel-Collector via OTLP/HTTP (Port 4318 Default).

let cfg = OtlpConfig {
    host: "otel-collector.internal".into(),
    port: 4318,
    service_name: "zerodds-publisher".into(),
    service_version: env!("CARGO_PKG_VERSION").into(),
    timeout: Duration::from_secs(5),
};
let exporter = OtlpExporter::new(cfg);

exporter.add_span(Span { /* ... */ });
exporter.add_histogram(Histogram { /* ... */ });
exporter.add_event(Event { /* ... */ });

exporter.flush()?;  // POST an Collector

▶ Runnable example: rust-audit-otlp

API-Surface

Quelle: crates/observability-otlp/src/lib.rs

Plugin-Wiring

Das LoggingPlugin wird in der DcpsRuntimeBuilder über das Security-Bundle eingehängt:

use zerodds_security_logging::{StderrLoggingPlugin, JsonLinesLoggingPlugin, FanOutLoggingPlugin};
use zerodds_security::logging::LogLevel;

let stderr_sink = StderrLoggingPlugin::with_level(LogLevel::Warning);
let audit_sink = JsonLinesLoggingPlugin::open("/var/log/zerodds/audit.ndjson", LogLevel::Notice)?;

let fanout = FanOutLoggingPlugin::new()
    .with(stderr_sink)
    .with(audit_sink);

let security_bundle = SecurityBundle::builder()
    .logging_plugin(Box::new(fanout))
    // ... auth, access, crypto Plugins ...
    .build();

let participant = DomainParticipantFactory::create(0)
    .with_security(security_bundle)
    .build()?;

▶ Runnable example: rust-audit-factory-chain

Die Reihenfolge im Wire-Pfad: bei jedem Security-Event (in zerodds-security-runtime) wird der Plugin-Handle synchron aufgerufen. Sinks sind Send + Sync und dürfen blockieren — aber blockieren sie zu lange, blockiert der Tick. Daher: I/O-heavy Sinks (Syslog-UDP, JsonLines-File) sind OK für 100-1000 Events/s; Syslog-TCP oder OTLP-on-LoggingPlugin wären zu langsam (deswegen ist OTLP separater Layer).

Overview

Audit & logging in ZeroDDS has two separate layers:

• Security audit (DDS-Security §8.6) — discrete events with severity, participant GUID and category. The standard's mandatory surface. Every auth-handshake break, every permission denial, every crypto mismatch lands here.
• Observability telemetry (OTLP) — continuous spans, histograms and events for performance tracing and SLO monitoring. Optional, but recommended for production deployments. Goes to an OpenTelemetry collector (Jaeger, Tempo, Honeycomb, …).

The two layers are orthogonal — the security audit is the compliance-relevant stream, OTLP is operational telemetry. Both can run in parallel without interaction.

Spec coverage: DDS-Security 1.2 coverage →

LoggingPlugin trait

The SPI is minimal — a single method:

pub trait LoggingPlugin: Send + Sync {
    fn log(
        &self,
        level: LogLevel,
        participant: [u8; 16],   // participant GUID bytes
        category: &str,         // e.g. "auth.handshake.failed"
        message: &str,          // free-form detail
    );
}

▶ Runnable example: rust-audit-loggingplugin

Source: crates/security/src/logging.rs

LogLevel scale (RFC 5424)

ZeroDDS follows the RFC 5424 severity scale — 8 levels, lower value = higher priority:

Sinks filter: StderrLoggingPlugin::with_level(LogLevel::Warning) drops everything ≥ Notice (higher numeric value). The default is Warning — Emergency..Warning pass, Notice..Debug are dropped.

Event categories

The category strings are not standardised by the OMG; ZeroDDS uses a consistent dot notation:

Convention: <subsystem>.<action>.<outcome> — e.g. auth.handshake.failed, access.endpoint.denied, crypto.sample.mac_mismatch. Filterable for a JSON aggregator (jq, Loki LogQL).

Audit sinks (zerodds-security-logging)

Four production-ready LoggingPlugin implementations. All Send + Sync, all with a configurable min_level.

NDJSON format (JsonLinesLoggingPlugin)

Each line is a self-contained JSON object — directly jq/Loki/Splunk-ready:

{"ts":"2026-05-15T10:22:33Z","level":"CRITICAL","participant":"0102030405060708...","category":"auth.handshake.failed","message":"cert chain rejected: untrusted root"}
{"ts":"2026-05-15T10:22:34Z","level":"NOTICE","participant":"aabbccddeeff...","category":"access.endpoint.granted","message":"writer for topic 'Telemetry'"}

Fields: ts (UTC ISO-8601), level (RFC 5424 name uppercase), participant (hex-encoded 16-byte GUID), category (dot notation), message (free-form, JSON-escaped). The schema is stable from v1.0 — new fields are added additively.

OTLP telemetry (zerodds-observability-otlp)

A separate layer for structured telemetry — spans, histograms, events. POSTs to an OTel collector via OTLP/HTTP (port 4318 default).

let cfg = OtlpConfig {
    host: "otel-collector.internal".into(),
    port: 4318,
    service_name: "zerodds-publisher".into(),
    service_version: env!("CARGO_PKG_VERSION").into(),
    timeout: Duration::from_secs(5),
};
let exporter = OtlpExporter::new(cfg);

exporter.add_span(Span { /* ... */ });
exporter.add_histogram(Histogram { /* ... */ });
exporter.add_event(Event { /* ... */ });

exporter.flush()?;  // POST to the collector

▶ Runnable example: rust-audit-otlp

API surface

Source: crates/observability-otlp/src/lib.rs

Plugin wiring

The LoggingPlugin is hooked into the DcpsRuntimeBuilder via the security bundle:

use zerodds_security_logging::{StderrLoggingPlugin, JsonLinesLoggingPlugin, FanOutLoggingPlugin};
use zerodds_security::logging::LogLevel;

let stderr_sink = StderrLoggingPlugin::with_level(LogLevel::Warning);
let audit_sink = JsonLinesLoggingPlugin::open("/var/log/zerodds/audit.ndjson", LogLevel::Notice)?;

let fanout = FanOutLoggingPlugin::new()
    .with(stderr_sink)
    .with(audit_sink);

let security_bundle = SecurityBundle::builder()
    .logging_plugin(Box::new(fanout))
    // ... auth, access, crypto plugins ...
    .build();

let participant = DomainParticipantFactory::create(0)
    .with_security(security_bundle)
    .build()?;

▶ Runnable example: rust-audit-factory-chain

The order in the wire path: on every security event (in zerodds-security-runtime) the plugin handle is called synchronously. Sinks are Send + Sync and may block — but if they block too long, the tick blocks. So: I/O-heavy sinks (syslog UDP, JsonLines file) are OK for 100-1000 events/s; syslog TCP or OTLP-on-LoggingPlugin would be too slow (which is why OTLP is a separate layer).