Telemetrie aus AWS, Azure und Google Cloud

Kurzfassung

• Jede grosse Cloud bietet dieselben drei Wege, Telemetrie herauszuholen: Pull (die Monitoring-API abfragen), Push (über einen Bus wie Event Hubs, Firehose oder Pub/Sub streamen) und Storage (in einen Bucket exportieren).
• Pull passt zu Metriken. Push passt zu Logs und Events in grossen Mengen. Storage passt zu Archiv und Bulk. Die meisten realen Setups holen Metriken per Pull und Logs per Push.
• Ein Standard-otelcol-contrib hat für die meisten dieser Wege einen Receiver. Wir haben jeden Namen gegen das Release v0.153.0 geprüft.
• Die Azure-Wege haben wir in einem Labor Ende zu Ende betrieben. AWS und Google Cloud beschreiben wir anhand der Dokumentation der Anbieter und der Receiver, nicht anhand eigener Läufe.

Die Frage kommt auf, sobald ein Team Workloads in mehr als einer Cloud betreibt: Wie holen wir die Telemetrie heraus, und an einen Ort? Die drei Clouds benennen alles anders, aber die Antwort hat jedes Mal dieselbe Form. Dieser Beitrag zeigt diese Form, was jeder Weg Sie kostet und welcher OpenTelemetry-Collector-Receiver passt.

Die drei Wege nach draussen

Abbildung 1. Drei Wege aus jeder Cloud, ein Collector. Die Herstellersymbole sind die unveränderten offiziellen Icon-Sets der jeweiligen Anbieter.

Lesen Sie die Matrix zeilenweise. Jede Zeile ist ein Weg, Daten herauszuholen, jede Spalte zeigt, wo dieser Weg in einer Cloud liegt.

Pull: die Monitoring-API abfragen

Der Collector fragt die Monitoring-API der Cloud in festen Abständen nach Zahlen. So reisen Metriken meistens, denn die Clouds speichern sie bereits in einem Zeitreihendienst und bieten dafür eine API: Azure Monitor, Amazon CloudWatch und Google Cloud Monitoring.

Sie bekommen eine einfache Einrichtung: einen Zugang, der Metriken lesen darf, und auf Cloud-Seite nichts zu bauen. Sie bezahlen mit der Form der API:

• Ein Raster von einer Minute. Azure erfasst Plattformmetriken im Minutentakt, sofern die Metrik nichts anderes vorgibt, und CloudWatch hält Datenpunkte im Minutenraster 15 Tage vor.
• Ratenlimits und Kosten pro Aufruf. CloudWatch-API-Aufrufe werden berechnet, GetMetricData hat dabei eine eigene Preisstruktur, und ein Aufruf kann höchstens 500 Metriken abfragen. Azure bietet eine Batch-Metrik-API für bis zu 50 Ressourcen-IDs pro Aufruf, gedacht für grosse Abfragen und um das Risiko von Drosselung zu senken.
• Sie legen den Umfang fest. Der Azure-Monitor-Receiver nimmt Subscription-IDs und optionale Filter nach Ressourcengruppe, Tag und Dienst, Sie entscheiden also, was abgefragt wird.

Unser Azure-Labor nutzte diesen Weg für die Metriken eines Event-Hubs-Namespace und eines Key Vaults, mit einem Service Principal, der nur die Rolle Monitoring Reader besitzt.

Push: über einen Bus streamen

Die Cloud sendet Events an einen Bus, und der Collector liest davon. So reisen Logs meistens, denn Logs sind Events, und das Volumen kann hoch sein:

• Azure: Eine Diagnoseeinstellung streamt Ressourcen-Logs, das Aktivitätsprotokoll und Plattformmetriken in Event Hubs. Jede Ressource kann bis zu fünf Einstellungen haben, und eine Einstellung enthält höchstens ein Ziel je Typ. Die Richtlinie einer Diagnoseeinstellung braucht Manage, Send und Listen. Geben Sie Ihrem Collector eine eigene Richtlinie, die nur lesen darf.
• AWS: CloudWatch-Logs-Subscription-Filter liefern einen Near-Real-Time-Feed an Kinesis Data Streams, Amazon Data Firehose oder Lambda, in der Regel in weniger als drei Minuten. Metric Streams senden Metriken über Firehose im JSON- oder OpenTelemetry-Format.
• Google Cloud: Eine Log-Router-Senke leitet Log-Einträge in ein Pub/Sub-Topic.

Sie bekommen ereignisgesteuerte Lieferung, die mit Volumen umgehen kann. Sie schulden Zustand und Sorgfalt:

• Eine Leseposition, die Neustarts übersteht. Ohne Checkpoint kann ein neu startender Collector überspringen, was in der Zwischenzeit eintraf. Wir haben das an Azure gemessen: Sechs Events, die vor dem Start des Receivers veröffentlicht wurden, wurden nie gelesen. Der Entra-Beitrag zeigt die Lösung.
• Duplikate. CloudWatch-Logs-Subscriptions liefern mindestens einmal, gelegentlich können daher Duplikate auftreten.
• Erreichbarkeit. Firehose liefert an einen HTTPS-Endpunkt auf Port 443, der Receiver des Collectors muss also von AWS aus erreichbar sein. Die Dokumentation des Receivers schlägt einen Load Balancer vor, wenn Sie einen anderen Port brauchen.
• Verzögerung. In unserem Azure-Labor erschienen Key-Vault-Events nach etwa zwei Minuten und Entra-Audit-Logs nach fünf bis fünfzehn.

Storage: exportieren und im Batch einsammeln

Die Cloud schreibt Daten in einen Bucket, und der Collector liest die Dateien. Dieser Weg ist für Archiv, Replay und Bulk-Ladungen da, nicht für Echtzeit. Azure-Diagnoseeinstellungen können in ein Standard-Speicherkonto schreiben. CloudWatch Logs lassen sich nach S3 exportieren, ein Exportauftrag kann von wenigen Sekunden bis zu mehreren Stunden dauern. Eine Google-Cloud-Log-Router-Senke nach Cloud Storage wird stündlich verarbeitet, und eine neue Senke kann mehrere Stunden brauchen, bis sie zu routen beginnt.

Brauchen Sie auch frische Daten, kombinieren Sie einen Storage-Weg mit einem Push- oder Pull-Weg.

Abbildung 2. Was jeder Weg Sie kostet. Die Latenzangabe stammt nur aus unserem Azure-Labor.

Welcher Receiver für welchen Weg

Alle gehören zu otelcol-contrib. Wir haben jeden Namen am 2026-11-07 gegen das Release v0.153.0 geprüft. Die Stabilität entspricht der Angabe in der eigenen Dokumentation der Komponente.

• Azure Pull: azure_monitor (alpha, Metriken).
• Azure Push: azure_event_hub (beta, Logs, Metriken und Traces).
• Azure Storage: azure_blob (alpha, Logs und Traces).
• AWS Pull: awscloudwatch (alpha). Die Dokumentation beschreibt das Lesen von CloudWatch Logs über das AWS SDK. Prüfen Sie die aktuelle Dokumentation, bevor Sie sich für CloudWatch-Metriken darauf verlassen.
• AWS Push: awsfirehose (alpha, Logs und Metriken), der auch CloudWatch Metric Streams dekodiert.
• AWS Storage: awss3 (alpha, Logs, Metriken und Traces), im zeitbasierten oder ereignisgesteuerten Modus.
• Google Cloud Pull: googlecloudmonitoring (alpha, Metriken).
• Google Cloud Push: googlecloudpubsub (beta, Logs, Metriken und Traces).
• Google Cloud Storage: Wir haben im Contrib-Repository keinen Receiver für Cloud Storage gefunden.

Manche Namen ändern sich mit der Reife der Receiver. Auf dem Entwicklungszweig heissen awscloudwatch und awss3 bereits aws_cloudwatch und aws_s3, prüfen Sie also die Komponentenliste des Releases, das Sie betreiben.

Wo soll der Collector laufen?

Hinter der ersten Frage steckt eine zweite: Erfassen Sie alles in einer zentralen Plattform, oder erfassen Sie innerhalb des Tenants jedes Kunden oder jeder Geschäftseinheit?

Abbildung 3. Ein Ort zum Hinschauen oder Daten, die den Tenant nie verlassen.

Zentrale Erfassung gibt Ihnen eine einheitliche Sicht und eine Plattform zu betreiben. Sie bedeutet aber auch, dass Daten den Tenant verlassen. Erfassung im Tenant hält die Daten dort, wo sie sind, zum Preis von mehr Plattformen und standardmässig ohne einheitliche Sicht. Ein verbreiteter Mittelweg ist, lokal zu erfassen und nur eine gefilterte Teilmenge weiterzuschicken. Die obigen Wege funktionieren in beiden Fällen gleich: Nur der Ort, an dem der Collector läuft, ändert sich.

Was wir belegt haben und was nicht

• Von uns belegt: Azure Event Hubs mit azure_event_hub und Azure Monitor mit azure_monitor, in einem Labor am 2026-11-07, beschrieben im Entra-ID-Beitrag.
• Dokumentiert, nicht von uns betrieben: jeder AWS- und Google-Cloud-Weg in diesem Beitrag sowie der Azure-Storage-Weg.
• Nicht behauptet: LinkMesh-Unterstützung für die Erfassung aus AWS oder Google Cloud. LinkMesh verwaltet Collector-Konfiguration, und heute kommen die Azure-Receiver als eigene Source-Blöcke hinein. Für die anderen beiden Clouds haben wir nichts gebaut.

Wenn Sie schon Collectors betreiben und sehen möchten, wie sich Ihre Konfiguration über eine Flotte verwalten lässt, installieren Sie LinkMesh. Wenn Sie mit Azure beginnen, enthält der Entra-ID-Beitrag eine Konfiguration, die funktioniert.