Transport i agregacja kłód na dużą skalę

Jak analizujesz pliki dziennika z maszyn z systemem UNIX / Linux? Obsługujemy kilkaset serwerów, które wszystkie generują własne pliki dziennika, bezpośrednio lub poprzez syslog. Poszukuję przyzwoitego rozwiązania do ich agregacji i wybrania ważnych wydarzeń. Ten problem dzieli się na 3 elementy:

1) Transport wiadomości

Klasycznym sposobem jest użycie syslog do rejestrowania wiadomości na zdalnym hoście. Działa to dobrze w przypadku aplikacji logujących się do syslog, ale mniej przydatne w przypadku aplikacji zapisujących do pliku lokalnego. Rozwiązania tego problemu mogą obejmować zalogowanie aplikacji do FIFO podłączonej do programu w celu wysłania wiadomości za pomocą syslog lub przez napisanie czegoś, co spowoduje grepowanie plików lokalnych i wysłanie danych wyjściowych do centralnego hosta syslog. Jeśli jednak będziemy mieli problem z pisaniem narzędzi do wysyłania wiadomości do syslog, czy lepiej zastąpilibyśmy całość czymś takim jak Facebook Scribe, który oferuje większą elastyczność i niezawodność niż syslog?

2) Agregacja wiadomości

Pozycje dziennika wydają się należeć do jednego z dwóch typów: dla hosta i dla usługi. Komunikaty dla poszczególnych hostów to te, które występują na jednym komputerze; pomyśl o awariach dysku lub podejrzanych logowaniach. Komunikaty dotyczące poszczególnych usług pojawiają się na większości lub wszystkich hostach obsługujących usługę. Na przykład chcemy wiedzieć, kiedy Apache znajdzie błąd SSI, ale nie chcemy tego samego błędu ze 100 maszyn. We wszystkich przypadkach chcemy widzieć tylko jeden z każdego rodzaju wiadomości: nie chcemy 10 wiadomości z informacją o awarii tego samego dysku i nie chcemy wiadomości za każdym razem, gdy zostanie uszkodzony uszkodzony SSI.

Jednym podejściem do rozwiązania tego problemu jest zebranie wielu wiadomości tego samego typu w jeden na każdym hoście, wysłanie wiadomości do centralnego serwera, a następnie zebranie wiadomości tego samego rodzaju w jedno ogólne zdarzenie. SER może to zrobić, ale korzystanie z niej jest niewygodne. Nawet po kilku dniach majstrowania miałem działające jedynie podstawowe agregacje i musiałem stale sprawdzać logikę, jaką SER wykorzystuje do korelowania zdarzeń. Jest to mocne, ale trudne zagadnienie: potrzebuję czegoś, co moi koledzy mogą odebrać i wykorzystać w jak najkrótszym czasie. Reguły SER nie spełniają tego wymagania.

3) Generowanie alertów

Jak powiedzieć naszym administratorom, kiedy dzieje się coś interesującego? Czy wysłać e-mail do skrzynki odbiorczej grupy? Wstrzyknąć do Nagios?

Jak więc rozwiązujesz ten problem? Nie oczekuję odpowiedzi na talerzu; Mogę sam opracować szczegóły, ale świetna byłaby dyskusja na wysokim szczeblu na temat tego, co z pewnością jest wspólnym problemem. W tej chwili używamy pomieszania zadań cron, syslog i kto wie, co jeszcze znaleźć zdarzenia. Nie jest to rozszerzalne, łatwe w utrzymaniu ani elastyczne i dlatego brakuje nam wielu rzeczy, których nie powinniśmy.

Zaktualizowano: już używamy Nagios do monitorowania, co jest świetne dla wykrytych hostów / usług testowych / itp., Ale mniej przydatne do zgarniania plików dziennika. Wiem, że dla Nagios dostępne są wtyczki dziennika, ale interesuje mnie coś bardziej skalowalnego i hierarchicznego niż alerty dla poszczególnych hostów.

Użyłem trzech różnych systemów do centralizacji logów:

1. Syslog / syslog-ng przekazywanie do jednego hosta
2. Zenoss do agregowania i ostrzegania o zdarzeniach
3. Splunk do agregacji i wyszukiwania logów

W przypadku nr 3 zwykle używam syslog-ng do przekazywania wiadomości z każdego hosta bezpośrednio do splunk. Może także bezpośrednio analizować pliki dziennika, ale może to być trochę uciążliwe.

Splunk jest całkiem niesamowity do wyszukiwania i kategoryzowania dzienników. Nie używałem splunk do powiadamiania o logach, ale myślę, że jest to możliwe.

Możesz spojrzeć na OSSEC, kompletny HIDS typu open source, analizuje logi i może wyzwalać akcje lub wysyłać pocztę w przypadku alertów. Alerty są wywoływane przez zestaw prostych reguł opartych na XML, uwzględniono wiele wstępnie zdefiniowanych reguł dla różnych formatów logów i można dodawać własne reguły

http://www.ossec.net/

Spójrz na Octopussy . Jest w pełni konfigurowalny i wydaje się odpowiadać na wszystkie Twoje potrzeby ...

PS: Jestem twórcą tego rozwiązania.

Musisz przyjrzeć się systemowi monitorowania, na przykład Zenoss Core . Między innymi napisano na stronie wprowadzenia:

Monitorowanie i zarządzanie zdarzeniami Zenoss zapewnia możliwość agregowania informacji o logach i zdarzeniach z różnych źródeł, w tym monitorowania dostępności, monitorowania wydajności, źródeł syslog, źródeł pułapek SNMP, dziennika zdarzeń Windows.

Zobacz, jakie narzędzie używasz do monitorowania serwerów .