Pagsubaybay sa Kubernetes Cluster: Isang Pangkalahatang-ideya at Panimula sa Prometheus

Tingnan natin ang konsepto ng pagsubaybay sa Kubernetes, kilalanin ang tool na Prometheus, at pag-usapan ang tungkol sa pag-alerto.

Ang paksa ng pagsubaybay ay napakalaki; hindi ito maaaring saklawin sa isang artikulo. Ang layunin ng tekstong ito ay magbigay ng pangkalahatang-ideya ng mga kasangkapan, konsepto, at diskarte.

Ang materyal ng artikulo ay isang pisilin mula sa bukas na panayam ng paaralan na "Slurm". Kung gusto mong makakuha ng buong pagsasanay, mag-sign up para sa isang kurso sa Pagsubaybay at pag-log imprastraktura sa Kubernetes.

Ano ang sinusubaybayan sa isang Kubernetes cluster

Mga pisikal na server. Kung ang isang Kubernetes cluster ay na-deploy sa sarili nitong mga server, kailangan mong subaybayan ang kanilang kalusugan. Pinangangasiwaan ng Zabbix ang gawaing ito; kung magtrabaho ka sa kanya, pagkatapos ay hindi na kailangang tumanggi, walang mga salungatan. Ang Zabbix ang sumusubaybay sa estado ng aming mga server.

Lumipat tayo sa pagsubaybay sa antas ng kumpol.

Mga bahagi ng Control Plane: API, Scheduler at iba pa. Sa pinakamababa, kailangan mong subaybayan na ang server API o etcd ay mas malaki sa 0. Ang Etcd ay maaaring magbigay ng maraming sukatan: sa mga disk kung saan ito umiikot, sa kalusugan ng etcd cluster nito, at iba pa.

Manggagawa sa pantalan ay lumitaw nang matagal na ang nakalipas at alam ng lahat ang mga problema nito: maraming mga lalagyan ang nagiging sanhi ng pagyeyelo at iba pang mga problema. Samakatuwid, ang Docker mismo, bilang isang sistema, ay dapat ding subaybayan, kahit man lang para sa availability.

dns. Kung nabigo ang DNS sa isang cluster, mabibigo din ang buong serbisyo ng Discovery, at hihinto sa paggana ang mga tawag mula sa mga pod patungo sa mga pod. Sa aking pagsasanay, walang ganoong mga problema, ngunit hindi ito nangangahulugan na ang katayuan ng DNS ay hindi kailangang subaybayan. Maaaring masubaybayan ang latency ng kahilingan at ilang iba pang sukatan sa CoreDNS.

Pagpasok. Kinakailangang kontrolin ang pagkakaroon ng mga pagpasok (kabilang ang Ingress Controller) bilang mga entry point sa proyekto.

Ang mga pangunahing bahagi ng kumpol ay na-disassemble - ngayon ay bumaba tayo, sa antas ng mga abstraction.

Mukhang tumatakbo ang mga application sa mga pod, na nangangahulugang kailangan nilang kontrolin, ngunit sa katotohanan ay hindi. Ang mga pod ay panandalian: ngayon ay gumagana sila sa isang server, bukas sa isa pa; Ngayon ay 10 sila, bukas 2. Kaya naman walang nagmomonitor sa mga pod. Sa isang arkitektura ng microservice, mas mahalaga na kontrolin ang availability ng application sa kabuuan. Sa partikular, suriin ang pagkakaroon ng mga endpoint ng serbisyo: may gumagana ba? Kung ang application ay magagamit, kung gayon kung ano ang nangyayari sa likod nito, kung gaano karaming mga replika ang mayroon na ngayon - ito ay mga pangalawang-order na tanong. Hindi na kailangang subaybayan ang mga indibidwal na pagkakataon.

Sa huling antas, kailangan mong subaybayan ang pagpapatakbo ng application mismo, kumuha ng mga sukatan ng negosyo: ang bilang ng mga order, pag-uugali ng user, atbp.

Promiteyus

Ang pinakamahusay na sistema para sa pagsubaybay sa isang kumpol ay Promiteyus. Wala akong alam na anumang tool na maihahambing sa Prometheus sa mga tuntunin ng kalidad at kadalian ng paggamit. Mahusay ito para sa maliksi na imprastraktura, kaya kapag sinabi ng mga tao na "Pagsubaybay ng Kubernetes" karaniwan nilang ibig sabihin ay Prometheus.

Mayroong ilang mga opsyon para sa pagsisimula sa Prometheus: gamit ang Helm, maaari kang mag-install ng regular na Prometheus o Prometheus Operator.

1. Regular na Prometheus. Maayos ang lahat dito, ngunit kailangan mong i-configure ang ConfigMap - mahalagang, magsulat ng mga text configuration file, tulad ng ginawa namin noon, bago ang microservice architecture.
2. Ang Prometheus Operator ay medyo mas malawak, medyo mas kumplikado sa panloob na lohika nito, ngunit mas madaling gamitin: may mga hiwalay na bagay, ang mga abstraction ay idinagdag sa kumpol, kaya mas maginhawa silang kontrolin at i-configure.

Upang maunawaan ang produkto, inirerekomenda ko ang pag-install muna ng regular na Prometheus. Kailangan mong i-configure ang lahat sa pamamagitan ng config, ngunit ito ay magiging kapaki-pakinabang: mauunawaan mo kung ano ang nabibilang sa kung ano at kung paano ito na-configure. Sa Prometheus Operator, agad kang tumaas sa isang mas mataas na abstraction, kahit na kung gusto mo, maaari mo ring bungkalin ang kalaliman.

Ang Prometheus ay mahusay na isinama sa Kubernetes: maaari itong mag-access at makipag-ugnayan sa API Server.

Sikat ang Prometheus at sinusuportahan ng malaking bilang ng mga application at programming language. Kinakailangan ang suporta dahil ang Prometheus ay may sariling format ng sukatan, at upang mailipat ito kailangan mo ng alinman sa isang library sa loob ng application o isang yari na exporter. At medyo marami ang mga naturang exporter. Halimbawa, mayroong PostgreSQL Exporter: kumukuha ito ng data mula sa PostgreSQL at iko-convert ito sa format na Prometheus upang magawa ito ng Prometheus.

Arkitektura ng Prometheus

Server ng Prometheus — ito ang bahagi ng server, ang utak ng Prometheus. Dito iniimbak at pinoproseso ang mga sukatan.

Ang mga sukatan ay naka-imbak sa time series database (TSDB). Ang TSDB ay hindi isang hiwalay na database, ngunit isang Go package na binuo sa Prometheus. Sa halos pagsasalita, ang lahat ay nasa isang binary.

Huwag mag-imbak ng data sa TSDB nang matagal

Ang imprastraktura ng Prometheus ay hindi angkop para sa pangmatagalang imbakan ng mga sukatan. Ang default na panahon ng imbakan ay 15 araw. Maaari mong lampasan ang limitasyong ito, ngunit tandaan: mas maraming data ang iniimbak mo sa TSDB at habang mas matagal mo itong ginagawa, mas maraming mapagkukunan ang kukunin nito. Ang pag-iimbak ng makasaysayang data sa Prometheus ay itinuturing na masamang kasanayan.

Kung mayroon kang malaking trapiko, ang bilang ng mga sukatan ay nasa daan-daang libo bawat segundo, pagkatapos ay mas mahusay na limitahan ang kanilang imbakan sa pamamagitan ng espasyo sa disk o tagal. Karaniwan, ang TSDB ay nag-iimbak ng "mainit na data", mga sukatan nang literal sa loob ng ilang oras. Para sa pangmatagalang imbakan, ginagamit ang panlabas na imbakan sa mga database na talagang angkop para dito, halimbawa InfluxDB, ClickHouse, at iba pa. Mas marami akong nakitang magagandang review tungkol sa ClickHouse.

Gumagana ang Prometheus Server ayon sa modelo paghila: siya mismo ang pumupunta para sa mga sukatan sa mga endpoint na ibinigay namin sa kanya. Sabi nila: "pumunta sa API Server," at pumupunta ito doon tuwing ika-XNUMX na bilang ng mga segundo at kinukuha ang mga sukatan.

Para sa mga bagay na may maikling habang-buhay (trabaho o cron job) na maaaring lumitaw sa pagitan ng mga panahon ng pag-scrape, mayroong bahagi ng Pushgateway. Ang mga sukatan mula sa mga panandaliang bagay ay itinulak dito: tumaas ang trabaho, nakumpleto ang pagkilos, ipinadala ang mga sukatan sa Pushgateway at natapos. Pagkalipas ng ilang panahon, lalabas si Prometheus sa sarili nitong bilis at kukunin ang mga sukatang ito mula sa Pushgateway.

Upang i-configure ang mga abiso sa Prometheus mayroong isang hiwalay na bahagi - Alertmanager. At ang mga alituntuning nagpapaalerto. Halimbawa, kailangan mong lumikha ng alerto kung ang API ng server ay 0. Kapag na-trigger ang kaganapan, ipapasa ang alerto sa tagapamahala ng alerto para sa karagdagang pagpapadala. Ang tagapamahala ng alerto ay may lubos na nababaluktot na mga setting ng pagruruta: isang pangkat ng mga alerto ang maaaring ipadala sa telegram chat ng mga admin, isa pa sa chat ng mga developer, at pangatlo sa chat ng mga manggagawa sa imprastraktura. Maaaring ipadala ang mga abiso sa Slack, Telegram, email at iba pang mga channel.

At sa wakas, sasabihin ko sa iyo ang tungkol sa tampok na pamatay ng Prometheus - Pagtuklas. Kapag nagtatrabaho sa Prometheus, hindi mo kailangang tukuyin ang mga tukoy na address ng mga bagay na susubaybayan; sapat na upang tukuyin ang kanilang uri. Iyon ay, hindi na kailangang isulat ang "narito ang IP address, narito ang port - monitor", sa halip kailangan mong matukoy kung anong mga prinsipyo ang mahahanap ang mga bagay na ito (target - mga layunin). Ang Prometheus mismo, depende sa kung aling mga bagay ang kasalukuyang aktibo, kinukuha ang mga kinakailangan at idinagdag ang mga ito sa pagsubaybay.

Ang diskarte na ito ay angkop na angkop sa istraktura ng Kubernetes, kung saan ang lahat ay lumulutang din: ngayon ay mayroong 10 server, bukas 3. Upang hindi maipahiwatig ang IP address ng server sa bawat oras, minsan naming isinulat kung paano hanapin ito - at gagawin ito ng Discovering.

Ang wikang Prometheus ay tinatawag PromQL. Gamit ang wikang ito, maaari mong makuha ang mga halaga ng mga partikular na sukatan at pagkatapos ay baguhin ang mga ito at bumuo ng mga analytical na kalkulasyon batay sa mga ito.

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)

Prometheus web interface

Ang Prometheus ay may sarili nitong, medyo minimalistic na web interface. Angkop lamang para sa pag-debug o pagpapakita.

Maaari kang magsulat ng query sa PromQL sa linya ng Expression.

Ang tab na Mga Alerto ay naglalaman ng mga panuntunan sa pag-aalerto, at mayroon silang tatlong katayuan:

1. hindi aktibo - kung ang alerto ay hindi aktibo sa ngayon, iyon ay, lahat ay maayos dito, at hindi ito gumana;
2. nakabinbin - ito ay kung ang alerto ay na-trigger, ngunit ang pagpapadala ay hindi pa nagaganap. Ang pagkaantala ay nakatakda upang mabayaran ang pagkislap ng network: kung ang tinukoy na serbisyo ay tumaas sa loob ng isang minuto, hindi na kailangang magpatunog ng alarma;
3. Ang pagpapaputok ay ang ikatlong katayuan, kapag ang alerto ay umilaw at nagpapadala ng mga mensahe.

Sa menu ng Status ay makakahanap ka ng access sa impormasyon tungkol sa kung ano ang Prometheus. Mayroon ding paglipat sa mga layunin na napag-usapan natin sa itaas.

Para sa isang mas detalyadong pangkalahatang-ideya ng Prometheus interface, tingnan sa lecture ng Slurm sa pagsubaybay sa isang cluster ng Kubernetes.

Pagsasama sa Grafana

Sa web interface ng Prometheus hindi ka makakahanap ng maganda at naiintindihan na mga graph kung saan maaari kang gumawa ng mga konklusyon tungkol sa estado ng cluster. Upang mabuo ang mga ito, ang Prometheus ay sumasama sa Grafana. Ito ang mga dashboard na nakukuha namin.

Ang pag-set up ng pagsasama ng Prometheus at Grafana ay hindi mahirap sa lahat; ang mga tagubilin ay matatagpuan sa dokumentasyon: GRAFANA SUPPORT FOR PROMETHEUS, sige, tatapusin ko na ito.

Sa mga sumusunod na artikulo ay ipagpapatuloy natin ang paksa ng pagsubaybay: pag-uusapan natin ang tungkol sa pagkolekta at pagsusuri ng mga log gamit ang Grafana Loki at mga alternatibong tool.

May-akda: Marcel Ibraev, sertipikadong tagapangasiwa ng Kubernetes, nagsasanay na inhinyero sa kumpanya Southbridge, tagapagsalita at developer ng kursong Slurm.

Pinagmulan: www.habr.com