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
<a name="windows-logging"></a>

Le applicazioni containerizzate in genere indirizzano i log delle applicazioni a STDOUT. Il runtime del contenitore intercetta questi registri e li utilizza, in genere li 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 Windows è che non generano STDOUT. È possibile eseguire l'operazione [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)per recuperare i registri ETW (Event Tracing for Windows), i registri degli eventi di Windows e altri registri specifici dell'applicazione dall'esecuzione di contenitori Windows e reindirizza l'output di 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](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)è un modo comune per raccogliere i log dai contenitori. Ti dà la possibilità di gestire i log routing/filtering/enrichment indipendentemente dall'applicazione. DaemonSet È possibile utilizzare un fluentd per trasmettere questi registri e qualsiasi altro registro generato dall'applicazione all'aggregatore di log desiderato.

[Informazioni più dettagliate sullo streaming dei log dai carichi di lavoro Windows a sono spiegate 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
<a name="_logging_recomendations"></a>

Le migliori pratiche 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 in quanto esistono molti parser predefiniti per tali formati strutturati.
+  **Centralizza** i log: i contenitori di registrazione dedicati possono essere utilizzati specificamente per raccogliere e inoltrare messaggi di log da tutti i contenitori a una destinazione
+ Mantieni bassa la **verbosità dei log tranne durante** il debug. La verbosità pone molto stress sull'infrastruttura di registrazione e nel rumore si possono perdere eventi significativi.
+ Registra sempre le **informazioni sull'applicazione** insieme all'ID della **transazione/richiesta** per la tracciabilità. Gli oggetti Kubernetes non hanno il nome dell'applicazione, quindi, ad esempio, il nome di un pod potrebbe non avere alcun significato durante il `windows-twryrqyw` debug dei log. Ciò facilita la tracciabilità e la risoluzione dei problemi delle applicazioni con i log aggregati.

  Il modo in cui vengono generati questi transaction/correlation ID dipende dal costrutto di programmazione. Ma uno schema molto comune consiste nell'utilizzare un Aspect/Interceptor di registrazione, che può utilizzare [MDC (Mapped](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html) diagnostic context) per iniettare un ID univoco a ogni richiesta in arrivo, in questo modo: transaction/correlation 

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