pl apacze

Kafka pod specjalnym nadzorem. Monitorowanie Apache Kafki w zarządzaniu Procesem… biznesowym

„Ktoś musiał zrobić doniesienie na Józefa K., bo mimo że nic złego nie popełnił, został pewnego ranka po prostu aresztowany”. [1]  To – jedno z lepiej znanych pierwszych zdań powieści – pochodzi z promieniującego absurdem i dystopią „Procesu” Franza Kafki. Gdy u Kafki poczucie zagrożenia bierze się z niejasnego zagrożenia i braku jasnych zasad – w innym klasycznym przykładzie, „Roku 1984” Orwella. dystopijny charakter świata osiągnięty jest przede wszystkim dzięki istnieniu permanentnego i wszechwiedzącego monitoringu obywateli.
Jak to często bywa – co dla ludzi byłoby światem nie do zniesienia, w systemach zbudowanych z kodu, jest konieczne do sprawnego, efektywnego i bezpiecznego działania. W dzisiejszym artykule przybliżymy Wam w związku z tym, jak zespół pracujący nad Flowee – naszą autorską platformą BPMN umożliwiającą łatwe tworzenie, zarządzanie i uruchamianie szeroko pojętych procesów biznesowych – wykorzystuje jeden z technicznych elementów tej platformy działający „w tle”, Apache Kafka. Oraz to, jak Kafkę monitorować 😉 [2] Jeśli chcecie wypróbować sposoby na monitorowanie – logujcie się na GtiHub, mamy dla Was repozytorium z przykładami.

Flowee jest platformą zaprojektowaną z myślą o minimalizowaniu konieczności pisania kodu podczas wdrażania nowych procesów u klienta. Osiąga to dzięki rozbudowanym graficznym edytorom procesów i formularzy. Jeśli chcesz dowiedzieć się o niej więcej, zajrzyj NA STRONĘ.

1. Co to jest Apache Kafka?

Apache Kafka to system przesyłania wiadomości zaprojektowany do obsługi dużych wolumenów danych w czasie rzeczywistym. To oznacza, że głównym celem tej platformy jest umożliwienie tworzenia systemów, dla których kluczowa jest możliwość szybkiego skalowana i asynchronicznego działania w postrzeganym przez użytkownika czasie rzeczywistym. Kafka została pierwotnie stworzona przez LinkedIn i jest obecnie projektem typu open-source zarządzanym przez Apache Software Foundation. Jest szeroko stosowana do budowy skalowalnych aplikacji przetwarzających strumienie danych, agregacji logów, systemów telemetrii, integracji danych, w architekturach opartych na mikrousługach i wielu innych. Za dowód niezawodności i skalowalności Kafki niech służy choćby to, że w 2019 roku LinkedIn, który z Kafki korzysta – podawał, że oparta na niej infrastruktura obsługuje 7 bilionów komunikatów dziennie! Dla tych, którzy gubią się w ilościach zer – bilion to inaczej milion milionów lub tysiąc miliardów. Robi wrażenie!

2. Apache Kafka we Flowee

Flowee jest systemem rozproszonym złożonym z wielu mikrousług. Każda z nich odpowiada za mały, jasno zdefiniowany, fragment logiki całego systemu. Jak w każdej tego typu architekturze – kluczowe jest zapewnienie niezawodnego i efektywnego mechanizmu komunikacji. Tworząc Flowee do realizacji tego celu wybraliśmy właśnie system Apache Kafka.

3. Dlaczego monitorowanie klastra Kafki jest kluczowe?

Monitorowanie Apache Kafka w środowisku produkcyjnym jest kluczowe z wielu powodów, zarówno pod kątem zapewnienia niezawodności i wydajności systemu, jak i minimalizowania czasu przestoju w razie problemów. Wyróżnić wśród nich możemy przede wszystkim następujące kwestie:

Monitorowanie pomaga zrozumieć, jak wykorzystywane są zasoby Kafki i gdzie mogą występować wąskie gardła. Pozwala to na optymalizację wydajności i zarządzanie zasobami w sposób bardziej efektywny.

Wczesne wykrywanie problemów, takich jak opóźnienia w przetwarzaniu, przeciążenie brokerów Kafki czy problemy z siecią, jest kluczowe dla utrzymania ciągłości działania systemu. Szybkie identyfikowanie i rozwiązywanie problemów minimalizuje negatywny wpływ na działalność biznesową. 

Monitorowanie pozwala na zrozumienie wzorców użytkowania i przepustowości systemu, co jest niezbędne przy planowaniu skalowania. Informacje te pomagają w podejmowaniu decyzji o rozbudowie lub modyfikacji infrastruktury w celu obsługi większego obciążenia.

Monitorowanie może pomóc w wykrywaniu nietypowych wzorców działania, które mogą wskazywać na problemy z bezpieczeństwem (np. ataki DDoS czy próby nieautoryzowanego dostępu). 

Wiele organizacji musi spełniać określone wymagania dotyczące dostępności i wydajności swoich usług. Monitorowanie pomaga w zapewnieniu, że usługi Kafka oraz aplikacje z niej korzystające spełniają te wymagania. 

W środowiskach produkcyjnych, gdzie przetwarzane są duże wolumeny danych, ważne jest, aby przepływ danych przez Kafkę był jak najbardziej efektywny. Monitorowanie pozwala na identyfikację i eliminację wąskich gardeł w przepływie danych.

Monitorowanie Kafki w środowisku produkcyjnym jest nie tylko kwestią utrzymania infrastruktury w sprawności, ale również strategicznym elementem zarządzania wydajnością, bezpieczeństwem i kosztami operacyjnymi systemów bazujących na tej technologii. 

4. Jak monitorujemy Kafkę we Flowee?

Monitoring we Flowee jest zrealizowany przez użycie dwóch narzędzi: Prometheus i Grafana. Pierwsze z nich odpowiada za zbieranie bieżących pomiarów ze zdefiniowanych źródeł, którymi mogą być np. poszczególne mikrousługi lub brokery Kafki. Grafana zaś pozwala na wizualizację w postaci wykresów gromadzonych przez Prometheus pomiarów. 

Tutaj znajdziecie dostępne repozytorium z gotową do uruchomienia konfiguracją docker compose demonstrującą działanie opisywanych w artykule konfiguracji. 

Po sklonowaniu repozytorium, aby uruchomić przykładowe środowisko, należy użyć polecenia: 

				
					docker compose -f compose.yaml up -d 
				
			

Po ich uruchomieniu w przeglądarce dostępne są dwa panele: 

Grafana: http://localhost:3000/dashboards 

Kafka UI: http://localhost:8080 (hasło admin:admin) 

4.1 Monitoring brokerów Kafki

Poszczególne części składowe klastra Kafki, czyli brokery, monitorujemy przez zainstalowanie w nich biblioteki jmx_exporter (https://github.com/prometheus/jmx_exporter). Dzięki temu poszczególne procesy udostępniają przez endpoint na porcie 8888 aktualne pomiary monitorowanych parametrów. Zmierzone wartości są następnie cyklicznie pobierane przez serwer Prometheus. 

Przykładowe parametry, które możemy monitorować dzięki jmx_exporter to m.in.: liczba aktywnych brokerów, liczba aktywnych partycji, partycje o niedostatecznej replikacji, liczba komunikatów na sekundę, obciążenie procesora, ilość danych przesyłanych z każdego i do każdego brokera, ilość danych przechowywanych na dysku przez poszczególne brokery, statystki producentów i konsumentów wiadomości, statystki dotyczące wewnętrznej replikacji danych między brokerami Kafki, oraz wiele innych. 

Konfiguracja jmx_exporter w brokerach Kafki polega na uruchomieniu procesu Java z tzw. agentem Java (przełącznik -javaagent):  

				
					KAFKA_OPTS: '-javaagent:/bitnami/kafka/libs/jmx_prometheus_javaagent-0.20.0.jar=8888:/bitnami/kafka/libs/kafka_broker.yml' 
				
			

Natomiast konfiguracja Prometheus zaczytująca wartości udostępniane przez jmx_exporter wygląda następująco: 

				
					- job_name: "kafka-broker" 
        static_configs: 
          - targets: 
            - kafka-1:8888 
            - kafka-2:8888 
            - kafka-3:8888 
        labels: 
            env: "dev" 
         relabel_configs: 
            - source_labels: [__address__] 
            target_label: hostname 
            regex: '([^:]+)(:[0-9]+)?' 
            replacement: '${1}' 
				
			

4.2. Monitoring opóźnień w konsumpcji wiadomości przez konsumentów ​

Jednym z podstawowych parametrów, który należy monitorować w systemach zbudowanych z wykorzystaniem Kafki, jest opóźnienie konsumpcji komunikatów.  Wysokie opóźnienie wskazuje na to, że konsumenci nie nadążają z przetwarzaniem wiadomości produkowanych do tematów w Kafce. Może to być sygnał problemów z wydajnością w aplikacjach konsumujących i wymaga podjęcia działań naprawczych – takich jak zwiększenie liczby instancji mikrousługi (ang. scale-out) czy optymalizacja implementacji komponentów w odpowiedzialnych za przetwarzanie danych.  Do zbierania statystyk dotyczących opóźnień konsumpcji korzystamy z aplikacji kafka-lag-exporter: https://github.com/seglo/kafka-lag-exporter Jest ona zdefiniowowana w pliku compose.yaml: 
				
					kafka-lag-exporter: 
        image: seglo/kafka-lag-exporter:0.8.2 
        volumes: 
            - ${PWD}/kafka-lag-exporter:/opt/docker/conf 
				
			

Natomiast w katalogu kafka-lag-exporter/application.conf znajduje się konfiguracja dla tej aplikacji: 

				
					kafka-lag-exporter { 
    port = 9999 
    client-group-id = "kafkaLagExporter"
    lookup-table-size = 120 
    poll-interval = 60 
    
    clusters = [ 
        { 
        name = "dev-cluster" 
        bootstrap-brokers = "kafka-1:29092,kafka-2:29092,kafka-3:29092" 
        
        admin-client-properties = { 
            client.id = "admin-client-id" 
            security.protocol = "PLAINTEXT" 
        } 
        
        consumer-properties = { 
            client.id = "consumer-client-id" 
            security.protocol = "PLAINTEXT" 
        } 
    } 
   ]
  }
				
			

Panel Grafana dla kafka-lag-exporter znajduje się w pliku: Kafka Lag Exporter.yaml. Jest on automatycznie wczytywany przy starcie przykładowego środowiska i jest dostępny pod adresem: http://localhost:3000/dashboards 

4.3. Kafka UI

Ostatnim demonstrowanym narzędziem jest Kafka UI: https://github.com/provectus/kafka-ui. Za jego pomocą można sprawdzić stan klastra, jego konfigurację oraz przeglądać i wyszukiwać zapisane w brokerach Kafki wiadomości. Jest to nieodzowne podczas prac programistycznych oraz analizy incydentów w środowisku produkcyjnym.

W naszym demonstracyjnym środowisku Kafka UI jest dostępna pod adresem: http://localhost:8080 (hasło i login admin:admin) 

I tym samym – wiecie już, jak monitorować Kafkę niczym Wielki Brat! 😉  

  • [1] Franz Kafka Proces, tłum. Bruno Schulz
[2] Nazwa Apache Kafki naprawdę pochodzi od Franza Kafki. 
Jay Kreps lubi twórczość pisarza i uważa, że – ponieważ system jest zoptymalizowany do pisania – powinien przyjąć nazwę właśnie od kogoś parającego się pisaniem w naturalnym języku.

CIEKAWE? POdziel się