Załóżmy, że mamy jakąś platformę przetwarzającą dane. Ot - zaawansowany sklep internetowy albo platforma aukcyjna. Dane są przetwarzane na wielu serwerach.

Podczas przetwarzania - z aplikacji tworzone są logi - zaczynając do wejścia użytkownika do systemu na jakimś balancerze, po etap zalogowania się, następnie wykonywania operacji - do tego operacje często wykonywane są w tle, a użytkownikowi prezentowane są jedynie informacje o wykonanych operacjach. 

I teraz - czym warto się zainteresować, by efektywnie przetwarzać, zbierać i korelować ze sobą logi z różnych elementów systemu - powiązane z danym użytkownikiem,  w tym móc obrazować trendy, anomalie itp. Ot - użytkownik zawsze logował się z jednego adresu IP, a nagle zalogował się z innego. Albo - zawsze wykonywał po zalogowaniu jakieś operacje, a tym razem wykonał coś innego.

Do tego potrzebujemy jeszcze możliwości selektywnego usuwania zbędnych/starych logów, tak by np. informacje o samych zalogowaniach użytkowników, którzy nie wykonali operacji kasować po 3 miesiącach, a zalogowania, które zakończyły się operacją (np. zakupem przedmiotu), przechowywane były dłużej.

Idealnie jakby zapewniona była możliwość kompresji/archiwizacji starszych informacji (tak by móc do nich wrócić, natomiast by zabierały mniej miejsca).

Wersja najprostsza - to zbieranie logów z aplikacji jakimś syslogiem do jednego miejsca i następnie jakimiś mechanizmami wyłapywanie konkretnych operacji związanych z użytkownikiem.

Problem w tym, że:

• takie rozwiązanie się nie skaluje (mamy dużo logów w wielu plikach, dane ciężko skorelować ze sobą, do tego zapis do plików potrafi mocno obciążyć system);
• łatwo możemy zrobić kompresję starych logów, natomiast selektywne usuwanie - jedynie usuwając całe wiersze;
• rozwiązanie nie jest HA, (chyba że dane będziemy równolegle zapisywać na dwie maszyny).
  
  

Alternatywą jest trzymanie danych w jakimś SQL - ułatwia to znacznie korelowanie danych, można kasować je selektywnie zostawiając te istotniejsze, ale - takie rozwiązanie ciężko się skaluje (praktycznie do jednego serwera). Wydajność również nie jest zbyt ciekawa w sytuacji, gdy mamy miliony/miliardy wierszy. Indeksy pozwalają na efektywne wyszukanie danych - ale raz, że obciążają bazę, a dwa - wymagane są indeksy na każde pole, po którym będziemy odpytywać.

Spotkałem się też z trzymaniem logów w mongodb, aczkolwiek nie mam pojęcia jak wygląda tutaj temat wydajności przy dużym obciążeniu, jak również korelowania/retencji danych.

A może są jakieś inne rozwiązania, którymi warto by się było zainteresować?

Idealny system powinien:

• móc dostawać dane w różny sposób (syslog, jakieś API...);
• móc się efektywnie skalować - idealnie gdyby był rozproszony i skalowanie polegało na dokładaniu do niego maszyn,
• był odporny na awarie pojedynczego węzła;
• dawać możliwość autoryzacji dostępu do logów (w tym ograniczaniu widoczności dla poszczególnych klas użytkowników - ot - pracownik BOK nie musi widzieć hasła...);
• dawać możliwość retencji logów na podstawie zadanych kryteriów (niekoniecznie pojedynczych wierszy logów, ale raczej logów związanych z nic niewnoszącymi sesjami);
• pozwalać na archiwizację starszych danych (a następnie bezproblemowe odtworzenie ich).