---
title: "Rehost Spring Boot mit Observability und VM-Rightsizing optimieren"
description: "Praktisches Optimize-Runbook für einen Rehost-Spring-Boot-Workload auf STACKIT mit managed Observability-Signalen und kontrolliertem VM-Rightsizing per IaC."
sidebar:
  badge:
    text: "STACKIT"
    variant: success
scfAsset:
  managed: false
  category: "runbook"
  external: false
  tags: ["migrate", "optimize", "rehost", "observability", "rightsizing", "spring-boot"]
  maintainers:
    - user: "lukas.weberruss"
      role: true
      website: true
source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/"
source_file: "docs/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.mdx"
---

## Dieselbe Referenzimplementierung fortsetzen

Dieses Asset führt dieselbe Spring-Boot- und PostgreSQL-Referenzimplementierung fort, die für
Provisioning, Migration, Cutover und Stabilisierung verwendet wurde. Es führt kein weiteres Beispiel
oder Repository ein. Die vorhandenen Terraform-Variablen, Ansible-Konfiguration, Observability-Instanz
und Validierungsworkflows bleiben die technische Baseline für Optimize.

Die Optimize-Erweiterung beantwortet eine praktische Frage: Wie lassen sich Über- oder
Unterprovisionierung erkennen und VM- oder Storage-Kapazität anschließend über einen kontrollierten
IaC-Workflow ändern?

<LinkCard
  title="STACKIT CMF Rehost Spring Boot Repository"
  description="Arbeiten Sie mit derselben Terraform- und Ansible-Referenzimplementierung weiter, die in den vorherigen Rehost-Migrationsschritten verwendet wurde."
  href="https://github.com/stackitcloud/stackit-cmf-Rehost-springboot"
/>

<LinkChip href="/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/">Rehost-Implementierungs-Asset</LinkChip>

## Observability-Setup für die Optimierung

Nutze den managed <LinkChip href="https://docs.stackit.cloud/de/products/logging-and-monitoring/observability/">STACKIT Observability</LinkChip>-Stack als Datenquelle.

- **Prometheus**: Metrik-Erfassung
- **Thanos**: Langfristige Aufbewahrung von Metriken
- **Grafana Loki**: Log-Analyse
- **Grafana Tempo**: Distributed Traces
- **Grafana**: Dashboards und Visualisierung

Architektur-Referenzen:

- <LinkChip href="https://docs.stackit.cloud/de/products/logging-and-monitoring/observability/basics/architecture-of-observability/">Architektur von Observability</LinkChip>
- <LinkChip href="https://docs.stackit.cloud/de/products/logging-and-monitoring/observability/getting-started/create-your-first-observability-service/">Ersten Observability-Service erstellen und konfigurieren</LinkChip>

## Observability-Entscheidungsdashboard

Nutze das Dashboard, um Infrastruktur-Auslastung, Anwendungszustand, Request-Verhalten und
Alert-Historie gemeinsam zu bewerten, bevor die VM-Kapazität geändert wird.

<Image
  src={grafanaDashboardScreenshot}
  alt="Grafana-Dashboard für die Observability eines Rehost-Spring-Boot-Workloads und VM-Rightsizing-Entscheidungen"
  style={{ width: "100%", maxWidth: "1540px", height: "auto", display: "block" }}
/>

## Signale und Schwellwerte für Rightsizing

Definiere technische Schwellwerte, bevor du Kapazität änderst.

- **Kandidat für Downsize**: CPU p95 unter 30% und Memory p95 unter 50% für mindestens 14 Tage.
- **Kandidat für Scale-up**: CPU p95 über 75% oder Memory p95 über 80% während Business-Lastfenstern für mindestens drei Tage in Folge.
- **Stabilitäts-Guardrail**: Keine offenen kritischen Alerts und keine Regression in der Error-Rate-SLO.

Halte Schwellwerte workload-spezifisch und validiere sie gegen reale Traffic-Muster.

{/* vale off */}

## Datenbank Sicht für Optimize Entscheidungen

{/* vale on */}

Für stateful Rehost-Workloads sollten Signale aus der Datenbank im selben Dashboard-Zyklus bewertet werden.

- **Verbindungen**: Trend aktiver Verbindungen und Verhalten bei Lastspitzen.
- **Datenbank Größe**: Entwicklung der Datenbankgröße über die Zeit.
- **Transaktionen**: Commit-/Rollback-Trends zur Stabilitätsbewertung.

Nutze diese Signale gemeinsam mit VM-Metriken, damit Optimize-Entscheidungen nicht nur auf CPU oder Memory basieren.

{/* vale off */}

## PostgreSQL Flex im späteren Optimize-Pfad

{/* vale on */}

Wenn der Rehost-Workload den Datenbank-Layer später auf PostgreSQL Flex umstellt, sollte DB-Rightsizing in denselben Optimize-Loop aufgenommen werden.

- **Ziel-Instanz planen**: <LinkChip href="https://docs.stackit.cloud/de/products/databases/postgresql-flex/basics/plan-your-postgresql-flex-instance/">PostgreSQL-Flex-Instanz planen</LinkChip>
- **Flavor und Performance-Klasse abstimmen**: <LinkChip href="https://docs.stackit.cloud/de/products/databases/postgresql-flex/reference/flavors-and-performance-classes-of-postgresql-flex/">Flavors und Performance-Klassen von PostgreSQL Flex</LinkChip>
- **Integriertes Dashboard für schnelle Prüfung**: <LinkChip href="https://docs.stackit.cloud/de/products/databases/postgresql-flex/reference/dashboard-metrics-in-postgresql-flex/">Dashboard-Metriken</LinkChip>
- **Observability-Metriken für Analyse im Detail**: <LinkChip href="https://docs.stackit.cloud/de/products/databases/postgresql-flex/reference/observability-metrics-in-postgresql-flex/">Observability-Metriken</LinkChip>

## Rightsizing-Workflow

1. Baseline-Metriken und Traces für einen repräsentativen Zeitraum erfassen.
2. Optimize-Kandidat mit Dashboards und Alert-Historie bestätigen.
3. Kapazitätsänderung und Rollback-Checkpoint planen.
4. VM-Größe per Terraform/OpenTofu anpassen.
5. Latenz, Error-Rates, Durchsatz und Kosten erneut validieren.
6. Behalten oder zurückrollen anhand objektiver Kriterien.

## Praktisches Beispiel

### Beispiel A: Downsize nach dauerhaft niedriger Auslastung

Passe die VM-Größe in `env.tfvars` an:

```hcl
machine_type = "g3i.2"
```

Apply und Plan-Ausgabe prüfen:

```bash
terraform plan -var-file=env.tfvars
terraform apply -var-file=env.tfvars
```

Danach validieren:

- Service-Health (`systemctl status`, synthetische Checks)
- p95-Latenz und Error-Rate-Trend
- Kosten-Differenz im Reporting-Zeitraum

### Beispiel B: Scale-up bei dauerhaft hoher Last

Passe die VM-Größe in `env.tfvars` an:

```hcl
machine_type = "g3i.4"
```

Apply durchführen und mit denselben Post-Change-Checks validieren.

## Rollback-Muster

Wenn sich SLOs nach dem Rightsizing verschlechtern, rolle zurück, indem du den vorherigen `machine_type` wiederherstellst und IaC erneut ausführst.
Behandle Rollback als regulären Runbook-Schritt und nicht nur als Notfallweg.

## Hinweise

- Abhängig von Plattform-Constraints und Machine Type kann ein Resize einen Neustart oder Ersatz der VM auslösen. Prüfe das Verhalten vorab in `terraform plan`.

## Storage als Optimierungsaspekt

In Rehost-Szenarien sind CPU und Memory nur eine Seite des Rightsizing. Auch Storage-Performance kann zum Engpass werden.

- **Wann Storage prüfen**: erhöhte I/O-Wait-Werte, instabile Latenz bei schreibintensiver Last oder Throughput-Sättigung trotz freier CPU.
- **Was auswählen**: Storage-Service-Plan und Performance-Klasse passend zum beobachteten IOPS- und Durchsatzprofil.
- **Guidance**: <LinkChip href="https://docs.stackit.cloud/de/products/storage/block-storage/basics/service-plans/">Block Storage Service Plans</LinkChip>

### Performance-Klasse vor dem Provisioning auswählen

Eine Block-Storage-Performance-Klasse definiert die maximalen IOPS und den maximalen Durchsatz für
das gesamte Volume. Zugriffe von Anwendung, Datenbank, Betriebssystem und Backup teilen dieses
Performance-Budget. Wählen Sie die Klasse vor dem Erstellen des Volumes anhand gemessener Lastspitzen,
Latenzanforderungen, Backup-Aktivität und expliziter Wachstumsreserve.

> Aus der STACKIT-Doku: [Service-Pläne › Derzeit verfügbare Servicepläne (Leistungs-Klassen)](https://docs.stackit.cloud/de/products/storage/block-storage/basics/service-plans/#derzeit-verfügbare-servicepläne-leistungs-klassen) (Stand der Quelle 20.01.2026, übernommen 05.10.2026)

Die folgende Tabelle listet die derzeit verfügbaren Leistungs-Klassen für die Region EU01 auf:

| Leistungs-Klasse | Name | Max. IOPS | Max. Durchsatz (MB/s) |
| --- | --- | --- | --- |
| Leistungs-Klasse 0 | storage_premium_perf0 | 120 | 25 |
| Leistungs-Klasse 1 | storage_premium_perf1 | 500 | 50 |
| Leistungs-Klasse 2 | storage_premium_perf2 | 1000 | 100 |
| Leistungs-Klasse 4 | storage_premium_perf4 | 2000 | 150 |
| Leistungs-Klasse 6 | storage_premium_perf6 | 5000 | 200 |
| Leistungs-Klasse 8 | storage_premium_perf8 | 10000 | 250 |
| Leistungs-Klasse 10 | storage_premium_perf10 | 15000 | 300 |
| Leistungs-Klasse 12 | storage_premium_perf12 | 20000 | 350 |
| Leistungs-Klasse 13 | storage_premium_perf13 | 20000 | 700 |
| Leistungs-Klasse 14 | storage_premium_perf14 | 25000 | 400 |
| Leistungs-Klasse 15 | storage_premium_perf15 | 25000 | 800 |
| Leistungs-Klasse 16 | storage_premium_perf16 | 30000 | 450 |
| Leistungs-Klasse 17 | storage_premium_perf17 | 30000 | 900 |
| Leistungs-Klasse 18 | storage_premium_perf18 | 35000 | 500 |
| Leistungs-Klasse 19 | storage_premium_perf19 | 35000 | 1000 |
| Leistungs-Klasse 20 | storage_premium_perf20 | 40000 | 550 |
| Leistungs-Klasse 21 | storage_premium_perf21 | 40000 | 1100 |

IOPS – Input/Output Operations per second (Ein-/Ausgabebefehle pro Sekunde)

Durchsatz – Durchsatz in Megabyte pro Sekunde

Somit lassen sich die verwendeten Klassen anhand der Namensgebung im Detail unterscheiden. Beispiel: „Block Storage Premium – Leistungs-Klasse 2“ entspricht SSD-Festplatten mit max. 1000 IOPS und max. 100 Mbyte/s Durchsatz.

In der Rehost-Baseline teilen sich Betriebssystem, Spring-Boot-Anwendung und PostgreSQL-Daten das
Boot Volume. Eine Änderung der Performance-Klasse erfordert daher ein kontrolliertes Ersatzziel:

1. Wählen Sie die neue Klasse anhand beobachteter IOPS, Durchsatz-, Latenz- und I/O-Wait-Werte.
2. Prüfen Sie die Bereitschaft für Backup und Datenbank-Rollback.
3. Stellen Sie Ersatz-VM und Boot Volume mit der gewählten Klasse über IaC bereit.
4. Wenden Sie die Ansible-Konfiguration erneut an und stellen oder migrieren Sie die Workload-Daten wieder her.
5. Validieren Sie vor der Umschaltung Applikationsverhalten, Datenintegrität, Storage-Latenz, Backup-Abdeckung und Kosten.

Verwenden Sie ein separates Data Volume, wenn Storage-Kapazität oder -Performance unabhängig vom
VM-Lifecycle weiterentwickelt werden müssen. Erstellen Sie für eine andere Performance-Klasse ein
neues Volume im erforderlichen Verfügbarkeitsmodell mit ausreichender Kapazität, stoppen Sie
Schreibzugriffe, migrieren und verifizieren Sie die Daten, wechseln Sie Attachment oder Mount und
bewahren Sie das Quell-Volume auf, bis Abnahme- und Rollback-Gates passiert sind.

<LinkChip href="https://docs.stackit.cloud/de/products/storage/block-storage/how-tos/migrate-data-from-a-block-storage/">Daten aus Block Storage migrieren</LinkChip>

Behandeln Sie Storage-Prüfungen als Teil derselben Optimize-Schleife und validieren Sie nach jeder
Änderung erneut Latenz, Fehlerverhalten, Recovery und Kostenwirkung.