View a markdown version of this page

Protokollierung - Amazon EKS
Empfehlungen zur Protokollierung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Protokollierung

Containerisierte Anwendungen leiten Anwendungsprotokolle in der Regel an STDOUT weiter. Die Container-Runtime fängt diese Logs ab und macht etwas mit ihnen — typischerweise schreibt sie in eine Datei. Wo diese Dateien gespeichert werden, hängt von der Laufzeit und Konfiguration des Containers ab.

Ein grundlegender Unterschied zu Windows-Pods besteht darin, dass sie kein STDOUT generieren. Sie können ausführen LogMonitor, um ETW (Event Tracing for Windows), Windows-Ereignisprotokolle und andere anwendungsspezifische Protokolle aus laufenden Windows-Containern abzurufen und formatierte Protokollausgaben an STDOUT weiterzuleiten. Diese Protokolle können dann mit Fluent-Bit oder Fluentd an Ihr gewünschtes Ziel wie Amazon gestreamt werden. CloudWatch

Der Mechanismus zur Protokollerfassung ruft STDOUT/STDERR Protokolle von Kubernetes-Pods ab. A DaemonSet ist eine übliche Methode, um Logs aus Containern zu sammeln. Es gibt Ihnen die Möglichkeit, routing/filtering Log/Enrichment unabhängig von der Anwendung zu verwalten. Ein Fluentd DaemonSet kann verwendet werden, um diese Protokolle und alle anderen von der Anwendung generierten Protokolle an einen gewünschten Protokollaggregator zu streamen.

Detailliertere Informationen zum Log-Streaming von Windows-Workloads an werden hier erklärt CloudWatch https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/

Empfehlungen zur Protokollierung

Die allgemeinen Best Practices für die Protokollierung unterscheiden sich nicht beim Betrieb von Windows-Workloads in Kubernetes.

  • Loggen Sie immer strukturierte Logeinträge (JSON/SYSLOG), was die Handhabung von Logeinträgen erleichtert, da es viele vorgefertigte Parser für solche strukturierten Formate gibt.

  • Zentralisieren Sie Protokolle — spezielle Logging-Container können speziell dazu verwendet werden, Log-Meldungen aus allen Containern zu sammeln und an ein Ziel weiterzuleiten

  • Halten Sie die Ausführlichkeit der Logs gering, außer beim Debuggen. Ausführlichkeit belastet die Logging-Infrastruktur stark und wichtige Ereignisse können im Lärm untergehen.

  • Protokollieren Sie die Anwendungsinformationen immer zusammen mit der transaction/request ID, um die Rückverfolgbarkeit zu gewährleisten. Kubernetes-Objekte tragen nicht den Anwendungsnamen, sodass beispielsweise ein Pod-Name beim Debuggen von windows-twryrqyw Protokollen möglicherweise keine Bedeutung hat. Dies hilft bei der Rückverfolgbarkeit und der Fehlerbehebung von Anwendungen mit Ihren aggregierten Protokollen.

    Wie Sie diese transaction/correlation IDs generieren, hängt vom Programmierkonstrukt ab. Ein sehr verbreitetes Muster ist jedoch die Verwendung einer Protokollierung Aspect/Interceptor, die MDC (Mapped diagnostic context) verwenden kann, um jeder eingehenden Anfrage eine eindeutige transaction/correlation ID hinzuzufügen, etwa so:

import org.slf4j.MDC;
import java.util.UUID;
Class LoggingAspect { //interceptor

    @Before(value = "execution(* *.*(..))")
    func before(...) {
        transactionId = generateTransactionId();
        MDC.put(CORRELATION_ID, transactionId);
    }

    func generateTransactionId() {
        return UUID.randomUUID().toString();
    }
}