Konsideru la koncepton pri monitorado de Kubernetes, konatiĝu kun la ilo Prometheus kaj parolu pri atentigo.
La temo de monitorado estas ampleksa, ĝi ne povas esti malmuntita en unu artikolo. La celo de ĉi tiu teksto estas doni superrigardon de la iloj, konceptoj kaj aliroj.
La materialo de la artikolo estas premo de . Se vi volas fari plenan kurson - aliĝu al kurso pri .
Kio estas monitorita en Kubernetes-areo
fizikaj serviloj. Se la Kubernetes-areo estas deplojita sur siaj serviloj, vi devas kontroli ilian sanon. Zabbix pritraktas ĉi tiun taskon; se vi laboras kun li, tiam vi ne bezonas rifuzi, ne estos konfliktoj. Estas Zabbix, kiu kontrolas la staton de niaj serviloj.
Ni transiru al monitorado ĉe la grapo-nivelo.
Komponantoj de Kontrolaviadiloj: API, Scheduler kaj aliaj. Minimume, vi devas certigi, ke la API de serviloj aŭ etcd estas pli granda ol 0. Etcd povas redoni multajn metrikojn: per la diskoj, sur kiuj ĝi turniĝas, per la sano de sia etcd-areto, kaj aliaj.
Docker aperis antaŭ longe kaj ĉiuj bone konscias ĝiajn problemojn: multaj ujoj generas frostiĝojn kaj aliajn problemojn. Tial Docker mem, kiel sistemo, ankaŭ devus esti kontrolita, almenaŭ por havebleco.
dns. Se DNS defalas en la areto, tiam la tuta Discovery-servo falos post ĝi, vokoj de podoj al podoj ĉesos funkcii. En mia praktiko, ne estis tiaj problemoj, sed ĉi tio ne signifas, ke la stato de la DNS ne bezonas esti monitorita. Peto-latenteco kaj iuj aliaj metrikoj povas esti spuritaj sur CoreDNS.
Eniro. Necesas kontroli la haveblecon de eniroj (inkluzive de la Eniro-Regilo) kiel enirpunktoj al la projekto.
La ĉefaj komponantoj de la areto estis malmuntitaj - nun ni malsupreniru al la nivelo de abstraktaĵoj.
Ŝajnus, ke aplikaĵoj funkcias en podoj, kio signifas, ke ili devas esti kontrolitaj, sed fakte ili ne estas. Podoj estas efemeraj: hodiaŭ ili funkcias per unu servilo, morgaŭ per alia; hodiaŭ estas 10 el ili, morgaŭ 2. Tial neniu kontrolas la guŝojn. Ene de mikroserva arkitekturo, estas pli grave kontroli la haveblecon de la aplikaĵo entute. Precipe, kontrolu la haveblecon de servofinpunktoj: ĉu io funkcias? Se la aplikaĵo disponeblas, kio okazas malantaŭ ĝi, kiom da kopioj estas nun - ĉi tiuj estas demandoj de la dua ordo. Ne necesas kontroli individuajn okazojn.
Je la lasta nivelo, vi devas kontroli la funkciadon de la aplikaĵo mem, preni komercajn metrikojn: la nombro da mendoj, uzantkonduto, ktp.
Prometeo
La plej bona sistemo por monitorado de areto estas . Mi ne konas iun ilon kiu povas kongrui kun Prometheus laŭ kvalito kaj facileco de uzado. Ĝi estas bonega por fleksebla infrastrukturo, do kiam ili diras "Kubernetes-monitorado", ili kutime signifas Prometeon.
Estas kelkaj ebloj por komenci kun Prometheus: uzante Helm, vi povas instali regulan Prometheus aŭ Prometheus Operator.
- Regula Prometeo. Ĉio estas bone ĉe li, sed vi devas agordi ConfigMap - fakte, verku tekst-bazitajn agordajn dosierojn, kiel ni faris antaŭe, antaŭ la mikroserva arkitekturo.
- Prometheus Operator estas iom pli disvastigita, iom pli komplika laŭ interna logiko, sed estas pli facile labori kun ĝi: estas apartaj objektoj, abstraktaĵoj estas aldonitaj al la areto, do ili estas multe pli oportune kontroli kaj agordi.
Por kompreni la produkton, mi rekomendas unue instali la regulan Prometheus. Vi devos agordi ĉion per la agordo, sed ĉi tio estos utila: vi ekscios, kio apartenas al kio kaj kiel ĝi estas agordita. En Prometheus Operator, vi tuj leviĝas al abstraktado pli alta, kvankam vi ankaŭ povas enprofundiĝi en la profundon, se vi volas.
Prometheus estas bone integrita kun Kubernetes: ĝi povas aliri kaj interagi kun la API-Servilo.
Prometheus estas populara, tial granda nombro da aplikoj kaj programlingvoj subtenas ĝin. Subteno necesas, ĉar Prometheus havas sian propran metrikan formaton, kaj por transdoni ĝin, vi bezonas aŭ bibliotekon ene de la aplikaĵo aŭ pretan eksportilon. Kaj estas sufiĉe multaj tiaj eksportantoj. Ekzemple, ekzistas PostgreSQL Exporter: ĝi prenas datumojn de PostgreSQL kaj konvertas ĝin al Prometheus-formato por ke Prometheus povu labori kun ĝi.
Prometeo-arkitekturo
Prometheus Server estas la malantaŭa fino, la cerbo de Prometeo. Metriko estas stokitaj kaj prilaboritaj ĉi tie.
La metrikoj estas stokitaj en la tempseriodatumbazo (TSDB). TSDB ne estas aparta datumbazo, sed pakaĵo en la Go-lingvo, kiu estas enigita en Prometheus. Malglate parolante, ĉio estas en unu binaro.
Ne konservu datumojn en TSDB dum longa tempo
La Prometheus-infrastrukturo ne taŭgas por longdaŭra stokado de metrikoj. La defaŭlta retenperiodo estas 15 tagoj. Vi povas superi ĉi tiun limon, sed memoru: ju pli da datumoj vi stokas en TSDB kaj ju pli longe vi faras ĝin, des pli da rimedoj ĝi konsumos. Stoki historiajn datumojn en Prometeo estas konsiderata malbona praktiko.
Se vi havas grandegan trafikon, la nombro da metrikoj estas centoj da miloj por sekundo, tiam estas pli bone limigi ilian stokadon per diskospaco aŭ per periodo. Kutime, "varmaj datumoj" estas stokitaj en TSDB, metrikoj en nur kelkaj horoj. Por pli longa stokado, ekstera stokado estas uzata en tiuj datumbazoj, kiuj vere taŭgas por tio, ekzemple, InfluxDB, ClickHouse, ktp. Mi vidis pli da bonaj recenzoj pri ClickHouse.
Prometheus Server funkcias sur la modelo tiri: li iras por metriko al tiuj finpunktoj kiujn ni donis al li. Ili diris: "iru al la API-Servilo", kaj li iras tien ĉiun n-an nombron da sekundoj kaj prenas la metrikojn.
Por objektoj kun mallonga vivdaŭro (laboro aŭ kronlaboro) kiuj povas aperi inter skrapperiodoj, ekzistas Pushgateway-komponento. Metrikoj de mallongdaŭraj objektoj estas puŝitaj en ĝin: la laboro altiĝis, faris agon, sendis metrikojn al Pushgateway kaj finiĝis. Post iom da tempo, Prometheus malsupreniros laŭ sia propra rapideco kaj prenos ĉi tiujn metrikojn de Pushgateway.
Por agordi sciigojn en Prometheus estas aparta komponanto - Alertmanaĝero. Kaj la atentaj reguloj. Ekzemple, vi devas krei atentigon se la servila API estas 0. Kiam la evento ekfunkciigas, la atentigo estas transdonita al la atentema administranto por plia sendo. La atentema administranto havas sufiĉe flekseblajn vojajn agordojn: unu grupo de atentigoj povas esti sendita al la telegrama babilejo de la administrantoj, alia al la babilejo de la programistoj, kaj tria al la babilejo de la infrastrukturaj laboristoj. Sciigoj povas esti senditaj al Slack, Telegramo, retpoŝto kaj aliaj kanaloj.
Kaj finfine, mi rakontos al vi pri la Prometheus-murdinta funkcio - malkovri. Kiam vi laboras kun Prometheus, vi ne bezonas specifi specifajn adresojn de objektoj por monitorado, sufiĉas agordi ilian tipon. Tio estas, vi ne bezonas skribi "jen la IP-adreso, jen la haveno - monitoro", anstataŭe, vi devas determini laŭ kiaj principoj trovi ĉi tiujn objektojn (celoj - celoj). Prometeo mem, depende de kiuj objektoj estas nuntempe aktivaj, eltiras la necesajn kaj aldonas ilin al monitorado.
Ĉi tiu aliro bone kongruas kun la strukturo de Kubernetes, kie ĉio ankaŭ flosas: hodiaŭ estas 10 serviloj, morgaŭ 3. Por ne specifi la IP-adreson de la servilo ĉiufoje, ili skribis unufoje kiel trovi ĝin - kaj Discovering faros ĝin. .
La lingvo Prometeo nomiĝas PromQL. Uzante ĉi tiun lingvon, vi povas akiri la valorojn de specifaj metrikoj kaj poste konverti ilin, konstrui analizajn kalkulojn bazitajn sur ili.
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)Interfaco de Prometheus
Prometheus havas sian propran, sufiĉe minimumisman retan interfacon. Taŭga nur por sencimigo aŭ pruvo.
En la Esprimlinio, vi povas skribi demandon en la lingvo PromQL.
La langeto Atentigoj enhavas atentajn regulojn, kaj ili havas tri statusojn:
- neaktiva - se la atentigo ne aktivas nuntempe, tio estas, ĉio estas en ordo kun ĝi, kaj ĝi ne funkciis;
- pritraktata - jen se la atentigo funkciis, sed la sendo ankoraŭ ne pasis. La prokrasto estas agordita por kompensi reton palpebrumante: se la specifita servo altiĝis ene de minuto, tiam la alarmo ankoraŭ ne estu sonita;
- pafo estas la tria statuso kiam la atentigo lumiĝas kaj sendas mesaĝojn.
En la menuo Statuso vi trovos aliron al informoj pri kio estas Prometeo. Estas ankaŭ transiro al la celoj (celoj), pri kiuj ni parolis supre.
Por pli detala superrigardo de la Prometheus-interfaco, vidu .
Integriĝo kun Grafana
En la retejo de Prometheus, vi ne trovos belajn kaj kompreneblajn grafikaĵojn, el kiuj vi povas tiri konkludon pri la stato de la areto. Por konstrui ilin, Prometeo estas integrita kun Grafana. Ni ricevas tiajn instrumentpanelojn.
Agordi la integriĝon de Prometheus kaj Grafana tute ne malfacilas, vi povas trovi instrukciojn en la dokumentado: Nu, mi finos per ĉi tio.
En la sekvaj artikoloj, ni daŭrigos la temon pri monitorado: ni parolos pri kolektado kaj analizo de protokoloj per Grafana Loki kaj alternativaj iloj.
Aŭtoro: Marcel Ibraev, atestita administranto de Kubernetes, praktikanta inĝeniero en la firmao , parolanto kaj kursprogramisto Slurm.
fonto: www.habr.com