Dlaczego system plików jest preferowany dla dzienników zamiast RDBMS?

Pytanie powinno jasno wynikać z tytułu. Na przykład Apache zapisuje swoje dzienniki dostępu i dzienniki błędów w plikach zamiast RDBMS bez względu na to, jak duży lub mały jest wykorzystywany.

W przypadku RDMS musimy po prostu pisać zapytania SQL, a to zadziała, podczas gdy w przypadku plików musimy zdecydować się na konkretny format, a następnie napisać wyrażenie regularne lub być parserami, aby nimi manipulować. A mogą nawet zawieść w szczególnych okolicznościach, jeśli nie zostanie zachowana wielka ostrożność.

Jednak wydaje się, że wszyscy wolą system plików do zarządzania dziennikami. Nie jestem stronniczy w stosunku do żadnej z tych metod, ale chciałbym wiedzieć, dlaczego jest to praktykowane w ten sposób. Czy to szybkość, łatwość konserwacji, czy coś innego?

1. Zbyt wiele rzeczy może zawieść w bazie danych i rejestrowanie tych awarii jest również ważne.

2. O ile nie masz systemu bazy danych, który umożliwia autonomiczne transakcje (lub w ogóle żadnych transakcji), rejestrowanie wymagałoby osobnego połączenia, aby wycofanie lub zatwierdzenie w dzienniku nie zakłócało wycofania lub zatwierdzenia w aplikacji.

3. Wiele rzeczy, które warto zarejestrować, dzieje się podczas uruchamiania, np. Przed nawiązaniem połączenia z bazą danych.

4. W typowej konfiguracji nowy dziennik jest tworzony codziennie, stare pliki dziennika są kompresowane i przechowywane przez 2 tygodnie, zanim zostaną ostatecznie usunięte. To samo nie jest łatwe w RDBMS.

Widziałem wcześniej dzienniki zapisywane w bazie danych (a czasem masz konfigurowalne opcje rejestrowania, gdzie śledzenie trafia do pliku, błędy do bazy danych, fatale do dziennika zdarzeń systemu Windows).

Głównymi przyczynami są szybkość i rozmiar, dzięki czemu niektóre śledzenie może generować ogromne, ogromne ilości rejestrowania - przeszukiwałem pliki dzienników o wielkości gigabajtów. Innym głównym powodem jest to, że czytanie dzienników musi odbywać się sekwencyjnie, nie ma potrzeby sprawdzania dziennika, z wyjątkiem znalezienia określonego błędu lub wpisu - a funkcja znajdowania w pliku działa w tym przypadku doskonale.

Szybkość jest jednym z powodów; inni są:

• Eliminowanie punktów awarii. System plików rzadko zawodzi w warunkach, w których DBMS by tego nie zrobił, ale w bazach danych jest wiele warunków błędów, które nie istnieją w systemach plików.
• Niska dostępność technologiczna. Jeśli coś pójdzie naprawdę źle, możesz uruchomić się w powłoce ratunkowej lub zamontować dysk w innym systemie i nadal mieć odpowiednie narzędzia do sprawdzania plików dziennika. Jeśli jest to baza danych, nigdzie nie ma uruchomionego serwera bazy danych.

Po pierwsze.

A mogą nawet zawieść w szczególnych okolicznościach, jeśli nie zostanie zachowana wielka ostrożność.

Transakcje w bazie danych nie mogą zawieść, jeśli nie jesteś ostrożny?

Pisanie do pliku tekstowego ma wiele zalet, z których najważniejszą jest

• Tekst jest czytelny dla ludzi. Każdy może otworzyć plik dziennika za pomocą prostego edytora tekstu i zobaczyć, jakie są wiadomości. Nie musisz rozumieć, w jaki sposób baza danych jest zorganizowana.
• Prędkość. Zapisywanie tekstu na dysk jest znacznie szybsze niż w przypadku usługi bazodanowej ustalającej, gdzie tekst trafia do bazy danych, zapisującej ją i zapewniającej zakończenie transakcji.

W szczególności wychowujesz Apache, więc omówię to szczegółowo.

Apache można skonfigurować tak, aby logował się do bazy danych, chociaż wymaga do tego zewnętrznej wtyczki . Korzystanie z takiej wtyczki może ułatwić analizę logów, ale tylko jeśli zamierzasz napisać własne oprogramowanie do analizy logów. Standardowe standardowe analizatory dzienników zakładają, że twoje dzienniki są w plikach, więc nie będziesz mógł ich używać.

Kiedy to robiłem, wystąpiły również problemy z niezawodnością: jeśli bufor bufora zapisu serwera bazy danych jest zapełniony (co może się zdarzyć w przypadku mysql, jeśli zużyjesz limit systemu plików dla użytkownika, na którym działa), zaczyna kolejkować zapytania, dopóki nie będą w stanie aby kontynuować, w tym momencie Apache zaczyna czekać na zakończenie, powodując zawieszenie żądań na twojej stronie internetowej.

(Ten problem można teraz oczywiście naprawić - zrobiłem to wiele lat temu)

System plików to baza danych. To rzeczywiście prostsza, hierarchiczna baza danych zamiast relacyjnego DBMS, ale mimo to baza danych.

Powodem, dla którego logowanie do systemu plików jest popularne, jest fakt, że dzienniki tekstowe dobrze pasują do filozofii Uniksa: „Tekst jest uniwersalnym interfejsem”.

Unix opracował wiele narzędzi ogólnego przeznaczenia, które mogą dobrze współpracować z logami tekstowymi. Nie ma znaczenia, czy dzienniki tekstowe są tworzone przez mysql, apache, aplikację niestandardową, oprogramowanie innych firm, które już dawno nie jest obsługiwane, sysadmin może używać standardowych narzędzi uniksowych, takich jak grep, sed, awk, sortować, uniq, cut, tail itd., aby mimo wszystko przeszukiwać kłody.

Jeśli każda aplikacja loguje się do własnej bazy danych, jedna do MySQL, inna do Postgres, inna do Elasticsearch, inna chce zalogować się do ELK, inna może zalogować się tylko do MongoDB, wtedy musisz nauczyć się dwudziestu różnych narzędzi do przeszukiwania dzienników każdego podanie. Tekst to uniwersalne medium, na którym każdy może się zalogować.

Nawet jeśli uda ci się to zrobić, aby wszystkie dzienniki trafiły do ​​jednej bazy danych, powiedzmy MySQL, możesz zauważyć, że każda aplikacja będzie chciała logować się przy użyciu różnych schematów tabel, więc nadal będziesz musiał napisać niestandardowe narzędzie do zapytania dzienników dla każdego podanie. A jeśli w jakiś sposób wcisnąłeś wszystkie aplikacje, aby zalogować się do jednego schematu, prawdopodobnie okaże się, że ten ogólny schemat nie byłby w stanie opowiedzieć pełnej historii każdej aplikacji, więc i tak musisz przeanalizować teksty dziennika.

Logowanie do bazy danych często w praktyce wcale nie ułatwia pracy.

Logowanie do bazy danych może być przydatne, gdy masz konkretną analizę, o której myślisz, lub w celu spełnienia określonego wymogu przechowywania audytu, dla którego możesz zaprojektować określony schemat bazy danych, aby gromadzić tylko dane do tych konkretnych celów. Ale w przypadku kryminalistyki i debugowania oraz podczas zbierania dziennika bez określonego celu dzienniki tekstowe są zwykle wystarczająco dobre, aby koszt nauki lub tworzenia specjalistycznych narzędzi często nie był tego wart.

Spójrzmy na to na kilku warstwach:

1. Warstwa maszyny
2. Warstwa systemu operacyjnego
3. Warstwa usługowa
4. Warstwa aplikacji

W skrócie:

• Na warstwie maszyny naprawdę nie można rejestrować inaczej niż jakieś zrzuty.
• W warstwie systemu operacyjnego można rejestrować, ale tak naprawdę dostępny jest tylko system plików.
• Usługi mogą logować się do systemu plików, ale nie mogą ufać, że inne usługi będą działały, więc nie mogą się tam zalogować.
• Aplikacje mogą logować się do usług i systemu plików.

Następnie mamy podejście oparte na przypadkach użycia:

Czy chcesz rejestrować błędy specyficzne dla węzłów w poziomo skalowanym systemie RDBMS, w którym musisz podjąć dodatkową pracę, aby znaleźć błąd określonego węzła, gdy możesz po prostu otworzyć pokrywę dla jednego węzła i zobaczyć go tam? Z drugiej strony aplikacja prawdopodobnie powinna zalogować się do RDBMS, aby zebrać błędy i powiadomienia na poziomie aplikacji.

Co dzieje się, gdy RDBMS musi sam się zarejestrować, ponieważ nie można zapisać bazy danych?

Złożoność. Dodanie RDBMS zwiększy astronomicznie złożoność całego systemu. A umiejętność zarządzania złożonością jest najważniejszą rzeczą, która odróżnia programistów od producentów kodu źródłowego.

Czy to szybkość, łatwość konserwacji, czy coś innego?

Prędkość.