Czy istnieją konwencje nazywania/organizowania indeksów Elasticsearch, które przechowują dane dziennika?

Question

Jestem w trakcie konfigurowania Elasticsearch i Kibana jako scentralizowanej platformy logowania w naszym biurze.

Mamy wiele niestandardowych programów narzędziowych i wtyczek, które chciałbym śledzić i jeśli użytkownicy napotykają jakiekolwiek błędy. Nie wspominając już o serwerach i zaplanowanych zadaniach, które również chciałbym śledzić.

Więc jeśli mam wiele różnych źródeł danych logów, wszystkie przechodzą do tego samego klastra elastycznego wyszukiwania, jakie są konwencje lub najlepsze praktyki dotyczące sposobu, w jaki jest to zorganizowane w indeksy i typy dokumentów?

Domyślną wartością indeksu stosowaną przez Logstash jest "logstash-%{+YYYY.MM.dd}". Wygląda więc na to, że najlepiej jest dodać nazwy indeksów z aktualną datą, ponieważ ułatwia to usuwanie starych danych.

Jednak Kibana pozwala na dodanie wielu "wzorców indeksów", które można wybrać w interfejsie użytkownika. Jednak wszystkie tutoriale, o których czytałem, wspominają tylko o tworzeniu jednego wzorca, takiego jak logstash-*.

W jaki sposób stosuje się wiele wzorców indeksu w praktyce? Czy mogę podać nazwy wszystkich źródeł moich danych? Takich jak:

BackupUtility-%{+YYYY.MM.dd} 
UserTracker-%{+YYYY.MM.dd} 
ApacheServer-%{+YYYY.MM.dd} 

Używam nLog w wielu moich narzędzi, które posiada elastic search target. Konwencją dla nLog i innych podobnych frameworków do logowania jest posiadanie "rejestratora" dla każdej klasy w kodzie źródłowym. Czy ten rejestrator powinien przełożyć się na indeksy w wyszukiwaniu elastycznym?

MyCompany.CustomTool.FooClass-%{+YYYY.MM.dd} 
MyCompany.CustomTool.BarClass-%{+YYYY.MM.dd} 
MyCompany.OtherTool.BazClass-%{+YYYY.MM.dd} 

Albo jest to zbyt ziarnisty nazw indeksów elasticsearch, i byłoby lepiej trzymać się tylko do jednego datowanego wskaźnika dla aplikacji?

CustomTool-%{+YYYY.MM.dd} 

Answer 1

nie jestem świadomy takich konwencji, ale dla mojego środowiska, użyliśmy stworzyć dwa różne typy indeksów logstash-* i logstash-shortlived-* w zależności od stopnia nasilenia. W moim przypadku tworzę wzorzec indeksu logstash-*, ponieważ będzie on spełniał oba rodzaje indeksów.

Ponieważ te indeksy będą przechowywane w Elasticsearch, a Kibana je odczyta, myślę, że powinien dać ci możliwość tworzenia indeksów o różnych wzorach. Spróbuj na lokalnej maszynie. Dlaczego nie spróbujesz logstash-XYZ, jeśli chcesz uzyskać większą szczegółowość, w przeciwnym razie zawsze możesz utworzyć indeksy z niestandardową nazwą.

Answer 2

W moim środowisku pracujemy nad podobnym pytaniem. Mamy mieszankę dzienników systemowych, alertów metrycznych z Prometheus oraz dzienników aplikacji z aplikacji klienckich i serwerowych. Ponadto mamy kilka wspólnych zmiennych między aplikacjami klienckimi i serwerowymi, które pozwalają nam je powiązać (np. Wiemy, które dzienniki serwera pasują do operacji na kliencie, która wysłała żądania do wspomnianego serwera).Jesteśmy eksperymentuje z poniższym schematem, aby pomóc odpowiedzieć na pytania Kibana dla nas:

logs-system-{date} 
logs-iis-{date} 
logs-prometheus-{date} 
logs-app-{applicationName}-{date} 

Gdzie:

• {applicationName} to unikalna nazwa jakiejś aplikacji pisaliśmy (mogą to być klient lub po stronie serwera)
• {date} jest cokolwiek data oparte schemat użyć dla indeksów

ten sposób możemy skonfigurować Kibana przeszukuje przeciwko LO gs-app- * i szybkie wyszukiwanie logów wśród naszych aplikacji. Jest to dla nas wciąż nowe, ale zaczęliśmy bez tego schematu i już tego żałujemy. To sprawia, że ​​wyszukiwanie skorelowanych dzienników w aplikacjach jest znacznie trudniejsze niż powinno.

Answer 3

W mojej firmie dużo pracowaliśmy na ten temat. Zgadzamy się w następujący sposób:

• Klientowi - Ten produkt --- Zastosowanie ---- Data

W każdym razie, jest to neccesary recenzję zarówno jak dane są zorganizowane i w jaki sposób dane są konsultowane wewnątrz organizacji

poważaniem

Dario Rodriguez