Ein Noisy Neighbor ist ein Workload, der eine geteilte Ressource wie CPU, Speicherbandbreite, Disk-I/O, Netzwerk oder einen Datenbank-Connection-Pool so stark beansprucht, dass andere Mandanten auf demselben Host, Kubernetes-Node oder Multi-Tenant-Service höhere Latenz oder Fehler sehen, obwohl sich ihre eigene Last nicht verändert hat.
Was ist ein Noisy Neighbor?
Ein Noisy Neighbor („lauter Nachbar“) ist ein Workload, der von einer gemeinsam genutzten Ressource einen unverhältnismäßig großen Anteil verbraucht und damit andere ausbremst. Das klassische Beispiel ist eine virtuelle Maschine auf einem ausgelasteten Hypervisor. Das Muster tritt aber überall auf, wo Ressourcen gepoolt werden: Container auf einem Kubernetes-Node, Mandanten in einer gemeinsamen Datenbank, Workloads auf demselben Storage-Volume, Services hinter demselben NAT-Gateway oder ein Batch-Job, der sich einen Connection-Pool mit einer API teilt.
Das typische Symptom: Der betroffene Service wird langsamer, ohne dass sich sein eigener Traffic oder Code geändert hat. Die Latenz steigt, die hohen Perzentile verschlechtern sich, Timeouts treten auf, während die Request-Rate konstant bleibt. Genau das macht Noisy Neighbors schwer zu debuggen: Die Ursache liegt außerhalb des Services, der das Symptom zeigt.
Welche Ressourcen betroffen sind
| Geteilte Ressource | Typischer Noisy Neighbor | Aussagekräftiges Signal |
|---|---|---|
| CPU auf einem Hypervisor | Eine andere VM auf demselben physischen Host | CPU Steal Time (%st in top/vmstat) |
| CPU auf einem Kubernetes-Node | Ein Pod ohne Limits oder mit zu niedrigen Requests | CFS-Throttling, Sättigung des Nodes, Run-Queue-Länge |
| Arbeitsspeicher und Caches | Ein speicherhungriger Pod oder ein Job, der Caches verdrängt | Memory Pressure, OOM-Kills, Evictions, Page Faults |
| Disk-I/O | Log-intensiver Workload oder Backup auf demselben Volume | I/O Wait, Disk-Queue-Länge, IOPS- und Durchsatzgrenzen |
| Netzwerk | Massentransfer über dieselbe Netzwerkkarte oder dasselbe Gateway | Bandbreite, Paketverluste, Retransmits |
| Gemeinsame Datenbank | Ein Mandant mit teuren Abfragen | Lock Waits, Auslastung des Connection-Pools, Slow-Query-Log |
So erkennen Sie einen Noisy Neighbor
Die Erkennung beruht vor allem auf Korrelation über Schichten hinweg: Sie vergleichen die Symptome des betroffenen Services mit den Ressourcensignalen der darunterliegenden geteilten Schicht und mit dem Verhalten der anderen Mandanten.
- Eigenverschulden ausschließen. Prüfen Sie, ob Request-Rate, Payload-Größen und deployte Version unverändert sind. Eine Baseline für Latenz und Durchsatz macht Abweichungen sofort sichtbar.
- Die geteilte Schicht finden. Auf welchem Node, Host, Volume, welcher Datenbank oder welchem Gateway läuft der Service? Topologiedaten beantworten das schnell.
- Contention-Signale prüfen. Steal Time, gedrosselte CPU-Perioden, Linux Pressure Stall Information (
/proc/pressure/cpu,memory,io), Disk-Queue-Länge oder Wartezeiten im Connection-Pool. - Den größten Verbraucher identifizieren. Sortieren Sie die benachbarten Workloads nach Nutzung der umkämpften Ressource im Incident-Zeitraum. Ein Anstieg, der in derselben Minute beginnt wie die Verlangsamung, ist eine starke Spur.
Beispiel: ein Batch-Job auf einem geteilten Node
Ein illustratives Szenario: Eine Checkout-API läuft auf einem Kubernetes-Node zusammen mit einem nächtlichen Report-Job. Um 02:00 Uhr springt die p99-Latenz der API von 180 ms auf 900 ms, während die Request-Rate gleich bleibt. Der Node zeigt eine CPU-Auslastung nahe 100 Prozent und eine wachsende Run Queue, die Container der API einen deutlichen Anstieg von container_cpu_cfs_throttled_periods_total. Der Report-Pod hat kein CPU-Limit und nur einen Request von 100m, deshalb hat der Scheduler ihn neben latenzkritische Pods gesetzt. Realistische Requests und ein Limit für den Job oder ein eigener Node-Pool beseitigen die Störung.
Noisy Neighbors vorbeugen
- Requests und Limits setzen. In Kubernetes steuern Requests das Scheduling und die QoS-Klasse (Guaranteed, Burstable, BestEffort). Latenzkritische Pods profitieren von Guaranteed QoS.
- Nach Workload-Typ isolieren. Eigene Node-Pools, Taints und Tolerations oder dedizierte Hosts für Batch-, Streaming- und interaktive Workloads.
- Quotas und faire Zuteilung nutzen. ResourceQuotas pro Namespace, I/O-Limits auf Volumes, Verbindungslimits pro Mandant und Rate Limiting in geteilten Services.
- Burst-Kapazität realistisch planen. Burstable-Instanztypen und überbuchte Nodes sind günstig, bis mehrere Mandanten gleichzeitig Last erzeugen.
- Auf Contention alarmieren, nicht nur auf Auslastung. Steal Time, Throttling und Pressure-Metriken zeigen Engpässe früher als die durchschnittliche CPU-Last.
Typische Fehler
- Den betroffenen Service hochskalieren: Das kostet Geld, löst aber nichts, wenn neue Replicas auf demselben Node landen.
- Nur Durchschnittswerte betrachten. Noisy Neighbors treffen p99 lange bevor sich der Mittelwert bewegt.
- Sehr knappe CPU-Limits für latenzkritische Services. Das erzeugt Throttling, das wie ein Noisy Neighbor aussieht, aber hausgemacht ist.
- Ressourcen jenseits der CPU ignorieren, etwa Disk-Queues und Connection-Pools.
- Den Noisy Neighbor nur abschalten, ohne die Ursache zu dokumentieren. Ohne Requests, Limits oder Isolation kehrt das Problem mit dem nächsten Workload zurück.
Wie Obseria hilft
Der Obseria Agent erfasst Host-, Container- und Prozessmetriken zusammen mit Traces, und Obseria TopoGraph zeigt, welche Services sich welche Nodes, Hosts und Datenbanken teilen. Steigt die Latenz, kann Obseria Intelligence eine agentische Ursachenanalyse starten, die dieser Topologie bis zur umkämpften Ressource und zum verursachenden Workload folgt, inklusive Beweiskette. Node- und Pod-Ansichten finden Sie im Kubernetes Monitoring.
