Dlaczego potrzebuję brokera do mojego produkcyjnego stosu ELK + specyfikacji maszyny?

Question

Niedawno wypróbowałem testową stertę Ubuntu ELK stack, aby przetestować funkcjonalność i byłem z niej bardzo zadowolony. Mój przypadek użycia do produkcji wymagałby spożywania co najmniej 100 GB dzienników dziennie. Chcę być tak skalowalny, jak to możliwe, ponieważ to 100 GB/dzień może szybko wzrosnąć, ponieważ mieliśmy więcej źródeł dziennika.

Przeczytałem kilka artykułów na temat produkcji ELK, w tym fantasic Logz.io ELK Deployment. Chociaż mam ogólne pojęcie o tym, co muszę zrobić, nie jestem pewien co do podstawowych pojęć, ile maszyn potrzebuję do tak dużej ilości danych i czy potrzebuję brokera takiego jak Redis w mojej architekturze.

Jaki jest cel brokera takiego jak Redis? W mojej instancji testowej mam wiele źródeł dziennika wysyłających logi przez TCP, syslog i forwarder logstash do mojego Logstash bezpośrednio na moim serwerze ELK (który również ma zainstalowane Elasticsearch, Nginx i Kibana z SSL).

W celu zachowania wysokiej dostępności najnowocześniejszego klastra produkcyjnego, jakie maszyny i specyfikacje są mi potrzebne w przypadku co najmniej 100 GB danych dziennie, prawdopodobnie w skali do 150 GB lub więcej w przyszłości? Planuję używać własnych serwerów. Z tego, co zbadałem, punktem wyjścia powinno być coś podobnego (zakładając, że włączam Redisa):

• Serwery 2/3 z instancją Redis + Logstash (indeksowaniem) dla każdego serwera. Dla specyfikacji mam na myśli 32 GB RAM, szybki dysk I/O 500GB może SSD, 8 rdzeni (i7)
• 3 serwery dla Elasticsearch (jest to ten, którego najbardziej nie jestem pewien) - Wiem, że potrzebuję co najmniej 3 węzły główne i 2 węzły danych, więc 2 serwery będą miały po 1 dane master/1 - będą to potężne 64 GB pamięci RAM, 20 TB, 8 rdzeni. Drugi pozostały węzeł główny może znajdować się na maszynie o niskim poziomie szczegółowości, ponieważ nie obsługuje danych.
• 2 serwery dla Nginx/Kibana - powinny to być maszyny o niewielkich rozmiarach, ponieważ są tylko serwerem WWW i interfejsem użytkownika. Czy konieczne jest tu wyrównywanie obciążenia?

EDYCJA: Planuje się prowadzenie dzienników przez 60 dni.

Answer 1

Jeśli chodzi o Redis, działa jak bufor w przypadku, gdy logstash i/lub elastyczne wyszukiwanie są wyłączone lub spowolnione. Jeśli używasz pełnej logstash lub logstash-forwarder jako nadawca, to wykryje, kiedy logstash jest niedostępny i przestanie wysyłać dzienniki (pamiętając, gdzie zostało przerwane, przynajmniej na chwilę).

Tak więc, w czystym środowisku logstash/logstash-forwarder, nie widzę powodu, aby używać brokera takiego jak redis.

Kiedy staje się ważny, jest dla źródeł, które nie dbają o status logstash i nie buforują po swojej stronie. syslog, snmptrap i inne należą do tej kategorii. Ponieważ twoje źródła zawierają syslog, chciałbym przywołać brokerów w twojej instalacji.

Redis jest aplikacją intensywnie wykorzystującą pamięć RAM, a ta ilość pamięci, którą posiadasz, będzie decydować o tym, jak długo można znieść awarię logstashu. Na serwerze o pojemności 32 GB (współdzielonym z logstash), ile pamięci dałabyś yo redis? Jak duży jest średni rozmiar dokumentu? Ile dokumentów zajęłoby wypełnienie pamięci? Ile czasu zajmuje wygenerowanie tylu dokumentów? Z mojego doświadczenia wynika, że ​​redis upada okropnie, gdy pamięć się wypełnia, ale to mógłbym być ja.

Logstash jest procesem wymagającym dużego obciążenia procesora, ponieważ wszystkie filtry są wykonywane.

Jeśli chodzi o rozmiar klastra elastycznego wyszukiwania, @magnus już wskazał ci pewne informacje, które mogą pomóc. Począwszy od maszyn o pojemności 64 GB jest świetny, a następnie skalować w poziomie w razie potrzeby.

Powinieneś mieć dwa węzły klienta (inne niż dane), które są używane jako punkt dostępu do insertów (efektywnie wysyłaj żądania do właściwego węzła danych) i wyszukiwania (obsługują fazę "zmniejszenia" danymi zwracanymi z danych węzły). Dwa z nich w konfiguracji failover będą dobrym początkiem.

Dwie maszyny kibana zapewnią nadmiarowość. Umieszczenie ich w konfiguracji failover również jest dobre. nginx był bardziej używany z kibaną3, jak sądzę. Nie wiem, czy ludzie używają go z kibana4, czy też przeszli do "tarczy".

Nadzieję, że pomaga.