As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Registro em log
<a name="windows-logging"></a>

Os aplicativos em contêineres geralmente direcionam os registros do aplicativo para o STDOUT. O tempo de execução do contêiner captura esses registros e faz algo com eles. Normalmente, grava em um arquivo. O local onde esses arquivos são armazenados depende do tempo de execução e da configuração do contêiner.

Uma diferença fundamental com os pods do Windows é que eles não geram STDOUT. Você pode executar [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)para recuperar o ETW (Event Tracing for Windows), os registros de eventos do Windows e outros registros específicos do aplicativo a partir da execução de contêineres do Windows e canalizar a saída de log formatada para STDOUT. Esses registros podem então ser transmitidos usando fluent-bit ou fluentd para o destino desejado, como a Amazon. CloudWatch

O mecanismo de coleta de STDOUT/STDERR registros recupera registros dos pods do Kubernetes. A [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)é uma forma comum de coletar registros de contêineres. Ele oferece a capacidade de gerenciar o log routing/filtering/enrichment independentemente do aplicativo. Um fluentd DaemonSet pode ser usado para transmitir esses registros e quaisquer outros registros gerados pelo aplicativo para um agregador de registros desejado.

[Informações mais detalhadas sobre o streaming de logs das cargas de trabalho do Windows para CloudWatch são explicadas aqui.](https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/) 

## Recomendações de registro
<a name="_logging_recomendations"></a>

As melhores práticas gerais de registro não são diferentes ao operar cargas de trabalho do Windows no Kubernetes.
+ Sempre registre **entradas de registro estruturadas** (JSON/SYSLOG), o que facilita o manuseio de entradas de registro, pois há muitos analisadores pré-escritos para esses formatos estruturados.
+  **Centralize** registros - contêineres de registro dedicados podem ser usados especificamente para coletar e encaminhar mensagens de registro de todos os contêineres para um destino
+ Mantenha a **verbosidade do registro** baixa, exceto durante a depuração. A verbosidade coloca muito estresse na infraestrutura de registro e eventos significativos podem ser perdidos no ruído.
+ Sempre registre as **informações do aplicativo** junto com o **ID da transação/solicitação** para rastreabilidade. Os objetos do Kubernetes não carregam o nome do aplicativo, então, por exemplo, um nome de pod `windows-twryrqyw` pode não ter nenhum significado ao depurar registros. Isso ajuda na rastreabilidade e na solução de problemas de aplicativos com seus registros agregados.

  A forma como você gera esses transaction/correlation IDs depende da construção de programação. Mas um padrão muito comum é usar um Aspect/Interceptor de registro, que pode usar o [MDC](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html) (contexto de diagnóstico mapeado) para injetar um transaction/correlation ID exclusivo em cada solicitação recebida, da seguinte forma:

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