Monitorowanie Manticore Search: jak zdiagnozować spowolnienie wyszukiwania w 5 minut
Gdy wyszukiwanie w Manticore Search zaczyna działać wolniej bez awarii serwisu, standardowe metryki często ukrywają prawdziwy problem. Użytkownicy zauważają opóźnienia, ale obciążenie CPU i średni czas odpowiedzi pozostają w normie. Diagnostyka staje się rutyną: sprawdzanie kolejek, logów, obciążenia poszczególnych workerów. Rozwiązanie — gotowy dashboard Grafana uruchamiany jedną komendą Docker. Agreguje krytyczne metryki w jednolitym interfejsie, skracając czas wykrywania incydentów z godzin do minut.
Dlaczego standardowy monitoring nie reaguje na częściowe spowolnienie
Typowy scenariusz: serwis technicznie działa poprawnie, ale użytkownicy narzekają na wolne wyszukiwanie. Podczas analizy:
- Średni czas odpowiedzi mieści się w akceptowalnych granicach
- Obciążenie CPU nie przekracza 70%
- Alerty nie uruchamiają się
Tymczasem latencja p99 rośnie, kolejka zapytań stopniowo się wydłuża, a pojedyncze ciężkie zapytania blokują przetwarzanie. Problem tkwi w rozproszeniu danych: metryki są rozłożone na różne narzędzia, a ich korelacja pozostaje niezauważona. Na przykład restart nody może być odnotowany w logach, a wzrost kolejki — w statystykach procesu. Bez jednolitego kontekstu diagnostyka wymaga ręcznego porównywania źródeł.
Uruchomienie gotowego dashboardu: szczegóły techniczne
Rozwiązanie to kontener z zintegrowanymi komponentami: Grafana, Prometheus i konfiguracja dla Manticore Search. Uruchomienie sprowadza się do jednej komendy:
docker run -p 3000:3000 manticoresearch/dashboard
Kluczowe parametry konfiguracji:
MANTICORE_TARGETS: lista instancji oddzielonych przecinkami (domyślnielocalhost:9308)GF_AUTH_ENABLED: włączenie uwierzytelniania w Grafana (domyślnie wyłączone)
Przykład dla klastra z trzech nodów:
docker run -p 3000:3000 \
-e MANTICORE_TARGETS=node1:9308,node2:9308,node3:9308 \
manticoresearch/dashboard
Przy zdalnym dostępie do serwera użyj tunelu SSH:
ssh -L 9308:localhost:9308 user@your-server
To przekierowuje lokalny port 9308 na zdalny host, umożliwiając dashboardowi połączenie z Manticore Search.
Kluczowe metryki w jednolitym interfejsie
Dashboard jest zorganizowany wokół pytań pojawiających się podczas incydentów. Główne sekcje:
- Ogólny status systemu
- Dostępność serwisu (zielony/czerwony wskaźnik)
- Czas ostatniego restartu nodów
- Dynamika wzrostu kolejki zapytań
- Aktualne obciążenie workerów
- Analiza obciążenia
- p95 i p99 czasu odpowiedzi
- Rozkład zapytań według typów
- Wykrywanie anomaliów (top-10 najdłuższych)
- Korelacja obciążenia workerów i kolejki
- Klaster i dane
- Stan replikacji
- Zużycie pamięci przez tabele
- Błędy indeksowania
- Rozmiary indeksów
Szczególna wartość to wizualizacja powiązań. Na przykład nakładka grafiki kolejki na obciążenie workerów natychmiast pokazuje, czy system osiągnął limit paralelizmu. Latencja p99 jest wyświetlana oddzielnie od średniej, ujawniając ukryte opóźnienia.
Jak dashboard skraca czas MTTR
Tradycyjna diagnostyka wymaga sekwencyjnego sprawdzania 5-7 źródeł danych. Gotowy dashboard eliminuje ten etap, skupiając uwagę na trzech kluczowych sygnałach:
- Wzrost kolejki przy 100% obciążeniu workerów — wskazuje na brak zasobów przetwarzania
- Rozbieżność p99 i średniego czasu odpowiedzi — wykrywa punktowe problemy w zapytaniach
- Synchronizowane restarty nodów — ostrzega przed problemami klastra
W rzeczywistych przypadkach to skraca średni czas wykrycia problemu (MTTD) z 120 do 8 minut. Zespół od razu widzi, czy skalować workery, optymalizować konkretne zapytania czy sprawdzać łączność sieciową nodów.
Co jest najważniejsze
- Jedna tabela zamiast rozproszonych metryk: wszystkie kluczowe wskaźniki dostępne bez przełączania narzędzi
- Skupienie na percentylach: p95/p99 odpowiedzi ważniejsze od średniej dla wykrywania ukrytych problemów
- Automatyczna korelacja zdarzeń: restart nody natychmiast łączy się ze wzrostem kolejki
- Gotowe alerty: progi ustawione pod realne scenariusze degradacji
- Minimalne koszty wdrożenia: kontener uruchamiany bez zmian w konfiguracji Manticore
Integracja nie zastępuje głębokiej analizy, ale eliminuje 80% czasu spędzanego na zbieraniu danych. Po wykryciu anomalii inżynier przechodzi od razu do profilowania zapytań lub alokacji zasobów. To zmienia proces: zamiast „co sprawdzić?” zespół pyta „jak naprawić?”.
— Editorial Team
Brak komentarzy.