Integration · Rust

Rust Monitoring mit OpenTelemetry

Verbinden Sie das tracing-Crate mit OpenTelemetry, und Obseria zeigt Spans, Metriken und Logs Ihrer Rust-Services per OTLP, korreliert mit CPU-Profilen, Infrastruktur und allen Aufrufern.
Kostenlos testenDemo anfordern
Obseria Apps und Funktionen: Observability, APM, Infrastruktur und Integrationen
Obseria Home-Dashboard mit Service-Zustand, offenen Problemen, SLO-Erfüllung und Ingestion
Obseria Trace-Explorer mit Span-Liste und Span-Attributen
Überblick

Warum Rust mit Obseria überwachen

tracing-Crate behalten

tracing-opentelemetry macht aus Ihren bestehenden Spans und #[instrument]-Attributen OpenTelemetry-Traces, ohne die Instrumentierung neu zu schreiben.

Standard-Export per OTLP

Das Crate opentelemetry-otlp sendet Traces, Metriken und Logs per HTTP oder gRPC an Obseria, ohne herstellerspezifisches Crate.

Profile für heiße Pfade

Continuous Profiling mit unter 1 % Overhead zeigt, welche Funktionen in Produktion CPU verbrauchen, direkt neben den betroffenen Traces.

Abdeckung

Rust-Crates und Runtimes, die Obseria überwacht

  • tracing und tracing-opentelemetry. Spans aus #[instrument] und tracing-Makros werden als OpenTelemetry-Spans exportiert, Felder als Attribute.
  • Services auf Basis von Tokio. Async-Tasks behalten ihren Span-Kontext über .await hinweg, nebenläufige Arbeit landet im richtigen Trace.
  • Axum, Actix Web und Tower-Middleware. HTTP-Server erhalten über tracing-fähige Middleware einen Span pro Request mit Route und Statuscode.
  • Reqwest, Tonic und weitere Clients. Ausgehende HTTP- und gRPC-Aufrufe können den W3C-Trace-Kontext übertragen und Rust mit Services anderer Sprachen verbinden.
  • SQLx-, Diesel- und Redis-Clients. In Spans gekapselte Datenbank- und Cache-Aufrufe zeigen Query-Dauer und Fehler.
  • Logs über opentelemetry-appender-tracing. tracing-Events werden als OpenTelemetry-Logs exportiert und mit dem aktiven Trace verknüpft.
Auf einen Blick

Die Rust-Kennzahlen, auf die es ankommt

Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.

Tempo und Nachfrage

Zeigt, wie schnell Ihre Rust-Dienste antworten und wie viele Anfragen sie gleichzeitig bearbeiten.

  • http.server.request.duration
  • http.server.active_requests

Tempo externer Dienste

Zeigt, wie lange Ihre Anwendung auf Datenbanken und andere Dienste wartet, und deckt langsame externe Abhängigkeiten auf.

  • http.client.request.duration
  • db.client.operation.duration

Rechenleistung und Speicher

Macht sichtbar, wie viel Rechenleistung und Speicher die Anwendung benötigt, als Grundlage für passende Server und Kostenkontrolle.

  • process.cpu.utilization
  • process.memory.usage

Interne Ordnung

Zeigt, wie viele Threads und offene Verbindungen die Anwendung hält, damit schleichende Lecks vor einem Ausfall auffallen.

  • process.threads
  • process.open_file_descriptors
Alle 8 Metriken im Detail anzeigen
MetrikEinheitAussage
http.server.request.durationsLatenz-Histogramm eingehender HTTP-Requests je Route und Statuscode.
http.server.active_requests{request}Laufende Requests; Wachstum bei gleichem Durchsatz heißt, Tasks hängen fest.
http.client.request.durationsLatenz ausgehender HTTP-Aufrufe an nachgelagerte Dienste.
db.client.operation.durationsDauer von Datenbankoperationen, um langsame Queries zu finden.
process.cpu.utilization1CPU-Anteil des Rust-Prozesses, erfasst vom hostmetrics-Receiver des Collectors.
process.memory.usageByResident Memory des Prozesses; stetiges Wachstum deutet auf ein Leak oder einen unbegrenzten Cache.
process.threads{thread}OS-Threads des Prozesses, einschließlich Tokio-Worker- und Blocking-Threads.
process.open_file_descriptors{count}Offene File Descriptors; steigende Werte zeigen nicht geschlossene Sockets oder Dateien.
Einrichtung

Rust-Monitoring in wenigen Minuten einrichten

  1. Schritt 1

    Crates hinzufügen

    Ergänzen Sie opentelemetry, opentelemetry_sdk, opentelemetry-otlp und tracing-opentelemetry in zueinander passenden Versionen in der Cargo.toml.

  2. Schritt 2

    Layer registrieren

    Erstellen Sie einen SdkTracerProvider mit OTLP-Exporter und registrieren Sie tracing_opentelemetry::layer() in Ihrem tracing-Subscriber.

  3. Schritt 3

    Auf Obseria zeigen

    Setzen Sie OTEL_SERVICE_NAME, den OTLP-Endpoint von Obseria und Ihr Token; der Obseria Agent ergänzt Prozess- und Host-Metriken.

Beispielkonfiguration · RUST
// Cargo.toml: opentelemetry = "0.33", opentelemetry_sdk = "0.33",
//   opentelemetry-otlp = { version = "0.33", features = ["http-proto", "reqwest-blocking-client"] },
//   tracing = "0.1", tracing-subscriber = "0.3", tracing-opentelemetry = "0.34"
use opentelemetry::trace::TracerProvider as _;
use opentelemetry_otlp::SpanExporter;
use opentelemetry_sdk::{trace::SdkTracerProvider, Resource};
use tracing_subscriber::prelude::*;

// OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT und OTEL_EXPORTER_OTLP_HEADERS
// (Authorization=Bearer%20${OBSERIA_TOKEN}) werden aus der Umgebung gelesen.
fn init_tracing() -> SdkTracerProvider {
    let exporter = SpanExporter::builder()
        .with_http()
        .build()
        .expect("failed to create OTLP exporter");
    let provider = SdkTracerProvider::builder()
        .with_batch_exporter(exporter)
        .with_resource(Resource::builder().build())
        .build();
    tracing_subscriber::registry()
        .with(tracing_opentelemetry::layer().with_tracer(provider.tracer("orders-api")))
        .with(tracing_subscriber::fmt::layer())
        .init();
    provider // vor dem Beenden provider.shutdown() aufrufen
}

Sofort einsatzbereit

Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.

  • Rust-Service-Health mit RED-Metriken je Route
  • Prozessansicht: CPU, Speicher, Threads, File Descriptors
  • Alert auf p99-Latenz je Endpoint
  • Alert bei stetig steigendem Prozessspeicher
  • Langsamste Datenbank- und Downstream-Aufrufe
Leitfaden

Rust-Monitoring: Darauf kommt es an

Warum Rust Monitoring wichtig ist

Teams setzen Rust für performancekritische Services ein: Proxys, Datenpipelines, Handels- und Zahlungssysteme und Backends, in denen Speichersicherheit und vorhersagbare Latenz zählen. Der Compiler verhindert ganze Fehlerklassen, verrät aber nicht, wie sich ein Service unter Produktionslast verhält. Async-Tasks können die Tokio-Runtime blockieren, ein nachgelagerter Dienst kann langsamer werden, und Caches können unbegrenzt wachsen. Rust Monitoring liefert Traces, Metriken und Logs, um zu sehen, wohin Zeit und Ressourcen fließen.

Im Rust-Ökosystem gibt es eine etablierte Konvention für Instrumentierung: das Crate tracing. Viele Bibliotheken erzeugen darüber bereits Spans und Events. Der Layer tracing-opentelemetry wandelt sie in OpenTelemetry-Spans um, und opentelemetry-otlp exportiert sie an jedes OTLP-Backend. Laut OpenTelemetry-Projekt sind Metriken und Logs für Rust stabil, Traces gelten noch als Beta. Rechnen Sie daher mit gelegentlichen API-Änderungen zwischen Minor-Releases und fixieren Sie zueinander passende Crate-Versionen.

Die wichtigsten Signale für Rust Performance Monitoring

  • Latenz und Fehler: http.server.request.duration je Route und Fehler-Spans liefern die RED-Sicht je Service. Erfassen Sie die Metrik über Metrik-Middleware oder eigene Instrumente nach den Semantic Conventions.
  • Nebenläufigkeit: Steigt http.server.active_requests bei gleichbleibendem Durchsatz, warten Tasks auf Locks, Pools oder langsame Abhängigkeiten.
  • Abhängigkeiten: http.client.request.duration und db.client.operation.duration zeigen, wie viel Latenz aus anderen Systemen stammt.
  • Prozessressourcen: process.cpu.utilization, process.memory.usage, process.threads und process.open_file_descriptors liefern der hostmetrics-Receiver des Collectors oder der Obseria Agent, ganz ohne Code.

Rust kennt keinen Runtime-Agent und keine Bytecode-Injektion. Die Abdeckung hängt deshalb davon ab, welche Crates tracing-Spans erzeugen und wo Sie #[instrument] ergänzen. Beginnen Sie an den Rändern, also bei eingehenden Requests und ausgehenden Aufrufen, und ergänzen Sie Spans im Service dort, wo die Latenz unklar ist.

Typische Performance-Probleme in Rust erkennen

Blockierte Async-Runtime

Synchrone I/O oder aufwendige Berechnungen in einem Async-Task legen einen Tokio-Worker-Thread lahm und verzögern alle anderen Tasks darauf. Traces zeigen unerklärliche Lücken zwischen Spans, CPU-Profile die blockierende Funktion. Verlagern Sie solche Arbeit nach spawn_blocking oder in einen eigenen Pool.

Unbegrenztes Speicherwachstum

Caches ohne Eviction, wachsende Channels oder verwaiste Tasks lassen den Resident Memory über die Zeit steigen. Ein Trend-Alert auf den Prozessspeicher erkennt das Problem, bevor der Container beendet wird.

Lock-Contention

Ein gemeinsam genutzter Mutex auf einem heißen Pfad serialisiert Requests. Aktive Requests steigen, die Latenz wächst, die CPU-Last bleibt moderat. Spans um kritische Abschnitte machen die Wartezeit sichtbar.

Langsame Abhängigkeiten

Fehlende Timeouts bei HTTP- oder Datenbank-Clients lassen langsame Aufrufe sich stauen. Client-Spans mit hoher Latenz benennen die Abhängigkeit sofort.

Zu viele Span-Daten

Wer jede kleine Funktion instrumentiert, erzeugt große Traces und hohes Ingest-Volumen, ohne mehr zu erkennen. Beobachten Sie die Zahl der Spans je Trace und belassen Sie detaillierte Spans auf Debug-Level, das Sie nur dort aktivieren, wo Sie gerade untersuchen. So bleiben Traces lesbar und Kosten planbar.

Best Practices für Rust Observability

  1. Fixieren Sie opentelemetry, opentelemetry_sdk, opentelemetry-otlp und tracing-opentelemetry auf gemeinsam veröffentlichte Versionen.
  2. Nutzen Sie #[instrument(skip(...))], um große oder sensible Argumente nicht zu erfassen, und maskieren Sie verbleibende personenbezogene Daten in Obseria Pipeline.
  3. Setzen Sie service.name, service.version und deployment.environment.name per Umgebungsvariable.
  4. Rufen Sie vor dem Beenden shutdown() auf den Providern auf, damit gebündelte Spans übertragen werden.
  5. Übertragen Sie den W3C-Trace-Kontext bei jedem ausgehenden Aufruf, um Rust mit Services anderer Sprachen zu verbinden.

So unterstützt Obseria Rust Monitoring

Obseria nimmt Traces, Metriken und Logs aus dem OpenTelemetry Rust SDK per OTLP entgegen; Sie nutzen ausschließlich Standard-Crates. Der Obseria Agent ergänzt Prozess-, Host- und Kubernetes-Metriken sowie Continuous Profiling mit unter 1 % Overhead. TopoGraph ordnet jeden Rust-Service in die Abhängigkeitskarte neben Services in Java, Go oder Python ein. Steigt die Latenz, korreliert Obseria Intelligence langsame Spans, Ressourcentrends und Deployments und präsentiert die Ursache mit nachvollziehbarer Beweiskette. Dashboards, Alerts und SLOs sind inklusive.

Verwandte Integrationen

GoGo MonitoringApache KafkaApache Kafka MonitoringPostgreSQLPostgreSQL Monitoring
Alle Integrationen

Passende Funktionen

Distributed Tracing

Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.

Mehr erfahren

Continuous Profiling

Dauerhaftes Continuous Profiling zeigt, welche Funktionen in Produktion CPU, Speicher und Locks beanspruchen, mit unter 1 % Overhead und Verknüpfung zu Traces.

Mehr erfahren

Fehler-Tracking

Die Errors Inbox gruppiert Exceptions aus Backend, Frontend und Mobile Apps zu Issues, zeigt deren Auswirkung und bündelt Zuweisung und Lösung in einem Workflow.

Mehr erfahren
Teil von Application Observability

Mehr erfahren

Was ist OpenTelemetry?

Was ist OpenTelemetry? So erzeugen API, SDKs, Collector, OTLP und Semantic Conventions herstellerneutrale Traces, Metriken, Logs und Profile.

Was ist APM (Application Performance Monitoring)?

Was ist APM? Wie Application Performance Monitoring Latenz, Durchsatz und Fehler misst, wie Distributed Tracing funktioniert und welche Kennzahlen zählen.

Häufige Fragen zum Rust-Monitoring

Viele Teams setzen es produktiv ein. Das OpenTelemetry-Projekt führt Metriken und Logs für Rust als stabil, Traces als Beta; APIs können sich zwischen Minor-Versionen also noch ändern. Fixieren Sie passende Crate-Versionen und lesen Sie bei Upgrades die Release Notes.

Nein. tracing-opentelemetry ist ein Layer für tracing-subscriber. Bestehende Spans und #[instrument]-Attribute werden als OpenTelemetry-Spans exportiert, die Konsolenausgabe kann bleiben, wie sie ist.

Rust hat keinen Runtime-Agent wie Java oder Python. Die Instrumentierung entsteht durch Crates, die tracing-Spans erzeugen, und wenige Zeilen Setup. Prozess- und Host-Metriken erfasst der Obseria Agent ohne Codeänderung.

Mit opentelemetry-appender-tracing senden Sie tracing-Events als OpenTelemetry-Logs per OTLP. Sie tragen Trace- und Span-ID des aktiven Spans, Logs und Traces sind in Obseria daher verknüpft.

Ja. Installieren Sie den Obseria Agent per Helm als DaemonSet und setzen Sie die OTEL_*-Variablen in der Pod-Spezifikation. Traces werden mit Pod-, Namespace- und Node-Metadaten angereichert.

Starten Sie heute mit dem Rust-Monitoring

Binden Sie Rust in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.

Kostenlos testenVertrieb kontaktieren