Linux: comment envoyer de nouvelles lignes dans des fichiers journaux vers un syslog distant?


8

Nous avons plusieurs applications qui génèrent leurs propres fichiers journaux en texte brut, que je voudrais transmettre à un serveur syslog distant pour une journalisation centralisée. Je n'ai pas accès à rootces machines et je ne peux pas non plus reconfigurer syslogpour rediriger la sortie vers une machine distante.

J'ai trouvé des solutions en ligne, mais ce sont principalement des scripts bash faits maison, et je recherche quelque chose de plus robuste qui soit adapté à la mise en œuvre dans un environnement de production potentiellement à volume élevé.

De préférence quelque chose conçu avec un oeil pour une petite empreinte, un démon d'arrière-plan qui continue de fonctionner, qui peut suivre un grand nombre de lignes, etc. - Quelles solutions sont actuellement disponibles?


3
Avez-vous regardé le module d'entrée de fichier texte pour rsyslog?
yoonix

@yoonix: Non, je ne l'ai pas fait, mais je vais le faire :)
Michael Martinez

3
Uhm, syslog peut envoyer vers des serveurs syslog distants. Configurez votre journal système local pour envoyer à un serveur distant. Ensuite, accédez à votre syslog local via les appels syslog standard ou en utilisant un enregistreur ou quelque chose.
Zoredache

4
Pourquoi n'écrivez-vous pas vos fichiers journaux dans un canal nommé et faites écouter un démon qui les envoie sur leur chemin serverfault.com/questions/189477/…
user9517

3
Vous ne devriez pas avoir à modifier l'application, placez simplement un canal nommé du même nom que le fichier journal dans lequel l'application écrit.
user9517

Réponses:


13

Vous avez déjà rejeté les "scripts bash d'autres personnes", mais c'est une solution assez courante - une utilisation créative de la loggercommande peut suivre un fichier et envoyer son contenu ailleurs.
Personnellement, je ne ferais pas cela dans un environnement de production.


Une meilleure option qui nécessite moins de piratage de scripts est utilisée rsyslogdet le module d'entrée de fichier texte comme yoonix mentionné - Ceci est une solution assez décente bien qu'il existe un potentiel de perte de lignes lors d'une rotation de fichier, et si vous êtes sur un système Linux avec rsyslogcomme votre démon syslog, il n'y a pas beaucoup de travail supplémentaire requis.

syslog-ngprend également en charge une source d'entrée de fichier avec des fonctionnalités similaires à rsyslog.


À mon humble avis, la meilleure solution - même si elle nécessite de modifier l'application générant ces journaux - est de se connecter directement à syslog. Vous ne voulez pas passer par des étapes intermédiaires, des fichiers, etc. - syslogest le SYStem LOGger, et les choses qui écrivent des journaux sur une plate-forme Unix devraient les envoyer à syslog.
L'implémentation de ceci est, malheureusement, laissée comme un exercice pour le lecteur (et le développeur d'application) et peut ne pas être possible si vos développeurs sont inexistants, paresseux ou incompétents ....


7
@MichaelMartinez Vous modifieriez la rsyslogconfiguration en cours d'exécution sur le système. Vous ne devez PAS exécuter deux démons Syslog. Pour ne pas être impoli, mais vous devez arrêter d'essayer de le faire mal *: Chaque solution appropriée à ce scénario nécessite des actions administratives (root) sur le serveur ou une modification de l'application. Vous allez devoir faire face à cette réalité et faire face à tout groupe au sein de votre organisation qui a ses racines dans les systèmes en question, sinon cette question est hors sujet (vous essayez de contourner les politiques de votre organisation) ....
voretaq7

5
@Michael Tout cela nous dit que quelqu'un essaie de forcer la mauvaise équipe à implémenter le correctif.
Andrew B

4
@MichaelMartinez à mon humble avis, cela ressemble à une voie assez rapide vers des niveaux de dette technique paralysants.
Sirex

2
@Sirex. Quoi qu'il en soit, c'est la voie des choses. Je travaille dans une organisation qui emploie des dizaines de milliers de personnes, dont la plupart sont des techniciens (ingénieurs, développeurs, opérateurs, etc.)
Michael Martinez

5
J'imagine. En général, j'ai constaté à long terme qu'il n'y a pas de médailles dans la victoire des batailles auto-infligées. Lorsque la dette technique arrive au point où elle affecte ironiquement l'entreprise, les gens qui ont travaillé avec diligence pour éviter l'éléphant dans la pièce ont tendance à porter la boîte, selon mon expérience. Donc je dirais de couvrir ton cul et de faire en sorte que quelqu'un accepte d'écrire les inconvénients de cela.
Sirex

6

Vous pouvez utiliser logstash avec l' entrée de fichier et la sortie syslog .

Par exemple, créez une configuration avec le ou les fichiers que vous souhaitez surveiller et les informations de votre serveur syslog.

file-to-syslog.conf:

input { file { path => "/var/log/kern.log" } }
output {
    syslog {
        facility => "kernel"
        host => "syslog.example.com"
        port => 514
        severity => "informational"
    }
}

Le journal de démarrage avec

java -jar logstash-1.2.2-flatjar.jar agent -f file-to-syslog.conf

+1. si l'utilisation de l'entrée de fichier de rsyslog n'est pas une option, logstash est la prochaine meilleure chose. À bien des égards, c'est mieux à long terme.
Sirex

Je ne connais pas ça. S'il fait ce dont j'ai besoin, cela m'aurait évité de pirater coreutils et util-linux.
Michael Martinez

oui, la configuration va ressembler un peu à ceci: pastebin.com/xeC9hxD3
Sirex

ressemble à un outil très cool, mais certainement exagéré pour ce dont j'ai besoin ici. logstash est son propre service, avec une interface Web, nécessite Java, etc. Je continuerai à utiliser mon enregistreur de fichiers qui est léger, à faible encombrement, optimisé pour les performances. ... Mais, merci d'avoir suggéré logstash car je peux en voir le besoin dans d'autres situations à l'avenir!
Michael Martinez

ouais c'est un outil jruby rempli de pots. Le gui est en fait kibana qui est facilement intégré mais est en fait un projet séparé, il n'est donc pas nécessaire uniquement pour l'analyse des messages. C'est essentiellement un couteau suisse de l'exploitation forestière. Vous définissez les entrées et les sorties et au milieu, vous pouvez éventuellement grok les journaux, ce qui leur donne le contexte. - L'informatique est probablement exagérée pour vous, sauf si vous souhaitez également utiliser elasticsearch sur vos données de journal.
Sirex

4

J'ai piraté ensemble tail.cet logger.cen un seul programme compilé à petite empreinte (binaire) qui est léger, rapide et stable. Tant qu'il dispose d'un accès en lecture aux fichiers journaux, il fonctionne sans avoir besoin du privilège root.

J'ai également apporté quelques améliorations à l'enregistreur natif et ajouté une nouvelle capacité (facultative) d'insertion d'une chaîne de texte au début de chaque ligne de journal avant qu'elle ne soit envoyée au serveur de journal. Le résultat est un programme qui peut être exécuté par lui-même, sans avoir besoin d'utiliser des tubes shell (c'est-à-dire pas besoin tail logfile | logger). Il s'exécutera pour toujours jusqu'à ce qu'il soit explicitement tué ou qu'il rencontre une erreur d'écriture sur la prise réseau. Il continue même de s'exécuter si le fichier journal est tourné ou même disparaît (il continuera simplement à regarder si le fichier réapparaît.)

Il est facile à utiliser: donnez-lui simplement un ou plusieurs fichiers journaux à surveiller, et chaque fois qu'une nouvelle ligne est écrite dans le fichier, il enverra une copie de cette ligne au serveur syslog local ou distant que vous spécifiez. Plus la chaîne de texte supplémentaire si vous utilisez cette option.

En fait, j'ai terminé le programme en décembre, mais j'attendais que Yahoo prenne le droit d'auteur et le rende disponible, ce qu'ils ont maintenant fait. (Je l'ai écrit dans le cadre de mon travail chez Yahoo).

informations sur le programme filelogger et lien de téléchargement:


@slm: J'ai réécrit comme vous l'aviez demandé
Michael Martinez

Très utile, merci Michael. Y a-t-il une chance que vous le conditionniez pour l'installation de debian apt-get?
joelparkerhenderson

@joelparkerhenderson. Salut Joel. Malheureusement, probablement pas parce que je ne travaille pas avec Debian. Avez-vous essayé de copier le binaire sur votre système et de voir s'il fonctionne?
Michael Martinez

1

Il existe plusieurs façons de résoudre ce problème. Mais très, très première chose que vous devez faire est: transmettre les journaux à l' aide syslog lui - même .

Syslog (et de nombreux remplacements pour syslog) ont des fonctionnalités intégrées pour transférer la journalisation vers un autre serveur syslog à une adresse différente. Vous pouvez facilement le faire en modifiant le fichier de configuration et en ajoutant l'adresse à laquelle transférer l'installation. Par exemple, ajouter cette ligne à:

*.*    @192.168.1.1

... transmettrait toutes les installations à la machine au 192.168.1.1, qui (espérons-le) fait fonctionner le service. L'exemple que je donne ici est pour rsyslog, qui est le serveur stock syslog sur Debian, bien qu'il devrait fonctionner pour beaucoup d'autres. Consultez la documentation de votre implémentation de syslog avec man sysloget voyez ce qu'il dit à propos du "transfert".

Le serveur syslog distant peut être tout ce que vous aimez. Il existe même des produits, comme Splunk , qui regroupent ces journaux dans une seule vue avec un tableau de bord Web, une recherche, des notifications événementielles, etc. etc. Vous pouvez en voir plus ici: http://www.splunk.com/ If qui ne répond pas à vos besoins, vous pouvez utiliser autre chose. Il y a même des serveurs syslog qui seront transférés dans une base de données SQL!

Bien sûr, vous pourriez écrire votre propre script / programme / service pour le faire pour vous, mais pourquoi réinventer la roue quand elle est à la fois faite pour vous et déjà donnée?


Edit: Alors je suis retourné et relu la question, et j'ai remarqué plusieurs commentaires. Cela ressemble:

  1. vous souhaitez agréger vos journaux d'application
  2. vous n'avez pas accès à root
  3. votre (vos) application (s) vider simplement le texte quelque part
  4. votre ou vos applications ne savent pas écrire dans le syslog local
  5. vous n'avez aucun contrôle sur le code source de votre application

Abordons donc chacun d'eux dans l'ordre:

  1. syslog était destiné à regrouper les journaux. Vous pouvez utiliser tout ce que vous aimez, mais il y a une raison pour laquelle cela existe depuis longtemps. Il est bien testé, bien débogué, bien documenté, bien connu et pour la plupart des plates-formes * nix presque universellement prises en charge dans une version ou une autre.
  2. nous n'avons pas besoin d'accéder à rootpour configurer la journalisation. Nous avons seulement besoin d'accéder à l'API syslog. rootn'est pas obligatoire pour écrire dans le syslog; si tel était le cas, tous les services qui abandonnent les privilèges ne pourraient pas écrire de diagnostics dans les fichiers journaux.
  3. Re: vidages de texte, c'est normal. cependant, vous devriez pouvoir utiliser un sous-shell pour diriger la sortie de STDERR et STDOUT vers un programme qui appelle l'API syslog. Ce n'est pas sorcier, c'est loin d'être fragile, et c'est bien documenté. En fait, c'est l'une des raisons pour lesquelles la redirection de sortie existe même. Une commande simple qui pourrait être lancée dans un script shell unique serait:

    (my-application 2> & 1 | my-syslog-shunt) &

  4. si vous avez la possibilité de modifier le code source de votre application, vous devez y écrire un shunt pour vider la sortie texte dans syslog au lieu d'un fichier texte brut. Cela ne devrait pas être trop difficile; tout ce que vous faites est de prendre les lignes que vous voulez sortir et de les envelopper avec un appel. Toutefois....

  5. vous n'avez peut-être pas du tout accès au code source, vous ne pouvez donc pas le faire. Ce qui signifie que quelque chose comme # 3 ci-dessus fonctionnerait bien.


deux raisons: (1) simplement parce que, comme déjà mentionné, il n'y avait pas de root ou sudo sur les cases en question. (2) "l'enregistreur" lui-même peut transmettre au serveur distant, mais a une limite de 400 caractères par ligne de journal, ce qui n'est pas approprié pour les journaux Apache. Quoi qu'il en soit, j'ai déjà mis au point une solution personnalisée qui fait exactement ce dont j'avais besoin (et améliore également le «logger»). Voir ma réponse ici pour "filelogger"
Michael Martinez

4. Syslog n'est pas seulement un flux de fichiers que je peux ouvrir et écrire du texte. Le shunt que j'écrirais devrait ouvrir un socket sur le port UDP sur lequel syslog écoute?
Noumenon

1
@Noumenon, je ne suis pas tout à fait clair sur votre intention, mais je suppose que vous voulez diriger la sortie du programme dans le journal système, ce qui peut être fait avec la commande logger. linux.die.net/man/1/logger
Avery Payne

@AveryPayne Alors comme Runtime.exec("logger ...") OK, merci.
Noumenon

0

Je réponds à ma propre question.

swatch a peut-être fonctionné, mais je n'ai pas réussi à faire fonctionner le module Sys :: Syslog de perl sur l'hôte, et / usr / bin / logger installé sur l'hôte ne prend pas en charge la journalisation sur le serveur distant (util-linux-ng- 2.17.2).

Donc, la première chose que j'ai faite a été de télécharger le code source d'util-linux-2.20.1 pour lequel le programme d'enregistrement prend en charge la journalisation à distance. Lors des tests, il est devenu évident qu'une limite était imposée au nombre de caractères autorisés sur la ligne de journal. En fouillant dans le code source, j'ai trouvé une limite de 400 caractères codée en dur. (Si vous ne me croyez pas, exécutez "strings / usr / bin / logger | grep 400" sur n'importe quel système Linux).

Cette limite n'est pas acceptable pour la journalisation de type apache (y compris nodejs), j'ai donc modifié le code et augmenté la limite à 4096. Pendant que j'y étais, j'ai également ajouté une nouvelle option de ligne de commande qui permet d'insérer une option chaîne de texte au début de chaque ligne de journal. Je l'ai fait parce que les journaux nodejs n'incluent pas le nom d'hôte comme on pourrait le voir dans apache.

À ce stade, j'ai pu exécuter un script shell avec "tail -F -n 0 [logfile] | ./modified_logger ...." et cela a fonctionné. Mais j'avais quelques inquiétudes à propos de l'exécution de cela depuis supervise (daemontools) ou même en arrière-plan, car si l'un ou l'autre côté du tuyau se termine, il y a un risque que tout le tuyau se termine. J'avais également des inquiétudes (bien que non testées) sur les performances.

J'ai donc décidé de combiner la fonctionnalité de queue avec la fonctionnalité d'enregistreur dans un seul fichier binaire exécutable qui contournerait la nécessité d'utiliser des canaux Unix ou des programmes externes. J'ai fait cela en piratant tail.c de gnu coreutils et en incorporant ce dont j'ai besoin dans le programme d'enregistrement modifié.

Le résultat est un nouveau binaire (taille 117k) que j'appelle "filelogger" et qui surveille en permanence un ou plusieurs fichiers et enregistre chaque nouvelle ligne dans un syslog local ou distant, via UDP ou TCP. Il fonctionne comme un charme. J'ai pu faire une petite analyse comparative et il enregistre environ 17000 lignes (1,8 Mo) en environ 3 secondes sur des sous-réseaux avec un vlan et quelques commutateurs physiques entre eux, sur un serveur distant exécutant syslog-ng.

pour exécuter le programme, vous faites quelque chose comme ceci (soit au premier plan, en arrière-plan ou supervisé avec daemontools):

./filelogger -t 'access' -d -p local1.info -n [hôte de connexion distant] -u / tmp / ignoré -a $ (nom d'hôte) / tmp / monfichier1 / tmp / monfichier2 ...

/ tmp / monfichier1 et / tmp / monfichier2 sont les fichiers surveillés.

Le "-a" est la nouvelle option que j'ai ajoutée. Dans ce cas, j'insère le nom d'hôte local au début de chaque ligne de journal.

Ces solutions étaient exactement le type de solution que je cherchais lorsque j'ai posé la question et, comme il s'est avéré, elles n'existaient pas avant que je ne les fasse moi-même. :)


Je vais probablement rendre cela disponible sur sourceforge à un moment donné. Ses avantages sont que son très faible encombrement, léger, facile à utiliser et optimisé pour les performances. Une fois le texte du message lu, tout le traitement est effectué dans la mémoire tampon puis transféré directement sur le socket.
Michael Martinez


4
J'essaie de ne pas être dur, mais je suis vais être franc: Cette solution n'existait pas parce qu'il est terrible. Plutôt que d'interfacer avec les autres groupes de votre organisation et de mettre en œuvre une solution standard saine, vous avez mis en place un hack avec du code totalement non pris en charge que vous devez maintenant tester / déboguer / maintenir à l'avenir. Vous avez ignoré facilement 50 ans d'expérience vous dire « Ne fais pas ça » - J'espère pour vous cela ne souffle pas dans votre visage, mais vous êtes tout à fait, sans aucun doute le faites mal ici ...
voretaq7

1
Ouais. à droite .... C'est ainsi que l'open source va de l'avant, mec. Si tout le monde le faisait à votre façon, il n'y aurait aucun progrès. Comment pensez-vous que GNU, Linux et tout ce qui en découle sont nés? Les gens font exactement le genre de choses que j'ai faites ici. Si cela vous fait vous sentir mieux, j'ai l'intention d'intégrer mon code dans notre système de gestion de packages, où tout le monde ici dans l'organisation est libre de l'utiliser, de le déployer et de l'améliorer, s'il le souhaite.
Michael Martinez

Et pour info, ce n'est pas une solution terrible. Au contraire, c'est un outil très utile. Lorsque je cherchais des solutions en ligne la semaine dernière, je suis tombé sur d'autres personnes demandant où trouver cette fonctionnalité exacte.
Michael Martinez
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.