Sistemų stebėjimas: Hostinger augimo pamokos

Kaip Lietuvos technologijų bendrovė augimą pavertė architektūros, kaštų ir žmonių pasitikėjimo pamoka.

Sistemų stebėjimas dažnai atrodo kaip grynai techninis rūpestis – iki akimirkos, kai sutrikimą pirmieji pastebi klientai. Lietuvos technologijų bendrovės „Hostinger“ kelionė rodo, kad augant verslui stebimumas tampa ne priedu prie infrastruktūros, o gebėjimu išlaikyti paslaugą patikimą. Apie tai 2026 m. liepą Danske Bank Lithuania renginyje pasakojo „Hostinger“ sistemų patikimumo inžinierius Edgaras Giedrė.

Stebimumas (angl. observability) reiškia gebėjimą pagal sistemos skleidžiamus signalus suprasti, kas vyksta jos viduje. Tie signalai paprastai yra metrikos, žurnalai ir paskirstytosios trasos. Esmė ne turėti kuo daugiau grafikų, o greitai atsakyti į verslui svarbų klausimą: kodėl paslauga veikia ne taip, kaip tikisi klientas?

Kai augimas paverčia paprastą sprendimą kliūtimi

2016 m. „Hostinger“ pradėjo nuo „Prometheus“. Taikinius sistema atnaujindavo kartą per valandą per „Chef“, o konfigūracijos failas išaugo iki maždaug 300–400 eilučių. 2019 m. dinaminis taikinių aptikimas išsprendė vieną problemą, tačiau sukūrė kitą: stebimų galinių taškų ir duomenų daugėjo taip greitai, kad saugojimo laiką teko trumpinti nuo mėnesio iki trijų, vėliau – dviejų savaičių.

2020 m. ilgalaikiam saugojimui pasirinkta M3DB, nes virtualių mašinų aplinkoje ji atrodė paprastesnė už alternatyvas. Praktikoje sunkios užklausos buvo lėtos, pasitaikydavo atminties trūkumo klaidų, o penkių minučių agregavimas sumažino duomenų detalumą. Vietiniai klasteriai ir „Prometheus“ agentai vėliau pagerino atsparumą, bet saugyklos efektyvumo ir kardinalumo – skirtingų etikečių reikšmių skaičiaus – klausimai liko.

Perėjusi prie „Grafana Mimir“, bendrovė išaugo nuo maždaug 600 tūkst. iki 3,5 mln. metrikų imčių per sekundę. Pranešimo metu sistema veikė 51 virtualioje mašinoje, turėjo apie 600 GB talpyklos ir apėmė tris duomenų centrus. „Grafana“ dokumentacijoje „Mimir“ apibūdinama kaip horizontaliai plečiama ilgalaikė „Prometheus“ metrikų saugykla, tačiau pats įrankis nepanaikina architektūros kompromisų: „Hostinger“ vis dar matė objektinės saugyklos ir viešojo tinklo priklausomybes.

Augimas neištrina silpnų vietų – jis jas perkelia. Kai gedimo priežastis nematoma infrastruktūroje, pasekmę pirmiausia pajunta vartotojas; panaši verslo ir technologijos skirtis matoma ir analizėje apie valstybės IT sistemų patogumą.

Migracija prasideda nuo pasitikėjimo, ne įrankio

„Pakeisti sistemas lengva, bet žmonės kasdieniuose įrankiuose išsiugdo raumenų atmintį, o pasitikėjimą nauja platforma reikia kurti iš naujo.“

Ši Edgaro Giedrės mintis, nuskambėjusi apie 12:14, svarbi ne tik inžinieriams. Naujas įrankis pradžioje beveik visada atrodo lėtesnis, nes komanda senajame jau žino trumpiausius kelius, užklausas ir keistenybes. Techninė migracija gali trukti savaites, o darbo įpročių migracija – gerokai ilgiau.

Pereidama nuo „Graylog“ ir „Elasticsearch“ pagrįsto sprendimo prie „Grafana Loki“, „Hostinger“ kurį laiką siuntė žurnalus į abi sistemas. To reikėjo, nes nebuvo automatinio būdo perkelti suvestinių ir įspėjimo taisyklių, o komandoms reikėjo ir istorinių duomenų, ir nenutrūkstamos prieigos. Augančiam Lietuvos startuoliui toks dubliavimas gali atrodyti brangus, tačiau kritinės infrastruktūros atveju tai yra ribotos trukmės draudimas nuo aklosios zonos.

Vadovui verta klausti ne vien „kada išjungsime seną sistemą?“. Svarbiau susitarti, kokie įspėjimai privalo veikti, kas patikrins svarbiausias suvestines, kaip bus imituojamas incidentas ir pagal kokį kriterijų komanda pripažins naują platformą patikima.

Metrikos, žurnalai ir trasos atsako skirtingai

Metrikos parodo, kad kažkas pasikeitė

Metrika yra skaitinė sistemos būsenos išraiška: užklausų skaičius, klaidų dalis ar atsako laikas. Ji puikiai tinka įspėjimams ir tendencijoms, bet dažnai nepasako, kodėl pokytis įvyko. Todėl didesnis metrikų kiekis savaime nereiškia geresnio matomumo.

Žurnalai pateikia įvykio detales

„Hostinger“ komandos kadaise tą patį lauką į žurnalus siųsdavo skirtingais tipais – viena jį siuntė kaip skaičių, kita – kaip tekstą. Dėl duomenų laukų tipų konflikto dalis įrašų tyliai dingdavo. „Loki“ sumažino šią trintį, nes, kaip aiškina oficiali dokumentacija, indeksuoja ne visą žurnalo eilutę, o nedidelį etikečių rinkinį ir suspaustus duomenis laiko objektinėje saugykloje.

Tačiau laisvesnė schema nėra kvietimas pamiršti tvarką. Pranešime parodyta, kad viena užklausa, priklausomai nuo etikečių strategijos, galėjo apdoroti apie 100 GB, kita – apie 2,5 TB duomenų. Vadinasi, klausimas „kokias etiketes kaupiame?“ yra kartu našumo ir kaštų klausimas.

Trasos seka vienos užklausos kelią

Paskirstytasis užklausų sekimas leidžia matyti, kaip viena kliento užklausa keliauja per kelias paslaugas. „OpenTelemetry“ yra nuo tiekėjo nepriklausoma sistema tokiems signalams generuoti, rinkti ir eksportuoti; ji pati nėra duomenų saugykla. „Hostinger“ naudoja vietinius rinktuvus, centrinį šliuzą ir „Grafana Tempo“, o automatinis instrumentavimas – telemetrijos prijungimas be rankinių pakeitimų kiekvienoje kodo vietoje – padeda greičiau įtraukti programas.

Patogumas turi kainą. Automatinis instrumentavimas gali sukurti pernelyg daug unikalių atributų, sulėtinti užklausas ar net netyčia surinkti jautrius parametrus. Ši riba aktuali ne tik infrastruktūroje – ją primena ir diskusija apie viską girdinčio AI įrenginio patogumą. Kaupti reikėtų ne viską, ką įmanoma, o tai, kas turi aiškų naudojimo tikslą.

Patikimumo kainą lemia sąmoningi kompromisai

„Hostinger“ darbo valandomis didina „Loki“ užklausas aptarnaujančių kopijų skaičių, tačiau naktį palieka minimalų replikų – veikiančių kopijų – kiekį, kad pirmoji užklausa nebūtų lėta. Tai sąmoningai „degina“ dalį biudžeto dėl patikimumo. Atminties kaštus komanda mažino pasitelkdama greitus vietinius SSD diskus ir taip sukūrė terabaitų dydžio talpyklą, kurią laikyti vien operatyviojoje atmintyje būtų brangu.

Ši logika naudinga ir mažesnei įmonei. Pigiausia infrastruktūra nėra ta, kurios mėnesio sąskaita mažiausia, jei incidento metu komanda valandų valandas ieško priežasties. Kartu perteklinis duomenų rinkimas taip pat nėra brandos ženklas: jis didina saugojimo kainą, užklausų laiką ir privatumo riziką.

Pranešimo pabaigoje Giedrė parodė vidinį asistentą, kuris per MCP – standartinę sąsają, suteikiančią asistentui prieigą prie skirtingų sistemų – sujungia „Loki“, „Tempo“, „Mimir“ ir „Kubernetes“ kontekstą. Jo teigimu, asistentas per kelias minutes padėjo nustatyti „Tempo“ duomenų glaudinimo podų strigimo priežastį ir pasiūlė pataisą. Tai skamba įspūdingai, tačiau vertė atsirado todėl, kad asistentas gavo struktūruotą ir susietą kontekstą – ne todėl, kad dirbtinis intelektas savaime sutvarkė infrastruktūrą.

Ką iš Hostinger kelionės gali išmokti auganti įmonė?

• Stebėkite kliento patirtį, ne vien serverius. Techninis veikimas dar nereiškia, kad paslauga daro tai, ko tikisi žmogus.
• Migruokite su pasitikėjimo planu. Lygiagretus veikimas, incidento bandymas ir aiškūs išjungimo kriterijai yra tokie pat svarbūs kaip duomenų perkėlimas.
• Ribokite kardinalumą ir duomenų kiekį. Kiekvienas naujas atributas turi kainą, o kartais – ir saugumo pasekmes.
• Pradėkite paprastai. Giedrė rekomenduoja pirmiausia pasirinkti aiškias trasų atrankos taisykles ir patikrinti, ar jos iš tikrųjų veikia.

Sistemų stebėjimas tampa konkurenciniu pranašumu tada, kai sutrumpina kelią nuo kliento problemos iki teisingo sprendimo. Naujos technologijos gali atverti didelį lūžį – kaip rodo ir kvantinių kompiuterių galimybių analizė – bet brandą parodo ne įrankių naujumas. Ją parodo gebėjimas žinoti, ką matuojame, kodėl tuo pasitikime ir kiek esame pasirengę už tai mokėti.

▶

Šaltiniai

• Danske Bank Lithuania: kintantis „Hostinger“ stebimumo veidas — Pagrindinis straipsnio šaltinis – Edgaro Giedrės pranešimas apie „Hostinger“ metrikų, žurnalų ir trasų infrastruktūrą.
• Grafana Mimir: įvadas — Oficialus horizontalaus mastelio didinimo, ilgalaikio saugojimo ir suderinamumo su „Prometheus“ paaiškinimas.
• Grafana Loki: apžvalga — Oficialus „Loki“ žurnalų indeksavimo ir saugojimo principų aprašymas.
• Kas yra OpenTelemetry? — Oficialus nuo tiekėjo nepriklausomos telemetrijos sistemos apibrėžimas.