Przyjrzymy się koncepcji monitorowania Kubernetes, zapoznamy się z narzędziem Prometheus i porozmawiamy o alertowaniu.
Temat monitorowania jest obszerny, więc trudno go omówić w jednym artykule. Celem tego tekstu jest przedstawienie przeglądowe narzędzi, koncepcji i podejść.
Materiał artykułu — podsumowanie z . Jeśli chcesz przejść pełne szkolenie — zapisz się na kurs dotyczący .
Co monitoruje się w klastrze Kubernetes
Fizyczne serwery. Jeśli klaster Kubernetes jest uruchomiony na własnych serwerach, należy śledzić ich stan. Z tym zadaniem radzi sobie Zabbix; jeśli go używasz, nie musisz rezygnować, ponieważ nie będzie kolizji. To właśnie Zabbix monitoruje stan naszych serwerów.
Przejdźmy do monitorowania na poziomie klastra.
Komponenty Control Plane: API, Scheduler i inne. Co najmniej należy monitorować, aby liczba serwerów API lub etcd była większa od 0. Etcd potrafi dostarczać wiele metryk: dotyczących dysków, na których działa, stanu swojego klastra etcd i innych.
Docker pojawił się dawno temu i o jego problemach wiadomo wszystkim: wiele kontenerów powoduje zawieszanie się i inne problemy. Dlatego sam Docker, jako system, również należy monitorować, przynajmniej pod kątem dostępności.
DNS. Jeśli w klastrze przestanie działać DNS, to cały system Discovery również przestanie działać, a komunikacje między podami przestaną funkcjonować. W mojej praktyce nie miałem podobnych problemów, ale to nie znaczy, że nie należy monitorować stanu DNS. Opóźnienia w zapytaniach i inne metryki można śledzić na CoreDNS.
Ingress. Należy kontrolować dostępność ingressów (w tym Ingress Controller) jako punktów dostępu do projektu.
Podstawowe komponenty klastra zostały omówione — teraz przejdźmy niżej, na poziom abstrakcji.
Wydawałoby się, że aplikacje uruchamiane są w podach, więc należy je monitorować, ale w rzeczywistości nie. Pody są efemeryczne: dziś działają na jednym serwerze, jutro na innym; dziś jest ich 10, jutro 2. Dlatego nikt nie monitoruje po prostu podów. W architekturze mikrousług ważniejsze jest monitorowanie dostępności aplikacji jako całości. W szczególności należy sprawdzać dostępność punktów końcowych usługi: czy coś działa? Jeśli aplikacja jest dostępna, to co się za nią dzieje, ile jest teraz replik — to są pytania drugorzędne. Nie ma potrzeby monitorować pojedynczych instancji.
Na najwyższym poziomie należy kontrolować pracę samej aplikacji, zbierać metryki biznesowe: liczbę zamówień, zachowanie użytkowników i inne.
Prometheus
Najlepszym systemem monitorowania klastra jest . Nie znam żadnego narzędzia, które mogłoby dorównać Prometheus pod względem jakości i łatwości użycia. Doskonale nadaje się do elastycznej infrastruktury, dlatego gdy mówi się „monitorowanie Kubernetes”, zazwyczaj ma się na myśli właśnie Prometheus.
Są dwa sposoby, by zacząć pracę z Prometheus: za pomocą Helm można zainstalować standardowy Prometheus lub Prometheus Operator.
- Standardowy Prometheus. Działa dobrze, ale wymaga konfiguracji ConfigMap — w praktyce oznacza to pisanie tekstowych plików konfiguracyjnych, jak robiliśmy wcześniej, przed architekturą mikroserwisów.
- Prometheus Operator jest nieco bardziej rozbudowany, trochę bardziej skomplikowany od wewnątrz, ale łatwiej się z nim pracuje: są oddzielne obiekty, abstrakcje są dodawane do klastra, co znacznie ułatwia kontrolę i konfigurację.
Aby zrozumieć produkt, polecam zacząć od standardowego Prometheus. Będzie trzeba skonfigurować wszystko za pomocą pliku konfiguracyjnego, ale to przyniesie korzyści: zrozumiecie, co do czego odnosi się i jak to skonfigurować. W Prometheus Operator od razu wchodzicie na wyższy poziom abstrakcji, chociaż jeśli chcecie, można również zbadać głębie.
Prometheus jest dobrze zintegrowany z Kubernetes: może komunikować się z API Server i współdziałać z nim.
Prometheus jest popularny, dlatego wspiera go wiele aplikacji i języków programowania. Wsparcie jest potrzebne, ponieważ Prometheus ma swój własny format metryk, a do ich przesyłania potrzebna jest albo biblioteka wewnątrz aplikacji, albo gotowy eksporteur. A takich eksporteurów jest całkiem sporo. Na przykład, istnieje PostgreSQL Exporter: pobiera dane z PostgreSQL i konwertuje je na format Prometheus, aby Prometheus mógł z nimi pracować.
Architektura Prometheus
Serwer Prometheus — to część serwerowa, umysł Prometheus. Tutaj przechowywane są i przetwarzane metryki.
Metryki są przechowywane w bazie danych szeregów czasowych (TSDB). TSDB to nie osobna baza danych, a pakiet napisany w języku Go, który jest wbudowany w Prometheus. Mówiąc w prost, wszystko znajduje się w jednym binarnym pliku.
Nie przechowuj danych w TSDB długo.
Infrastruktura Prometheus nie jest odpowiednia do długoterminowego przechowywania metryk. Domyślnie czas przechowywania wynosi 15 dni. Można przekroczyć to ograniczenie, ale należy pamiętać: im więcej danych będziesz przechowywać w TSDB i im dłużej to robisz, tym więcej zasobów to będzie wymagać. Przechowywanie danych historycznych w Prometheus uważane jest za złą praktykę.
Jeśli masz ogromny ruch, a liczba metryk wynosi setki tysięcy na sekundę, lepiej ograniczyć ich przechowywanie według objętości dysku lub według czasu. Zazwyczaj w TSDB przechowuje się "gorące dane", metryki dosłownie sprzed kilku godzin. Do dłuższego przechowywania używa się zewnętrznych magazynów w tych bazach danych, które rzeczywiście są do tego odpowiednie, na przykład InfluxDB, ClickHouse i tak dalej. Wiele dobrych opinii widziałem o ClickHouse.
Serwer Prometheus działa w modelu pull: sam zbiera metryki z tych punktów końcowych, które mu przekazaliśmy. Powiedzieliśmy: „zbieraj z API Server”, a on co n-ty sekund tam zagląda i pobiera metryki.
Dla obiektów o krótkiej żywotności (job lub cron job), które mogą się pojawiać między cyklami skanowania, jest komponent Pushgateway. W nim są przesyłane metryki z krótkoterminowych obiektów: job został uruchomiony, wykonał działanie, wysłał metryki do Pushgateway i zakończył działanie. Po pewnym czasie Prometheus w swoim tempie zbiera te metryki z Pushgateway.
Do ustawienia powiadomień w Prometheus jest osobny komponent — Alertmanager. I zasady alertingowe — alerting rules. Na przykład, trzeba stworzyć alert w przypadku, gdy API serwerów wynosi 0. Gdy zdarzenie występuje, alert jest przekazywany do alert managera w celu dalszego przesyłania. W alert managerze dostępne są dość elastyczne ustawienia routingu: jedną grupę alertów można wysłać do czatu Telegram dla administratorów, inną do czatu deweloperów, a trzecią do czatu inżynierów infrastruktury. Powiadomienia mogą przychodzić na Slack, Telegram, e-mail i inne kanały.
I na koniec opowiem o killer-funkcji Prometheus — Discovering. Przy pracy z Prometheus nie trzeba podawać konkretnych adresów obiektów do monitorowania, wystarczy określić ich typ. To znaczy, nie trzeba pisać „oto adres IP, oto port — monitoruj”, zamiast tego należy określić, na jakich zasadach znaleźć te obiekty (targets — cele). Prometheus sam, w zależności od tego, jakie obiekty są obecnie aktywne, pobiera potrzebne i dodaje do monitoringu.
Takie podejście dobrze pasuje do struktury Kubernetes, gdzie wszystko się zmienia: dzisiaj 10 serwerów, jutro 3. Aby za każdym razem nie podawać adresu IP serwera, napisaliśmy raz, jak go znaleźć — a Discovering to zrobi.
Język Prometheus nazywa się PromQL. Dzięki temu językowi można uzyskiwać wartości konkretnych metryk, a następnie je przetwarzać i budować na ich podstawie analizy.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Proste zapytanie
container_memory_usage_bytes
Operacje matematyczne
container_memory_usage_bytes / 1024 / 1024
Funkcje wbudowane
sum(container_memory_usage_bytes) / 1024 / 1024
Precyzowanie zapytania
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Interfejs webowy Prometheus
Prometheus ma swój, dość minimalistyczny interfejs webowy. Nadaje się głównie do debugowania lub prezentacji.
W polu Expression można pisać zapytania w języku PromQL.
W zakładce Alerts znajdują się zasady alarmów — alerting rules; mają one trzy statusy:
- inactive — jeśli w danym momencie alarm nie jest aktywny, tzn. wszystko jest w porządku, i nie zadziałał;
- pending — to w przypadku, gdy alarm zadziałał, ale wysyłka jeszcze nie dotarła. Opóźnienie jest ustalane, aby zrekompensować migotanie sieci: jeśli w ciągu minuty wskazany serwis został uruchomiony, nie należy jeszcze wywoływać alarmu;
- firing — to trzeci status, kiedy alarm się włącza i wysyła powiadomienia.
W menu Status znajdziesz dostęp do informacji o tym, czym jest Prometheus. Tam również znajduje się przejście do celów (targets), o których mówiliśmy wcześniej.
Bardziej szczegółowy przegląd interfejsu Prometheus można znaleźć .
Integracja z Grafana
W interfejsie webowym Prometheus nie znajdziesz ładnych i czytelnych wykresów, na podstawie których można wyciągać wnioski o stanie klastra. Aby je tworzyć, Prometheus integruje się z Grafana. Oto takie pulpitów.
Skonfigurowanie integracji Prometheus i Grafana nie jest trudne, instrukcje znajdziesz w dokumentacji: , a ja na tym kończę.
W następnych artykułach kontynuujemy temat monitorowania: porozmawiamy o zbieraniu i analizie logów za pomocą Grafana Loki oraz alternatywnych narzędzi.
Autor: Marcel Ibraev, certyfikowany administrator Kubernetes, inżynier praktykujący w firmie , mówca i twórca kursów Sloerm.
Źródło: habr.com
