Centralisation des logs avec Graylog

Rédigé par -Fred- Aucun commentaire

L'auto-hébergement c'est super mais quand on commence à avoir plusieurs services qui tournent, il faut quand même superviser un peu tout ça. Jusqu'à présent, je comptais sur quelques scripts pour cela. Mon serveur a peu d'activité et ça suffit à peu près même si ce n'est pas parfait. L'un des problèmes tient au fait que j'utilise plusieurs machines virtuelles (via virtualbox) et que je dois donc tout traiter machine par machine. Un autre problème est lié au fait que côté visualisation, ben ça reste des logs plus ou moins brutes. Bref, il ne me manquait qu'un peu de temps pour travailler sur ce sujet.

Raisons de ce choix

Force est de constater que pas mal de solutions diverses existent. Après une recherche rapide, deux d'entre elles ont retenu mon attention. La stack ELK (Elasticsearch + Logstash + Kibana) et Graylog (+ elasticsearch + mongodb). C'est cette seconde solution que j'ai décidé de déployer, non pas qu'elle soit forcement meilleure que l'autre (je n'en sais rien) mais mon cas d'usage est assez basic donc, les deux doivent faire l'affaire (je changerai peut être d'avis ensuite).

Installation de base

J'ai opté pour une installation de chacun de ces outils (mongodb, elasticsearch et graylog) à partir des .deb dans une machine virtuelle à part. Pour les fans de docker, pas de soucis non plus : http://docs.graylog.org/en/3.0/pages/installation/docker.html. Autant le dire tout de suite, graylog et elasticsearch demandent beaucoup de RAM pour fonctionner de manière convenable. Beaucoup, ça veut dire 1 Go chacun par défaut. C'est probablement peu pour une gros serveur mais pas forcement pour une machine plus modeste. J'ai tenté de réduire ces paramètres (voir les paramètres Xms et Xmx dans les fichiers de configuration) et en gros, c'est juste inutilisable. J'ai donc alloué 4 Go de mémoire vive à ma machine virtuelle sur les 8 Go installé sur mon serveur. Au passage, le problème serait à peu près identique avec la stack ELK. Pas de jaloux donc...

Quoi récupérer ?

Dans un premier temps, je me concentre sur les services qui sont ouverts sur l'extérieur, à savoir le serveur mail et le serveur web. J'utilises pour cela Rsyslog sur chaque machine dont je veux rapatrier les logs. Dans le fichier "/etc/rsyslog.conf ", ajouter pour envoyer les logs UDP (@) ou TCP(@@) (dans le cas présent, j'envoie mes logs en UDP d'où le commentaire sur la ligne correspondant à TCP):

*.* @IP_MACHINE_GRAYLOG:514;RSYSLOG_SyslogProtocol23Format
#*.* @@IP_MACHINE_GRAYLOG:514;RSYSLOG_SyslogProtocol23Format

Concernant les logs apache, j'ai simplement ajouté ce qui suit dans la config de chaque VHost :

ErrorLog "|/usr/bin/logger -t apache -p local0.info"
CustomLog "|/usr/bin/logger -t apache -p local0.info" combined

Je rapatrie aussi les logs de mon NAS Synology (même si cette machine n'est pas accessible de l'extérieur). Pour le faire, j'ai simplement ajouté le paquet "centres de journaux" et je n'ai eu ensuite qu'à activer le transfert de log en indiquant l'adresse IP du serveur de log, le port (514) et le protocole (UDP) à employer.

Au passage, puisque les logs ne transitent que sur mon réseau local, je n'ai pas cherché à chiffrer les échanges. C'est un choix qui n'est pas gravé dans le marbre mais dans la mesure où je considère mon réseau local sûr, pas de soucis normalement ...

Configuration serveur

Côté serveur Graylog, j'ai ajouté les règles iptables suivantes afin de rediriger l'ensemble des paquets arrivant sur le port 514 vers le port 1514, ceci afin de pouvoir les capturer ensuite :

iptables -t nat -A PREROUTING -p tcp --dport 514 -j REDIRECT --to 1514
iptables -t nat -A PREROUTING -p udp --dport 514 -j REDIRECT --to 1514

La configuration à proprement parler de Graylog s'effectue dans le fichier "/etc/graylog/server/server.conf". En fait, peu de choses à modifier si ce n'est le mot de passe admin et l'URI permettant d'accéder au serveur (ici, uniquement depuis le réseau local ; la version 3 de Graylog tout juste sortie simplifie cette partie en unifiant ces paramètres par rapport à la version 2.5 que j'avais d'abord installé). J'ai aussi modifié ce qui suit afin de ne pas répliquer les données et de toutes les regrouper dans un seul shard (à priori, je resterai quoi qu'il arrive assez loin des limites pouvant me faire reconsidérer la question) :

elasticsearch_shards = 1
elasticsearch_replicas = 0

Démarrage

Une fois cela fait, reste à lancer le tout et à prévoir de démarrer ces service à chaque démarrage :

# systemctl enable elasticsearch.service
# systemctl start elasticsearch.service

# systemctl enable mongod.service
# systemctl start mongod.service

# systemctl enable graylog-server.service
# systemctl start graylog-server.service

Après une phase de démarrage qui peut durer plusieurs minutes, Graylog est accessible via une interface web sur le port 9000. À ce stade, il faut définir des entrées dans Graylog car pour le moment, c'est un coquille vide. J'ai créé deux "input" avec un attribut "Global" (rien à modifier sinon):

  • Syslog UDP
  • Syslog TCP (au cas où mais normalement, rien ne doit arriver sur cette entrée)

Là si tout va bien, dans l'onglet "search", on verra progressivement arriver nos logs et les graphs associés. Il est possible de filtrer les entrées en fonction de nos besoins, de paramétrer la période de visualisation, les champs que l'on veut voir apparaître, etc... Chose super cool, la possibilité de paramétrer des tableaux de bord dans lesquels on aura la possibilité de retrouver que l'on aura pré-paramétré. Les résultats sont présentés de manière synthétique sous forme de graphe et il est possible d'accéder rapidement aux données ayant produit ces tableaux.

Conclusion

Une fois installé et configuré, Graylog est réactif et intéressant à l'usage. C'est visuel et intuitif. :D . Difficile de tout décrire en quelques ligne ici. Cela fera donc l'objet d'un autre billet dans quelque temps ...

Écrire un commentaire

Quelle est le dernier caractère du mot mct14 ?

Fil RSS des commentaires de cet article