Comment avez-vous implémenté la gestion des journaux sur vos serveurs?

J'essaie de comprendre comment d'autres personnes implémentent leurs systèmes de gestion des journaux.

J'ai 20-30 serveurs Linux et quelques boîtes Windows (la plupart virtualisées). Nous utilisons beaucoup de scripts Perl et Bash pour effectuer la plupart de nos travaux automatisés et j'essaie de standardiser leur journalisation.

J'ai regardé log4perl et log4sh pour la journalisation des scripts et syslog-ng pour obtenir tous les journaux sur un serveur de journalisation centralisé. J'ai également lu sur Splunk, même si cela ressemble à l'édition entreprise est assez cher et je pourrais dépasser la limite de licence gratuite avec tous mes serveurs.

J'ai vu d'autres outils comme swatch et logcheck, mais je ne suis pas sûr de savoir comment toutes ces pièces s'assemblent ... Toutes les recommandations seraient grandement appréciées!

J'ai environ 30 serveurs, et j'utilise simplement syslog pour envoyer tous les journaux à un seul serveur de journalisation. Pour la sauvegarde, toutes les machines sont également configurées pour stocker leurs propres journaux localement pendant quelques jours, en utilisant logrotate pour prendre en charge la rotation et la suppression des anciens journaux.

Chacun de mes serveurs d'applications exécute un petit script perl pour envoyer leurs journaux à syslog, qui les transmet ensuite à l'hôte de connexion (script perl ci-dessous).

Ensuite, sur l'hôte de connexion, nous avons des scripts personnalisés similaires à logcheck qui surveillent essentiellement les journaux entrants pour tout élément suspect.

Nous avons également tous les e-mails de chaque hôte allant à un seul endroit, de sorte que si un programme se plaint de cette façon, nous recevons tous les messages. Cela pourrait théoriquement aller dans une seule boîte aux lettres sur laquelle un programme pourrait agir et analyser.

Voici mon script perl de journalisation. Il fonctionne en canalisant la sortie du programme dedans, puis il syslog la sortie et la recrache pour que vous puissiez l'envoyer ailleurs (j'envoie au multilog). Vous pouvez également lui donner l'option -q pour simplement aller dans syslog.

#!/usr/bin/perl

use Sys::Syslog;
use Getopt::Long;

$SERVER_NAME = `hostname`;
chomp $SERVER_NAME;
$FACILITY = 'local0';
$PRIORITY = 'info';

GetOptions ('s=s' => \$SERVER_NAME, 'f=s' => \$FACILITY, 'p=s' => \$PRIORITY, 'q+' => \$quiet);

#print "$SERVER_NAME\n$FACILITY\n$PRIORITY\n";

#Sys::Syslog::setlogsock('unix');
openlog ($SERVER_NAME,'ndelay',$FACILITY);

if (!($quiet)) {syslog($PRIORITY,"Logging Started -- Logger version 1.1");}

$| = 1;

while (<>) {
    if (!($quiet)) {print $_ unless $_ =~ /^\s+$/};
    chomp;
    syslog($PRIORITY,$_) if $_;
}

closelog;

$| = 0;

Bien que je ne l'ait pas encore implémenté, je prévois de déplacer toutes mes machines génératrices de journaux vers rsyslog et d'implémenter un serveur de type bastion qui fonctionnera comme le collecteur de syslogs. À partir de là, je pense que la version gratuite de Splunk peut faire tout ce dont j'ai besoin pour extraire des informations.

Maintenant, juste pour l'implémenter ...

J'utilise un hôte syslog central. Chaque système de périphérie envoie * .debug à l'hôte de connexion central. L'hôte syslog central exécute syslog-ng et a des règles pour diviser les journaux afin que chaque machine génère ses propres fichiers nommés pour ce jour. Il décharge également tout dans un seul fichier, contre lequel j'exécute un descendant de logcheck.sh.

Une fois par jour, je lance un compacteur de journaux, qui zippe tous les journaux de plus de 7 jours et supprime tout ce qui date de plus de 28 jours. Entre les deux, il donne aux journaux une durée de vie prévue de 35 jours sur le serveur, ce qui signifie que tous les journaux doivent se rendre aux sauvegardes mensuelles, où ils peuvent être récupérés jusqu'à deux ans.

C'est un stockage intensif, mais semble être le meilleur moyen d'assurer la couverture.

Pour la journalisation centralisée, je recommande fortement LogZilla . Nous l'utilisons depuis plus d'un an maintenant et nous l'adorons absolument. L'interface utilisateur est extrêmement facile à apprendre et à utiliser et l'installation m'a pris environ une heure.

Même si vous ne le faites pas, vous devriez vraiment essayer de vous éloigner de la surveillance basée sur des scripts car c'est exactement ce que vous obtenez ... la surveillance. Ce que vous devriez essayer d'atteindre, c'est la gestion. La réparation des problèmes sur les haut-parleurs, etc. réduira considérablement le nombre de "feux" déclenchés par la surveillance basée sur les scripts. Voici un très bon article sur la gestion de Syslog:

http://www.cisco.com/en/US/technologies/collateral/tk869/tk769/white_paper_c11-557812.html

Nous utilisons une appliance de LogLogic pour la journalisation de notre entreprise. Il est basé sur syslog, donc toutes les boîtes * nix n'ont aucun problème à l'utiliser; il y a une petite application qui doit être installée sur les serveurs Windows. Je peux rechercher tout ce que je veux, y compris les requêtes REGEX, et il semble être capable de gérer un peu de charge (notre configuration Active Directory génère à elle seule une quantité ahurissante de trafic).

Pour le serveur de journalisation centralisé, vous pouvez jeter un œil à mon projet Octopussy .

C'est beaucoup de travail au début, mais après, vous pouvez faire beaucoup de choses avec ces journaux!

Voici un tutoriel que j'ai écrit qui couvre tous les aspects de la journalisation et de l'analyse centralisées.

Lien: http://crunchtools.com/centralizing-log-files/