Nous avons trois serveurs qui exécutent des programmes python qui exécutent des tâches d'analyse de données dans une tmuxsession. La méthode que nous utilisons en ce moment consiste à connecter chacun d'eux à la tmuxsession et à regarder la sortie sur la ligne de commande.

Cette méthode est fastidieuse, donc ce que nous recherchons est une solution qui automatise la surveillance de la progression du programme (sortie sur CLI) pour plusieurs serveurs en même temps. Nous aimerions idéalement une solution d'interface utilisateur Web, mais une CLI conviendrait également parfaitement.

Merci pour la lecture.

Chaque fois que vous exécutez des commandes ad hoc de longue durée, vous devez prendre du recul et repenser votre processus, car cela devrait être automatisé, y compris la gestion des erreurs.

Plutôt que de se connecter aux serveurs pour voir l'état, une meilleure approche consiste à pousser ces informations. Vous pouvez faire une grande variété de choses si vous souhaitez écrire un tas de code personnalisé, mais la chose la plus simple est probablement de commencer à envoyer la sortie via syslog à un système de journalisation centralisé (syslog lui-même, ou ELK, ou autre). De cette façon, vous pouvez tout surveiller depuis un emplacement central.

À l'avenir, si ce n'est pas une tâche ponctuelle, la surveillance devrait être automatisée. Autrement dit, vous ne devriez jamais avoir à regarder les journaux pour voir si les choses progressent comme elles le devraient. Au lieu de cela, vous devez supposer qu'ils le sont (et continuer avec d'autres travaux) jusqu'à ce que votre alerte se déclenche . Il s'agit d'un investissement de temps pour obtenir des alertes fiables et à large couverture, mais à mesure que vos systèmes deviennent de plus en plus complexes, cela sera payant car vous n'avez pas à tout surveiller à chaque fois que vous modifiez quoi que ce soit .

Graylog

Étant donné que deux personnes vous ont déjà conseillé de repenser votre processus actuel (ce que j'appuie car cela vous causera des nuits blanches à un moment donné;)), je vais emprunter une autre voie et recommander un logiciel spécifique qui - à mon avis - convient à la plupart des vos besoins: Graylog .

J'ai implémenté et utilisé quelques piles ELK à la fois pour l'agrégation de journaux et pour la veille stratégique, et j'ai également exécuté / maintenu le graylog pendant environ deux ans chez mon employeur actuel. Je recommande graylog car il a les fonctionnalités suivantes intégrées et est - à mon avis - un peu plus facile à configurer et à entretenir:

• Une interface web
• Capacités multi-utilisateurs
• Alerte

Pour autant que je comprends votre scénario, il semble que vous deviez agir ou être alerté de certains événements qui apparaissent dans votre flux de messages de journal. Si nous regardons les fonctionnalités de Graylog :

Déclenchez des actions ou recevez une notification lorsque quelque chose nécessite votre attention, comme les tentatives de connexion infructueuses, les exceptions ou la dégradation des performances.

Idées: envoyez un e-mail ou un message Slack à votre équipe. Créez une nouvelle machine pour équilibrer la charge de traitement. Bloquer automatiquement les plages d'adresses IP dans vos pare-feu lorsqu'une attaque est détectée.

Pour essayer Graylog, je recommande les deux étapes suivantes:

• Configurez un hôte dédié accessible à tous vos hôtes d'application pour exécuter le graylog (et ses dépendances MongoDB et ElasticSearch)
• Envoyer des journaux de votre application à graylog (éventuellement sous forme de messages GELF )

Remarque: Ces deux étapes ont la capacité de remplir des pages et des pages de bonnes pratiques et devraient recevoir au moins quelques réflexions. Sans oublier que le graylog n'est pas une solution de surveillance et le graylog lui-même devrait être surveillé par un outil de surveillance approprié (comme par exemple Icinga, Prometheus, Nagios pour n'en nommer que quelques-uns).

Je suis d'accord avec @Xiong Chiamiov et je veux donner une option plus claire. Si vous voulez que chaque ligne de la CLI soit surveillée, je vous suggère de rediriger toutes les sorties vers un fichier spécifique et l'erreur vers un autre fichier, puis utilisez logstash ou filebeat pour envoyer ces deux fichiers à Elasticsearch , vous pouvez alors configurer Logtril avec Kibana pour vous permettre de visualiser, d'analyser, de rechercher et de suivre les événements du journal de plusieurs hôtes en temps réel avec une interface conviviale pour les développeurs

centralisé tmux

Bien que les autres réponses soient plus intelligentes et plus judicieuses à long terme, je pense que la solution CLI rapide et piratée mérite d'être mentionnée. Exécutez tmuxsur un serveur qui peut atteindre tous les autres. Un bon endroit pour cela serait une boîte à sauter ou un autre endroit où les gens sont généralement connectés de toute façon. Dans ce tmuxssh "central" à chaque boîte dans un volet différent et à la queue tous les fichiers journaux nécessaires. Vous pouvez utiliser ctrl- b "pour obtenir plus de volets dans un onglet tmux. Maintenant, tout ce que quelqu'un a à faire pour vérifier les choses, c'est s'attacher à la tmuxsession "centrale" et ils peuvent voir l'ensemble du cluster en un coup d'œil.

J'ai passé beaucoup de temps à créer les solutions d'interface utilisateur Web sur lesquelles vous travaillez, mais si vous en avez besoin aujourd'hui, pirater quelque chose avec tmuxpeut sauver la journée.