Einheit 5.1: Observability und Debugging

Einführung

Sie haben TaskBoard in Modul 3 auf Managed Kubernetes bereitgestellt und in Modul 4 mit PostgreSQL, Redis, Object Storage und Kafka verbunden. Jetzt läuft die Anwendung im Produktivbetrieb, und irgendwann wird sie sich ungewöhnlich verhalten: Die API-Latenz steigt sprunghaft an, ein Pod gerät in einen Crash-Loop, eine Datenbankverbindung läuft stillschweigend in ein Timeout, oder der Traffic erreicht eine bestimmte Ebene nicht mehr, und niemand weiß, warum. Ohne eingebundene Observability-Funktionen debuggen Sie blind.

In dieser Einheit erfahren Sie, wie Sie TaskBoard auf IONOS CLOUD programmatisch instrumentieren und debuggen. Sie übergeben Metriken an den Monitoring Service, leiten Protokolle an den Logging Service weiter, prüfen Infrastrukturänderungen über Activity Logs und erfassen Netzwerkverkehr mit Flow Logs. Jedes Tool deckt eine andere Schicht des Stacks ab, und die Einheit schließt mit einem wiederholbaren Kubernetes-Debugging-Workflow, der sie alle zusammenführt. Entscheidend ist auch, dass Sie die eine IONOS CLOUD-Einschränkung kennenlernen, die die meisten Teams trifft: Kubernetes-Control-Plane-Ereignisse werden nicht automatisch über den Logging Service weitergeleitet, sodass Sie Cluster-Protokolle selbst weiterleiten müssen.

1. Metriken mit dem Monitoring Service

Der Monitoring Service nimmt Metriken über eine Pipeline auf, die Sie über die REST API erstellen. Jede Pipeline stellt einen HTTP-Push-Endpunkt bereit, der Metriken im Prometheus-Format (Counter, Gauge, Histogram, Summary) akzeptiert. Die Visualisierung erfolgt in einer verwalteten Grafana-Instanz, die je nach Vertrag und Region bereitgestellt wird. Das alternative Aufnahmeformat ist JSON, das mit Snappy komprimiert werden muss.

Sie erstellen eine Pipeline, indem Sie POST an /pipelines auf dem regionalen Endpunkt senden. 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-Agenten 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 Ingest-Key pro Pipeline in metadata.key zurück, jedoch nur bei der Erstellung. Aus Sicherheitsgründen wird der Key in späteren Antworten nie zurückgegeben. Erfassen Sie ihn daher sofort und speichern Sie ihn in Ihrem Secret Manager.

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 Host-Muster für den Ingest ist <id>-metrics.<id>.monitoring.<region>.ionos.com, und der Push-Pfad ist /api/v1/push über den ausgehenden Port 443. Das vollständige Muster für die Push-URL lautet <httpEndpoint>/api/v1/push.

1.2 Pushen von Metriken aus TaskBoard

Konfigurieren Sie Ihren Agenten, um an den Pipeline-Endpunkt zu pushen. Grafana Agent, Prometheus und OpenTelemetry authentifizieren sich alle, 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 ist konfigurierbar.

# 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 eingetroffen sind, erstellen Sie Dashboards und Alerts in der verwalteten Grafana-Instanz unter der grafanaEndpoint aus der Create-Antwort. Sie definieren Alert-Bedingungen, Schwellenwerte und Benachrichtigungseinstellungen direkt in Grafana, beispielsweise einen Alert, wenn die p95-Anfragelatenz der TaskBoard API einen Schwellenwert über ein Zeitfenster von 5 Minuten überschreitet. Der Zugriff auf den Monitoring Service wird durch das IAM-Privileg mit dem Namen Access and manage Monitoring gesteuert.

2. Zentrale Protokolle mit dem Logging Service

Der Logging Service sammelt Protokolle über eine eigene Pipeline, die mit POST /pipelines am regionalen Endpunkt https://logging.<region-slug>.ionos.com erstellt wird. Eine neue Pipeline gibt den Status PROVISIONING zurück und wird erst dann nutzbar, wenn sie Ready ist. Die unterstützten Protokollquellen sind Kubernetes, Docker, Linux Systemd, HTTP (JSON REST API) und Generic. Die Standardaufbewahrungsdauer beträgt 30 Tage, und die zulässigen Aufbewahrungswerte sind 7, 14, 30 oder unbegrenzt. Jede Pipeline erlaubt 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}
          ]
        }
      }'

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

2.1 Weiterleitung von Logs mit Fluent Bit

Fluent Bit ist der unterstützte Log-Agent. Jede Log-Quelle benötigt den Pipeline-Endpunkt und einen Schlüssel, die beide aus der REST API-Antwort abgeleitet werden. Für Kubernetes das Fluent Bit-Paket für Ihre Distribution installieren und anschließend die Forward-Ausgabe auf den tcpAddress der Pipeline mit dem gemeinsamen Schlüssel ausrichten.

# 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 in JSON formatierte Protokolleinträge akzeptiert. Strukturieren Sie daher Ihre Anwendungsprotokolle als JSON, wenn Sie den HTTP-Pfad anstelle des Forward-Protokolls verwenden.

2.2 Die Einschränkung der Kubernetes Control-Plane

Dies ist die IONOS CLOUD-spezifische Falle. Ereignisse der Kubernetes Control-Plane werden nicht automatisch über den IONOS CLOUD Logging Service geleitet. Die Bereitstellung einer Workload in Managed Kubernetes bietet keine automatische Weiterleitung von Cluster-Protokollen. Sie müssen die clusterweite Protokollweiterleitung separat konfigurieren. In der Praxis bedeutet dies, dass Sie Fluent Bit als DaemonSet in Ihrem Cluster ausführen, um Knoten- und Pod-Protokolle an Ihre Pipeline zu übermitteln.

# 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 eine integrierte Weiterleitung, ohne dass jedes Produkt seinen eigenen Ingestion-Stack betreibt, bietet der Logging Service auch Central Logging an. Dabei handelt es sich um eine auf Vertragsebene und pro Region verfügbare Funktion, die mit PUT /central (Körper {"properties":{"enabled":true}}) aktiviert wird. Nur Vertragsverwalter, Eigentümer und Benutzer mit dem Access and manage Logging Service-Privileg können sie umschalten.

3. Änderungen mit Activity Logs protokollieren

Wenn sich ein Vorfall auf eine Konfigurationsänderung zurückführen lässt, liefern Activity Logs die Antwort, wer was und wann geändert hat. Die API-Basis-URL lautet https://api.ionos.com/activitylog/v1, und der Dienst ist nach Konstruktionsprinzip schreibgeschützt: Jeder Aufruf ist ein GET. Er protokolliert Benutzeranmeldungen, die Bereitstellung von Ressourcen, Konfigurationsänderungen, Datenzugriffe, das Abrufen von Ressourcen, Änderungen an Ressourcen und das Löschen von Ressourcen. Jeder Eintrag erfasst zudem die Quelle einer Aktion, die betroffenen Ressourcen und den Zeitverlauf der Ereignisse. Die Antworten werden im JSON-Format zurückgegeben, und die Authentifizierung unterstützt Basic Authentication oder einen Bearer Token.

3.1 Abfragen des Activity Logs

Filtern Sie anhand eines date-Zeitraums mit Start- und Endzeitpunkt, um den Untersuchungszeitraum einzuschränken. Die Paginierung wird über ein Limit gesteuert, das die Anzahl der Antwortelemente pro Seite begrenzt, sowie über einen Offset-Wert, 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 Basispfad /activitylog/v1 ohne das Segment /contracts/{contractNumber} liefert nur API Versionsinformationen, keine Protokolleinträ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 darüber hinaus erforderlich ist, 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 langfristige Persistenz, sodass ein geplanter Exportjob in einen Bucket eine Audit-Trail-Spur bereitstellt, die über das eingebaute Zeitfenster hinaus besteht.

4. Netzwerk-Debugging mit Flow Logs

Wenn die Konnektivität zwischen den Ebenen von TaskBoard abbricht und die Anwendungsprotokolle keine Einträge enthalten, liegt das Problem in der Regel auf der Netzwerkebene: eine Firewall-Regel, eine Routing-Lücke oder eine falsch konfigurierte NIC. Flow Logs erfassen den Datenverkehr, sodass Sie genau sehen können, was akzeptiert und was abgelehnt wird. Die unterstützten Ressourcen sind die VM NIC, Managed Network Load Balancer, Managed Application Load Balancer und Managed NAT Gateway. Die Erfassungsaktionen sind Rejected, Accepted oder Any, und die Erfassungsrichtungen sind Ingress, Egress oder Bidirectional. Sowohl IPv4 als auch IPv6 werden unterstützt.

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

4.1 Lesen von Flow-Log-Einträgen

Jeder Eintrag hat ein festes, unveränderliches Format (Version 2). Die nützlichsten Felder für das Debugging sind srcaddr, dstaddr, srcport, dstport, protocol und action, wobei action entweder ACCEPT (durch die Firewall erlaubt) oder REJECT (durch die Firewall blockiert) ist. Eine Häufung von REJECT-Einträgen auf dem Port, den Ihre Anwendung 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 Feld log-status ist OK für ein normales Intervall oder SKIPDATA, wenn während des Intervalls Datensätze übersprungen wurden. Wenn SKIPDATA angezeigt wird, bedeutet dies, dass Sie für dieses Zeitfenster nicht das vollständige Gesamtbild erhalten.

5. Der Kubernetes-Debugging-Workflow

Die meisten Produktionsvorfälle von TaskBoard treten zuerst in Kubernetes auf. Arbeiten Sie die Ebenen nacheinander ab, statt direkt zu Plattformtools zu springen, da das günstigste Signal am Pod am nächsten liegt.

5.1 Eskalationspfad

Beginnen Sie mit kubectl und eskalieren Sie zu Plattform-Beobachtbarkeitstools nur, wenn das Signal innerhalb des Clusters erschöpft 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

Erinnern Sie sich an die Einschränkung aus Abschnitt 2: kubectl logs zeigt Ihnen die Live-Ausgabe von Containern, speichert diese jedoch nicht, und Control-Plane-Ereignisse erreichen das Logging Service nicht von selbst. Die Suche im Logging Service ist nur dann nützlich, wenn Ihr Fluent Bit DaemonSet bereits weiterleitet. Integrieren Sie Observability, bevor der Vorfall eintritt, nicht währenddessen.

5.2 Health Checks

Liveness- und Readiness-Probes sind Ihre erste Verteidigungslinie für die automatische Wiederherstellung. Ein fehlgeschlagener Readiness-Probe entfernt den Pod von den Service-Endpunkten, sodass der Datenverkehr nicht mehr zu einer defekten Instanz fließt, während ein Liveness-Probe einen aufgehängten 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 der Managed Application Load Balancer separat von Ihren K8s-Manifesten bereitgestellt wird, konfigurieren Sie seinen Health Check so, dass er denselben /readyz-Pfad verwendet, damit der ALB und Kubernetes übereinstimmen, welche Backends gesund sind.

Schnellkarte zur API-Referenz

Wichtige Endpunkte für das Thema dieser Einheit:

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

Code-Labor

Ziel: Richten Sie Metriken und zentralisiertes Logging für TaskBoard ein und beheben Sie anschließend einen simulierten Verbindungsstörungsvorfall unter Verwendung von Activity Logs und Flow Logs.

Voraussetzungen:

• IONOS CLOUD Konto mit API-Token (IONOS_TOKEN exportiert)
• TaskBoard läuft auf Managed Kubernetes (Einheit 3.2)
• kubectl ist für Ihren MKS-Cluster konfiguriert
• Ein Object Storage Bucket sowie Access Key und Secret Key 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

Erwartete Ausgabe:

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

Schritt 2: Ingest-Schlüssel erfassen

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

Erwartete Ausgabe:

Stored key length: 44

Schritt 3: Erstellen der Protokollierungspipeline

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

Erwartete Ausgabe:

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

Schritt 4: Deployment des Fluent Bit DaemonSet zum Weiterleiten der Cluster-Logs (andernfalls treffen die Control-Plane-Logs nicht ein)

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

Erwartete Ausgabe:

daemonset.apps/fluent-bit created

Schritt 5: Eine Störung simulieren, indem Sie eine NSG-Regel hinzufügen, die den Port der App-Ebene blockiert, und dann beobachten, wie der Traffic fehlschlägt

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

Schritt 6: Die Änderung in Activity Logs finden

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"

Erwartete Ausgabe:

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

Schritt 7: Bestätigung auf der Netzwerkebene mit Flow Logs

python3 read_flowlogs.py | grep BLOCKED

Erwartete Ausgabe:

BLOCKED: 10.0.2.5 -> 10.0.3.7 port 8080

Prüfliste:

• [ ] Überwachungspipeline erstellt und Schlüssel erfasst, bevor ein zweiter API-Auftrag ausgeführt wird
• [ ] Protokollierungspipeline erreicht Ready und der Fluent Bit DaemonSet läuft
• [ ] Die Abfrage in Activity Logs gibt die fehlerhafte Konfigurationsänderung zurück
• [ ] Flow Logs zeigen REJECT-Einträge auf dem blockierten Port

Aufräumarbeiten:

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 Fehler

Fehler von Entwicklerinnen und Entwicklern, die bei der Observability auf IONOS CLOUD zu vermeiden sind:

1. Erwartung von Kubernetes-Logs ohne Weiterleitung

   • Problem: Sie öffnen Grafana des Logging Service nach der Bereitstellung auf MKS und sehen keine Cluster- oder Control-Plane-Logs.
   • Ursache: Ereignisse der Kubernetes Control-Plane werden nicht automatisch über den IONOS CLOUD Logging Service geleitet. Die Plattform übernimmt diese Übertragung nicht für Sie.
   • Lösung: Führen Sie Fluent Bit als DaemonSet aus (oder konfigurieren Sie Central Logging) und richten Sie es auf das tcpAddress Ihrer Logging-Pipeline mit dem gemeinsamen Schlüssel ein, bevor Sie die Logs benötigen.

2. Verlust des Schlüssels der Metrik-Pipeline

   • Problem: Ihr Agent erhält 401/403 beim Push, und Sie können den Schlüssel nicht finden, um das Problem zu beheben.
   • Ursache: Der Ingest-Schlüssel wird nur einmal zurückgegeben, nämlich in metadata.key bei der Erstellung der Pipeline, und erscheint aus Sicherheitsgründen nie in späteren Antworten.
   • Lösung: Erfassen Sie den Schlüssel zum Zeitpunkt der Erstellung in Ihrem Secret Store. Wenn er verloren geht, können Sie ihn nicht wiederherstellen; erstellen Sie eine neue Pipeline oder rotieren Sie den Schlüssel.

3. Versuch, ein Flow Log an Ort und Stelle zu bearbeiten

   • Problem: Sie aktualisieren die Erfassungsrichtung eines Flow Logs über die API, und die Änderung wird nicht wirksam.
   • Ursache: Die Konfiguration eines Flow Logs ist nach der Erstellung unveränderlich, und es gibt genau ein Flow Log pro Ressource.
   • Lösung: Löschen Sie das vorhandene Flow Log und erstellen Sie ein neues mit den gewünschten Einstellungen. Kodieren Sie dieses Muster „Löschen, dann Erstellen“ in Ihrem Terraform bzw. Ihrer Automatisierung, anstatt eine Aktualisierung an Ort und Stelle zu erwarten.

Zusammenfassung

Sie können TaskBoard nun von Anfang bis Ende auf IONOS CLOUD instrumentieren. Metriken fließen in eine Monitoring Service-Pipeline und werden in verwaltetem Grafana mit Alarmen dargestellt; Protokolle fließen über Fluent Bit in eine Logging Service-Pipeline; Infrastrukturänderungen sind über die schreibgeschützte Activity Logs API überprüfbar; und netzwerkseitige Fehler sind in Flow Logs sichtbar, die in Object Storage geschrieben werden. Mit implementierten Proben und passenden ALB-Health-Checks werden defekte Instanzen automatisch aus der Rotation entfernt. Am wichtigsten ist, dass Sie die IONOS CLOUD-Einschränkung kennen, die Teams in der Produktion trifft: Cluster-Protokolle und Control-Plane-Ereignisse müssen von Ihnen, nicht von der Plattform, weitergeleitet werden.

Wichtige Punkte:

• Monitoring-Pipelines akzeptieren Metriken im Prometheus-Format unter /api/v1/push; der Ingest-Schlüssel wird nur einmal bei der Erstellung angezeigt
• Logging-Pipelines unterstützen Quellen wie Kubernetes, Docker, Systemd, HTTP und Generic mit Aufbewahrungszeiten von 7/14/30 Tagen oder unbegrenzt; Fluent Bit ist der unterstützte Agent
• Kubernetes-Control-Plane-Ereignisse fließen NICHT automatisch durch den 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-Aufbewahrung; exportieren Sie nach Object Storage für längere Audit-Trails
• Flow Logs erfassen ACCEPT/REJECT pro NIC, NLB, ALB und NAT Gateway in .log.gz-Objekten; die Konfiguration ist unveränderlich und pro Ressource einzeln

Wichtige Begriffe:

• Metrik-Pipeline: Eine Monitoring Service-Instanz, erstellt über POST /pipelines, die einen HTTP-Push-Endpunkt für Metriken im Prometheus-Format bereitstellt.
• Ingest-Schlüssel: Das pro Pipeline zurückgegebene Credential, das einmalig in metadata.key angezeigt wird; Agenten senden es als APIKEY-Header (oder Bearer für Fluent Bit).
• Central Logging: Ein vertraglicher, regionaler Schalter (PUT /central), der integrierten Produkten ermöglicht, Protokolle an den Logging Service zu senden, ohne dass jedes Produkt eigene Ingestion betreibt.
• Activity Logs: Die schreibgeschützte Audit-API unter /activitylog/v1, die aufzeichnet, wer welche Ressource wann geändert hat, mit 35-Tage-Aufbewahrung.
• Flow Logs: Unveränderliche, ressourcenspezifische Netzwerkaufnahmen, die als Gzip-Text in Object Storage veröffentlicht werden, um akzeptierten und abgelehnten Verkehr zu sehen.

Nächste Schritte

Weiter lernen: Einheit 5.2: Security Automation

Verwandte Themen:

• Einheit 3.2: Kubernetes Deployment and Operations
• Einheit 4.2: Object Storage Integration