AWS → STACKIT · LOGGING UND MONITORING
CloudWatch-Logging und -Monitoring auf STACKIT
CloudWatch bündelt Log Groups, aus Logs abgeleitete Metriken, Alarme und Benachrichtigungen. Auf STACKIT werden daraus eine Logs-Instanz, eine Observability-Instanz mit Alert-Regeln und E-Mail-Empfänger. StackToIT entwirft Instanzen und Alert-Gruppe in Terraform und führt Datei für Datei auf, was Ihr Team noch schreibt: Log-Labels, Alert-Ausdrücke und das Mail-Relay.
Die Migration in sieben Schritten
Die Reihenfolge folgt der Umgebung, die StackToIT für diese Seite bewertet hat: zwei Log Groups, ein Metric Filter, zwei Alarme, ein SNS-Topic mit E-Mail-Abonnement und eine CloudWatch-Übersichtsseite.
Erfassen, was die Umgebung wirklich nutzt
Lesen Sie die Log Groups mit ihrer Aufbewahrung, die Metric Filter, die Alarme und die Topics dahinter. Einen Metric Filter oder Alarm, den niemand liest, stillzulegen ist günstiger, als ihn neu zu bauen. Die Bewertung führt jede Log Group, jeden Alarm, das Topic und die Übersichtsseite als eigene Einheit; Metric Filter und E-Mail-Abonnement gehören zu den Einheiten, an denen sie hängen.
Logs-Instanzen anlegen
Log Groups mit gleicher Aufbewahrungsdauer teilen sich eine Logs-Instanz. Die Aufbewahrung gehört zur Instanz, nicht zur Gruppe; die 30-Tage-Gruppe und die 365-Tage-Gruppe landeten daher auf zwei Instanzen.
Label-Konvention und Schreib-Token festlegen
STACKIT Logs kennt weder Log Group noch Stream. Der Gruppenname überlebt nur als Label, das Ihr Shipper mitsendet. Legen Sie pro Instanz einen Schreib-Token an und richten Sie den Shipper auf die Ingest-Adresse der Instanz (Loki-API oder OpenTelemetry).
Aus Logs abgeleitete Metriken neu bauen
Eine Logs-Instanz hat keinen Metric Filter. Machen Sie aus dem Filter eine Log-Alert-Regel in Observability, oder lassen Sie die Anwendung die Metrik selbst liefern.
Alert-Ausdrücke schreiben
Die Alert-Gruppe übernimmt Name und „for“-Dauer jedes Alarms. Der Ausdruck ist eine Pflichtvariable, denn von keiner CloudWatch-Metrik ist bekannt, dass sie in Ihrer Observability-Instanz existiert.
Empfänger einrichten
Das E-Mail-Abonnement des SNS-Topics wird zu einem Empfänger samt Route in der Alert-Konfiguration der Observability-Instanz. Adresse und SMTP-Relay tragen Sie als Variablen ein.
Beides parallel betreiben, dann stilllegen
Senden Sie Logs an beide Ziele, vergleichen Sie das Alarmverhalten an echten Störungen und schalten Sie die CloudWatch-Seite nach der Abnahme ab.
Log Groups, ein Metric Filter und zwei Alarme
Die Eingabe wurde für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links die Eingabe von der Audit-Log-Group bis zum Latenz-Alarm, rechts Blöcke aus dem STACKIT-Terraform der Engine, ohne die Prüfkommentare, die in der Datei über jedem Block stehen.
resource "aws_cloudwatch_log_group" "audit" {
name = "/acme/audit"
retention_in_days = 365
}
resource "aws_cloudwatch_log_metric_filter" "errors" {
name = "orders-api-errors"
log_group_name = aws_cloudwatch_log_group.api.name
pattern = "ERROR"
metric_transformation {
name = "OrdersApiErrors"
namespace = "Acme/Orders"
value = "1"
}
}
resource "aws_sns_topic" "oncall" {
name = "acme-oncall"
}
resource "aws_sns_topic_subscription" "oncall_mail" {
topic_arn = aws_sns_topic.oncall.arn
protocol = "email"
endpoint = "oncall@example.com"
}
resource "aws_cloudwatch_metric_alarm" "errors_high" {
alarm_name = "orders-api-errors-high"
namespace = "Acme/Orders"
metric_name = "OrdersApiErrors"
statistic = "Sum"
period = 300
evaluation_periods = 1
threshold = 10
comparison_operator = "GreaterThanThreshold"
alarm_actions = [aws_sns_topic.oncall.arn]
}
resource "aws_cloudwatch_metric_alarm" "latency_high" {
alarm_name = "orders-alb-latency-high"
namespace = "AWS/ApplicationELB"
metric_name = "TargetResponseTime"
statistic = "Average"
period = 60
evaluation_periods = 5
threshold = 1.5
comparison_operator = "GreaterThanThreshold"
alarm_actions = [aws_sns_topic.oncall.arn]
}resource "stackit_logs_instance" "logs_retention_180d" {
project_id = var.project_id
display_name = "logs-retention-180d"
retention_days = 180
}
resource "stackit_observability_alertgroup" "migrated" {
project_id = var.project_id
instance_id = stackit_observability_instance.migrated.instance_id
name = "migrated-alarms"
rules = [{
alert = "errors-high"
expression = var.alarm_errors_high_expression
labels = {
source_alarm = "aws_cloudwatch_metric_alarm.errors_high"
notify_receiver = "sns-oncall"
}
annotations = {
summary = "orders-api-errors-high"
}
}, {
alert = "latency-high"
expression = var.alarm_latency_high_expression
for = "240s"
labels = {
source_alarm = "aws_cloudwatch_metric_alarm.latency_high"
notify_receiver = "sns-oncall"
}
annotations = {
summary = "orders-alb-latency-high"
}
}]
}Aus 365 werden 180 Tage
Die Audit-Gruppe bewahrt ihre Logs 365 Tage auf. Eine STACKIT-Logs-Instanz hält höchstens 180 Tage; der Entwurf setzt daher 180 Tage an und hält eine Entscheidung fest: dabei bleiben oder die Logs zusätzlich in einen Langzeitspeicher streamen.
Die „for“-Dauer ist abgeleitet, der Ausdruck nicht
Der Latenz-Alarm wertet fünf Ein-Minuten-Perioden aus. Der Entwurf rechnet (Perioden minus eins) × Periode, daher trägt die Regel for = 240s; der Fehler-Alarm mit nur einer Periode erhält kein for. Metrik, Vergleich und Schwelle werden nicht übersetzt; sie gehören in die Variable, die Sie liefern.
Labels steuern die Benachrichtigung
Jede Regel trägt ein Label notify_receiver, das die Route der Observability-Instanz mit dem E-Mail-Empfänger abgleicht.
Was aus jeder CloudWatch-Ressource wurde
Aus Bewertung und Terraform des Laufs gelesen. Alle sechs Einheiten sind als RECONFIGURE eingestuft; keine Einheit blieb ohne Zuordnung.
| CloudWatch-Ressource | STACKIT-Ziel | Was Ihr Team noch tut |
|---|---|---|
| aws_cloudwatch_log_group (zwei) | STACKIT-Logs-Instanz, eine je Aufbewahrungsdauer | Label wählen, Schreib-Token und Zugriffsliste anlegen, Shipper auf die Ingest-Adresse richten |
| aws_cloudwatch_log_metric_filter | Kein Gegenstück in Logs; als nicht übernommen benannt | Als Log-Alert-Regel oder als Anwendungsmetrik neu bauen |
| aws_cloudwatch_metric_alarm (zwei) | Regeln in einer Observability-Alert-Gruppe | PromQL-Ausdruck je Regel gegen Metriken schreiben, die Ihre Instanz wirklich hat |
| aws_sns_topic und E-Mail-Abonnement | Empfänger und Route in der Alert-Konfiguration der Observability-Instanz | Empfängeradresse und SMTP-Relay eintragen; andere Abonnementarten brauchen eigene Empfänger |
| Ressource der CloudWatch-Übersichtsseite | Grafana in der Observability-Instanz (Konfidenz LOW) | Panels in Grafana neu bauen; der Inhalt der Übersichtsseite wird nicht übernommen |
Sowohl der Metric Filter als auch das SNS-Abonnement werden in die Einheiten aufgenommen, zu denen sie gehören. Sie erscheinen nicht als eigene Einheiten, doch der Entwurf benennt für beide, was nicht übernommen wird.
Die Observability-Instanz mit ihrem Empfänger
Der Empfänger für das SNS-E-Mail-Abonnement, wie in derselben Datei geschrieben. Die Empfängeradresse ist eine Variable: Die Engine kopiert keine persönliche Adresse aus der Quelle.
resource "stackit_observability_instance" "migrated" {
project_id = var.project_id
name = "migrated-observability"
plan_name = var.observability_plan_name
alert_config = {
receivers = [{
name = "default"
}, {
name = "sns-oncall"
email_configs = [{
to = var.alert_mail_to_oncall_mail
from = var.alert_mail_from
smart_host = var.alert_mail_smart_host
send_resolved = false
}]
}]
route = {
receiver = "default"
routes = [{
receiver = "sns-oncall"
matchers = ["notify_receiver=\"sns-oncall\""]
}]
}
}
}Entscheidungen, die bei Ihren Architekten liegen
Aufbewahrung über 180 Tage
Audit-Logs, die älter als 180 Tage sind, gibt es nur, wenn Sie sie archivieren, etwa in einem eigenen Object-Storage-Bucket. Die FAQ von STACKIT empfiehlt diesen Cold-Storage-Ansatz für lange Aufbewahrung.
Label-Schlüssel für den Gruppennamen
Der Plan wählt keinen Label-Schlüssel und konfiguriert keinen Producer um. Legen Sie eine Konvention für alle Logquellen fest, bevor die erste Zeile gesendet wird.
Alarm-Semantik
CloudWatch wertet Statistik, Periode und Datenpunkte aus. Eine PromQL-Regel wertet anders aus; prüfen Sie jede Regel an einer echten Störung, nicht nur mit einer Syntaxprüfung.
Mail-Relay und Zugangsdaten
Der Entwurf schreibt keinen SMTP-Login und erzeugt keinen Zugriffstoken für Logs, denn dieser Token ist ein Zugangsdatum, das im State landet. Entscheiden Sie, wo beides liegt.
Übersichtsseiten und Historie
Panels bauen Sie von Hand neu. Historische Logs und Metriken kopiert der Entwurf nicht; klären Sie, ob nach dem Cutover jemand sie braucht.
Perzentil- und Anomalie-Alarme
Diese Umgebung hat keine. Wenn Ihre Umgebung welche hat, prüfen Sie, ob Prometheus sie ausdrücken kann, bevor Sie Gleichwertigkeit zusagen.
Fragen aus dem Betrieb
Kann ich meinen CloudWatch-Agent behalten?
Nein. Der Agent sendet an CloudWatch. Auf STACKIT versenden Sie Logs mit einem Collector, der die Loki-API oder OpenTelemetry spricht. Die Logs-Dokumentation von STACKIT enthält Anleitungen für Vector, Fluent Bit, den OpenTelemetry Collector und Grafana Alloy.
Werden Metric Filter übernommen?
Nein. Ein CloudWatch Metric Filter macht aus passenden Log-Ereignissen eine Metrik und zählt nur Ereignisse nach seiner Erstellung. STACKIT Logs hat kein solches Objekt; der Lauf führt ihn als nicht übernommen und verweist auf eine Log-Alert-Regel oder eine Anwendungsmetrik.
Wie lange kann STACKIT Logs meine Logs halten?
Laut der FAQ zu STACKIT Logs wird eine individuelle Aufbewahrung über 180 Tage nicht unterstützt. Für längere Zeiträume streamen Sie parallel eine Kopie in einen günstigeren Langzeitspeicher.
Zieht StackToIT die vorhandene Log-Historie um?
Nein. StackToIT ändert nichts in einer Cloud und kopiert keine Daten. Es entwirft die Ziele und schreibt die Schritte, die Ihr Team ausführt.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.