Architektura danych dla metryk dziennika zdarzeń?

Moja usługa ma dużą liczbę bieżących zdarzeń użytkowników i chcielibyśmy robić takie rzeczy, jak „policzenie wystąpienia typu T od daty D ”.

Staramy się podjąć dwie podstawowe decyzje:

1. Co przechowywać? Przechowywanie każdego zdarzenia a tylko gromadzenie agregatów

   • (Styl dziennika zdarzeń) rejestruj każde zdarzenie i policz je później, vs.
   • (Styl szeregów czasowych) przechowuj pojedynczą zagregowaną „liczbę zdarzeń E dla daty D ” dla każdego dnia

2. Gdzie przechowywać dane

   • W relacyjnej bazie danych (szczególnie MySQL)
   • W nierelacyjnej bazie danych (NoSQL)
   • W płaskich plikach dziennika (gromadzonych centralnie przez sieć za pośrednictwem syslog-ng)

Co to jest standardowa praktyka / gdzie mogę przeczytać więcej na temat porównywania różnych typów systemów?

Dodatkowe Szczegóły:

• Całkowity strumień zdarzeń jest duży, potencjalnie setki tysięcy wpisów dziennie
• Ale naszą obecną potrzebą jest zliczanie tylko niektórych rodzajów zdarzeń
• Nie potrzebujemy dostępu w czasie rzeczywistym do nieprzetworzonych danych lub wyników agregacji

IMHO, „rejestruj wszystkie zdarzenia w plikach, przeszukuj je później, aby filtrować i agregować strumień” to dość standardowy sposób UNIX, ale moi rodacy z Rails-y wydają się myśleć, że nic nie jest prawdziwe, chyba że jest w MySQL.

Zawsze zależy, dam ci radę, by zaoferować ci nową perspektywę

Co przechowywać? Przechowywanie każdego zdarzenia a tylko gromadzenie agregatów

(Styl dziennika zdarzeń) rejestruj każde zdarzenie i policz je później, vs.

Jeśli planujesz nie umknąć żadnemu szczegółowi, mimo że teraz nie są one istotne, moim zdaniem jest to najlepsze podejście, ponieważ czasami, gdy nadchodzą wyniki, możesz znaleźć inne zdarzenia, które dla X lub Y nie były istotne lub nie przynieśli żadnych dodatkowych informacji, ale po pewnej analizie to po prostu robi i trzeba je również śledzić, a następnie, ponieważ zostały zarejestrowane, ale nie uwzględnione, zajęłoby Ci trochę czasu, zanim można je dodać do zdjęcia .

(Styl szeregów czasowych) przechowuj pojedynczą zagregowaną „liczbę zdarzeń E dla daty D” dla każdego dnia

Jeśli chcesz go wdrożyć i wykorzystać jutro, może działać, ale jeśli masz nowe wymagania lub znajdziesz korelację z innym zdarzeniem, które z jakiegoś powodu zostało pominięte, musisz dodać to nowe zdarzenie, a następnie poczekać długi czas na dobre poziomy agregacji

Gdzie przechowywać dane

W relacyjnej bazie danych (szczególnie MySQL)

Pierwsza opcja może być ciężka dla DB, jeśli zdecydujesz się na rejestrowanie wszystkich zdarzeń, więc obawiam się, że MySQL może stać się zbyt mały, a jeśli chcesz wybrać rozwiązania RDBMS, możesz pomyśleć o większych, takich jak PostgreSQL lub zastrzeżone jak Oracle lub DB2 .

Ale dla agregacji byłby dobrym wyborem, w zależności od generowanego obciążenia można agregować w kodzie i wstawiać te agregacje do bazy danych.

W nierelacyjnej bazie danych (NoSQL)

Jeśli zdecydujesz się na to rozwiązanie, musisz zobaczyć, które podejście chcesz podążać za przyjemną lekturą na wikipedii, może ci pomóc, nie mogę ci pomóc w tym temacie, ponieważ po prostu nie mam wystarczającego doświadczenia, głównie używam rdbms.

W płaskich plikach dziennika (gromadzonych centralnie przez sieć poprzez syslog-ng)

Osobiście odradzałbym ci skorzystanie z tej opcji, jeśli plik wzrośnie za bardzo, trudniej byłoby go przeanalizować, ale nadal nie wiem, jaki jest główny cel, to sprawdzenie w systemie lub po prostu sprawdzenie dziennika plik ...

Mam nadzieję, że to pomoże!

Myślę, że Twój pomysł na parsowanie dzienników, liczenie i przechowywanie wyników w bazie danych jest poprawny. Nie jestem pewien, czy chcesz mieć te wszystkie surowe dzienniki w bazie danych (myślę, że tak sugerują twoi rodacy). Masz już dzienniki w plikach, prawda? Możesz po prostu zarchiwizować je. Przypuszczam, że ten bit naprawdę zależy od twoich przypadków użycia.

Zgadzam się również z @ Thorbjørn Ravn Andersen o przeniesieniu „odpowiedzi na komentarz” na pytanie.

Zależy od zamierzonego użycia. Jeśli masz standardowy wykres lub raport pokazujący wartości zagregowane, po prostu zechcesz filtrować zdarzenia w miarę ich pojawiania się i agregować je w odpowiednim segmencie. Jeśli potrzebujesz zgłębić konkretne wydarzenia lub jeśli uważasz, że możesz chcieć wrócić i ponownie przeanalizować / ponownie sklasyfikować wydarzenia później, powinieneś zapisać poszczególne zdarzenia.

Jeśli masz czas i przestrzeń, zazwyczaj lubię agregować dane, ale przechowywać szczegóły w (skompresowanym) pliku. Szczegóły nie muszą być łatwo dostępne, ponieważ prawie nigdy ich nie potrzebuję, ale są dostępne do masowego ponownego przetworzenia, jeśli zmienią się kryteria klasyfikacji.

Każda decyzja dotycząca architektury powinna wynikać z potrzeb biznesowych. W twoim przypadku powinieneś mieć dokładniejszy obraz tego, jakie informacje chcesz uzyskać ze swojego systemu logów i aby zdecydować, jak przechowywać, jak często będziesz potrzebować tych informacji i ile czasu możesz poczekać, aby uzyskać wynik . To właśnie napędza projektowanie kolektorów dziennika, korelatorów zdarzeń i podobnych aplikacji.

Zamiast wyrażać swoją opinię, sugeruję przyjrzeć się niektórym aplikacjom podobnym do tego, co próbujesz opracować. Niektóre z nich mogą być znacznie potężniejsze niż to, co udajesz, że się rozwija, ale nie zaszkodzi, jeśli spojrzysz na architekturę i przestrzegane zasady przechowywania. Po stronie profesjonalnej masz aplikacje SIEM, takie jak RSA i Arcsight, a po stronie Open Source masz inicjatywy takie jak Kiwi lub OSSIM (która ma również profesjonalną wersję opartą na urządzeniach).

Inną rzeczą do rozważenia jest to, że kiedy zaczniesz korzystać z wyników uzyskanych przez narzędzie, zaczniesz otrzymywać bardzo prawdopodobne wiele wniosków od twojego kierownictwa o więcej informacji i bardziej szczegółowy. Więc ... używaj go ostrożnie i planuj z widokiem na horyzoncie. Może dać ci więcej pracy, ale na pewno możesz uzyskać dużo wsparcia i widoczności (presja przychodzi w pakiecie) ....