Kapazitätsplanung

Während Alerting dir sagt, dass jetzt gerade etwas eskaliert, schaut Kapazitätsplanung nach vorne: Wann wird es eskalieren, wenn wir nichts ändern? Wann ist die Disk voll? Wann muss der nächste Server her? Wann wird das Anwendungs-Cluster knapp? Das ist keine Mystik, sondern angewandte Datenanalyse aus den Zeitreihen, die Monitoring sowieso schon sammelt. Diese Lektion zeigt dir die Methoden: Baselines messen, lineare Regression auf Wachstumskurven, Headroom-Planung, der Unterschied zwischen On-Premises-Beschaffung und Cloud-Auto-Scaling. Praxis-Ziel: nie wieder durch volle Disks überrascht werden – und gleichzeitig nicht aus Übervorsicht teure Hardware ungenutzt herumstehen lassen.

1) Trends erkennen – die wichtigste Disziplin

Ein Punktwert verrät dir, wo du bist. Ein Trend verrät dir, wohin du gehst. Probiere unten: stell die aktuelle Disk-Belegung und die wöchentliche Wachstumsrate ein, der Graph zeigt dir den Verlauf und prognostiziert, wann die Disk voll ist:

2) Wer wachst wie? – Linear, polynomisch, exponentiell

Nicht jedes Wachstum ist linear. Du musst die Form deiner Daten kennen, sonst greift die falsche Methode:

3) Headroom – wieviel Reserve ist sinnvoll?

Headroom ist die Differenz zwischen aktueller Auslastung und maximaler Kapazität. Zuviel Headroom = Geldverschwendung (Hardware steht herum). Zu wenig Headroom = ein Lastpeak und du fällst um. Gängige Faustregeln:

Bei der Anwendung gilt zusätzlich: Connection-Pools, Thread-Pools, Queue-Längen sind Auslastungs-Indikatoren, die du im Monitoring ebenso pflegen solltest wie CPU. Mehr zum „was sammeln" in Monitoring-Konzept.

4) Vorlauf für Beschaffung einplanen

On-Premises: zwischen „wir wissen, dass wir Hardware brauchen" und „die Hardware steht im Rack" liegen Wochen. Diese Zeit musst du in die Schwellenwerte einplanen:

Im Klartext: wenn die Disk in 4 Wochen voll ist und der Lieferant 6 Wochen braucht, hast du verloren. Faustregel: erste Warning bei 60 % geplanter Voll-Last, Critical bei 80 %. So bleibt Zeit für ordentlichen Beschaffungsprozess. In Cloud-Welten verkürzt sich das auf Minuten – siehe nächste Sektion.

5) Cloud-Auto-Scaling – Kapazität wird elastisch

In Cloud-Umgebungen verändert sich das Bild komplett. Statt physischer Hardware kaufst du Capacity on Demand: Server kommen und gehen je nach Last, oft automatisch. Drei Begriffe musst du kennen:

• Vertikales Skalieren (Scale Up). Du gibst der bestehenden VM mehr CPU/RAM. Schneller Effekt, aber begrenzt durch die größte verfügbare Instanz und meist mit Neustart verbunden.
• Horizontales Skalieren (Scale Out). Mehr Instanzen hinzufügen, eine Load-Balancer verteilt die Last. Bevorzugt, weil grenzenlos – setzt aber stateless oder gut verteilte Anwendungen voraus.
• Auto-Scaling. Regeln, die Scale-Out/-In automatisch auslösen: „bei CPU > 70 % über 5 Min., neue Instanz starten; bei < 30 % über 15 Min., Instanz entfernen". AWS Auto Scaling Group, GCP Managed Instance Group, Kubernetes Horizontal Pod Autoscaler.

Vorsicht: Auto-Scaling löst nicht alle Kapazitätsprobleme. Eine überlastete Datenbank wächst nicht durch mehr Webserver. Und ohne Limits kann Auto-Scaling unerwartete Rechnungen erzeugen – ein „runaway Bot" kann über Nacht 200 Instanzen anschmeißen. Mehr in Cloud-Modelle.

6) Baselines – das eigene Normalverhalten kennen

Bevor du sagen kannst, dass etwas auffällig ist, musst du wissen, was normal ist. Eine Baseline ist das gemittelte Verhalten über eine repräsentative Zeitspanne – meist Wochen oder Monate, pro Stunde des Tages und Wochentag. Damit erkennst du:

• Saisonalität. Ein E-Commerce-Shop hat freitagabends viel Traffic, Sonntagvormittags wenig. Eine flache Schwelle „CPU > 70 %" alarmiert um 20 Uhr regelmäßig grundlos.
• Anomalien. Ein Wert ist nicht „hoch" oder „niedrig" – er ist hoch für diese Uhrzeit an diesem Wochentag.
• Releases als Stichproben. Wenn nach einem Deploy die p95-Latenz um 30 ms steigt – ist das innerhalb der üblichen Streuung oder eine echte Regression?

Tools dafür: Prometheus' holt_winters(), Zabbix Anomaly Detection, dedizierte Anomaly-Detection-Lösungen wie Anodot oder Dynatrace. Mehr zu langfristigem Datenaufbewahrung in der vorigen Lektion Grafana & Prometheus (Stichwort Long-Term-Storage).

7) Stolperfallen

• Mittelwerte verstecken Spitzen. CPU-Durchschnitt 30 % heißt nicht, dass alles entspannt ist – wenn dahinter Peaks von 100 % stecken, hast du regelmäßig Aussetzer. Immer auch p95/p99 oder Max-Werte beobachten.
• „Disk voll" ist nicht die einzige Limite. Inodes können vor den Bytes ausgehen (viele kleine Dateien); IOPS können vor dem Durchsatz limitieren (DB-Workload); Connections vor RAM; Sockets vor Bandbreite. Prüfe alle Limits, nicht nur das offensichtliche.
• Sägezahn-Muster nicht missverstehen. Heap-Nutzung in JVMs sieht aus wie ein Sägezahn (GC räumt regelmäßig auf). Schwellen anhand der oberen Spitzen, nicht des Durchschnitts.
• Forecast funktioniert nur, wenn das Verhalten zukünftig wie vergangen ist. Ein einmaliges Marketing-Event, eine Migration, ein neuer großer Kunde zerstört jede lineare Prognose. Reality-Check durch echten Menschen bleibt nötig.

Zusammenfassung

Kapazitätsplanung nutzt Monitoring-Daten, um Engpässe vorher zu erkennen. Drei Pfeiler: Trends aus historischen Daten (lineare Regression, predict_linear, forecast), Headroom-Reserven je nach Komponente (Disk 20-30 % frei, CPU max 60 % Mittel), Vorlauf für Beschaffung (On-Premises: Wochen, Cloud: Minuten dank Auto-Scaling). Wachstum kann linear, polynomisch oder exponentiell sein – Methode zur Form passen. Baselines erkennen Anomalien im Kontext (Tageszeit, Wochentag). Stolperfallen: Mittelwerte verstecken Peaks, „voll" hat viele Limits (Inodes, IOPS, Connections), Forecast bricht bei einmaligen Events. Eng verbunden mit SLAs – „nie länger als X überlastet" ist ein Kapazitätsversprechen.

Verwandte Lektionen: Schwellenwerte & Alerting · Grafana & Prometheus · Load Balancing · und mehrWeitere relevante LektionenMonitoring-KonzeptCloud-ModelleService Level ManagementAngebote einholenQuantitativer VergleichVerfügbarkeit berechnenRTO/RPO