Quelle est une bonne pratique de journalisation pour les tâches distribuées?

J'ai le réglage suivant:

Créez plusieurs travailleurs, effectuez un calcul et terminez-les une fois le calcul terminé.

Ainsi, chaque fois que ce sera une instance différente exécutant la tâche, chaque hôte aura donc son propre fichier journal, cela se traduira par une énorme liste de fichiers.

Est-ce une bonne pratique? Sinon, quelle serait une meilleure façon de consigner le traitement des tâches dans ce cas d'utilisation particulier?

PS: Mon infrastructure est sans serveur. Donc, pour l'instant, je me connecte à (AWS) CloudWatch. Mais, veuillez répondre à la question indépendamment d'AWS et convenant autant que possible à une configuration sans serveur.

«Sans serveur» signifie simplement que vous disposez de microservices relativement simples, généralement juste une petite webapp ou une seule fonction qui est automatiquement connectée à une interface REST. Les mêmes concepts s'appliquent que ceux que vous utiliseriez pour des services Web plus traditionnels: généralement un mélange d'écrivains syslog distants et ElasticSearch.

Le syslog en réseau ou distant existe depuis longtemps et dispose d'un ensemble d'outils assez robuste. Vous devrez exécuter le (s) serveur (s) central (s) syslog mais le protocole est très simple et il existe des bibliothèques clientes pures dans toutes les langues que vous pouvez utiliser pour envoyer des journaux. Un problème commun avec le syslog distant est qu'il est traditionnellement basé sur UDP. Cela signifie qu'en cas de forte charge, certains messages de journal peuvent être perdus. Cela pourrait être une bonne chose, aider à éviter une surcharge en cascade, mais c'est quelque chose dont il faut être conscient. Certains démons syslog plus récents prennent également en charge un protocole basé sur TCP, mais la prise en charge du client est moins unifiée, alors faites vos recherches.

La connexion à ElasticSearch est plus récente mais très populaire. Ceci est principalement utile en raison du tableau de bord Kibana et de Logstash taklit (souvent appelé ELK, ElasticSearch + Logstash + Kibana). Amazon propose même une option ElasticSearch hébergée, ce qui facilite un peu le démarrage. ES utilise une API REST relativement simple, donc toute langue avec un client HTTP (lire: tous) devrait être d'accord avec la connexion à ES mais assurez-vous de faire attention au blocage des opérations réseau en cas de pannes partielles du système (c.-à-d. Assurez-vous que votre l'application ne restera pas bloquée dans un appel de journalisation qui ne réussira jamais et cessera de répondre aux demandes des utilisateurs).

Les topologies de journalisation plus complexes ne sont limitées que par votre imagination, bien que ces jours-ci, vous verrez une grande utilisation de la base de données / file d'attente / de ce que vous voulez appeler comme un point de connexion dans des systèmes de distribution de journaux très complexes. .

Du côté "sans serveur", vous souhaiterez généralement intégrer ces systèmes directement au niveau du réseau, donc envoyer des données de journal directement à syslog ou ES à partir de votre service / fonction, plutôt que d'écrire dans des fichiers locaux (bien que cela puisse faire écho à ceux-ci également pour le débogage local et le développement).

Cette réponse concerne davantage les considérations d'évolutivité - si le nombre de travailleurs peut être élevé et / ou plusieurs d'entre eux peuvent produire des journaux à un taux élevé en même temps.

Oui, l'utilisation simultanée de plusieurs fichiers journaux est une bonne pratique.

Tenter de combiner en un seul fichier journal les journaux de plusieurs travailleurs en temps réel soulèvera des problèmes:

• utiliser des mécanismes de blocage pour éviter la perte de messages ralentira les travailleurs
• les messages de journal peuvent apparaître dans le désordre dans le fichier journal combiné
• une installation de journalisation centralisée qui combine les journaux peut être surchargée en raison de la vitesse d'écriture limitée, les messages seraient perdus

Le partage de fichiers journaux (en utilisant plusieurs fichiers journaux actifs en même temps) est en soi une technique utilisée par certains fournisseurs d'hébergement offrant des services de journalisation centralisée évolutifs et hautes performances. Par exemple, lors de l'exportation de journaux vers des fichiers, StackDriver Logging de Google produit plusieurs fichiers journaux partagés. À partir des entrées du journal dans Google Cloud Storage :

Lorsque vous exportez des journaux vers un compartiment Cloud Storage, Stackdriver Logging écrit un ensemble de fichiers dans le compartiment. Les fichiers sont organisés en hiérarchies de répertoires par type et date de journal. Le type de journal peut être un nom simple comme syslogou un nom composé comme appengine.googleapis.com/request_log. Si ces journaux étaient stockés dans un compartiment nommé my-gcs-bucket, les répertoires seraient nommés comme dans l'exemple suivant:

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

Un seul compartiment peut contenir des journaux de plusieurs types de journaux.

Les répertoires feuilles ( DD/) contiennent plusieurs fichiers, chacun contenant les entrées de journal exportées pendant une période spécifiée dans le nom de fichier. Les fichiers sont partagés et leurs noms se terminent par un numéro de partition, Snou An(n = 0, 1, 2, ...). Par exemple, voici deux fichiers qui pourraient être stockés dans directory my-gcs-bucket/syslog/2015/01/13/:

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

Ensemble, ces deux fichiers contiennent les syslogentrées de journal pour toutes les instances pendant l'heure commençant à 0800 UTC. Pour obtenir toutes les entrées de journal, vous devez lire tous les fragments pour chaque période. Dans ce cas, les fragments de fichier 0 et 1. Le nombre de fragments de fichier écrits peut changer pour chaque période en fonction du volume des entrées de journal.

Ces services de journalisation haute performance peuvent également offrir des alternatives à la journalisation dans des fichiers, la gestion des fichiers journaux peut ainsi être évitée si cela vous intéresse:

• insérer des journaux directement dans une base de données. Par exemple, Stackdriver Logging peut envoyer des journaux directement dans Google BigQuery
• pousser les journaux directement dans un moteur de traitement. Par exemple, Stackdriver Logging peut envoyer des journaux dans des sujets Google Pub / Sub

Enfin - si la fusion de fichiers journaux en temps réel n'est pas une exigence, avoir plusieurs fichiers journaux peut aider à la gestion des journaux hors ligne:

• facile à concevoir des plans de sauvegarde, de compression, d'archivage et d'élimination des journaux progressifs
• le traitement parallèle de plusieurs ensembles de journaux (fichiers journaux) est possible, réduisant / évitant les effets de goulot d'étranglement
• aucun fractionnement et réécriture de fichiers nécessaires