Architektura danych dla metryk dziennika zdarzeń?

17

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.

elliot42
źródło
1
Masz szczęście w tym projekcie?
hiwaylon
2
@hiwaylon Skończyliśmy z użyciem systemu hybrydowego: 1) MySQL, gdzie to możliwe (mała objętość) (ułatwia agregację SELECT...GROUP BY, można łatwo przechowywać wyniki SELECTs), 2) korzystanie z Grafitu do prostej agregacji i wizualizacji na dużą skalę, oraz 3) rejestrowanie pełnych zdarzeń w celach informacyjnych i oglądanie szczegółów przepływu danych w czasie rzeczywistym. Każda z nich była naprawdę cenna na różne sposoby.
elliot42
To brzmi jak świetne rozwiązanie, całkiem podobne do tego, co robimy.
hiwaylon 10.01.2013
1
UPDATE ponad rok później zbudowaliśmy system, który rejestrował wszystko i okresowo iterował dzienniki zliczające rzeczy, a następnie przechowywał te zliczone liczby w bazie danych (mógł / powinien być bazą danych szeregów czasowych, ale MySQL wystarczył). Było to kilka tygodni pracy, ale okazało się, że jest to zaskakująco wydajne / szybkie podejście - gdy jest to tylko twój kod iterujący po zalogowanym JSON, łatwo jest dodać wiele metadanych i łatwo kodowi mieć elastyczne reguły dokładnie do tego, co chce się liczyć.
elliot42
1
Aktualizacja 2016: Kafka może robić takie rzeczy w dzisiejszych czasach, przynajmniej dla surowego przechowywania. Następnie możesz albo przykleić je do dużego zadania MapReduce lub Spark, albo dużego magazynu, takiego jak Vertica itp., Jeśli chcesz zapytać / zagregować je.
elliot42

Odpowiedzi:

4

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!


źródło
1
Pliki dziennika należy obracać według rozmiaru lub długości. Nie sądzę, by ostatnia sprawa była problemem.
hiwaylon
1

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.

hiwaylon
źródło
1

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.

TMN
źródło
„agreguj dane, ale przechowuj szczegóły w (skompresowanym) pliku”. Szczególnie świetna myśl, dzięki!
elliot42,
Czy istnieją obawy co do ilości rejestrowania wspomnianego PO i przeprowadzania filtrowania + agregowania w miarę ich wprowadzania? Wydaje się, że może to być niebezpieczne wąskie gardło, jeśli objętość kłody jest wysoka i / lub agregacja nie jest trywialna.
hiwaylon
OP wspomniała o tomach „setek tysięcy wydarzeń dziennie”. Milion wydarzeń dziennie to mniej niż siedemset na minutę, czyli około jedenastej na sekundę. O ile dane wejściowe nie zawierają jakiegoś długiego kodu XML, przeciętny serwer powinien być w stanie sobie z tym poradzić bez potu. Jest to zdecydowanie coś, co należy wziąć pod uwagę podczas projektowania (i wdrażania) rozwiązania.
TMN
1

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) ....

Picarus
źródło