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



23.11.2017

Z IEEE 802.3bz

Przełączniki Netgear
21.11.2017

4K z USB-C

EIZO FlexScan EV2785
16.11.2017

Wielofunkcyjne MFP

Canon imageRUNNER ADVANCE C256i, C356i oraz C356P
14.11.2017

Fabryka Przyszłości w drodze...

W dniach 25 i 26 października we Wrocławiu odbyła się czwarta edycja konferencji...
14.11.2017

Pamięć definiowana programowo

Red Hat Container-Native Storage 3.6
09.11.2017

Zgodnie z rodo

Snow Software GDPR Risk Assessment
07.11.2017

Bezpieczna stacja robocza

F-Secure Protection Service for Business (PSB)
03.11.2017

III Forum Bezpieczeństwa...

21 listopada 2017 r. w PSE w Konstancinie-Jeziornie odbędzie się III Forum Bezpieczeństwa...
27.10.2017

Zasilanie gwarantowane

Schneider Electric Galaxy VX

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"