A nevem Anton Baderin. A High Technology Centerben dolgozom és rendszeradminisztrációt végzek. Egy hónapja ért véget céges konferenciánk, ahol felhalmozott tapasztalatainkat osztottuk meg városunk informatikai közösségével. Beszéltem a webes alkalmazások figyeléséről. Az anyagot junior vagy középszintnek szánták, akik ezt a folyamatot nem a semmiből építették fel.
Minden felügyeleti rendszer alapköve az üzleti problémák megoldása. A monitorozás érdekében végzett monitorozás senkit nem érdekel. Mit akar az üzlet? Hogy minden gyorsan és hibamentesen működjön. A vállalkozások proaktívak akarnak lenni, hogy mi magunk azonosítsuk a szolgáltatásban felmerülő problémákat, és a lehető leggyorsabban kijavítsuk azokat. Valójában ezeket a problémákat oldottam meg tavaly egész évben az egyik ügyfelünk projektje során.
a projektről
A projekt az ország egyik legnagyobb hűségprogramja. Különféle marketingeszközökkel, például bónuszkártyákkal segítjük a kiskereskedelmi láncokat az értékesítés gyakoriságának növelésében. A projekt összesen 14 alkalmazást tartalmaz, amelyek tíz szerveren futnak.
Az interjú során többször is észrevettem, hogy az adminisztrátorok nem mindig közelítik meg megfelelően a webes alkalmazások figyelését: sokan továbbra is az operációs rendszer mérőszámaira koncentrálnak, és időnként figyelik a szolgáltatásokat.
Az én esetemben az ügyfél felügyeleti rendszere korábban az Icinga alapú volt. A fenti problémákat semmilyen módon nem oldotta meg. Gyakran maga az ügyfél tájékoztatott minket a problémákról, és gyakran egyszerűen nem volt elegendő adatunk ahhoz, hogy megértsük az okot.
Ezen túlmenően világosan megértették a továbbfejlesztés hiábavalóságát. Szerintem aki ismeri az Icingát, az meg fog érteni. Ezért úgy döntöttünk, hogy teljesen újratervezzük a projekt webalkalmazás-figyelő rendszerét.
Prométheusz
A Prometheust három fő mutató alapján választottuk:
- Rengeteg elérhető mérőszám. Nálunk 60 ezren vannak. Persze érdemes megjegyezni, hogy ezek túlnyomó többségét (valószínűleg kb. 95%-át) nem használjuk. Másrészt mindegyik viszonylag olcsó. Nálunk ez a másik véglet a korábban használt Icinga-hoz képest. Ebben különösen fájdalmas volt a mutatók hozzáadása: a meglévők drágák voltak (csak nézd meg bármelyik bővítmény forráskódját). Bármelyik beépülő modul egy Bash vagy Python szkript volt, amelyek elindítása költséges az elhasznált erőforrásokat tekintve.
- Ez a rendszer viszonylag kis mennyiségű erőforrást fogyaszt. 600 MB RAM, egy mag 15%-a és pár tucat IOPS elegendő minden mérőszámunkhoz. Természetesen metrika-exportőröket kell futtatnia, de ezek mind Go nyelven vannak írva, és nem is nagyon éhesek. Nem hiszem, hogy a modern valóságban ez probléma lenne.
- Lehetővé teszi a Kubernetesre való migrációt. Az ügyfél terveit figyelembe véve a választás kézenfekvő.
JÁVORSZARVAS
Korábban nem gyűjtöttünk és nem dolgoztunk fel naplókat. A hiányosságok mindenki számára nyilvánvalóak. Azért választottuk az ELK-t, mert már volt tapasztalatunk ezzel a rendszerrel. Csak az alkalmazásnaplókat tároljuk ott. A fő kiválasztási szempont a teljes szöveges keresés és annak sebessége volt.
Сlickhouse
Kezdetben az InfluxDB-re esett a választás. Felismertük, hogy össze kell gyűjteni az Nginx-naplókat, statisztikákat a pg_stat_statements-ből, és tárolni kell a Prometheus előzményadatait. Nem szerettük az Influx-ot, mert időnként nagy mennyiségű memóriát kezdett elfoglalni, és összeomlott. Ezenkívül a lekérdezéseket a remote_addr szerint szerettem volna csoportosítani, de ebben a DBMS-ben a csoportosítás csak címkék szerint történik. A címkék drágák (memória), számuk feltételesen korlátozott.
Újra elkezdtük a keresést. Minimális erőforrás-felhasználású analitikus adatbázisra volt szükség, lehetőleg lemezen történő adattömörítéssel.
A Clickhouse mindezen kritériumoknak megfelel, és soha nem bántuk meg a választásunkat. Nem írunk bele rendkívüli mennyiségű adatot (a beszúrások száma percenként mindössze ötezer körül van).
NewRelic
A NewRelic történelmileg azért volt velünk, mert az ügyfél választotta. APM-ként használjuk.
Zabbix
A Zabbixot kizárólag a különféle API-k Black Box-jának figyelésére használjuk.
Monitoring megközelítés meghatározása
A feladatot szét akartuk bontani, és ezáltal rendszerezni akartuk a monitoring megközelítését.
Ehhez a rendszerünket a következő szintekre osztottam:
- hardver és VMS;
- operációs rendszer;
- rendszerszolgáltatások, szoftververem;
- Alkalmazás;
- üzleti logika.
Miért kényelmes ez a megközelítés:
- tudjuk, ki a felelős az egyes szintek munkájáért, és ez alapján tudunk riasztást küldeni;
- használhatjuk a struktúrát a riasztások elnyomásakor – furcsa lenne riasztást küldeni az adatbázis elérhetetlenségéről, ha a virtuális gép egésze nem elérhető.
Mivel a feladatunk a rendszer működésében előforduló jogsértések azonosítása, ezért minden szinten ki kell emelnünk egy bizonyos mérőszámot, amelyre érdemes odafigyelni a riasztási szabályok írásakor. Ezután menjünk végig a „VMS”, „Operációs rendszer” és „Rendszerszolgáltatások, szoftververem” szinteken.
Virtuális gépek
A hosting processzort, lemezt, memóriát és hálózatot foglal le számunkra. És az első kettővel voltak problémáink. Tehát a mérőszámok:
CPU ellopott ideje – ha vásárol egy virtuális gépet az Amazonon (például t2.micro), meg kell értenie, hogy nem a teljes processzormagot osztják ki, hanem annak csak egy kvótáját. És ha kimeríti, a processzort elveszik tőled.
Ez a mérőszám lehetővé teszi az ilyen pillanatok nyomon követését és döntések meghozatalát. Például kell-e zsírosabb tarifát venni, vagy a háttérfeladatok, API kérések feldolgozását szétosztani különböző szerverekre?
IOPS + CPU várakozási idő – valamilyen oknál fogva sok felhőtárhely vétkezik azzal, hogy nem biztosít elegendő IOPS-t. Ráadásul az alacsony IOPS-es ütemezés nem érv számukra. Ezért érdemes CPU iowait gyűjteni. Ezzel a grafikonpárral - alacsony IOPS és magas I/O várakozás mellett - már lehet beszélni a tárhellyel és megoldani a problémát.
Operációs rendszer
Operációs rendszer mutatói:
- a rendelkezésre álló memória mennyisége %-ban;
- cserehasználati tevékenység: vmstat swapin, swapout;
- a rendelkezésre álló inodok száma és a fájlrendszer szabad területe %-ban
- átlagos terhelés;
- kapcsolatok száma tw állapotban;
- conntrack asztal teltség;
- A hálózat minősége az ss segédprogrammal, az iproute2 csomaggal nyomon követhető - a kimenetéből lekérheti az RTT-kapcsolatok jelzőjét, és célport szerint csoportosítja.
Az operációs rendszer szintjén is van egy ilyen entitásunk, mint a folyamatok. Fontos azonosítani a rendszerben a működésében fontos szerepet játszó folyamatok összességét. Ha például több pgpool-ja van, akkor mindegyikhez információkat kell gyűjtenie.
A mérőszámok halmaza a következő:
- PROCESSZOR;
- a memória elsősorban rezidens;
- IO - lehetőleg IOPS-ben;
- FileFd - nyitott és limit;
- jelentős oldalhibák – így megértheti, hogy melyik folyamatot cserélik.
Az összes megfigyelést a Dockerben telepítjük, és az Advisort használjuk a metrikaadatok gyűjtésére. Más gépeken folyamat-exportőrt használunk.
Rendszerszolgáltatások, szoftververem
Minden alkalmazásnak megvannak a sajátosságai, és nehéz egy konkrét mérőszámot kiemelni.
Az univerzális készlet a következő:
- kérési arány;
- hibák száma;
- késleltetés;
- telítettség.
Ezen a szinten a figyelésre a legszembetűnőbb példáink az Nginx és a PostgreSQL.
Rendszerünkben a legtöbbet terhelt szolgáltatás az adatbázis. Korábban gyakran volt gondunk kitalálni, mit csinál az adatbázis.
Nagy terhelést láttunk a lemezeken, de a lassú naplók nem igazán mutattak semmit. Ezt a problémát a pg_stat_statements, a lekérdezési statisztikákat gyűjtő nézet segítségével oldottuk meg.
Ennyi kell az adminisztrátornak.
Grafikonokat készítünk az olvasási és írási kérések aktivitásáról:
Minden egyszerű és világos, minden kérésnek megvan a maga színe.
Ugyanilyen feltűnő példa az Nginx naplók. Nem meglepő, hogy kevesen elemzik ezeket, vagy említik meg a kötelező termékek listáján. A szabványos formátum nem túl informatív, és bővítésre szorul.
Személy szerint hozzáadtam a request_time, upstream_response_time, body_bytes_sent, request_length, request_id értékeket. A válaszidőt és a hibák számát ábrázoljuk:
Grafikonokat készítünk a válaszidőről és a hibák számáról. Emlékezik? Beszéltem az üzleti célokról? Gyorsan és hiba nélkül? Ezeket a kérdéseket már két grafikonon is bemutattuk. És máris hívhatja az ügyeletes adminisztrátorokat ezek használatával.
De még egy probléma marad - az incidens okainak gyors megszüntetése.
Az incidens megoldása
A teljes folyamat a probléma azonosításától a megoldásig több lépésre osztható:
- a probléma azonosítása;
- értesítés az ügyeleti ügyintézőnek;
- reagálás egy eseményre;
- okok megszüntetése.
Fontos, hogy ezt a lehető leggyorsabban meg kell tennünk. És ha a probléma azonosításának és az értesítés küldésének szakaszában nem nyerhetünk sok időt - két percet mindenképpen el kell költeni rájuk, akkor a továbbiak egyszerűen felszántatlan terület a fejlesztésekhez.
Képzeljük csak el, hogy megcsörrent az ügyeletes telefonja. Mit fog tenni? Keressen választ a kérdésekre – mi tört el, hol tört el, hogyan reagáljon? Így válaszolunk ezekre a kérdésekre:
Mindezeket az információkat egyszerűen belefoglaljuk az értesítés szövegébe, adunk neki egy hivatkozást egy wikioldalra, amely leírja, hogyan reagáljunk erre a problémára, hogyan oldjuk meg és hogyan terjesszük tovább.
Még mindig nem mondtam semmit az alkalmazási rétegről és az üzleti logikáról. Sajnos alkalmazásaink még nem valósítják meg a mérőszámok gyűjtését. Az ezekről a szintekről származó információk egyetlen forrása a naplók.
Pár pont.
Először írjon strukturált naplókat. Nem szükséges szövegkörnyezetet feltüntetni az üzenet szövegében. Ez megnehezíti csoportosításukat és elemzésüket. A Logstash-nak sok időbe telik, mire mindezt normalizálja.
Másodszor, helyesen használja a súlyossági szinteket. Minden nyelvnek megvan a maga szabványa. Személy szerint négy szintet különböztetek meg:
- nincs hiba;
- ügyféloldali hiba;
- a hiba a mi oldalunkon van, nem veszítünk pénzt, nem vállalunk kockázatot;
- A hiba a mi oldalunkon van, pénzt veszítünk.
Hadd foglaljam össze. Meg kell próbálnia üzleti logika alapján felépíteni a monitoringot. Próbálja magát az alkalmazást figyelni, és olyan mérőszámokkal működni, mint az eladások száma, az új felhasználók regisztrációinak száma, a jelenleg aktív felhasználók száma stb.
Ha az egész vállalkozás egyetlen gomb a böngészőben, akkor figyelnie kell, hogy az kattint-e és megfelelően működik-e. A többi nem számít.
Ha nem rendelkezik ezzel, megpróbálhatja utolérni az alkalmazásnaplókban, az Nginx naplókban és így tovább, ahogy mi tettük. A lehető legközelebb kell lennie az alkalmazáshoz.
Az operációs rendszer mérőszámai természetesen fontosak, de az üzletet nem érdekli, nem fizetnek értük.
Forrás: will.com