Prometheuse ja Grafana integratsioon, mis märkab probleeme

Avaldatud 6. oktoobril 2026

Prometheuse ja Grafana integratsioon aitab serveri mõõdikuid kasulikult rakendada: näidata, mis muutub, hoiatada enne piirangu ületamist ja teenuse aegluse korral tõendusmaterjali anda. Prometheus kogub ja talletab arvandmeid. Grafana muudab need juhtpaneelideks ja hoiatusteks, millest meeskond saab hetkega aru. Koos asendavad need oletamise rahulikuma ülevaatega süsteemi toimimisest.

Olgu tegemist VPS-i, pühendatud serveri, SaaS-platvormi või suure külastatavusega veebipoega, on see lahendus kõige väärtuslikum enne, kui midagi rikki läheb. Täis ketas, ammendunud mälu, pikenevad vastusajad või piirini jõudev andmebaasiühenduste kogum jätavad tavaliselt mõõdikutesse esmalt jälje. Teenus võib praegu töötada, kuid graafik jutustab juba loo järgmist osa.

Prometheuse ja Grafana ülesanded

Prometheus on aegridade jälgimise süsteem. See kogub sihtmärkidelt regulaarsete ajavahemike järel mõõdikuid, lisab neile sildid ja hoiab need päringuteks kättesaadavana. See sobib eriti hästi serverite ja rakenduste jälgimiseks, sest sellised mõõdikud nagu protsessori kasutus, mälukoormus, päringute sagedus, latentsus ja failisüsteemi maht sobituvad selle mudeliga loomulikult.

Grafana on visualiseerimise ja hoiatuste kiht. See ühendub andmeallikana Prometheusega, võimaldab PromQL-päringute põhjal paneele luua ja koondab need paneelid juhtpaneelidele. Hea Grafana juhtpaneel ei pea olema dekoratiivne. Selle eesmärk on vastata kiiresti praktilistele küsimustele: kas server on töökorras? Milline teenus ressursse kasutab? Kas jõudlus halveneb? Kas kell 14:00 tehtud juurutus muutis midagi?

Prometheus saab häirereegleid ise hinnata, Alertmanager aga haldab teavituste rühmitamist, suunamist ja vaigistamist. Grafana saab luua häireid ka juhtpaneeli päringute põhjal. Mõlemad lähenemisviisid võivad toimida. Kogu taristut hõlmavate, koodina hallatavate häirete puhul on Prometheuse reegleid ja Alertmanagerit sageli lihtsam standardiseerida. Konkreetse teenuse juhtpaneeli korral võivad Grafana hallatavad häired olla mugavad. Väldi mõlema kasutamist täpselt sama tingimuse korral, välja arvatud juhul, kui kell 3 öösel saabuvad dubleeritud teavitused. on plaani osa.

Prometheuse ja Grafana integratsioon: praktiline arhitektuur

Mõistlik algarhitektuur on lihtne. Võimaluse korral käita Prometheust ja Grafanat jälgimiseks mõeldud VPS-is, jälgitavast serverist või rakendusest eraldi. Paigalda jälgitavatesse süsteemidesse eksportijad. Eksportijad teevad mõõdikud HTTP-lõpp-punktis kättesaadavaks ja Prometheus kogub neid ajakava alusel.

Linuxi serverite puhul on Node Exporter tavapärane esimene valik. See teeb kättesaadavaks hosti taseme mõõtmised, sealhulgas protsessori, mälu, keskmise koormuse, kettakasutuse, võrguliikluse ja failisüsteemi statistika. Andmebaasi eksportijad võivad lisada ülevaate MySQL-ist, PostgreSQL-ist, Redisest ja muudest teenustest. Rakenduse mõõdikud võivad pärineda Prometheuse algupärasest lõpp-punktist, raamistikuteegist või hoolikalt valitud eksportijast.

Andmete põhivoog on lihtne:

• Eksportija teeb serveri, andmebaasi või rakenduse mõõdikud kättesaadavaks.
• Prometheus kogub lõpp-punktist aegridade andmed ja talletab need.
• Grafana esitab Prometheusele päringuid ja kuvab tulemused.
• Häirereeglid hindavad läviväärtusi või ebatavalist käitumist ning saadavad teavitused valitud kanali kaudu.

Lihtne skeem on oluline, sest see teeb ka tõrkeotsingu lihtsaks. Kui Grafana paneel on tühi, kontrolli, kas Grafana saab Prometheusele päringuid esitada. Kui Prometheusel andmeid pole, kontrolli sihtmärkide lehte ja eksportija lõpp-punkti. Kui sihtmärk pole kättesaadav, kontrolli võrgupääsu, tulemüüri reegleid, teenuse olekut ja eksportija seadistust. Nüüd räägivad logid tavaliselt sama lugu.

Alusta mõõdikutest, mille põhjal saab tegutseda

Kõigi saadaolevate mõõdikute kogumine tekitab müra, kulutab salvestusruumi ja annab tulemuseks juhtpaneelid, mida keegi ei ava. Alusta mõõdikutest, mis toetavad selget operatiivset otsust. Enamiku serverite puhul tähendab see protsessori kasutust ja koormust, vaba mälu, saalefaili kasutust, kettaruumi ja inode'ide kasutust, ketta I/O latentsust, võrguvigu, protsesside kättesaadavust ja süsteemi tööaega.

Veebirakenduste puhul lisa vajaduse korral HTTP-päringute sagedus, veamäär, päringute kestus, aktiivsed ühendused ja järjekorra pikkus. Andmebaaside puhul jälgi ühenduste arvu, aeglaseid päringuid, replikatsiooni olekut, vahemälu tõhusust, lukke ja salvestusruumi kasvu. E-kaubanduse sait võib pidada väga oluliseks ostu vormistamise vigu ja andmebaasi latentsust; arendusagentuur võib eelistada klientide keskkondade tööaja ja varundamise edukuse jälgimist. See sõltub töökoormusest, mitte sellest, milline juhtpaneel kõige muljetavaldavam välja näeb.

Kasuta silte läbimõeldult. Sildid võimaldavad filtreerida keskkonna, serveri rolli, kliendi, piirkonna või rakenduse järgi. Need võivad tekitada ka suure hulga eristuvaid aegridu, kui sisaldavad pidevalt muutuvaid väärtusi, näiteks kasutaja ID-sid, tellimuse ID-sid, seansitokeneid või dünaamiliste parameetritega päringuteid. Suure kardinaalsusega sildid panevad Prometheuse märkamatult palju rohkem tööd tegema, kui vaja.

Seadista andmete kogumine uusi riske tekitamata

Prometheus vajab oma seadistuses sihtmärkide loendit. Node Exporteri lihtne sihtmärk võib välja näha nii:

``\`yaml scrape_configs:

• job_name: node

static_configs:

• targets: ['10.0.0.15:9100']

labels: environment: production role: web ``\`

Väikeses keskkonnas on staatilised sihtmärgid selged ja töökindlad. Taristu kasvades sobib teenuste automaattuvastus tavaliselt paremini, sest sihtmärgid lisatakse ja eemaldatakse automaatselt. Ükskõik millise meetodi valid, hoia jälgimise lõpp-punktid võimaluse korral privaatsena. Ära jäta eksportija porte laialdaselt avalikku internetti avatuks pelgalt seetõttu, et juhtpaneel vajab andmeid.

Kasuta vajaduse korral privaatvõrku, tulemüüri lubatud loendeid, VPN-i või autentimisega pöördpuhverserverit. Krüpteeri liiklus, kui mõõdikud liiguvad üle usaldamata võrkude. Prometheuse mõõdikud võivad paljastada hostinimesid, sisemiste teenuste nimesid, töökoormuse mustreid ja versiooniteavet. Need on operatiivandmed, mitte avalik silmailu.

Määra säilitusaeg vastavalt intsidentide uurimise ja võimsuse planeerimise vajadustele. Paljude väikeste paigalduste jaoks piisab viieteistkümnest kuni kolmekümnest päevast, et tuvastada hiljutised muudatused ja lühiajalised suundumused. Pikem säilitusaeg aitab jälgida hooajalist nõudlust ja järkjärgulist võimsuse kasvu, kuid suurendab kettaruumi vajadust. Pikaajalise ajaloolise aruandluse jaoks kaalu kaugsalvestust, selle asemel et rakendada piiramatut säilitusaega samas VPS-is, kus töötab Grafana.

Koosta juhtpaneelid kiireks diagnoosimiseks

Loo esmalt üks ülevaatejuhtpaneel. See peaks näitama kõige olulisemate süsteemide seisundit, mitte kõiki kataloogis olevaid mõõdikuid. Kasulik ülevaade sisaldab sageli serveri kättesaadavust, protsessori ja mälu kasutust, kettakasutust, võrguliiklust, HTTP veamäära ja päringute latentsust. Kasuta hosti, keskkonna ja teenuse jaoks muutujaid, et üks juhtpaneel sobiks mitmele süsteemile ega muutuks kopeerimise-kleepimise muuseumiks.

Seejärel loo teenusepõhised juhtpaneelid. Andmebaasi juhtpaneel vajab teistsuguseid paneele kui veebiserveri juhtpaneel. Taustatöölise juhtpaneel peaks näitama järjekorra pikkust, töötlemisaega, korduskatseid ja tõrkeid. Paneelide pealkirjad olgu otsekohesed: „Vaba kettaruum kataloogis /var”, „HTTP 5xx veamäär” ja „PostgreSQL-i aktiivsed ühendused” on paremad kui nutikad nimed, mis halvimal hetkel vajavad tõlkimist.

Juurutuste, hooldusakende ja seadistuse muudatuste kohta tasub lisada annotatsioone. Kui latentsus kasvab varsti pärast väljalaset, muudab annotatsioon kahtlase graafiku kasulikuks aruteluks. See ei tõesta põhjuslikku seost, kuid annab uurimisele mõistliku lähtekoha.

Loo häireid sümptomite, mitte iga arvväärtuse põhjal

80% protsessorikasutuse häire võib ühe serveri puhul kasulik olla ja teise puhul mõttetu. Pakktöötluse sõlm võibki kavakohaselt tundide kaupa suure koormusega töötada, samal ajal kui API latentsuse järsk kasv võib kliente kohe mõjutada isegi mõõduka protsessorikasutuse korral. Häirereeglid peaksid kajastama mõju ja eeldatavat käitumist.

Alusta häiretest tingimuste kohta, mis nõuavad reageerimist: eksportija või teenus pole kättesaadav, kettaruum saab peagi otsa, varundustööd ebaõnnestuvad, mälukoormus põhjustab saalefaili kasutamist, veamäär kasvab, sertifikaatide kehtivusaeg hakkab lõppema või andmebaasi replikatsioon ei toimi korralikult. Määra kestus, et lühiajalised hüpped kedagi asjatult üles ei ärataks. Näiteks on viisteist minutit püsinud vähene kettaruum üldiselt olulisem kui viiesekundiline langus.

Iga häire peaks vastama kolmele küsimusele: mis on valesti, kus see toimub ja mida peaks reageerija esmalt kontrollima? Lisa häire annotatsiooni serveri nimi, keskkond, teenus ja lühike juhis käivitusjuhendist. „Kettaruum on otsakorral” ei ole piisav, kui servereid on kakskümmend ja keegi loeb teadet telefonist.

Vaigistused ja hooldusaknad on toimiva häirehalduse osa, mitte viis probleemide peitmiseks. Kasuta neid kavandatud tööde ajal ja eemalda, kui töö on lõpetatud. Unustatud vaigistus tabab alati väga halval ajal.

Hoia jälgimistaristu hallatavana

Käsitle juhtpaneele, häirereegleid ja Prometheuse seadistust operatiivvaradena. Varunda need, vaata need pärast intsidente üle ja salvesta seadistus versioonihaldusse, kui meeskond saab seda turvaliselt teha. Testi häireid aeg-ajalt. Teavituskanal, mida pole kunagi testitud, on vaid lootusrikas oletus.

Jälgi ka jälgimissüsteemi ennast. Prometheus vajab piisavalt mälu ja salvestusruumi, Grafana vajab oma seadistuse ja andmebaasi varukoopiaid ning eksportijad peavad pärast tulemüüri või võrgu muudatusi endiselt kättesaadavad olema. Jälgi kogumise kestust, ebaõnnestunud kogumisi, salvestusruumi mahtu ja häirete edastamise tõrkeid. Kui jälgimisserver on üle koormatud, võivad graafikud paista rahulikud, kuigi süsteem jätab vaikselt vajalikud tõendid kogumata.

Meeskondadele, kes eelistavad taristu kõrval ka operatiivset tuge, saab kodu.cloud abiks olla jälgitavate VPS-ide ja serverikeskkondadega, samal ajal kui hoiate ettevõtte jaoks olulistel mõõdikutel silma peal. Eesmärk ei ole muuta jälgimist salapäraseks. Eesmärk on muuta järgmine probleem väiksemaks, varasemaks ja hõlpsamini lahendatavaks.

Hästi seadistatud Prometheuse ja Grafana lahendus ei kõrvalda intsidente. See annab meeskonnale varasema hoiatuse, selgema konteksti ja intsidendi korral vähem pimesi tehtud otsuseid. Alusta ühest serverist, ühest juhtpaneelist ja väikesest hulgast häiretest, mille peale inimesed päriselt tegutsevad. Sealt edasi muutub teenuse haldamine taas rahulikuks.

Andres Saar, klienditoe insener