CloudWatch-logging en -monitoring op STACKIT

De migratie in zeven stappen

De volgorde volgt de omgeving die StackToIT voor deze pagina beoordeelde: twee loggroepen, één metric filter, twee alarmen, één SNS-topic met een e-mailsubscription en één CloudWatch-board.

1. 01

   Som op wat de omgeving echt gebruikt

   Lees de loggroepen met hun retentie, de metric filters, de alarmen en de topics erachter. Een metric filter of alarm dat niemand leest, is goedkoper uit te faseren dan opnieuw op te bouwen. Het assessment noemt elke loggroep, elk alarm, elk topic en het board als eigen eenheid; de metric filter en de e-mailsubscription zitten in de eenheden waartoe ze behoren.

2. 02

   Maak de Logs-instances aan

   Loggroepen die hun logs hetzelfde aantal dagen bewaren, delen één Logs-instance. Retentie is een instelling van de instance, niet van een groep, dus de groep van 30 dagen en de groep van 365 dagen kwamen op twee instances terecht.

3. 03

   Kies een labelconventie en een schrijftoken

   STACKIT Logs kent geen object voor loggroepen of streams. De groepsnaam blijft alleen bestaan als label dat uw shipper meestuurt. Maak per instance een schrijftoegangstoken aan en richt de shipper op het ingest-adres van de instance (Loki API of OpenTelemetry).

4. 04

   Bouw uit logs afgeleide metrics opnieuw op

   Een Logs-instance kent geen metric filter. Maak van het filter een logalertregel in Observability, of laat de applicatie de metric zelf publiceren.

5. 05

   Schrijf de alertexpressies

   De alertgroep neemt van elk alarm de naam en de “for”-duur over. De expressie is een verplichte variabele, omdat niet bekend is dat er een CloudWatch-metric in uw Observability-instance bestaat.

6. 06

   Stel receivers in

   De e-mailsubscription van het SNS-topic wordt een receiver en een route in de alertconfiguratie van de Observability-instance. Het adres en de SMTP-relay zijn variabelen die u invult.

7. 07

   Draai beide parallel en faseer daarna uit

   Stuur logs naar beide doelen, vergelijk het alertgedrag bij echte incidenten en schakel de CloudWatch-kant uit na acceptatie.

Loggroepen, een metric filter en twee alarmen

De invoer is voor deze pagina geschreven en op 4 november 2026 door StackToIT beoordeeld. Links: de invoer van de auditloggroep tot en met het latency-alarm. Rechts: blokken van de STACKIT-Terraform die de engine schreef, zonder de reviewcommentaren die in het bestand boven elk blok staan.

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"
    }
  }]
}

• 365 dagen worden 180

  De auditgroep bewaart de logs 365 dagen. Een STACKIT Logs-instance bewaart er maximaal 180, dus het concept stelt 180 in en legt een beslissing vast: houd het daarbij, of stream de logs ook naar langetermijnopslag.

• De “for”-duur wordt afgeleid, de expressie niet

  Het latency-alarm evalueert vijf perioden van een minuut. Het concept hanteert (perioden min één) × periode, dus de regel krijgt for = 240s; het foutalarm, met één periode, krijgt geen for. Metric, vergelijking en drempel worden niet vertaald; ze komen in de variabele die u aanlevert.

• Labels sturen meldingen

  Elke regel heeft een label notify_receiver dat de route van de Observability-instance koppelt aan de e-mailreceiver.

Wat elke CloudWatch-resource werd

Gelezen uit het assessment en de Terraform van de run. Alle zes eenheden zijn ingedeeld als RECONFIGURE; geen enkele eenheid bleef zonder koppeling.

Zowel de metric filter als de SNS-subscription gaan op in de eenheden waartoe ze behoren. Ze verschijnen niet als aparte eenheden, maar het concept noemt per eenheid wat niet wordt overgenomen.

De Observability-instance met de bijbehorende receiver

De receiver voor de SNS-e-mailsubscription, zoals in hetzelfde bestand geschreven. Het adres van de ontvanger is een variabele: de engine kopieert geen persoonlijk adres uit de bron.

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\""]
      }]
    }
  }
}

Beslissingen van uw architecten

• Retentie langer dan 180 dagen

  Auditlogs ouder dan 180 dagen bestaan alleen als u ze archiveert, bijvoorbeeld in een aparte Object Storage-bucket. De eigen FAQ van STACKIT raadt die cold-storage-aanpak aan voor lange retentie.

• Labelsleutel voor de groepsnaam

  Het plan kiest geen labelsleutel en configureert geen producer opnieuw. Kies één conventie voor alle logbronnen voordat de eerste regel wordt verstuurd.

• Alertsemantiek

  CloudWatch evalueert statistiek, periode en datapunten. Een PromQL-regel evalueert anders, dus controleer elke regel aan de hand van een echt incident, niet alleen met een syntaxcontrole.

• Mailrelay en inloggegevens

  Het concept schrijft geen SMTP-login en genereert geen Logs-toegangstoken, omdat het token een credential is die in de state terechtkomt. Bepaal waar beide worden bewaard.

• Boards en historie

  Panelen worden handmatig opnieuw opgebouwd. Historische logs en metrics worden door het concept niet gekopieerd; bepaal of iemand ze na de cutover nodig heeft.

• Percentiel- en anomaliealarmen

  Deze omgeving heeft ze niet. Als de uwe ze wel heeft, controleer dan of Prometheus ze kan uitdrukken voordat u gelijkwaardigheid belooft.

Vragen van operationsteams

Bronnen

• AWS: Working with log groups and log streams
• AWS: Creating metrics from log events using filters
• AWS: Using Amazon CloudWatch alarms
• STACKIT-documentatie: Logs-FAQ
• STACKIT-documentatie: Observability