Zum Inhalt springen

FAQ

Zuletzt aktualisiert am

  • Allgemein

    Was ist der Telemetry Router?

    Der STACKIT Telemetry Router und seine Komponenten dienen dazu, Telemetriedaten zu erfassen und zu verteilen. Ein Telemetry Link verbindet den Telemetry Router mit Ihren Cloud-Ressourcen, um automatisch standardisierte Datenströme zu erfassen. Sie haben die volle Kontrolle darüber, diesen einheitlichen Datenstrom an interne STACKIT-Dienste oder externe, mit OpenTelemetry oder S3 kompatible Ziele weiterzuleiten.

    Eine Schritt-für-Schritt-Anleitung zur Einrichtung finden Sie unter Telemetry Router-Instanzen erstellen und verwalten.

    Warum heißt es "Telemetry Router", wenn es aktuell nur Audit Logs verarbeitet?

    Der Name spiegelt die langfristige Ausrichtung des Produkts wider. Die aktuelle Version verarbeitet ausschließlich Audit Logs, der Telemetry Router ist jedoch so konzipiert, dass er in zukünftigen Releases weitere Observability-Signale wie Service Logs und Metriken unterstützen wird.

    Was ist der Unterschied zwischen einem Telemetry Router und einem Telemetry Link?

    Der Telemetry Router ist die Komponente, die Telemetriedaten empfängt, filtert und weiterleitet. Er lässt sich eigenständig verwalten, und um Daten an seinem Endpunkt einzuspeisen, ist ein eigener Access Token erforderlich.

    Der Telemetry Link verbindet den Router mit Ihren Cloud-Ressourcen auf einer bestimmten Hierarchieebene (Organisation, Ordner oder Projekt) und erfasst den Datenstrom. Für die Konfiguration eines Links werden die ID und der Access Token eines bestehenden Routers benötigt. Telemetry Links sind zwingend erforderlich, um Logs in jedem Fall an Ihren Telemetry Router weiterzuleiten.

    Ein einzelner Router stellt für sich allein nicht sicher, dass STACKIT-interne Logs an die konfigurierten Ziele weitergeleitet werden.

    Kann ein Telemetry Router auf Ordner- oder Organisationsebene erstellt werden?

    Nein. Aus technischen Gründen muss ein Telemetry Router immer innerhalb eines Projekts erstellt werden. Um zusätzlich Daten auf Ordner- oder Organisationsebene zu erfassen, erstellen Sie separate Telemetry Links auf diesen Ebenen, die alle auf denselben Router in einem Projekt verweisen.

    Welche Datenformate und Protokolle unterstützt der Telemetry Router?

    Der Telemetry Router unterstützt zwei Arten von Zielen: einen mit dem OpenTelemetry Protocol (OTLP) kompatiblen Endpunkt oder ein S3-kompatibles Ziel wie STACKIT Object Storage. Stellen Sie sicher, dass Ihr Zielsystem oder Ihre Integrationsskripte mit einem dieser beiden Formate kompatibel sind.

    Wohin kann ich meine Audit-Daten mit STACKIT Telemetry Router senden?

    Der STACKIT Telemetry Router bietet flexibles Routing. Sie können Audit-Daten an STACKIT-Dienste (wie Observability, Logs oder Object Storage) oder an externe Ziele (wie Ihre eigene SIEM-Lösung oder Storage von Drittanbietern) senden. So behalten Sie die volle Kontrolle darüber, wo Ihre Daten landen.

    Welches Format haben die Access Tokens des Telemetry Routers?

    Access Tokens sind JSON Web Tokens (JWT) und werden benötigt, um mit dem Endpunkt eines Telemetry Routers zu interagieren.

  • Architektur und Einrichtung

    Sollte ich einen zentralen Telemetry Router verwenden oder einen Router pro Projekt einrichten?

    Wir empfehlen einen einzigen, zentralen Telemetry Router in einem Kernprojekt, der über Telemetry Links aus Ihren anderen Projekten gespeist wird. Ein Router pro Projekt ist nicht notwendig. Zwei Dinge sollten Sie dabei beachten:

    • Ein Telemetry Link kann nur auf einen Router in derselben Region verweisen. Wenn Sie in mehreren Regionen aktiv sind, benötigen Sie einen Router pro Region.
    • Links vererben sich nicht über Hierarchieebenen hinweg: Jeder Link erfasst nur Daten der eigenen Ebene (Organisation, Ordner oder Projekt). Um alles in Ihrer Organisation zu erfassen, benötigen Sie auf jeder relevanten Ebene einen Link, der auf den zentralen Router verweist.

    Kann ich mehr als einen Telemetry Link für dieselbe Organisation, denselben Ordner oder dasselbe Projekt erstellen?

    Nein. Jedes Hierarchieobjekt kann jeweils nur mit einem Telemetry Router verbunden werden. Das gilt unabhängig davon, ob Sie das Portal, die API oder Terraform verwenden (ab Provider-Version v0.105.0). Beim Versuch, ein Duplikat zu erstellen, erhalten Sie stets eine eindeutige Fehlermeldung.

    Unterstützt der Telemetry Router Traces und Metriken, oder nur Logs?

    Aktuell werden ausschließlich Logs unterstützt, genauer gesagt interne Audit Logs. Die Weiterleitung von Traces und Metriken, einschließlich der Umwandlung von Traces in Metriken über Connectors wie den OpenTelemetry SpanMetrics-Connector, ist noch nicht verfügbar.

    Kann ich Labels und Attribute von Audit Logs auf Router- oder Link-Ebene hinzufügen, umbenennen oder transformieren?

    Nein. Audit-Logs werden in einem festen OpenTelemetry-Schema ausgegeben und können weder auf Router- noch auf Link-Ebene neu gelabelt werden. Die einzige konfigurierbare Verarbeitung ist ein Filter, mit dem Sie Datensätze anhand von Attributen auf resource-, scope- oder logRecord-Ebene ein- oder ausschließen können. Damit steuern Sie, was weitergeleitet wird, nicht wie es gelabelt ist. Filter-Ausdrücke verwenden den Operator = (entspricht) oder != (schließt aus) gegen ein reines Array von String-Werten, nicht gegen reguläre Ausdrücke. Falls Sie ein Relabeling benötigen, führen Sie dieses nachgelagert an Ihrem Ziel durch (z. B. Splunk, Elasticsearch).

  • Datenabdeckung und Datenschutz

    Warum sehe ich keine Audit-Events für Logins, IAM-Änderungen oder andere STACKIT-Dienste an meinem Ziel?

    Noch nicht alle STACKIT-Dienste senden Audit-Events an den Telemetry Router. Die Abdeckung wird schrittweise pro Dienst erweitert, sobald dieser die allgemeine Verfügbarkeit (General Availability, GA) erreicht; Dienste, die sich noch in der Preview-Phase befinden, erscheinen noch nicht. Die aktuelle Liste der integrierten Dienste finden Sie in der Audit Log-Dokumentation.

    Protokolliert der Telemetry Router Zugriffe auf Object Storage (S3)-Daten, wie GET/PUT-Requests?

    Derzeit protokolliert der Router noch keine Zugriffe auf Object Storage (S3)-Daten. Er protokolliert Vorgänge der Object Storage Management API, zum Beispiel die Erstellung von S3-Credentials, jedoch nicht die eigentlichen Datenzugriffe (GET/PUT auf Objekte). Diese Funktion ist für ein zukünftiges Release geplant. Falls Ihr Sicherheitskonzept ein Audit-Trail für Uploads und Downloads erfordert, implementieren Sie dieses Logging in der Zwischenzeit in Ihrer eigenen Anwendung.

    Warum zeigen Service-Account-Erstellungs-/Löschereignisse nicht die Email-Adresse des Initiators, im Gegensatz zu Sign-in-Events?

    Das ist beabsichtigt. Sign-in-Events enthalten das Attribut stackit.initiator.email, Service-Account-Lifecycle-Events lassen direkte personenbezogene Identifikatoren jedoch aus Datenschutz- und Anonymisierungsgründen weg; stattdessen sehen Sie die stackit.initiator-UUID. Eine Email-basierte Zuordnung für SIEM-Zwecke wird als Feature Request für ein zukünftiges Release geführt.

  • Ziele und Konfiguration

    Kann ich Daten von einem einzelnen Telemetry Router an mehrere Ziele senden?

    Ja. Sie können mehrere Ziele pro Router konfigurieren, die jeweils unabhängig voneinander als OTLP oder S3 eingerichtet werden. Die vom Router erfassten Daten werden parallel an alle konfigurierten Ziele weitergeleitet, nicht nur an eines.

    Welche Authentifizierungsmethoden werden für OTLP-Ziele unterstützt?

    Der Telemetry Router unterstützt entweder Basic Auth oder Token Auth (Bearer Token), je nachdem, was Ihr Zielendpunkt erfordert.

    Wie konfiguriere ich ein Ziel, das Logs an eine STACKIT Observability-Instanz weiterleitet?

    Sie benötigen die OTLP-Ingest-URL sowie die Zugangsdaten Ihrer Observability-Instanz, beide finden Sie im Portal:

    • URL: Observability → [gewünschte Instanz auswählen] → API → Information → OTLP Ingest (Logs müssen für diese Instanz aktiviert sein)
    • Zugangsdaten: Observability → [gewünschte Instanz auswählen] → API → Credentials → Create Credentials

    Welchen URL-Pfad sollte ich bei der Konfiguration eines benutzerdefinierten OTLP-Ziels verwenden?

    Die Ziel-URI muss den vollständigen OTLP-konformen Pfad für Logs enthalten, der auf /v1/logs endet (z. B. https://your-endpoint.example.com/v1/logs). Im Gegensatz zu einem OTLP Collector hängt der Telemetry Router diesen Pfad nicht automatisch an, Sie müssen ihn also explizit angeben.

    Kann ich ein selbstsigniertes TLS-Zertifikat für ein benutzerdefiniertes OTLP-Ziel verwenden?

    Nein. Zielendpunkte müssen ein TLS-Zertifikat vorweisen, das von einer anerkannten, öffentlichen Certificate Authority (z. B. Let’s Encrypt) signiert wurde. Selbstsignierte Zertifikate werden nicht unterstützt. Verwendet Ihr Endpunkt eines, werden Logs stillschweigend nicht zugestellt.

    Kann ich den ausgehenden Request an ein Ziel anpassen, zum Beispiel durch das Hinzufügen benutzerdefinierter HTTP-Header?

    Nein. Keiner der beiden unterstützten Zieltypen, OTLP oder S3, erlaubt benutzerdefinierte Header oder Änderungen am Request. Falls Ihr Ziel einen solchen benötigt, etwa einen anbieterspezifischen API-Key-Header, leiten Sie die Daten zunächst über einen zwischengeschalteten OpenTelemetry Collector oder die eigene HTTP-Quelle Ihres Ziels, um den Header dort umzuschreiben.

  • Netzwerk

    Wie finde ich die ausgehenden IP-Adressen des Telemetry Routers (für Whitelisting oder ACLs)?

    Der ausgehende IP-Bereich kann sich unabhängig vom Zieltyp ändern, je nachdem, welche Cluster wir bereitstellen. Statt feste Adressen zu hinterlegen, empfehlen wir, die aktuellen STACKIT Public IP Ranges abzurufen:

    stackit curl https://iaas.api.stackit.cloud/v2/networks/public-ip-ranges

    Falls Sie die API nicht aufrufen möchten, sind dies unsere aktuell aktiven Bereiche:

    • EU01: 188.34.68.97/32, 188.34.92.238/32
    • EU02: 45.137.173.48/32, 45.137.172.30/32

    Diese Bereiche können sich ändern, wenn neue Cluster bereitgestellt werden. Wenn Sie sie direkt statt über die API verwenden, aktualisieren Sie Ihre ACLs bitte entsprechend.

  • Fehlerbehebung

    Warum schlägt das Erstellen eines Telemetry Links oder Ziels manchmal ohne eindeutige Fehlermeldung fehl?

    Bevor die Ressource erstellt wird, prüft die API, ob Ihre konfigurierten Werte (Endpunkt, ACL usw.) tatsächlich Zugriff auf das Zielsystem erlauben. Ist der Zugriff nicht möglich (zum Beispiel weil eine Netzwerk- oder IP-Beschränkung die Verbindung blockiert), wird die Erstellung abgelehnt. Prüfen Sie vor dem Erstellen des Links, ob die Zugriffskontrollen Ihres Ziels Traffic vom Telemetry Router zulassen.

    Ich habe ein Object Storage-Ziel eingerichtet, aber es kommen keine Logs in meinem Bucket an. Was sollte ich prüfen?

    Zwei häufige Ursachen:

    1. Falsche Router-Referenz: Ihr Telemetry Link muss auf die korrekte Telemetry Router-ID verweisen. Prüfen Sie, ob diese existiert (gegebenenfalls sowohl in EU01 als auch in EU02).

    2. Falsches Endpunkt-Format: Verwenden Sie den generischen Object Storage-Host ohne eingebetteten Bucket-Namen, zum Beispiel https://object.storage.eu01.onstackit.cloud, statt https://<bucketName>.object.storage.eu01.onstackit.cloud. Geben Sie den Bucket-Namen stattdessen im dafür vorgesehenen Feld an.

    Wie frage ich Telemetry Router Audit Logs in Grafana Loki ab und filtere sie?

    Stellen Sie sicher, dass Ihr Ziel den vollständigen Observability-Ingestion-Pfad verwendet und keine verkürzte URI. Ein unvollständiger Pfad kann dazu führen, dass Logs stillschweigend verworfen werden, selbst wenn die Pipeline als “ACTIVE” angezeigt wird.

    Da Attribute auf Log-Ebene bereitgestellt werden und nicht als Standard-Loki-Labels, muss Ihre Query zunächst alle Logs abrufen und als JSON parsen, bevor gefiltert wird. Zum Beispiel:

    {service_name=~".+"} | json | service_name_extracted="telemetry-router"

    oder gefiltert nach Sichtbarkeit:

    {service_name=~".+"} | json | stackit_visibility="PUBLIC"

    Beachten Sie, dass noch nicht alle STACKIT-Dienste in den Telemetry Router integriert sind, weshalb keine vollständige 1:1-Parität mit allen Audit-Events besteht.