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



19.09.2017

Do sieci miejskich

D-Link DGS-3000 DGS-3000
15.09.2017

RODO: Chmura przychodzi z...

Rozporządzenie o Ochronie Danych Osobowych (RODO) zacznie obowiązywać już za niespełna...
15.09.2017

Kamery zmiennopozycyjne

Axis Q86 i Q87
12.09.2017

Procesy zgodne z rodo

Doxis4 iECM
08.09.2017

Kompleksowa obsługa

Oracle Cloud Applications Release 13
05.09.2017

Konteneryzacja

Red Hat OpenShift Container Platform 3.6
29.08.2017

Zmiana zakresu napięcia

Ever UPS ECO Pro CDS
28.08.2017

HackYeah: rekordowy hackathon...

Dwa tysiące programistów i specjalistów IT z całej Europy spotka się 27-29 października w...
25.08.2017

Router mini

MikroTik RB931-2nD

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ą.

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"