View a markdown version of this page

Logging - Amazon EKS
Recommandations relatives à la journalisation

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Logging

Les applications conteneurisées redirigent généralement les journaux des applications vers STDOUT. Le moteur d'exécution du conteneur piège ces journaux et fait quelque chose avec eux. Il écrit généralement dans un fichier. L'emplacement de stockage de ces fichiers dépend de l'exécution et de la configuration du conteneur.

Une différence fondamentale avec les pods Windows est qu'ils ne génèrent pas de sortie STDOUT. Vous pouvez exécuter LogMonitor pour récupérer l'ETW (Event Tracing pour Windows), les journaux d'événements Windows et d'autres journaux spécifiques à l'application à partir de conteneurs Windows en cours d'exécution et canaliser la sortie des journaux formatés vers STDOUT. Ces journaux peuvent ensuite être diffusés en utilisant fluent-bit ou fluentd vers la destination de votre choix, telle qu'Amazon. CloudWatch

Le mécanisme de collecte de STDOUT/STDERR journaux extrait les journaux des pods Kubernetes. A DaemonSet est un moyen courant de collecter les grumes dans les conteneurs. Il vous permet de gérer le routing/filtering journal/l'enrichissement indépendamment de l'application. Un fluentd DaemonSet peut être utilisé pour diffuser ces journaux et tout autre journal généré par une application vers l'agrégateur de journaux souhaité.

Des informations plus détaillées sur le streaming de journaux depuis les charges de travail Windows vers CloudWatch sont expliquées ici https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/

Recommandations relatives à la journalisation

Les meilleures pratiques générales en matière de journalisation ne sont pas différentes lorsque vous utilisez des charges de travail Windows dans Kubernetes.

  • Enregistrez toujours les entrées de journal structurées (JSON/SYSLOG), ce qui facilite la gestion des entrées de journal car il existe de nombreux analyseurs pré-écrits pour ces formats structurés.

  • Centralisation des journaux : des conteneurs de journalisation dédiés peuvent être utilisés spécifiquement pour collecter et transférer les messages de journal de tous les conteneurs vers une destination

  • Limitez la verbosité du journal, sauf lors du débogage. La verbosité exerce une forte pression sur l'infrastructure forestière et des événements importants peuvent être perdus dans le bruit.

  • Enregistrez toujours les informations de l'application ainsi que l'transaction/request identifiant pour la traçabilité. Les objets Kubernetes ne portent pas le nom de l'application. Par exemple, un nom de pod windows-twryrqyw peut n'avoir aucune signification lors du débogage des journaux. Cela facilite la traçabilité et le dépannage des applications avec vos journaux agrégés.

    La façon dont vous générez ces transaction/correlation identifiants dépend de la construction de programmation. Mais un modèle très courant consiste à utiliser une journalisation Aspect/Interceptor, qui peut utiliser MDC (Mapped Diagnostic Context) pour injecter un transaction/correlation identifiant unique à chaque demande entrante, comme suit :

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