Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


23.06.2017

Z autotrackingiem

Aver PTC500
20.06.2017

Do budynków i na zewnątrz

Ubiquiti UAP-AC-HD
16.06.2017

Monitor 16:3

BenQ BH281
13.06.2017

Monitorowanie

Axence nVision 9.2
12.06.2017

Exatel Security Day –...

Już 20 czerwca w Warszawie rozpocznie się druga edycja Exatel Security Day. W tym roku...
09.06.2017

Automatyzacja...

Red Hat Ansible
06.06.2017

Optymalizacja wydatków

Snow for Office 365
01.06.2017

Zarządzanie końcówkami

baramundi Management Suite 2017
12.05.2017

SAP Executive Forum 2017

Jak rozwijać firmę w dobie digitalizacji? To jedno z wielu zagadnień, o których będą...

Zapis i przetwarzanie logów w systemach uniksowych

Data publikacji: 31-03-2017 Autor: Marcin Jurczyk
Autor: Rys. K. Kanoniak

Logi systemowe, syslog, sysklogd, rsyslog, syslog-ng, logstash, fluentd, greylog to terminy i określenia przewijające się nieustannie wszędzie tam, gdzie mamy do czynienia z tematyką zbierania i zarządzania informacjami pochodzącymi z różnorodnych systemów źródłowych. Spróbujmy nieco uporządkować ten temat na przykładzie dwóch popularnych programów – rsyslog i syslog-ng.

Na początku był… syslog. Tym zdaniem można by rozpocząć długi cykl artykułów poświęconych zbieraniu i przechowywaniu informacji generowanych przez różnorodne systemy i programy uniksowe. Postęp w świecie IT jest jednak na tyle dynamiczny, że sięganie do lat 80., kiedy to Eric Allman wymyślił sysloga przy okazji tworzenia sendmaila, wydaje się bezcelowe. Syslog użyty początkowo wyłącznie jako program do odbierania i logowania informacji sendmaila, z biegiem czasu stał się standardem w świecie Unix/Linux i doczekał się oficjalnych dokumentów RFC. Najbardziej znane to RFC3164 (oryginalny format BSD opisany w 2001) oraz RFC5424 – aktualna specyfikacja protokołu z 2009 roku. Pomimo upływu lat podstawowe założenia się nie zmieniły i w dalszym ciągu mówi się o standaryzowanym procesie, którego głównym zadaniem jest odbieranie informacji o statusie działania innych programów czy procesów i zapisywanie ich w dzienniku (logu), czyli pliku znajdującym się gdzieś na dysku twardym komputera lokalnego lub zdalnego, czy też wyświetlanie tego typu informacji na ekranie.

Przekazywanie informacji pomiędzy procesami sysloga w środowisku sieciowym to również jedno z fundamentalnych założeń projektu, dzięki czemu zamiast sprawdzać po kolei status pracy każdego serwera z osobna, administrator był w stanie przeanalizować jeden log na desygnowanym serwerze, w którym możliwe było rozróżnienie zdarzeń z podziałem na hosty dostarczające dane. Dokumenty RFC wprost określają syslog jako protokół przenoszenia informacji o zdarzeniach, a więc można tu mówić zarówno o oficjalnym standardzie, jak też o programie realizującym funkcje transportu sieciowego i przechowywania danych. Standard określa również format wiadomości syslog wraz ze wszelkimi zaleceniami dotyczącymi istotności czy wymagalności poszczególnych pól.

Jedno z najczęściej pojawiających się pytań dotyczy standardowej długości wiadomości syslog. RFC5424 definiuje, że wszystkie zgodne systemy muszą obsłużyć wiadomości o długości co najmniej 480 bajtów, a powinny poradzić sobie z pakietami do 2 KB. Powyżej tej granicy dopuszcza się odrzucenie wiadomości lub obcięcie informacji payload. Innymi popularnymi informacjami zawartymi w wiadomości syslog są kody facility oraz severity. Pierwsza wartość określa, skąd pochodzi informacja (kody od 0 do 23), druga z kolei określa ważność (od 0 do 7) logowanego zdarzenia. Obie informacje składają się na tzw. priority number, wyliczany jako suma wartości pola severity i wartości facility przemnożonej przez 8. Informacje o ważności logowanych informacji to chyba najpopularniejsza cecha charakteryzująca wiadomości syslog. Critical, Error czy Warning to komunikaty powodujące wzmożoną uwagę administratora bez względu na źródło informacji. Na podstawie informacji facility i severity można również sterować logowaniem zdarzeń – ze względu na określony typ informacji lub jej ważność można chociażby zdefiniować konkretny plik loga, do którego będą trafiały zdarzenia, czy też specyficzny host kolektora logów, odpowiedzialny za przechowywanie wiadomości danego typu.

[...]

Autor jest architektem w międzynarodowej firmie z branży IT. Zajmuje się infrastrukturą sieciowo-serwerową, wirtualizacją infrastruktury i pamięcią masową.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2013 Presscom / Miesięcznik "IT Professional"