Einheit 5.1: Beobachtbarkeit und Fehlersuche

Einführung

Sie haben TaskBoard in Modul 3 auf Managed Kubernetes ausgeliefert und es in Modul 4 mit PostgreSQL, Redis, Object Storage und Kafka verbunden. Jetzt läuft es in der Produktion, und irgendwann wird es Fehlverhalten zeigen: API-Latenzspitzen, ein Pod-Neustart, eine Datenbankverbindung, die stillschweigend abläuft, oder Datenverkehr, der aufhört, eine Ebene zu erreichen, und niemand weiß warum. Ohne in die Observierbarkeit eingebundene Tools sind Sie blind beim Debuggen.

Diese Einheit zeigt Ihnen, wie Sie TaskBoard programmatisch auf IONOS Cloud instrumentieren und debuggen. Sie werden Metriken an das Monitoring Service übertragen, Protokolle an das Logging Service weiterleiten, Infrastrukturänderungen durch Activity Logs überwachen und Netzwerkverkehr mit Flow Logs erfassen. Jedes Tool deckt eine andere Schicht des Stacks ab, und die Einheit schließt mit einem wiederholbaren Kubernetes-Debugging-Workflows ab, der sie zusammenfügt. Kritisch ist, dass Sie auch die eine IONOS-Einschränkung lernen werden, die die meisten Teams erwischt: Kubernetes-Steuerungsebene-Ereignisse fließen nicht automatisch durch das Logging Service, sodass Sie selbst Cluster-Protokolle weiterleiten müssen.

1. Metriken mit dem Monitoring Service

Der Monitoring Service nimmt Metriken über eine Pipeline auf, die Sie durch den REST API erstellen. Jede Pipeline stellt einen HTTP-Push-Endpunkt bereit, der Metriken im Prometheus-Format (Zähler, Messgerät, Histogramm, Zusammenfassung) akzeptiert, und die Visualisierung erfolgt in einer gemanagten Grafana-Instanz, die pro Vertrag und pro Region bereitgestellt wird. Das alternative Aufnahmeformat ist JSON, das mit Snappy komprimiert werden muss.

Sie erstellen eine Pipeline, indem Sie sich bei /pipelines auf dem regionalen Endpunkt POST anmelden. Der Endpunkt folgt dem Muster https://monitoring.<region-slug>.ionos.com, beispielsweise https://monitoring.de-txl.ionos.com/pipelines für Berlin oder https://monitoring.de-fra.ionos.com/pipelines für Frankfurt. Die unterstützten Push-Agents sind Prometheus, Grafana Agent, OpenTelemetry und Fluent Bit.

1.1 Erstellen einer Metrik-Pipeline

Erstellen Sie die Pipeline mit einem Bearer-Token. Die Antwort gibt den pro-Pipeline-Aufnahmeschlüssel in metadata.key zurück, aber nur bei der Erstellung. Aus Sicherheitsgründen wird der Schlüssel in späteren Antworten nie zurückgegeben, daher sollten Sie ihn sofort erfassen und in Ihrem Geheimnis-Manager speichern.

curl -s -X POST "https://monitoring.de-txl.ionos.com/pipelines" \
  -H "Authorization: Bearer $IONOS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "properties": {
          "name": "taskboard-prod"
        }
      }'

Erwartete Ausgabe (gekürzt):

{
  "id": "a1b2c3d4-...",
  "metadata": {
    "key": " exporter-api-key-shown-once ",
    "grafanaEndpoint": "https://a1b2c3d4-...grafana.de-txl.ionos.com"
  },
  "properties": { "name": "taskboard-prod", "status": "PROVISIONING" }
}

Das Muster für den Aufnahmehost ist <id>-metrics.<id>.monitoring.<region>.ionos.com, und der Push-Pfad ist /api/v1/push über den ausgehenden Port 443. Das vollständige Push-URL-Muster ist <httpEndpoint>/api/v1/push.

1.2 Pushen von Metriken von TaskBoard

Konfigurieren Sie Ihren Agenten, um auf den Pipeline-Endpunkt zu pushen. Der Grafana Agent, Prometheus und OpenTelemetry authentifizieren sich, indem sie den Header APIKEY: <key> setzen. Das Fluent-Bit-Beispiel verwendet stattdessen Authorization: Bearer <apiKey>. Das Standard-Push-Intervall beträgt 1 Minute und kann konfiguriert werden.

# grafana-agent.yaml - remote_write block for TaskBoard API pods
metrics:
  configs:
    - name: taskboard
      remote_write:
        - url: https://a1b2c3d4-metrics.a1b2c3d4.monitoring.de-txl.ionos.com/api/v1/push
          headers:
            APIKEY: ${MONITORING_PIPELINE_KEY}
      scrape_configs:
        - job_name: taskboard-api
          static_configs:
            - targets: ["taskboard-api:8080"]

Sobald die Daten angekommen sind, erstellen Sie Dashboards und Alerts in der gemanagten Grafana-Instanz unter der grafanaEndpoint aus der Erstellungsantwort. Sie definieren Alert-Bedingungen, Schwellenwerte und Benachrichtigungseinstellungen direkt in Grafana, beispielsweise einen Alert, wenn die TaskBoard-API-Anfrageverzögerung p95 einen Schwellenwert über einem 5-Minuten-Fenster überschreitet. Der Zugriff auf den Monitoring Service wird durch das IAM-Privileg mit dem Namen Access and manage Monitoring gesteuert.

2. Zentralisierte Protokolle mit dem Logging Service

Der Logging Service sammelt Protokolle über seine eigene Pipeline, die mit POST /pipelines auf dem regionalen Endpunkt https://logging.<region-slug>.ionos.com erstellt wird. Eine neue Pipeline gibt den Status PROVISIONING zurück und wird erst nutzbar, wenn sie Ready ist. Die unterstützten Protokollquellen sind Kubernetes, Docker, Linux Systemd, HTTP (JSON REST API) und Generic. Die Standardaufbewahrungsfrist beträgt 30 Tage, und die zulässigen Aufbewahrungsfristen sind 7, 14, 30 oder unbegrenzt. Jede Pipeline ermöglicht bis zu 5 Protokollströme.

curl -s -X POST "https://logging.de-txl.ionos.com/pipelines" \
  -H "Authorization: Bearer $IONOS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "properties": {
          "name": "taskboard-logs",
          "logs": [
            {"source": "kubernetes", "tag": "taskboard", "protocol": "tcp", "retentionInDays": 30}
          ]
        }
      }'

Protokolle können im Logging Service-Grafana über ein 30-Tage-Abfragefenster abgefragt werden. Der Zugriff erfordert das IAM-Privileg Access and manage Logging Service.

2.1 Weiterleiten von Protokollen mit Fluent Bit

Fluent Bit ist der unterstützte Protokoll-Agent. Jede Protokollquelle erfordert den Pipeline-Endpunkt und einen Schlüssel, die beide aus der REST-API-Antwort erhalten werden. Für Kubernetes installieren Sie das Fluent-Bit-Paket für Ihre Distribution und zeigen dann die Ausgabe auf den tcpAddress der Pipeline mit dem gemeinsamen Schlüssel.

# fluent-bit.conf - forward TaskBoard pod logs to the Logging Service
[OUTPUT]
    Name      forward
    Match     *
    Host      <tcpAddress-host>
    Port      9000
    Tag       taskboard
    tls       on
    SharedKey ${LOGGING_PIPELINE_KEY}

Beachten Sie, dass die HTTP-REST-Quelle nur JSON-formatierte Protokollaufzeichnungen akzeptiert, sodass Sie Ihre Anwendungsprotokolle als JSON strukturieren sollten, wenn Sie den HTTP-Pfad anstelle des Weiterleitungsprotokolls verwenden.

2.2 Die Kubernetes-Steuerungsebene-Beschränkung

Dies ist die IONOS-spezifische Falle. Kubernetes-Steuerungsebene-Ereignisse fließen nicht automatisch durch die IONOS-Logging Service. Das Bereitstellen eines Workload in Managed Kubernetes gibt Ihnen keine Cluster-Protokollweiterleitung kostenlos. Sie müssen die Cluster-Ebene-Protokollweiterleitung separat konfigurieren, was in der Praxis bedeutet, Fluent Bit als DaemonSet in Ihrem Cluster auszuführen, um Node- und Pod-Protokolle an Ihre Pipeline zu senden.

# Excerpt: Fluent Bit DaemonSet output for an MKS cluster
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
spec:
  template:
    spec:
      containers:
        - name: fluent-bit
          image: fluent/fluent-bit:latest
          env:
            - name: LOGGING_PIPELINE_KEY
              valueFrom:
                secretKeyRef:
                  name: logging-pipeline
                  key: shared-key

Für die integrierte Weiterleitung ohne separate Ausführung jedes Produkts bietet der Logging Service auch eine zentrale Protokollierung, eine vertragsbezogene, regionsbezogene Funktion, die mit PUT /central (Body {"properties":{"enabled":true}}) aktiviert wird. Nur Vertragsadministratoren, Besitzer und Benutzer mit dem Access and manage Logging Service-Privileg können dies umschalten.

3. Änderungen mit Activity Logs überprüfen

Wenn ein Vorfall auf eine Konfigurationsänderung zurückzuführen ist, beantwortet Activity Logs, wer was und wann geändert hat. Die Basis-URL von API ist https://api.ionos.com/activitylog/v1, und der Dienst ist aus Sicherheitsgründen schreibgeschützt: jeder Aufruf ist ein GET. Er zeichnet Benutzeranmeldungen, Ressourcenbereitstellung, Konfigurationsänderungen, Datenzugriff, Ressourcenabrufe, Ressourcenänderungen und Ressourcenlöschungen auf. Jeder Eintrag verfolgt auch die Quelle einer Aktion, die betroffenen Ressourcen und die Zeitleiste der Ereignisse. Antworten sind JSON, und die Authentifizierung akzeptiert Basic-Authentifizierung oder ein Bearer-Token.

3.1 Abfrage des Aktivitätsprotokolls

Filtern Sie nach einem date-Start- und Endbereich, um ein Untersuchungsfenster zu definieren. Die Paginierung wird mit einer Begrenzung gesteuert, die die Anzahl der Antwortelemente pro Seite begrenzt, und einem Offset, um auf nachfolgende Seiten zuzugreifen.

# Find all changes during the incident window
curl -s "https://api.ionos.com/activitylog/v1/contracts/${CONTRACT_NUMBER}?startDate=2026-06-04&endDate=2026-06-05&limit=50" \
  -H "Authorization: Bearer $IONOS_TOKEN"

Ersetzen Sie ${CONTRACT_NUMBER} durch Ihre Vertragsnummer. Der Basis-/activitylog/v1-Pfad ohne /contracts/{contractNumber}-Segment gibt nur API-Version-Informationen zurück, nicht jedoch Log-Einträge.

import requests

def find_changes(token, contract_number, start, end):
    url = f"https://api.ionos.com/activitylog/v1/contracts/{contract_number}"
    headers = {"Authorization": f"Bearer {token}"}
    offset, limit = 0, 100
    while True:
        params = {"startDate": start, "endDate": end, "limit": limit, "offset": offset}
        items = requests.get(url, headers=headers, params=params, timeout=30).json()["hits"]["hits"]
        if not items:
            break
        for entry in items:
            yield entry["_source"]
        offset += limit

Die Aufbewahrungsfrist für Activity Logs beträgt 35 Tage. Für alles, was Sie darüber hinaus benötigen, laden Sie die Daten herunter und speichern Sie sie an einem anderen Ort. IONOS Cloud Object Storage ist das ausdrücklich empfohlene Ziel für die Langzeitpersistenz, sodass ein geplanter Exportauftrag in einen Bucket Ihnen eine Audit-Trail gibt, die das integrierte Zeitfenster überlebt.

4. Netzwerktechnische Fehlerbehebung mit Flow Logs

Wenn die Konnektivität zwischen TaskBoard-Ebenen unterbrochen wird und die Anwendungsprotokolle still sind, liegt das Problem normalerweise in der Netzwerkschicht: eine Firewall-Regel, eine Routinglücke oder eine falsch konfigurierte Netzwerkkarte. Flow Logs erfassen den Datenverkehr, sodass Sie genau sehen können, was akzeptiert und abgelehnt wird. Unterstützte Ressourcen sind die VM-Netzwerkkarte, Managed Network Load Balancer, Managed Application Load Balancer und Managed NAT Gateway. Erfassungsaktionen sind Abgelehnt, Akzeptiert oder Beliebig, und Erfassungsrichtungen sind Eingehend, Ausgehend oder Bidirektional. Sowohl IPv4 als auch IPv6 werden unterstützt.

Flow Logs veröffentlichen in einem IONOS Cloud Object Storage-Bucket als .log.gz (gzip-komprimierter Text), der alle 10 Minuten rotiert wird. Zwei Einschränkungen sind für die Automatisierung wichtig: die Konfiguration ist nach der Erstellung unveränderlich, und es gibt einen Flow-Log pro Ressource. Um eine Einstellung zu ändern, müssen Sie diese löschen und neu erstellen. Die Erstellung von Flow Logs erfordert die Create Flow logs-DCD-Gruppenberechtigung.

4.1 Lesen von Flow-Log-Einträgen

Jeder Eintrag hat ein festes, unveränderliches Format (Version 2). Die nützlichsten Felder für die Fehlerbehebung sind srcaddr, dstaddr, srcport, dstport, protocol und action, wobei action entweder ACCEPT (erlaubt durch Firewall) oder REJECT (durch Firewall blockiert) ist. Ein Schub von REJECT-Einträgen auf dem Port, den Ihre App verwendet, weist direkt auf eine NSG-Regel hin.

import boto3, gzip

# Flow logs land in an Object Storage bucket as .log.gz objects
s3 = boto3.client("s3",
    endpoint_url="https://s3-eu-central-1.ionoscloud.com",
    aws_access_key_id=ACCESS_KEY,
    aws_secret_access_key=SECRET_KEY)

obj = s3.get_object(Bucket="taskboard-flowlogs", Key="2026/06/05/flow-0001.log.gz")
for line in gzip.decompress(obj["Body"].read()).decode().splitlines():
    f = line.split()
    # version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
    if f and f[-2] == "REJECT":
        print("BLOCKED:", f[3], "->", f[4], "port", f[6])

Das log-status-Feld ist OK für ein normales Intervall oder SKIPDATA, wenn Einträge während des Intervalls übersprungen wurden. Wenn Sie SKIPDATA sehen, bedeutet dies, dass Sie für dieses Zeitfenster nicht das vollständige Bild erhalten.

5. Der Kubernetes-Debugging-Workflow

Die meisten TaskBoard-Produktionszwischenfälle treten in Kubernetes zuerst auf. Arbeiten Sie die Schichten in der Reihenfolge ab, anstatt direkt zu Plattform-Tools zu springen, da das billigste Signal dem Pod am nächsten ist.

5.1 Eskalationspfad

Beginnen Sie mit kubectl und eskalieren Sie zu Plattform-Beobachtbarkeit nur, wenn das Signal innerhalb von Cluster nicht mehr verfügbar ist:

# 1. What is the pod actually doing?
kubectl get pods -n taskboard
kubectl logs -n taskboard deploy/taskboard-api --tail=100

# 2. Why won't it start or stay healthy?
kubectl describe pod -n taskboard <pod-name>
kubectl get events -n taskboard --sort-by=.lastTimestamp

# 3. Is it a resource or latency problem? -> Monitoring Service metrics in Grafana
# 4. Need historical/aggregated logs across pods? -> Logging Service search

Denken Sie daran, dass die Einschränkung aus Abschnitt 2: kubectl logs zeigt Ihnen die Live-Ausgabe von Container, aber es persistiert nicht und Control-Plane-Ereignisse erreichen das Logging Service nicht von selbst. Die Suche in Logging Service ist nur nützlich, wenn Ihr Fluent Bit DaemonSet bereits weiterleitet. Verbinden Sie die Beobachtbarkeit vor dem Zwischenfall, nicht währenddessen.

5.2 Gesundheitschecks

Liveness- und Readiness-Sonden sind Ihre erste Linie der automatischen Wiederherstellung. Eine Readiness-Sonde, die fehlschlägt, entfernt den Pod aus den Service-Endpunkten, so dass der Datenverkehr zu einer defekten Instanz stoppt, während eine Liveness-Sonde einen hängenden Container neu startet.

# TaskBoard API deployment probes
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  initialDelaySeconds: 10
  periodSeconds: 15
readinessProbe:
  httpGet: { path: /readyz, port: 8080 }
  initialDelaySeconds: 5
  periodSeconds: 10

Da Managed Application Load Balancer separat von Ihren K8s-Manifesten bereitgestellt wird, konfigurieren Sie seinen Gesundheitscheck, um denselben /readyz-Pfad zu verwenden, damit der ALB und Kubernetes übereinstimmen, welche Backends gesund sind.

API Referenz-Quick-Card

Wichtige Endpunkte für das Thema dieser Einheit:

Basis-URL (CloudAPI): https://api.ionos.com/cloudapi/v6 Authentifizierung: Authorization: Bearer <token> (Metrik-Push verwendet APIKEY: <key>)

Code-Labor

Ziel: Metriken und zentrales Logging für TaskBoard einrichten, dann einen simulierten Konnektivitätsausfall mithilfe von Activity Logs und Flow Logs debuggen.

Voraussetzungen:

• IONOS Cloud-Konto mit API-Token (IONOS_TOKEN exportiert)
• TaskBoard läuft auf Managed Kubernetes (Einheit 3.2)
• kubectl konfiguriert gegenüber Ihrem MKS Cluster
• Ein Object Storage-Bucket und Zugriffsschlüssel + Geheimschlüssel für Flow Logs

Schritt 1: Erstellen der Überwachungspipeline

curl -s -X POST "https://monitoring.de-txl.ionos.com/pipelines" \
  -H "Authorization: Bearer $IONOS_TOKEN" -H "Content-Type: application/json" \
  -d '{"properties":{"name":"taskboard-prod"}}' | tee pipeline.json

Das erwartete Ergebnis:

{"id":"...","metadata":{"key":"...","grafanaEndpoint":"https://...grafana.de-txl.ionos.com"},...}

Schritt 2: Erfassung des Ingest-Schlüssels

export MON_KEY=$(python3 -c "import json;print(json.load(open('pipeline.json'))['metadata']['key'])")
echo "Stored key length: ${#MON_KEY}"

Die Erwarteten Ausgaben:

Stored key length: 44

Schritt 3: Erstellen der Protokollpipeline

curl -s -X POST "https://logging.de-txl.ionos.com/pipelines" \
  -H "Authorization: Bearer $IONOS_TOKEN" -H "Content-Type: application/json" \
  -d '{"properties":{"name":"taskboard-logs","logs":[{"source":"kubernetes","tag":"taskboard","protocol":"tcp","retentionInDays":30}]}}'

Die Erwartete Ausgabe:

{"id":"...","properties":{"name":"taskboard-logs","status":"PROVISIONING"}}

Schritt 4: Bereitstellen des Fluent Bit DaemonSet, um Cluster-Protokolle (Steuerungsebenenprotokolle werden ansonsten nicht ankommen) weiterzuleiten

kubectl create namespace logging
kubectl create secret generic logging-pipeline -n logging --from-literal=shared-key="$LOGGING_PIPELINE_KEY"
kubectl apply -f fluent-bit-daemonset.yaml

Die Erwartete Ausgabe:

daemonset.apps/fluent-bit created

Schritt 5: Simulieren eines Ausfalls durch Hinzufügen einer NSG-Regel, die den App-Tier-Port blockiert, und beobachten Sie, wie der Datenverkehr ausfällt

kubectl get pods -n taskboard   # pods Running, but requests time out

Schritt 6: Ermitteln Sie die Änderung in Activity Logs

curl -s "https://api.ionos.com/activitylog/v1/contracts/${CONTRACT_NUMBER}?startDate=2026-06-05&endDate=2026-06-05&limit=20" \
  -H "Authorization: Bearer $IONOS_TOKEN"

Die Erwartete Ausgabe:

{"hits":{"total":1,"hits":[{"_source":{"action":"configuration changes","resource":"firewallrule/...","user":"...","time":"..."}}]}}

Schritt 7: Bestätigen Sie auf der Netzwerkebene mit Flow Logs

python3 read_flowlogs.py | grep BLOCKED

Die Erwarteten Ausgaben:

BLOCKED: 10.0.2.5 -> 10.0.3.7 port 8080

Validierungs-Checkliste:

• [ ] Überwachungspipeline erstellt und Schlüssel erfasst, bevor der zweite API-Aufruf erfolgt
• [ ] Protokollpipelinausgabe erreicht Ready und Fluent Bit DaemonSet ist aktiv
• [ ] Activity Logs-Abfrage gibt die fehlerhafte Konfigurationsänderung zurück
• [ ] Flow Logs zeigt REJECT-Einträge auf dem blockierten Port an

Aufräumen:

curl -s -X DELETE "https://monitoring.de-txl.ionos.com/pipelines/$MON_ID" -H "Authorization: Bearer $IONOS_TOKEN"
curl -s -X DELETE "https://logging.de-txl.ionos.com/pipelines/$LOG_ID" -H "Authorization: Bearer $IONOS_TOKEN"
kubectl delete namespace logging

Häufige Fehlerquellen

Entwicklerfehler, die bei der Beobachtbarkeit auf IONOS Cloud vermieden werden sollten:

1. Erwartung von Kubernetes-Protokollen ohne Weiterleitung

   • Problem: Sie öffnen das Logging Service-Grafana nach der Bereitstellung auf MKS und sehen keine Cluster- oder Control-Plane-Protokolle.
   • Warum es passiert: Kubernetes-Control-Plane-Ereignisse fließen nicht automatisch durch die IONOS-Logging Service-Plattform. Die Plattform liefert sie nicht für Sie.
   • Lösung: Führen Sie Fluent Bit als DaemonSet (oder konfigurieren Sie das zentrale Logging) aus und zeigen Sie es auf die tcpAddress-Pipeline mit dem gemeinsamen Schlüssel, bevor Sie die Protokolle benötigen.

2. Verlust des Metrik-Pipeline-Schlüssels

   • Problem: Ihr Agent erhält 401/403 bei der Übertragung und Sie können den Schlüssel nicht finden, um es zu beheben.
   • Warum es passiert: Der Ingest-Schlüssel wird nur einmal zurückgegeben, in metadata.key bei der Pipeline-Erstellung, und erscheint nie in späteren Antworten aus Sicherheitsgründen.
   • Lösung: Erfassen Sie den Schlüssel in Ihrem Geheimnis-Speicher bei der Erstellung. Wenn er verloren geht, können Sie ihn nicht abrufen; bereitstellen Sie eine neue Pipeline oder drehen Sie den Schlüssel.

3. Versuch, einen Flow-Log an einem bestimmten Ort zu bearbeiten

   • Problem: Sie aktualisieren die Erfassungsrichtung eines Flow-Logs über API und die Änderung wird nicht wirksam.
   • Warum es passiert: Die Flow-Log-Konfiguration ist nach der Erstellung unveränderlich und es gibt einen Flow-Log pro Ressource.
   • Lösung: Löschen Sie den vorhandenen Flow-Log und erstellen Sie einen neuen mit den gewünschten Einstellungen. Kodieren Sie dieses Löschen-und-Neuerstellen-Muster in Ihrem Terraform/Automatisierungsprozess, anstatt eine Aktualisierung vor Ort zu erwarten.

Zusammenfassung

Sie können jetzt TaskBoard von Ende zu Ende auf IONOS Cloud instrumentieren. Metriken fließen in eine Monitoring Service-Pipeline und werden in einem gemanagten Grafana mit Alerts gerendert; Logs fließen in eine Logging Service-Pipeline durch Fluent Bit; Infrastrukturänderungen sind über das schreibgeschützte Activity Logs API überprüfbar; und Netzwerkebene-Fehler sind in Flow Logs sichtbar, die in Object Storage geschrieben werden. Mit Sonden und entsprechenden ALB-Health-Checks können fehlerhafte Instanzen automatisch aus der Rotation entfernt werden. Am wichtigsten ist, dass Sie die IONOS-Einschränkung kennen, die Teams in der Produktion beeinträchtigt: Cluster-Logs und Control-Plane-Ereignisse müssen von Ihnen und nicht von der Plattform weitergeleitet werden.

Wichtige Punkte:

• Überwachungspipelines akzeptieren Prometheus-Format-Metriken bei /api/v1/push; der Ingest-Schlüssel wird nur einmal bei der Erstellung angezeigt
• Logging-Pipelines unterstützen Kubernetes, Docker, Systemd, HTTP und generische Quellen mit 7/14/30/unbegrenzter Aufbewahrungsfrist; Fluent Bit ist der unterstützte Agent
• Kubernetes-Control-Plane-Ereignisse fließen nicht automatisch durch die Logging Service; leiten Sie sie selbst mit einem Fluent Bit DaemonSet oder Central Logging weiter
• Activity Logs ist schreibgeschützt (nur GET), filterbar nach Datum, mit 35-Tage-Aufbewahrungsfrist; Exportieren Sie in Object Storage für längere Audit-Trails
• Flow Logs erfassen ACCEPT/REJECT pro NIC, NLB, ALB und NAT-Gateway in .log.gz-Objekte; die Konfiguration ist unveränderlich und pro Ressource

Wichtige Begriffe:

• Metrik-Pipeline: Eine Monitoring Service-Instanz, die über POST /pipelines erstellt wird und einen HTTP-Push-Endpunkt für Prometheus-Format-Metriken bereitstellt.
• Ingest-Schlüssel: Die pro-Pipeline-Anmeldeinformationen, die einmal in metadata.key zurückgegeben werden; Agents senden sie als APIKEY-Header (oder Bearer für Fluent Bit).
• Central Logging: Ein vertragsbezogener, pro-Region-Schalter (PUT /central), der es integrierten Produkten ermöglicht, Logs an die Logging Service weiterzuleiten, ohne dass jedes Produkt seine eigene Aufnahme ausführt.
• Activity Logs: Das schreibgeschützte Audit-API bei /activitylog/v1, das aufzeichnet, wer welche Ressource geändert hat und wann, und das für 35 Tage aufbewahrt wird.
• Flow Logs: Unveränderliche, pro-Ressource-Netzwerkerfassungen, die als gzip-Text in Object Storage veröffentlicht werden, um angenommene und abgelehnte Datenverkehr zu sehen.

Nächste Schritte

Weiterlernen: Einheit 5.2: Automatisierung der Sicherheit

Verwandte Themen:

• Einheit 3.2: Kubernetes-Bereitstellung und -Betrieb
• Einheit 4.2: Object Storage-Integration