Logowanie do serwera - w bazie danych lub pliku dziennika?

Question

Pracuję na serwerze i zaczynam implementować rejestrowanie. Jednak nie jestem pewien, czy powinienem używać db do logowania, czy po prostu plik tekstowy.

Mam zamiar zarejestrować kilka podstawowych informacji dla każdego żądania (jaki typ zapytania, adres IP żądania, śledzenie sesji). W przypadku niektórych wniosków będą dostępne rozszerzone informacje (szczegółowe informacje na temat rodzaju wniosku), a jeśli wystąpią jakiekolwiek błędy, będę je również rejestrować.

Z jednej strony, umieszczenie dzienników w db oznacza, że ​​mogę uruchamiać zapytania do zalogowanych danych. Z drugiej strony nie jestem pewien, czy byłoby to niepotrzebne obciążenie dla bazy danych. Oczywiście, mógłbym również użyć zarówno db jak i logu do logowania. Jakie są ludzkie przemyślenia na temat prawidłowego logowania?

(Jeśli to robi różnicę, używam mod_pythona na serwerze Apache z db MySQL. Więc chciałbym być albo przy użyciu biblioteki logging lub po prostu tworząc kilka tabel zalogowaniu db.)

Answer 1

Najpierw użyj biblioteki rejestrowania, takiej jak SLF4J/Logback, która umożliwia podjęcie decyzji w sposób dynamiczny. Następnie możesz zmodyfikować plik konfiguracyjny i skierować niektóre lub wszystkie swoje logi do każdego z kilku różnych miejsc docelowych.

Bądź ostrożny przed zalogowaniem się do bazy danych aplikacji, możesz łatwo go przytłoczyć, jeśli logujesz się dużo, a objętość zaczyna rosnąć. A jeśli twoja aplikacja działa blisko pełnej pojemności lub w trybie awarii, komunikaty dziennika mogą być niedostępne i będziesz latał na ślepo. Prawdopodobnie jedynymi komunikatami, które powinny trafić do bazy danych aplikacji, są zdarzenia zorientowane na aplikacje na wysokim poziomie (typ danych aplikacji).

Znacznie lepiej jest "zalogować się do systemu plików" (który dla dużego środowiska produkcyjnego obejmuje rejestrowanie do adresu multiemisji odczytanego przez nadmiarowe serwery agregacji dzienników).

Pliki dzienników można odczytywać w specjalnych bazach danych analitycznych, w których można użyć np. Hadoop do mapowania/zmniejszania analiz danych dziennika.

Answer 2

Zawsze logowaliśmy dane do oddzielnej bazy danych.

Umożliwia to zapytanie bez wpływu na bazę danych aplikacji. Upraszcza to również sytuację, gdy zdajemy sobie sprawę, że musimy wyłączyć rejestrowanie lub zmienić ilość tego, co rejestrujemy.

Jednak najnowocześniejsze biblioteki rejestrowania obsługują osadzanie rejestrowania w aplikacji i wybieranie miejsca docelowego według konfiguracji - pliku, bazy danych itp.

Logger daje wiele sposobów na zarządzanie logowaniem, a chociaż pakiet domyślny nie ma rejestratora bazy danych, napisanie takiej procedury obsługi zdarzeń nie byłoby trudne.

Answer 3

Mieszanka file.log + db byłaby najlepsza. Zaloguj się do informacji o db, które być może będziesz musiał przeanalizować, na przykład średnia liczba użytkowników dziennie itd. I użyj pliku file.log do przechowywania niektórych informacji debugowania.

Answer 4

Jeśli zdecydujesz się na format pliku dziennika, który można parsować, możesz zalogować się do pliku, a następnie mieć proces zewnętrzny (być może uruchomiony przez cron), który przetwarza pliki dziennika i wstawia szczegóły do ​​bazy danych. Można to ustawić w czasie, gdy obciążenie aplikacji i bazy danych jest niskie.

Zawsze martwię się o to, co stanie się, gdy baza danych stanie się niedostępna: czy to uniemożliwi uruchomienie aplikacji lub ją w jakikolwiek sposób pogorszy? Logowanie do systemu plików pozwala uniknąć konieczności radzenia sobie z tym problemem, ale nadal trzeba się martwić o zapełnianie dysków i rotację plików dziennika.

Answer 5

Zaloguj się do DB tylko wtedy, gdy generuje przychody.

Na przykład dla jednej witryny, wszystkie reklamy umieszczone w witrynie internetowej zostały zarejestrowane w bazie danych. To generowało przychody. Nie ma powodu, aby parsować pliki dziennika dla czegoś, co jest ważne.

Cała reszta trafia do systemu plików.

Zaloguj się do systemu plików w celu debugowania. To na ogół prywatne rzeczy. Szczegóły dotyczące wdrożenia. Nie udostępniać.

Apache rejestruje górę rzeczy do systemu plików. Nie duplikuj tego.

Dzienniki kontroli dostępu przechodzą do systemu plików.Rzadko będziesz chciał spojrzeć na te szczegóły w szczegółach.

Działalność użytkownika może wymagać podsumowania w bazie danych. Są to informacje marketingowe i dotyczące użyteczności, które warto przeanalizować, aby poprawić swoją witrynę. Jednak szczegółowe informacje o działaniach są zbyt obszerne, aby można je było zarejestrować w bazie danych. Umieść go w systemie plików i przetestuj go w bazie danych analizy marketingowej/ulepszania produktu/użyteczności.

Answer 6

Na wypadek, gdybyś chciał poprawić standardowy logger Pythona, aby logować się do bazy danych, ten przepis może dać ci przewagę: Logging to a Jabber account.

Answer 7

Najpierw używałbym logowania do systemu plików, tak jak zaleca większość innych odpowiedzi. Dzięki pakietowi rejestrowania w języku Python można łatwo utworzyć procedurę obsługi bazy danych, dostosowując sugestię wykonaną here. Można także utworzyć niestandardową instancję filtru i dołączyć ją do obsługi obsługi bazy danych - pozwoli to określić w czasie rzeczywistym dokładnie, które zdarzenia faktycznie logują się do bazy danych. Zgodnie z innymi odpowiedziami, powiedziałbym, że naprawdę warto rejestrować niektóre typy zdarzeń w bazie danych do późniejszej analizy.

Zgodziłbym się z zaleceniem logowania do oddzielnej bazy danych (na oddzielnym serwerze), jeśli główna aplikacja ma wysoką przepustowość.

Answer 8

Rodzaj rejestrowania zależy od tego, co zamierzasz zrobić z danymi i jak masz zamiar to zrobić. Logowanie do db jest korzystne, jeśli zamierzasz zbudować system raportowania oparty na tym dzienniku db. Inaczej możesz rejestrować rzeczy w określonym formacie, który możesz później przeanalizować, jeśli chcesz wykorzystać dane do analizy. Na przykład z dziennika plików można analizować tylko wymagane informacje i generować pliki CSV w razie potrzeby. Jeśli zamierzasz korzystać z programu rejestrującego db, zgodnie z sugestiami, oddziel go od bazy danych aplikacji.

Po drugie, można rozważyć niezależność rejestratora od głównej aplikacji. Odradza się wątek, który wykonuje rejestrowanie, lub uruchamia rejestrator w określonym porcie/gnieździe i przekazuje do niego komunikaty dziennika, lub zbiera wszystkie komunikaty rejestrowania razem i usuwa je do dziennika po zakończeniu każdego cyklu.

Answer 9

Wykonujemy obie.

Rejestrujemy informacje operacyjne/postęp/etc. do pliku logu. Standardowe pliki dzienników.

W bazie danych rejestrujemy stany operacji. Na przykład. każdy element, który jest przetwarzany, dzięki czemu możemy wykonywać zapytania dotyczące przepustowości/czasu, który upłynął/etc. Dane te są szczególnie przydatne w przypadku trendów i wykrywania anomalii (system jest "zbyt cichy" itp.), Które potencjalnie wskazują na inne problemy.

Answer 10

Rzeczywiście wydaje się ważne, aby później móc przełączać się między rejestrowaniem bazy danych/pliku. Rejestrowanie bazy danych wydaje się być znacznie wolniejsze niż rejestrowanie pliku tekstowego, co może stać się ważne przy dużym ruchu dzienników. Zrobiłem bibliotekę (która może działać jako samodzielna lub jako nośnik), gdy miałem takie same wymagania. Loguje się do bazy danych i/lub plików, i pozwala na archiwizowanie krytycznych wiadomości (a archiwum może na przykład być bazą danych, podczas gdy wszystko idzie do plików tekstowych). To może uratować cię przed zakodowaniem innego od zera ... Zobacz: The rrlog library

Answer 11

Wygląda na to, że wielu z was rejestruje niektóre zdarzenia w bazie danych. Robię to samo, ale to dodaje trochę opóźnień. Czy ktokolwiek loguje się do bazy danych za pośrednictwem kolejki komunikatów? Jeśli tak, to czego używasz do kolejkowania i jak wygląda twoja architektura rejestrowania? Używam Java/J2EE.