Röviden: A custom metrika, a log ingestion és a retention csendben felfújja a megfigyelési számlát. Néhány beállítás, amivel a megfigyelhetőség hasznos marad, de nem eszi meg a büdzsét.
Van egy visszatérő pillanat a felhőszámla átnézésekor, amikor valaki elakad egy soron: a megfigyelés többe kerül, mint a megfigyelt rendszer egy része. Nem ritkaság. A megfigyelhetőség díja csendben nő, mert több apró tételből áll össze — custom metrika, logbeeresztés, megőrzés, lekérdezés —, és egyik sem tűnik önmagában drágának. Együtt viszont igen.
Honnan jön a költség?
Érdemes szétszedni a megfigyelési számlát a fő tételeire, mert a spórolás iránya tételenként más:
- Custom metrikák — minden egyedi metrika külön díjtétel. Itt a kardinalitás a gyilkos: ha minden metrikára egyedi címkéket aggatsz, robbanásszerűen nő a számuk.
- Log ingestion — a beeresztett logmennyiség után fizetsz. A bőbeszédű, debug szintű logolás productionben ezt gyorsan felhúzza.
- Retention — meddig őrzöd a logokat és metrikákat. Az „örökre, minden” a legdrágább alapértelmezés.
- Lekérdezés — a nagy logállományokon futó lekérdezések is költenek.
A kardinalitás, megint
A custom metrikák költségének leggyakoribb oka a magas kardinalitás. Ha egy metrikát felhasználói azonosítóval, kérésazonosítóval vagy teljes URL-lel bontasz, akkor gyakorlatilag végtelen sok különböző metrikát hozol létre. A metrika arra való, hogy alacsony kardinalitású dimenziók mentén aggregálj — szolgáltatás, régió, státuszkód. A részletnek a logban a helye.
Retention-stratégia
A megőrzést rétegezni kell, nem egységesen maximumra állítani:
- A friss, részletes logot rövid ideig tartsd teljes felbontásban — ez kell a hibakereséshez.
- A hosszú távú trendet aggregált metrikában őrizd, ami olcsóbb, mint a nyers log.
- Amit compliance miatt hosszan meg kell tartani, azt told olcsóbb, archív tárolóba, ne a forró megfigyelési rétegben hagyd.
A logszintek fegyelme
Productionben a debug szintű logolás bekapcsolva hagyása az egyik leggyakoribb rejtett költség. Fejlesztés közben hasznos, élesben viszont hatalmas mennyiségű, ritkán olvasott adatot termel — és mindegyikért fizetsz a beeresztéskor. A logszintet környezetenként külön kell szabályozni, és élesben visszafogni a részletességet arra, ami tényleg kell.
A haszon megőrzése
Fontos, hogy a spórolás ne csapjon át vakrepülésbe. A cél nem a megfigyelés leépítése, hanem a zaj eltávolítása. A jól megválasztott, alacsony kardinalitású metrikák, a fegyelmezett logszintek és a rétegzett megőrzés együtt olcsóbb és jobb megfigyelhetőséget adnak, mint a „gyűjtsünk mindent, hátha” hozzáállás — mert a kevesebb, releváns adatban gyorsabban is megtalálod a hibát.
A logszintek környezetenkénti kezelése
A megfigyelési költség egyik legnagyobb, legkönnyebben orvosolható forrása a productionben bekapcsolva felejtett debug logolás. Fejlesztés közben a részletes log aranyat ér, élesben viszont hatalmas mennyiségű, ritkán olvasott adatot termel — és minden beeresztett bájtért fizetsz. A logszintet környezetenként külön kell szabályozni: fejlesztésben részletes, productionben visszafogott.
Érdemes a logolást úgy tervezni, hogy a szint futásidőben állítható legyen. Így egy incidens alatt átmenetileg felkapcsolhatod a részletes logolást, majd utána vissza — anélkül, hogy állandóan a legdrágább szinten futnál.
A metrikák tervezése
A custom metrikák költségét a kardinalitás hajtja. Minden egyedi címke-kombináció külön metrika, és ezek száma robbanásszerűen nőhet, ha rossz dimenziókat választasz. A szabály egyszerű: a metrika alacsony kardinalitású dimenziók mentén aggregáljon (szolgáltatás, régió, státuszkód), a magas kardinalitású részlet (felhasználói azonosító, kérésazonosító) pedig a logba és a trace-be kerüljön.
- Kerüld az egyedi azonosítókat a metrika-címkékben.
- Aggregálj stabil, alacsony kardinalitású dimenziók mentén.
- A részletes, egyedi adatot logold, ne metrikázd.
A megőrzés rétegzése
A retention beállítása is jelentős tétel. Nem kell mindent örökké, teljes részletességgel tartani. A friss, részletes adatot rövid ideig őrizd (ez kell a hibakereséshez), a hosszú távú trendet aggregált formában (ez olcsóbb), és amit compliance miatt sokáig meg kell tartani, azt told olcsó, archív tárolóba. Ez a rétegzés a különbség a fenntartható és a kontrollálatlanul dráguló megfigyelhetőség között.
Mit jelent ez neked?
Ha a megfigyelési számlád elszaladt, először a custom metrikák kardinalitását és a log beeresztett mennyiségét nézd meg — jellemzően itt van a pénz. Tartsd alacsonyan a metrikák dimenzióit, fogd vissza a debug logolást élesben, és rétegezd a megőrzést a fontosság szerint. A jó megfigyelhetőség nem a legtöbb adatról szól, hanem a leghasznosabbról — és az mellékesen olcsóbb is.