Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

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

Las aplicaciones en contenedores suelen dirigir los registros de las aplicaciones a STDOUT. El motor de ejecución del contenedor captura estos registros y hace algo con ellos; por lo general, graba en un archivo. El lugar donde se almacenan estos archivos depende del tiempo de ejecución y la configuración del contenedor.

Una diferencia fundamental con los pods de Windows es que no generan STDOUT. Puede ejecutar [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)para recuperar el ETW (seguimiento de eventos para Windows), los registros de eventos de Windows y otros registros específicos de aplicaciones desde contenedores de Windows en ejecución y canalizar la salida de registro formateada a STDOUT. Luego, estos registros se pueden transmitir mediante fluent-bit o fluentd al destino que desee, como Amazon. CloudWatch

El mecanismo de recopilación de registros recupera STDOUT/STDERR los registros de los pods de Kubernetes. A [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)es una forma común de recopilar registros de los contenedores. Permite gestionar los registros de routing/filtering/enrichment forma independiente de la aplicación. Se DaemonSet puede usar un fluentd para transmitir estos registros y cualquier otro registro generado por la aplicación al agregador de registros deseado.

[Aquí se explica información más detallada sobre la transmisión de registros desde las cargas de trabajo de Windows CloudWatch ](https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/) 

## Recomendaciones de registro
<a name="_logging_recomendations"></a>

Las prácticas recomendadas generales de registro no son diferentes cuando se utilizan cargas de trabajo de Windows en Kubernetes.
+ Registre siempre **las entradas de registro estructuradas** (JSON/SYSLOG), lo que facilita la gestión de las entradas de registro, ya que hay muchos analizadores preescritos para dichos formatos estructurados.
+  **Centralice** los registros: los contenedores de registro dedicados se pueden utilizar específicamente para recopilar y reenviar los mensajes de registro de todos los contenedores a un destino
+ Mantenga baja la **verbosidad de los registros**, excepto cuando esté depurando. La verbosidad ejerce mucha presión sobre la infraestructura maderera y los eventos importantes pueden perderse en el ruido.
+ Registre siempre la **información de la solicitud** junto con el identificador de la **transacción/solicitud** para garantizar la trazabilidad. Los objetos de Kubernetes no llevan el nombre de la aplicación, por lo que, por ejemplo, el nombre de un pod `windows-twryrqyw` puede no tener ningún significado al depurar los registros. Esto contribuye a la trazabilidad y a la solución de problemas de las aplicaciones con los registros agregados.

  La forma de generar estos transaction/correlation identificadores depende de la estructura de programación. Sin embargo, un patrón muy común es usar un Aspect/Interceptor de registro, que puede usar el [MDC](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html) (contexto de diagnóstico mapeado) para inyectar un transaction/correlation identificador único a cada solicitud entrante, de la siguiente manera:

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