Collecte de journaux et métriques d'application
Cette section présente ce qui est enregistré dans l’image WorkflowGen et comment. Il indique également les pointeurs permettant de configurer la journalisation centralisée avec certains services et orchestrateurs.
WorkflowGen n'a pas de génération de métriques prête à l'emploi. Néanmoins, vous pouvez configurer certains logiciels ou services existants avec le conteneur de WorkflowGen afin d'obtenir des indicateurs de valeur pour la surveillance des performances et du trafic.
Lors du déploiement de WorkflowGen, de nombreuses applications fournissent des journaux via différents flux. Ce tableau liste les différentes sources des journaux et leurs flux :
Source | Flux |
Applications Web WorkflowGen | Journaux écrits dans le fichier App_Data |
Services Windows WorkflowGen | Journaux écrits via l'API d'événements Windows |
Internet Information Services (IIS) | Journaux écrits dans les fichiers du conteneur |
iisnode | Journaux écrits dans plusieurs fichiers du dossier de chaque application Node.js dans le conteneur |
Comme vous pouvez le constater, il existe de nombreuses sources pour les journaux et toutes ne sont pas gérées directement par le conteneur. Certains d'entre eux doivent être gérés manuellement.
Ces journaux sont écrits dans un fichier du dossier
App_Data et ce dossier est exposé via un volume. Pour plus d'informations sur les volumes exposés, voir la section Gestion des fichiers.Afin de centraliser ces journaux dans un service ou un système de journalisation, vous devez développer votre propre script ou votre propre application, qui lira périodiquement les journaux du volume
App_Data et les poussera au service. Concrètement, cela se fait en développant un conteneur Singleton qui a accès au volume de données WorkflowGen. Dans Kubernetes, vous déploieriez ce conteneur à l'intérieur d'un pod qui n'a qu'une seule réplique pour éviter les problèmes de concurrence.Ces journaux sont écrits dans l'API d'événements Windows et sont récupérés par le conteneur WorkflowGen uniquement lorsque le mode de démarrage est
win_services, dir_sync ou engine. Dans tous les autres cas, ce sont les journaux IIS qui sont redirigés vers la sortie standard et les logs des services Windows sont ignorés.Pour obtenir tous les journaux de WorkflowGen, vous devez utiliser l'architecture qui sépare chaque mode de démarrage dans son propre conteneur. Pour plus d'informations, voir la section Architectures recommandées.
Les journaux IIS sont écrits dans plusieurs fichiers dans le conteneur WorkflowGen. Vous n'avez pas à les gérer manuellement. Le conteneur lit les journaux et les dirige vers la sortie standard du conteneur. La sortie standard de chaque conteneur est récupérée par le système de journalisation Docker.
Il existe de nombreux pilotes de journalisation Docker pour indiquer à Docker où placer ces journaux. Par défaut, ils sont écrits sur l'hôte au format JSON par le chemin
C:\ProgramData\Docker\logs. Le reste de cette section fournit des informations supplémentaires sur le système de journalisation Docker et sur son utilisation pour centraliser les journaux.Dans Kubernetes, vous pouvez configurer votre propre agent de journalisation ou utiliser celui par défaut fourni. Pour plus de détails sur la journalisation dans Kubernetes, consultez la page Logging Architectures. De nombreux fournisseurs de cloud proposent un service centralisé pour visualiser les journaux des pods dans leur service Kubernetes. Consultez la documentation de votre fournisseur de cloud pour plus de détails.
Ces journaux sont désactivés par défaut et peuvent être activés en définissant les variables d'environnement suivantes pour le conteneur WorkflowGen :
WFGEN_IISNODE_AUTH_loggingEnabled=true
WFGEN_IISNODE_GRAPHQL_loggingEnabled=true
WFGEN_IISNODE_SCIM_loggingEnabled=true
WFGEN_IISNODE_HOOKS_loggingEnabled=true
# Also specify these values to expose the logs through HTTP
WFGEN_ENABLE_IISNODE_OPTION_AUTH=exposelogs
WFGEN_ENABLE_IISNODE_OPTION_GRAPHQL=exposelogs
WFGEN_ENABLE_IISNODE_OPTION_SCIM=exposelogs
WFGEN_ENABLE_IISNODE_OPTION_HOOKS=exposelogs
Il est recommandé d'activer ces journaux dans un environnement de développement uniquement, car ils peuvent être exposés via HTTP.
Comme vous pouvez le constater, la journalisation s'effectue par application et par conteneur. Pour extraire ces journaux du conteneur, vous devez utiliser des volumes et une application personnalisée pour les centraliser ou créer votre propre image basée sur l'image WorkflowGen qui redirigera ces journaux d'une manière ou d'une autre vers la sortie standard du conteneur. Pour plus d'informations sur la création d'une image WorkflowGen personnalisée, voir la section Image WorkflowGen personnalisée.
Afin de centraliser les journaux en dehors d'un hôte Docker, vous devez d'abord choisir un système ou un service de journalisation. Une fois cette opération effectuée, vous devez utiliser la méthode spécifique de votre orchestrateur pour lier le service aux journaux.
Kubernetes dispose d'une fonctionnalité similaire pour gérer les journaux des conteneurs. Voir la page suivante pour plus d'informations :
Vous pouvez également utiliser Azure Monitor avec votre cluster Kubernetes. Voir la page suivante pour plus d'informations :
La documentation du service Azure Kubernetes recommande l'utilisation d'Azure Monitor pour les conteneurs. Voir sa page de documentation pour plus de détails :
Ce logiciel peut vous aider à réduire les coûts liés à la surveillance des applications utilisant un service cloud. Prometheus peut être déployé en tant que conteneur dans votre cluster, parallèlement à WorkflowGen. Vous devez ajouter un utilitaire au conteneur WorkflowGen. Vous devez donc créer une image WorkflowGen personnalisée. Pour plus d'informations sur la création d'une image WorkflowGen personnalisée, voir la section Image WorkflowGen personnalisée.
Voici quelques liens vers la documentation Prometheus et des exemples Dockerfile pour vous aider à démarrer avec les métriques d'application avec Prometheus :
Grafana est un concurrent direct de Prometheus et vous pouvez également utiliser ce logiciel de la même manière. Il dispose également d'un service cloud payant. Voici quelques liens pour vous aider à démarrer :
Si vous préférez collecter uniquement les journaux IIS directement à partir du conteneur, Azure Application Insights fournit un outil PowerShell appelé Application Insights Agent, installé directement dans le conteneur. Voir l'article Microsoft Déployer Azure Monitor Application Insights Agent pour les serveurs locaux pour plus d'informations. Vous devrez créer votre propre image qui intègre cet outil dans le conteneur. Pour plus d'informations sur les images personnalisées WorkflowGen, voir la section Image WorkflowGen personnalisée.
Cette approche ne doit être envisagée que si votre cluster Kubernetes n'est pas géré par Azure Kubernetes Service et que vous souhaitez qu'Application Insights collecte les journaux. Sinon, utilisez l'agent de journalisation par défaut ou quelque chose comme une pile ELK (ElasticSearch, Logstash et Kibana) ou une pile EFK (ElasticSearch, fluentd et Kibana).
Dernière mise à jour 2yr ago