View a markdown version of this page

Registrazione dei log - Amazon EKS
Raccomandazioni per la registrazione

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Registrazione dei log

Le applicazioni containerizzate in genere indirizzano i log delle applicazioni a STDOUT. Il runtime del contenitore blocca questi log e fa qualcosa con essi, in genere scrive su un file. La posizione in cui vengono archiviati questi file dipende dal runtime e dalla configurazione del contenitore.

Una differenza fondamentale con i pod di Windows è che non generano STDOUT. È possibile eseguire LogMonitor per recuperare ETW (Event Tracing for Windows), i registri degli eventi di Windows e altri registri specifici dell'applicazione dall'esecuzione di contenitori Windows e inviare l'output del registro formattato a STDOUT. Questi log possono quindi essere trasmessi in streaming utilizzando fluent-bit o fluentd verso la destinazione desiderata, ad esempio Amazon. CloudWatch

Il meccanismo di raccolta dei log recupera i log dai pod Kubernetes. STDOUT/STDERR A DaemonSet è un modo comune per raccogliere i log dai contenitori. Ti dà la possibilità di gestire i log e routing/filtering l'arricchimento indipendentemente dall'applicazione. DaemonSet È possibile utilizzare un fluentd per trasmettere questi log e qualsiasi altro log generato dall'applicazione all'aggregatore di log desiderato.

Informazioni più dettagliate sullo streaming di log dai carichi di lavoro di Windows a sono illustrate qui CloudWatch https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/

Raccomandazioni per la registrazione

Le best practice generali di registrazione non sono diverse quando si utilizzano carichi di lavoro Windows in Kubernetes.

  • Registra sempre le voci di registro strutturate (JSON/SYSLOG), il che semplifica la gestione delle voci di registro poiché esistono molti parser pre-scritti per tali formati strutturati.

  • Centralizza i log: i contenitori di registrazione dedicati possono essere utilizzati specificamente per raccogliere e inoltrare i messaggi di registro da tutti i contenitori a una destinazione

  • Mantieni bassa la verbosità dei log tranne durante il debug. La verbosità pone molta enfasi sull'infrastruttura di registrazione e gli eventi significativi possono essere persi nel rumore.

  • Registra sempre le informazioni sull'applicazione insieme all'transaction/request ID per la tracciabilità. Gli oggetti Kubernetes non portano il nome dell'applicazione, quindi, ad esempio, il nome di un pod windows-twryrqyw potrebbe non avere alcun significato durante il debug dei log. Questo aiuta nella tracciabilità e nella risoluzione dei problemi delle applicazioni con i log aggregati.

    Il modo in cui si generano questi transaction/correlation ID dipende dal costrutto di programmazione. Ma uno schema molto comune consiste nell'utilizzare un logging Aspect/Interceptor, che può utilizzare MDC (Mapped diagnostic context) per iniettare un transaction/correlation ID univoco per ogni richiesta in arrivo, in questo modo:

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();
    }
}