Multi-Tenant-Collectors

Früher oder später wird das Collector-Fleet eines Teams zum Fleet aller. Ein Plattform-Team baut die Erfassung für seine eigenen Dienste auf, es funktioniert, und dann will der nächste Geschäftsbereich mit hinein, und der übernächste, und irgendwann vielleicht externe Kunden, deren Daten man einliest. Nun betreibt man geteilte Erfassungsinfrastruktur für viele Tenants – und die Fragen wechseln von „Fliesst Telemetrie?” zu „Wessen Telemetrie ist das, wohin soll sie, wer darf ändern, wie sie behandelt wird, und wie verhindere ich, dass ein lauter Tenant alle anderen beeinträchtigt?”

In diesem Leitfaden geht es darum, diese Multi-Tenant-Collector-Architektur bewusst zu entwerfen, statt sie zusammenwachsen zu lassen. Wir behandeln, was Mandantenfähigkeit hier tatsächlich bedeutet, die Isolationsentscheidungen (dedizierte Pipelines vs. eine geteilte Pipeline mit Routing), wie man identifiziert, zu welchem Tenant ein Signal gehört, das mandantenweise Routing von Telemetrie, mandantenspezifische Verarbeitung und Ziele, das Noisy-Neighbor-Problem sowie die Governance und RBAC, die Tenants davon abhalten, sich gegenseitig ins Gehege zu kommen.

Was Mandantenfähigkeit für ein Collector-Fleet bedeutet

„Tenant” ist bewusst breit gefasst. Je nach Organisation kann es sein:

• Teams oder Squads, die sich eine plattformbetriebene Erfassungsschicht teilen, jeweils ihre eigenen Dienste besitzen und ihre eigenen Ziele und Aufbewahrung wollen.
• Geschäftsbereiche mit getrennten Kostenstellen, Compliance-Pflichten oder Backends, die alle über gemeinsame Infrastruktur einliefern.
• Externe Kunden, deren Telemetrie man erfasst und strikt voneinander isolieren muss – der härteste Fall, bei dem ein Leck zwischen Tenants ein ernster Vorfall ist.

Der rote Faden ist, dass ein einziges Erfassungsgewebe mehrere Parteien bedient, die die Daten des jeweils anderen nicht sehen dürfen, unterschiedliche Behandlung benötigen können und sich nicht gegenseitig im Dienst beeinträchtigen können sollten. Alles Folgende ergibt sich aus diesen drei Anforderungen: Isolation, mandantenspezifische Behandlung und Fairness.

Zwei Isolationsmodelle: dedizierte vs. geteilte Pipelines

Es gibt zwei Enden eines Spektrums, und die meisten realen Deployments landen irgendwo dazwischen.

Dedizierte Pipelines pro Tenant geben jedem Tenant seine eigenen Receiver, Prozessoren und Exporter – oft seine eigene Collector-Instanz oder seinen eigenen OTLP-Endpunkt. Die Isolation ist stark und einfach zu durchdenken: Eine Fehlkonfiguration in der Pipeline von Tenant A kann die Daten von Tenant B nicht berühren, weil sie sich nie einen Pfad teilen. Der Preis ist Multiplikation – mehr Pipelines, mehr Konfigurationen, mehr Infrastruktur, die zu betreiben und konsistent zu halten ist – und es skaliert schlecht auf Hunderte von Tenants.

Eine geteilte Pipeline mit attributbasiertem Routing betreibt einen Satz von Receivern und teilt die Telemetrie unterwegs anhand eines Tenant-Identifikators auf, wobei mandantenspezifische Verarbeitung und Ziele auf separaten Zweigen angewendet werden. Das ist weit effizienter und im Massstab weit einfacher zu betreiben, aber die Isolation hängt nun vollständig davon ab, dass das Routing korrekt ist – eine falsche Regel schickt die Daten von Tenant A in den Zweig von Tenant B, was bei externen Kunden ein Verstoss ist.

Die meisten Teams starten dediziert für ein paar Tenants mit hohem Einsatz und wechseln zu geteilt-mit-Routing, sobald die Tenant-Anzahl wächst und mandantenspezifische Infrastruktur untragbar wird – und behalten volle Isolation den Tenants vor, bei denen der Wirkungsradius eines Fehlers sie rechtfertigt.

Den Tenant identifizieren

Routing ist nur so gut wie die Fähigkeit zu sagen, zu welchem Tenant ein gegebenes Signal gehört. Drei gängige Mechanismen, oft kombiniert:

• Resource-Attribute. Am saubersten: Emittenten versehen die Telemetrie mit einem Resource-Attribut tenant.id (oder service.namespace, deployment.environment.name), und die Pipeline routet danach. Setzt voraus, dass Produzenten es zuverlässig setzen – was man am Rand erzwingen kann, falls sie es nicht tun.
• Mandantenspezifische OTLP-Endpunkte. Jeder Tenant sendet an einen eigenen Endpunkt oder Port, und der empfangende Collector stempelt ein Tenant-Attribut basierend darauf, welcher Listener es gefangen hat. Einfach und schwer zu fälschen, um den Preis, viele Endpunkte zu verwalten.
• Header. Tenants fügen einen identifizierenden Header hinzu (z. B. ein X-Tenant-ID oder ein Auth-Token, das einem Tenant zugeordnet ist); der Collector extrahiert ihn in ein Attribut. Praktisch für HTTP/OTLP-Aufnahme, aber nur so vertrauenswürdig wie die Fähigkeit, ihn zu validieren.

Für externe Kunden ist ein Mechanismus vorzuziehen, den der Tenant nicht fälschen kann – ein dedizierter authentifizierter Endpunkt schlägt ein selbstbehauptetes Attribut. Was auch immer man wählt, normalisiere es früh in ein einziges Resource-Attribut, damit der Rest der Pipeline eine konsistente Sache zum Routen hat.

Telemetrie mandantenweise routen

Mit einem Tenant-Attribut an Ort und Stelle teilt der Routing-Connector des OpenTelemetry Collectors (und der ältere routing-Prozessor) den Stream in mandantenspezifische Pipelines auf. Man definiert eine Tabelle, die Attributwerte auf nachgelagerte Pipelines abbildet:

connectors:
  routing:
    default_pipelines: [logs/unrouted]
    table:
      - context: resource
        condition: attributes["tenant.id"] == "acme"
        pipelines: [logs/acme]
      - context: resource
        condition: attributes["tenant.id"] == "globex"
        pipelines: [logs/globex]

service:
  pipelines:
    logs/in:
      receivers: [otlp]
      exporters: [routing]
    logs/acme:
      receivers: [routing]
      processors: [redaction/acme, probabilistic_sampler/acme]
      exporters: [otlphttp/acme]
    logs/globex:
      receivers: [routing]
      processors: [transform/globex]
      exporters: [loki/globex]

Der Zweig jedes Tenants ist eine vollständige Pipeline mit eigenen Prozessoren und Exportern. Beachten Sie das default_pipelines-Auffangbecken – Telemetrie, die zu keinem Tenant passt, muss irgendwohin, und sie an eine Quarantäne-/Unrouted-Pipeline zu senden (statt sie still zu verwerfen oder, schlimmer, fehlzuleiten) ist die sichere Voreinstellung. Ein Signal ohne erkannten Tenant ist ein zu untersuchender Bug, keine Daten, über die man raten sollte.

Tenant-Identität ist nur ein Attribut, nach dem sich routen lässt. Dieselbe nach Priorität geordnete Erst-Treffer-Mechanik funktioniert für jede inhaltsbasierte Aufteilung — Severity, Namespace, Statuscode —, was wir ausführlicher behandeln, einschliesslich der Frage, wie LinkMesh die Bedingung in einen Feld-/Operator-/Wert-Builder statt handgeschriebenes OTTL verwandelt, in Route Telemetry by Attribute (englisch).

Mandantenspezifische Verarbeitung, Ziele und Quotas

Der Gewinn mandantenspezifischer Zweige ist, dass jeder Tenant seine eigene Behandlung erhält:

• Unterschiedliche Verarbeitung. Tenant A verlangt aggressive PII-Maskierung aus Compliance-Gründen; Tenant B will rohe Genauigkeit; Tenant C sampelt stark, um Kosten zu steuern. Jeder Zweig trägt die Maskierungs- und Sampling-Kette, die dieser Tenant braucht, nicht einen kleinsten-gemeinsamen-Nenner-Kompromiss.
• Unterschiedliche Ziele. Tenant A liefert an seinen eigenen Grafana-Cloud-Stack, Tenant B an Ihr geteiltes Loki, Tenant C an ein Datadog-Konto, das ihm gehört. Mandantenspezifische Exporter machen „Ihre Daten gehen an Ihr Backend” buchstäblich wahr.
• Mandantenspezifische Quotas. Hier wird das Noisy-Neighbor-Problem gelöst. Ohne Limits verbraucht ein Tenant, der ein ausser Kontrolle geratenes Log-Volumen ausstösst, den Arbeitsspeicher, die CPU und die Export-Bandbreite des geteilten Collectors – und beeinträchtigt alle. Mandantenspezifisches Sampling und Volumenobergrenzen auf jedem Zweig begrenzen den Wirkungsradius, sodass ein lauter Tenant seine Obergrenze trifft, nicht die Decke des Fleets.

Noisy Neighbors sind das prägende Risiko des geteilten Modells. Ein Tenant, der sein Volumen über Nacht ver-10-facht, kann die Pipeline für alle aushungern, sofern nicht jeder Zweig begrenzt ist. Plane Quotas von Anfang an ein; sie nach einem Vorfall nachzurüsten ist schmerzhaft.

Governance und RBAC: wer wessen Pipeline ändern kann

Mandantenfähigkeit ist ebenso ein Autoritätsproblem wie ein Datenflussproblem. Auf geteilter Infrastruktur brauchen die Fragen „Wer kann die Maskierungsregeln von Tenant A ändern?” und „Kann Tenant B versehentlich die Daten von Tenant A umleiten?” echte Antworten, keine Konventionen. Ohne Governance bekommt man das Schlechteste aus beiden Welten: eine geteilte Pipeline, in der jeder Operator die Behandlung jedes Tenants ändern kann, und keine Aufzeichnung, wer was geändert hat.

Die Kontrollen, die zählen:

• Eingegrenzte Änderungsrechte. Der Eigentümer eines Tenants kann seinen Zweig bearbeiten; er kann die Verarbeitung oder Ziele eines anderen Tenants nicht anfassen. Das Plattform-Team regiert die geteilte Aufnahme und die Routing-Tabelle.
• Eine versionierte, auditierte Konfiguration. Jede Änderung an jedem Zweig wird aufgezeichnet – wer, was, wann –, sodass eine Fehlleitung oder eine Aufweichung der Maskierung nachvollziehbar und umkehrbar ist.
• Vorschau vor dem Anwenden. Eine Routing- oder Verarbeitungsänderung, die an einer Stichprobe vorab geprüft wird, bevor sie ausgeliefert wird, ist die Art, wie man „Diese Regel schickt A’s Daten an B’s Backend” fängt, bevor es zu einem tenantübergreifenden Leck wird.

Das ist dieselbe Governance- und Durchsetzungs-Disziplin, die für jedes Fleet gilt, mit erhöhten Einsätzen, weil ein Fehler eine Tenant-Grenze überschreitet, statt nur die eigenen Dashboards zu brechen.

Wie eine Control Plane es handhabbar macht

Routing-Tabellen und mandantenspezifische Pipelines über ein Fleet hinweg von Hand zu pflegen ist genau der Ort, an dem Multi-Tenant-Konfigurationen wuchern und driften. LinkMesh ist gebaut, um diese Form zu halten: Sein visueller Builder setzt routenspezifische Verarbeitungsketten zusammen und routet Telemetrie nach Label, Umgebung oder Tenant, sodass der Zweig jedes Tenants – seine Maskierung, sein Sampling, sein Ziel – eine erstklassige Sache ist, die man einmal zusammensetzt und über OpAMP an das Fleet ausrollt.

Bilde jeden Tenant auf seine eigene Collector-Gruppe ab, und die Grenze wird konkret: Jedes Mitglied der Gruppe teilt einen Satz gruppenspezifischer Quellen, Ziele und Routen, und eine eingegrenzte Rolle gibt dem Eigentümer dieses Tenants Bearbeitungsrechte über seine Gruppe – und nichts sonst.

Weil die Konfiguration versioniert und auditiert ist, hat „wer wessen Pipeline geändert hat” immer eine Antwort. Änderungsrechte sind auf Collectors und Collector-Gruppen eingegrenzt, sodass das Abbilden jedes Tenants auf seine eigene Collector-Gruppe dem Eigentümer dieses Tenants Bearbeitungsrechte über seinen Teil des Fleets gibt und über niemandes sonst. Und das Vorabprüfen einer Verarbeitungsänderung an gesampelten Datensätzen, bevor sie ausgeliefert wird, fängt eine schlechte Maskierungs- oder Drop-Regel, bevor sie die Daten eines Tenants erreicht. Pipeline-Telemetrie fliesst nie durch LinkMesh – sie bleibt auf Ihrer Infrastruktur, direkt zum Ziel jedes Tenants geroutet –, sodass die Control Plane die Aufteilung regiert, ohne je zu einem Ort zu werden, an dem sich Tenant-Daten vermischen. (Wo Mandantenfähigkeit in einem grösseren Design sitzt, siehe OpenTelemetry-Architektur für Unternehmen.)

Wo anfangen

1. Wählen Sie Ihr Isolationsmodell pro Tenant. Dedizierte Pipelines für die wenigen Tenants mit hohem Einsatz, geteilt-mit-Routing für die vielen.
2. Bringen Sie die Tenant-Identifikation auf den Punkt. Normalisieren Sie früh auf ein einziges Resource-Attribut und nutzen Sie einen fälschungssicheren Mechanismus für externe Tenants.
3. Routen Sie mit einem Auffangbecken. Teilen Sie nach Tenant-Attribut auf und stellen Sie alles Unerkannte unter Quarantäne, statt zu raten.
4. Begrenzen Sie jeden Zweig. Mandantenspezifische Quotas und Sampling, damit kein Noisy Neighbor das Fleet beeinträchtigen kann.
5. Regieren Sie die Autorität. Eingegrenzte Änderungsrechte, ein versionierter Audit-Trail und Vorschau vor dem Anwenden, damit Tenants sich nicht gegenseitig ins Gehege kommen.

Ein Fleet, das viele Tenants bedient, ist effizient und, unachtsam gemacht, ein Leck, das nur darauf wartet zu geschehen. Die Architektur, die trägt, ist bewusste Isolation, vertrauenswürdige Tenant-Identifikation, begrenzte mandantenspezifische Zweige und Governance darüber, wer was ändern kann – sodass geteilte Infrastruktur geteilt bleibt, ohne je zu geteilten Daten zu werden.