Jak wdrożyłeś zarządzanie logami na swoich serwerach?

Próbuję dowiedzieć się, jak inne osoby wdrażają swoje systemy zarządzania dziennikami.

Mam 20-30 serwerów Linux i kilka urządzeń Windows (większość z nich zwirtualizowanych). Używamy wielu skryptów Perla i Basha do wykonywania większości naszych automatycznych zadań i staram się ustandaryzować ich rejestrowanie.

Patrzyłem na log4perl i log4sh do rejestrowania skryptów i syslog-ng, aby uzyskać wszystkie dzienniki na scentralizowanym serwerze rejestrującym. Przeczytałem również o splunk, chociaż wydaje się, że wersja Enterprise jest dość droga i mogę przekroczyć limit bezpłatnych licencji na wszystkich moich serwerach.

Widziałem inne narzędzia, takie jak Swatch i Logcheck, ale nie jestem do końca pewien, jak te wszystkie elementy pasują do siebie ... Wszelkie zalecenia będą mile widziane!

Mam około 30 serwerów i używam zwykłego syslog, aby wysłać wszystkie dzienniki do jednego serwera logowania. W celu wykonania kopii zapasowej wszystkie komputery są również skonfigurowane do przechowywania własnych dzienników przez kilka dni, przy użyciu programu logrotate, aby zadbać o rotację i usuwanie starych dzienników.

Każdy z moich serwerów aplikacji uruchamia mały skrypt perla, aby wysłać swoje dzienniki do syslog, który następnie przesyła dalej do loghost (skrypt perla poniżej).

Następnie na loghost mamy niestandardowe skrypty, które są podobne do logcheck, które w zasadzie obserwują przychodzące logi pod kątem czegoś podejrzanego.

Mamy również wszystkie wiadomości e-mail od każdego hosta, które udają się w jedno miejsce, więc jeśli jakiś program w ten sposób złoży skargę, otrzymamy wszystkie wiadomości. Teoretycznie może to prowadzić do pojedynczej skrzynki pocztowej, na której program mógłby działać i analizować.

Oto mój skrypt do logowania w Perlu. Działa, przesyłając do niego dane wyjściowe programu, a następnie sysloguje dane wyjściowe i wypluwa je z powrotem, aby można było wysłać je gdzie indziej (wysyłam do multiloga). Możesz także podać opcję -q, aby przejść do 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;

Chociaż jeszcze go nie wdrożyłem, planuję przenieść wszystkie moje maszyny do generowania logów do rsyslog i zaimplementować serwer typu bastion, który będzie działał jako kolektor syslogów. Stamtąd myślę, że darmowa wersja Splunk może zrobić wszystko, czego potrzebuję, aby wyciągnąć informacje.

Teraz tylko go zaimplementuj ...

Korzystam z centralnego hosta syslog. Każdy system brzegowy wysyła * .debug do centralnego loghosta. Centralny host syslog uruchamia syslog-ng i ma reguły dzielenia logów, aby każda maszyna generowała własne pliki nazwane na ten dzień. Zrzuca wszystko do jednego pliku, na którym uruchamiam potomka logcheck.sh.

Raz dziennie uruchamiam logarytm dziennika, który usuwa wszystkie dzienniki starsze niż 7 dni i usuwa wszystko starsze niż 28 dni. Między nimi daje dziennikom oczekiwany czas życia na serwerze wynoszący 35 dni, co oznacza, że ​​wszystkie dzienniki powinny przechodzić do miesięcznych kopii zapasowych, gdzie można je odzyskać nawet przez dwa lata.

Zajmuje dużo miejsca, ale wydaje się być najlepszym sposobem na zapewnienie zasięgu.

W przypadku scentralizowanego rejestrowania gorąco polecam LogZilla . Używamy go od ponad roku i absolutnie go uwielbiamy. Interfejs użytkownika jest niezwykle łatwy do opanowania i użytkowania, a instalacja zajęła mi około godziny.

Nawet jeśli tego nie zrobisz, naprawdę powinieneś spróbować uciec od monitorowania opartego na skryptach, ponieważ właśnie to otrzymujesz ... monitorowanie. To, co powinieneś spróbować osiągnąć, to zarządzanie. Naprawianie problemów z najlepszymi mówcami itp. Znacznie zmniejszy liczbę „pożarów” wywołanych przez monitorowanie skryptów. Oto bardzo dobry artykuł na temat zarządzania syslog:

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

Używamy urządzenia LogLogic do logowania w naszym przedsiębiorstwie. Opiera się na syslog, więc wszystkie pola * nix nie mają problemu z jego użyciem; istnieje mała aplikacja, którą należy zainstalować na serwerach Windows. Mogę wyszukiwać wszystko, co chcę, w tym zapytania REGEX, i wydaje się, że jest w stanie poradzić sobie z dużym obciążeniem (sama konfiguracja Active Directory generuje olbrzymią ilość ruchu).

W przypadku scentralizowanego serwera rejestrującego możesz zapoznać się z moim projektem Octopussy .

Na początku jest dużo pracy, ale po tych logach możesz zrobić wiele rzeczy!

Oto samouczek, który napisałem, który obejmuje wszystkie aspekty scentralizowanego rejestrowania i analizy.

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