Fontolja meg a Kubernetes monitorozás koncepcióját, ismerkedjen meg a Prometheus eszközzel, és beszéljen a riasztásról.
A monitorozás témája terjedelmes, egy cikkben nem bontható szét. Ennek a szövegnek az a célja, hogy áttekintést nyújtson az eszközökről, fogalmakról és megközelítésekről.
A cikk anyaga kinyomott . Ha egy teljes tanfolyamot szeretne elvégezni, iratkozzon fel egy tanfolyamra .
Mit figyel a Kubernetes-fürt
fizikai szerverek. Ha a Kubernetes-fürt telepítve van a szerverein, figyelnie kell az állapotukat. Zabbix kezeli ezt a feladatot; ha dolgozol vele, akkor nem kell visszautasítanod, nem lesznek konfliktusok. A Zabbix figyeli szervereink állapotát.
Térjünk át a fürtszintű monitorozásra.
Vezérlősík összetevői: API, ütemező és mások. Legalább meg kell győződnie arról, hogy a kiszolgálók vagy az etcd API-ja nagyobb, mint 0. Az Etcd számos mérőszámot képes visszaadni: a lemezek, amelyeken pörög, az etcd-fürt állapota és mások szerint.
Dokkmunkás nagyon régen jelent meg, és mindenki tisztában van a problémáival: sok konténer fagyást és egyéb problémákat okoz. Ezért magát a Dockert, mint rendszert is ellenőrizni kell, legalább a rendelkezésre állás szempontjából.
dns. Ha a DNS kiesik a fürtben, akkor a teljes Discovery szolgáltatás leesik utána, és a podokról a podokra irányuló hívások leállnak. Az én gyakorlatomban nem volt ilyen probléma, de ez nem jelenti azt, hogy a DNS állapotát nem kell figyelni. A kérések késleltetése és néhány egyéb mérőszám nyomon követhető a CoreDNS-en.
Ingress. Szükséges ellenőrizni a belépések elérhetőségét (beleértve a Belépés-vezérlőt is), mint a projekt belépési pontjait.
A klaszter fő alkotóelemei lebontásra kerültek – most menjünk le az absztrakciók szintjére.
Úgy tűnik, hogy az alkalmazások podokban futnak, ami azt jelenti, hogy ellenőrizni kell őket, de valójában nem. A pod-ok múlékonyak: ma az egyik szerveren futnak, holnap egy másikon; ma 10 van belőle, holnap 2. Ezért senki sem figyeli a hüvelyeket. A mikroszolgáltatási architektúrán belül sokkal fontosabb az alkalmazás egészének elérhetőségének szabályozása. Különösen ellenőrizze a szolgáltatási végpontok elérhetőségét: működik valami? Ha az alkalmazás elérhető, akkor mi történik mögötte, hány replika van most - ezek másodrendű kérdések. Nincs szükség az egyes esetek figyelésére.
Az utolsó szinten magának az alkalmazásnak a működését kell irányítania, üzleti mérőszámokat kell vennie: a megrendelések számát, a felhasználói viselkedést stb.
Prométheusz
A klaszterek megfigyelésére a legjobb rendszer az . Nem ismerek olyan eszközt, amely minőségében és könnyű kezelhetőségében megfelelne a Prometheusnak. Nagyszerű a rugalmas infrastruktúrához, így amikor azt mondják, hogy „Kubernetes monitoring”, általában a Prometheusra gondolnak.
Van néhány lehetőség a Prometheus használatának megkezdéséhez: a Helm segítségével telepíthet egy normál Prometheust vagy Prometheus Operatort.
- Rendszeres Prometheus. Minden rendben van vele, de konfigurálnia kell a ConfigMap-et - valójában szöveges konfigurációs fájlokat kell írni, mint korábban, a mikroszolgáltatási architektúra előtt.
- A Prometheus Operator kicsit szétszórtabb, kicsit bonyolultabb belső logikát tekintve, de könnyebb vele dolgozni: külön objektumok vannak, absztrakciók kerülnek a klaszterbe, így sokkal kényelmesebb a vezérlés és a konfigurálás.
A termék megértéséhez azt javaslom, hogy először telepítse a normál Prometheust. Mindent a konfiguráción keresztül kell konfigurálnod, de ez előnyös lesz: rájössz, hogy mi tartozik mihez és hogyan van beállítva. A Prometheus Operatorban azonnal egy absztrakcióval magasabbra emelkedik, bár a mélységbe is beleáshat, ha akar.
A Prometheus jól integrálva van a Kubernetes-szel: képes hozzáférni az API-kiszolgálóhoz és együttműködni vele.
A Prometheus népszerű, ezért számos alkalmazás és programozási nyelv támogatja. Támogatásra van szükség, mivel a Prometheusnak saját metrika formátuma van, és ennek átviteléhez vagy az alkalmazáson belüli könyvtárra, vagy egy kész exportőrre van szükség. És van jó néhány ilyen exportőr. Például ott van a PostgreSQL Exporter: adatokat vesz a PostgreSQL-ből, és Prometheus formátumba konvertálja, hogy a Prometheus tudjon vele dolgozni.
Prometheus építészet
Prometheus szerver — ez a szerver rész, a Prometheus agya. Itt tárolják és dolgozzák fel a mérőszámokat.
A mérőszámokat az idősoros adatbázis (TSDB) tárolja. A TSDB nem egy különálló adatbázis, hanem egy Go nyelvű csomag, amely a Prometheusba van beágyazva. Durván szólva minden egy binárisban van.
Ne tároljon adatokat hosszú ideig a TSDB-ben
A Prometheus infrastruktúra nem alkalmas mérőszámok hosszú távú tárolására. Az alapértelmezett megőrzési időszak 15 nap. Túllépheti ezt a határt, de ne feledje: minél több adatot tárol a TSDB-ben, és minél hosszabb ideig csinálja, annál több erőforrást fogyaszt. A történelmi adatok Prometheusban való tárolása rossz gyakorlatnak minősül.
Ha nagy a forgalom, a mutatók száma több százezer másodpercenként, akkor jobb, ha a tárolást lemezterülettel vagy periódussal korlátozza. Általában a „forró adatokat” a TSDB tárolja, a mérőszámok mindössze néhány óra alatt. Hosszabb tároláshoz külső tárolót használnak azokban az adatbázisokban, amelyek erre valóban alkalmasak, például InfluxDB, ClickHouse stb. Több jó véleményt is láttam a ClickHouse-ról.
A Prometheus Server működik a modellen húzza: az általunk megadott végpontokhoz méri a mérőszámokat. Azt mondták: „menjen az API szerverre”, ő pedig minden n-edik másodpercben odamegy, és leveszi a mérőszámokat.
A rövid élettartamú objektumokhoz (job vagy cron job), amelyek a kaparási időszakok között jelenhetnek meg, létezik egy Pushgateway összetevő. A rövid távú objektumok mérőszámai be vannak tolva: a feladat felemelkedett, végrehajtott egy műveletet, elküldte a mérőszámokat a Pushgateway-nek és befejeződött. Egy idő után a Prometheus a saját tempójában lejön, és felveszi ezeket a mutatókat a Pushgateway-től.
Az értesítések konfigurálásához a Prometheusban van egy külön összetevő - Alertmanager. És a riasztási szabályok. Például riasztást kell létrehoznia, ha a kiszolgáló API értéke 0. Amikor az esemény elindul, a riasztás továbbküldésre kerül a riasztáskezelőnek további elküldés céljából. A riasztáskezelő meglehetősen rugalmas útválasztási beállításokkal rendelkezik: a riasztások egyik csoportja az adminisztrátorok távirati chatjére, egy másik a fejlesztői chatre, egy harmadik pedig az infrastruktúra dolgozóinak chatjére küldhető. Az értesítések elküldhetők a Slack, a Telegram, az e-mail és más csatornákra.
És végül elmondom a Prometheus gyilkos funkcióját - Felfedezése. A Prometheusszal végzett munka során nem kell megadnia az objektumok konkrét címét a megfigyeléshez, elegendő beállítani a típusukat. Vagyis nem kell azt írni, hogy "itt az IP-cím, itt a port - monitor", hanem meg kell határoznia, hogy milyen elvek alapján találja meg ezeket az objektumokat (célok - gólok). Maga a Prometheus attól függően, hogy mely objektumok éppen aktívak, előkeresi a szükségeseket, és hozzáadja a megfigyeléshez.
Ez a megközelítés jól illeszkedik a Kubernetes struktúrához, ahol szintén minden lebeg: ma 10 szerver van, holnap 3. Hogy ne adják meg minden alkalommal a szerver IP-címét, egyszer megírták, hogyan lehet megtalálni - és a Discovering megteszi. .
A Prométheusz nyelvet ún PromQL. Ezzel a nyelvvel megkaphatja az adott metrikák értékeit, majd konvertálhatja azokat, és ezek alapján analitikai számításokat készíthet.
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 webes felület
A Prometheus saját, meglehetősen minimalista webes felülettel rendelkezik. Csak hibakeresésre vagy bemutatóra alkalmas.
A Kifejezés sorban PromQL nyelven írhatunk lekérdezést.
A Riasztások lap riasztási szabályokat tartalmaz, és három állapotuk van:
- inaktív - ha a riasztás pillanatnyilag nem aktív, vagyis minden rendben van vele, és nem működött;
- függőben – ez akkor történik, ha a riasztás működött, de a küldés még nem telt el. A késleltetés a hálózat villogásának kompenzálására van beállítva: ha a megadott szolgáltatás egy percen belül emelkedik, akkor a riasztást még nem szabad megszólaltatni;
- a tüzelés a harmadik állapot, amikor a riasztás világít és üzeneteket küld.
Az Állapot menüben információkat talál arról, hogy mi is az a Prometheus. Átmenet is történik a célokra (célpontokra), amiről fentebb beszéltünk.
A Prometheus felület részletesebb áttekintését lásd .
Integráció a Grafana-val
A Prometheus webes felületén nem találsz olyan szép és érthető grafikonokat, amelyekből következtetést lehetne levonni a klaszter állapotára vonatkozóan. Ezek elkészítéséhez a Prometheus integrálva van a Grafana-val. Kapunk ilyen műszerfalakat.
A Prometheus és a Grafana integráció beállítása egyáltalán nem nehéz, a dokumentációban talál utasításokat: Nos, ezzel befejezem.
A következő cikkekben folytatjuk a monitorozás témáját: szó lesz a naplók gyűjtéséről és elemzéséről Grafana Loki és alternatív eszközök segítségével.
Szerző: Marcel Ibraev, okleveles Kubernetes-adminisztrátor, gyakorló mérnök a vállalatnál , hangszóró és tanfolyamfejlesztő Slurm.
Forrás: will.com