Journalisation centralisée du réseau - Syslog et alternatives? [fermé]

Question

Au travail, nous construisons une application distribuée (éventuellement sur plusieurs machines d’un réseau local, éventuellement plus tard sur plusieurs continents sur un réseau WAN + VPN). Nous ne voulons pas de fichiers journaux locaux pour chaque machine (remplir son disque et impossible à afficher de manière globale), nous devons donc centraliser la journalisation sur le réseau. La plupart des journaux ne seront pas importants, donc UDP leur convient, mais certains sont des alertes importantes qui font perdre de l'argent et doivent être distribués de manière fiable, ce qui implique TCP. Nous craignons d'encombrer le réseau si le protocole de journalisation est trop bavard ou de faire glisser les applications vers une analyse si elle ne répond pas.

Certaines des possibilités que j'ai envisagées sont les suivantes:

• syslog (cela semble parfait, mais mon chef a un animus contre cela, je ne serai peut-être pas en mesure de le choisir).
• scribe sur Facebook (mais cela semble un peu lourd avec un serveur sur chaque machine - chaque message de journal n'a pas besoin d'une ultra-fiabilité).
• en utilisant une file d'attente de messages telle que rabbitmq , qui peut avoir plusieurs files d'attente ajustées à différents niveaux de sécurité des transactions.
• pire des cas, je peux écrire mon propre à partir de zéro.

Avez-vous d'autres suggestions? Quelles solutions d’enregistrement centralisé avez-vous utilisées et quelle a été leur efficacité?

Modifier: je me suis penché vers scribe, car sa conception avec enregistrement et retransmission dissocie l'application en cours d'exécution de la latence du réseau. Mais après avoir eu du mal à l’installer, j’ai trouvé que (1) il n’était pas disponible sous forme de paquet binaire - de nos jours, c’est impardonnable - et (2) que cela dépend intimement d’une bibliothèque (épargne) qui n’est pas non plus disponible comme paquet binaire! Et le pire de tout, il ne serait même pas compiler correctement. Ce n'est pas un code de qualité pour l'édition, même en open source.

Answer 1

Nous avons utilisé avec succès ZeroMQ les journaux d'un scénario d'application distribuée, comme le vôtre. C'est très fiable et incroyablement rapide. Nous sommes passés à ZeroMQ après une implémentation pas si réussie avec Spread . Dans notre configuration, un seul serveur ZeroMQ est capable de gérer plus de 70 journaux différents à partir d'une application distribuée moyennement occupée. Il reçoit des données du réseau local et via Internet.

Si vous avez besoin d'une comparaison détaillée du serveur de files d'attente, consultez cette page à partir du wiki de Second Life .

J'espère que ça aide!

Answer 2

Il y a plusieurs alternatives récemment. Notamment, Scribe n'est plus maintenu. Facebook a développé son successeur appelé Caligraphus, qui n'est pas à source ouverte. Voici une liste d'alternatives.

• syslog: installé sur toutes les distributions Linux
• Fluentd : enregistreur léger basé sur C + Ruby, qui traite les journaux en tant que flux JSON
• Flume : développé à Cloudera, écrit en Java et fonctionne bien avec les écosystèmes Hadoop
• Apache Kafka : mise au point sur LinkedIn, architecture basée sur la technologie d'extraction
• Scribe: code source ouvert par Facebook, mais plus maintenu

Avertissement: je suis un partisan du projet Fluentd.

Answer 3

Syslog est utile si vous avez l’intention de vous concentrer uniquement sur les journaux d’infrastructure (au niveau du système, par exemple). J'ai entendu dire que le serveur KIWI Syslog était un bon choix, même s'il ne l'a pas essayé moi-même. D'un autre côté, si vous souhaitez consigner des éléments liés à une application, un syslog n'est peut-être pas la meilleure option pour cela. Si vous utilisez des services de journalisation Apache (log4j, log4xxx et les autres), logFaces serait un bon Cette solution est spécialement conçue pour regrouper plusieurs applications en un seul endroit. Fonctionne à la fois avec les connexions TCP ou UDP et possède un visualiseur de journal et une intégration de base de données décents.

Divulgation : je suis l'auteur de ce produit.

Answer 4

Les autres exemples sont peut-être intéressants, mais j'ai eu de la chance avec Syslog-NG . Il est extrêmement flexible et configurable. bien qu’il soit assez facile de le récupérer et de faire quelque chose d’utile avec rapidement.

Answer 5

Vous pouvez également envisager d'utiliser des alertes SNMP.

Answer 6

a examiné toutes les alternatives recommandées dans ce fil de discussion. Recherché quelque chose de python. Nous avons cherché davantage sur Google et trouvé une sentinelle https://getsentry.com/welcome/ Open source, bien documenté. Devrait être fiable à des fins commerciales, car il existe une entreprise basée sur cela.