Rozważ koncepcję monitorowania Kubernetes, zapoznaj się z narzędziem Prometheus i porozmawiaj o alertowaniu.
Temat monitoringu jest obszerny, nie da się go rozłożyć w jednym artykule. Celem tego tekstu jest przedstawienie przeglądu narzędzi, koncepcji i podejść.
Materiał artykułu jest wyciskany z . Jeśli chcesz wziąć udział w pełnym kursie - zapisz się na kurs na .
Co jest monitorowane w klastrze Kubernetes
serwery fizyczne. Jeśli na jego serwerach wdrożony jest klaster Kubernetes, należy monitorować ich kondycję. Zabbix zajmuje się tym zadaniem; jeśli z nim współpracujesz, nie musisz odmawiać, nie będzie konfliktów. To Zabbix monitoruje stan naszych serwerów.
Przejdźmy do monitoringu na poziomie klastra.
Komponenty płaszczyzny sterowania: API, Harmonogram i inne. Przynajmniej musisz upewnić się, że API serwerów lub etcd jest większe niż 0. Etcd może zwrócić wiele metryk: dyski, na których się obraca, stan klastra etcd i inne.
Doker pojawił się dawno temu i wszyscy doskonale zdają sobie sprawę z jego problemów: wiele kontenerów powoduje zawieszanie się i inne problemy. Dlatego sam Docker jako system również powinien być kontrolowany, przynajmniej pod kątem dostępności.
dns. Jeśli DNS w klastrze przestanie działać, to po nim przestanie działać cała usługa Discovery, wywołania z podów do podów przestaną działać. W mojej praktyce nie było takich problemów, ale nie oznacza to, że stanu DNS nie trzeba monitorować. Opóźnienie żądania i niektóre inne wskaźniki można śledzić w CoreDNS.
Ingres. Konieczne jest kontrolowanie dostępności ingresów (w tym Ingress Controllera) jako punktów wejścia do projektu.
Główne elementy klastra zostały zdemontowane – zejdźmy teraz na poziom abstrakcji.
Wydawać by się mogło, że aplikacje działają w podach, co oznacza, że trzeba je kontrolować, ale w rzeczywistości tak nie jest. Pody są efemeryczne: dzisiaj działają na jednym serwerze, jutro na innym; dzisiaj jest ich 10, jutro 2. Dlatego nikt nie monitoruje strąków. W architekturze mikrousługowej ważniejsze jest kontrolowanie dostępności aplikacji jako całości. W szczególności sprawdź 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 pytania drugiego rzędu. Nie ma potrzeby monitorowania poszczególnych przypadków.
Na ostatnim poziomie trzeba kontrolować działanie samej aplikacji, brać pod uwagę wskaźniki biznesowe: liczbę zamówień, zachowania użytkowników i tak dalej.
Prometheus
Najlepszym systemem monitorowania klastra jest . Nie znam żadnego narzędzia, które mogłoby dorównać Prometeuszowi pod względem jakości i łatwości obsługi. Świetnie sprawdza się w przypadku elastycznej infrastruktury, dlatego gdy mówią „monitorowanie Kubernetesa”, zwykle mają na myśli Prometheusa.
Istnieje kilka opcji rozpoczęcia pracy z Prometheusem: używając Helma, możesz zainstalować zwykłego Prometheusa lub Prometheusa Operatora.
- Zwykły Prometeusz. Wszystko z nim w porządku, ale trzeba skonfigurować ConfigMap - a właściwie pisać pliki konfiguracyjne w formie tekstowej, tak jak to robiliśmy wcześniej, przed architekturą mikroserwisową.
- Prometheus Operator jest trochę bardziej rozbudowany, nieco bardziej skomplikowany pod względem wewnętrznej logiki, ale łatwiej się z nim pracuje: są osobne obiekty, do klastra dodawane są abstrakcje, dzięki czemu znacznie wygodniej jest je kontrolować i konfigurować.
Aby zrozumieć produkt, zalecam najpierw zainstalowanie zwykłego Prometheusa. Będziesz musiał wszystko skonfigurować za pomocą konfiguracji, ale będzie to korzystne: dowiesz się, co należy do czego i jak jest skonfigurowane. W Prometheus Operator od razu wznosisz się na wyższą abstrakcję, chociaż możesz też zagłębić się w głębiny, jeśli chcesz.
Prometheus jest dobrze zintegrowany z Kubernetesem: może uzyskać dostęp do serwera API i wchodzić z nim w interakcję.
Prometheus jest popularny, dlatego obsługuje go duża liczba aplikacji i języków programowania. Wsparcie jest potrzebne, ponieważ Prometheus ma swój własny format metryk i do jego przeniesienia potrzebna jest albo biblioteka wewnątrz aplikacji, albo gotowy eksporter. A takich eksporterów jest całkiem sporo. Na przykład istnieje PostgreSQL Exporter: pobiera dane z PostgreSQL i konwertuje je do formatu Prometheus, aby Prometheus mógł z nimi pracować.
Architektura Prometeusza
Serwer Prometeusz to zaplecze, mózg Prometeusza. Tutaj przechowywane i przetwarzane są metryki.
Metryki są przechowywane w bazie danych szeregów czasowych (TSDB). TSDB nie jest odrębną bazą danych, ale pakietem w języku Go, który jest osadzony w Prometheusie. Z grubsza rzecz biorąc, wszystko jest w jednym pliku binarnym.
Nie przechowuj danych w TSDB przez długi czas
Infrastruktura Prometheus nie nadaje się do długoterminowego przechowywania metryk. Domyślny okres przechowywania wynosi 15 dni. Możesz przekroczyć ten limit, ale pamiętaj: im więcej danych przechowujesz w TSDB i im dłużej to robisz, tym więcej zasobów pochłonie. Przechowywanie danych historycznych w Prometheusie jest uważane za złą praktykę.
Jeśli masz duży ruch, liczba metryk sięga setek tysięcy na sekundę, wtedy lepiej ograniczyć ich przechowywanie ze względu na miejsce na dysku lub okres. Zwykle „gorące dane” są przechowywane w TSDB, metryki w ciągu zaledwie kilku godzin. W przypadku dłuższego przechowywania używana jest pamięć zewnętrzna w tych bazach danych, które są do tego naprawdę odpowiednie, na przykład InfluxDB, ClickHouse i tak dalej. Widziałem więcej dobrych recenzji na temat ClickHouse.
Serwer Prometheus działa na tym modelu Ciągnąć: pobiera metryki do tych punktów końcowych, które mu daliśmy. Powiedzieli: „przejdź do serwera API”, a on wchodzi tam co n-tą liczbę sekund i pobiera metryki.
W przypadku obiektów o krótkim czasie życia (zadanie lub zadanie cron), które mogą pojawiać się pomiędzy okresami skrobania, dostępny jest komponent Pushgateway. Do niego trafiają metryki z obiektów krótkoterminowych: zadanie się rozpoczęło, wykonało akcję, wysłało metryki do Pushgateway i zostało ukończone. Po pewnym czasie Prometheus zejdzie na dół we własnym tempie i pobierze te dane z Pushgateway.
Aby skonfigurować powiadomienia w Prometheusie, istnieje osobny komponent - Menedżer alertów. I zasady ostrzegania. Na przykład musisz utworzyć alert, jeśli interfejs API serwera ma wartość 0. Po uruchomieniu zdarzenia alert jest przekazywany do menedżera alertów w celu dalszej wysyłki. Menedżer alertów ma dość elastyczne ustawienia routingu: jedną grupę alertów można wysyłać na czat telegramowy administratorów, inną na czat programistów, a trzecią na czat pracowników infrastruktury. Powiadomienia mogą być wysyłane na Slack, Telegram, e-mail i inne kanały.
Na koniec opowiem o funkcji zabójcy Prometheusa - Odkrywanie. Pracując z Prometheusem nie trzeba podawać konkretnych adresów obiektów do monitorowania, wystarczy ustawić ich typ. Oznacza to, że nie musisz pisać „tutaj jest adres IP, tutaj jest port - monitor”, zamiast tego musisz określić, według jakich zasad znaleźć te obiekty (cele - cele). Sam Prometheus w zależności od tego, które obiekty są aktualnie aktywne, pobiera potrzebne i dodaje je do monitoringu.
Takie podejście dobrze wpisuje się w strukturę Kubernetesa, gdzie też wszystko pływa: dziś jest 10 serwerów, jutro 3. Aby nie podawać za każdym razem adresu IP serwera, napisali kiedyś jak go znaleźć - i Discovering się tym zajmie .
Nazywa się język Prometeusza PromQL. Za pomocą tego języka można uzyskać wartości konkretnych metryk, a następnie je przekonwertować i zbudować na ich podstawie obliczenia analityczne.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Interfejs sieciowy Prometeusza
Prometheus posiada własny, dość minimalistyczny interfejs WWW. Nadaje się tylko do debugowania lub demonstracji.
W linii Wyrażenie możesz napisać zapytanie w języku PromQL.
Zakładka Alerty zawiera reguły alertów, które mają trzy statusy:
- nieaktywny - jeśli alert nie jest w tej chwili aktywny, to znaczy wszystko z nim w porządku i nie zadziałał;
- w toku – dzieje się tak, jeśli alert zadziałał, ale wysyłanie jeszcze nie minęło. Opóźnienie jest ustawione tak, aby kompensować miganie sieci: jeśli w ciągu minuty podniosła się określona usługa, alarm nie powinien jeszcze się włączać;
- odpalanie to trzeci stan, gdy alarm się zapala i wysyła wiadomości.
W menu Status znajdziesz dostęp do informacji o tym, czym jest Prometeusz. Następuje również przejście do celów (celi), o których mówiliśmy powyżej.
Bardziej szczegółowy przegląd interfejsu Prometheusa można znaleźć w artykule .
Integracja z Grafaną
W interfejsie internetowym Prometheusa nie znajdziesz pięknych i zrozumiałych wykresów, z których można wyciągnąć wnioski na temat stanu klastra. Aby je zbudować, Prometheus jest zintegrowany z Grafaną. Dostajemy takie dashboardy.
Konfiguracja integracji Prometheusa i Grafany nie jest wcale trudna, instrukcje znajdziesz w dokumentacji: Cóż, na tym zakończę.
W kolejnych artykułach będziemy kontynuować temat monitoringu: porozmawiamy o zbieraniu i analizowaniu logów za pomocą Grafana Loki i narzędzi alternatywnych.
Autor: Marcel Ibraev, certyfikowany administrator Kubernetes, praktykujący inżynier w firmie , mówca i twórca kursów Slurm.
Źródło: www.habr.com