Logujesz się do pliku tekstowego lub bazy danych?

Kiedy powinienem używać bazy danych do logowania, a kiedy pliki tekstowe?
Widzę, że serwery i frameworki (z których aplikacja korzysta wewnętrznie) zazwyczaj (zawsze?) Domyślnie rejestrują żądania i błędy w plikach tekstowych. Widzę jednak, że ludzie, którzy rozwijają swoją aplikację w oparciu o te serwery i frameworki, czasami logują się do bazy danych (nawet głównej bazy danych aplikacji, a nie zewnętrznej).
Być może istnieje różnica między dziennikami debugowania a dziennikami kontroli - przeczytałem tę klasyfikację gdzieś na tej stronie.

Mówiąc bardzo ogólnie, logowanie do pliku tekstowego jest znacznie szybsze niż logowanie do bazy danych. To główny aspekt rejestrowania, który należy wziąć pod uwagę.

Powodem, dla którego logujesz się do bazy danych jest bardziej prawdopodobne, ponieważ chcesz zapytać o wyniki - wyszukiwanie danych dziennika jest łatwiejsze w bazie danych, szczególnie jeśli logujesz informacje kontekstowe, których można użyć do grupowania wpisów dziennika. Zwykle łatwiej jest również uzyskać dostęp do centralnej bazy danych niż do pliku dziennika na serwerze, który może być zabezpieczony i niedostępny.

Idealnym rozwiązaniem byłoby zalogowanie się lokalnie do pliku, a następnie migracja tych danych do bazy danych w celu sprawdzenia, jeśli zajdzie taka potrzeba.

Teraz audyt to zupełnie inna bestia. Chociaż jest to koncepcja podobna do rejestrowania, inspekcja jest zwykle potrzebna do przechowywania przez długi czas (w przeciwieństwie do plików dziennika używanych do debugowania lub śledzenia, które można usunąć kaprysem). Audyty mają na celu pokazanie ważnych informacji. Rejestrujesz znacznie mniej informacji kontrolnych i rzadziej niż zwykłe rejestrowanie, więc wydajność nie jest problemem. Z tego powodu widoczne są zalety pisania tych informacji kontroli do centralnej bazy danych.

Nie ma jednego uniwersalnego podejścia, a ze względu na odporność czasami trzeba zastosować wiele podejść. Biorąc przykład, możesz chcieć ukryć dzienniki debugowania w pliku i przechowywać dzienniki kontroli w bazie danych.

Bułka tarta aplikacji

Zalety: Łatwy do wdrożenia i od razu widoczny dla użytkownika

Wady: informacje są przechowywane tylko podczas działania aplikacji

Plik tekstowy

Plusy: łatwe do wdrożenia

Minusy: Konieczne jest zablokowanie pliku. Co zrobić, gdy na dysku dziennika zabraknie miejsca na dysku?

Dziennik zdarzeń

Plusy: łatwe do wdrożenia

Wady: dziennik zdarzeń może się zapełnić, jeśli nie zostanie poprawnie skonfigurowany lub stare dzienniki mogą zostać utracone z powodu zasad przechowywania / usuwania.

Baza danych

Plusy: łatwe do wdrożenia

Minusy: większy ruch DB. Jak zarejestrować utratę DB lub innego problemu z DB?

Wiadomości (MQ)

Plusy: Strzelaj i zapominaj

Minusy: kolejna warstwa, która może się nie udać. Wymaga konfiguracji

Dzienniki audytu muszą zapewniać pełną identyfikowalność operacji przez dłuższy czas dla celów audytu, w celu pełnego uzasadnienia zawartości bazy danych.

W niektórych przypadkach (np. Aplikacje finansowe) dzienniki te mogą wymagać zapewnienia zgodności z wymogami prawnymi, takimi jak przechowywanie (w niektórych krajach przez 10 lat) lub niezmienność. Ponieważ dzienniki te muszą uzasadniać zawartość bazy danych na poziomie aplikacji, powszechną praktyką jest przechowywanie ich w bazie danych, gdzie dostęp można kontrolować, aby uniknąć nieautoryzowanych zmian.

Inne dzienniki , takie jak dzienniki monitorowania lub dzienniki zabezpieczeń, często muszą radzić sobie z ograniczeniami wydajności i woluminów. Zazwyczaj są one zapisywane w pliku, ponieważ zapisywanie jest szybsze (bez narzutów związanych z zarządzaniem transakcjami), łatwiejsze do archiwizacji offline i łatwiejsze do zintegrowania z zewnętrznymi narzędziami SIEM do monitorowania .

Należy zauważyć, że chociaż tego rodzaju dzienniki można wykorzystać do wykazania wiarygodności dzienników kontroli (np. Brak nieautoryzowanego dostępu), mają one generalnie krótsze ograniczenia przechowywania (na przykład od 6 miesięcy do 2 lat dla celów egzekwowania prawa od dzienników telekomunikacyjnych) jeśli w ogóle jakieś ograniczenie.

Jednym z wielu powodów, dla których warto korzystać z bazy danych do rejestrowania debugowania, jest brak dostępu do aplikacji lub serwera WWW w celu przeglądania podglądu zdarzeń lub plików tekstowych

Dzienniki audytu różnią się od dzienników debugowania w kontekście aplikacji internetowej, ponieważ w niektórych aplikacjach może być konieczne pokazanie ich użytkownikowi końcowemu, aby mogli oni przejść do bazy danych w celu łatwego wyszukiwania.

Możesz użyć DB Tools do filtrowania i łatwego przeglądania.