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


17.10.2017

Ultrapanorama

Philips 492P8
13.10.2017

Druk w bieli

Oki Pro8342WT
11.10.2017

PolCAAT’ 2017 już w...

30 listopada 2017 r. w warszawskim hotelu Marriott odbędzie się XIII edycja konferencji...
10.10.2017

Pełna ochrona

Kaspersky Total Security 2018, Internet Security 2018
06.10.2017

Przeprowadzka do chmury

Oracle Exadata Cloud
03.10.2017

Automatyzacja...

Red Hat Ansible
02.10.2017

Bezpieczeństwo danych zaczyna...

Aby zapewnić bezpieczeństwo danych, w tym informacji poufnych o klientach i pracownikach,...
27.09.2017

Dotykowe 75 cali

BenQ RP750K
22.09.2017

Wydajne CPU

AMD Ryzen Threadripper

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"