Prometheus un Grafana integrācija, kas laikus pamana problēmas
Publicēts 2026. gada 6. oktobrī
Prometheus un Grafana integrācija ļauj servera metrikām lietderīgi darboties: parādīt izmaiņas, brīdināt jūs, pirms ierobežojuma sasniegšana izraisa darbības pārtraukumu, un sniegt pierādījumus, ja pakalpojums šķiet lēns. Prometheus apkopo un saglabā datus. Grafana pārvērš tos informācijas paneļos un brīdinājumos, ko jūsu komanda var uzreiz saprast. Kopā tie minējumu vietā sniedz skaidrāku pārskatu par darbību.
VPS, dedicated server, SaaS platformai vai noslogotam tiešsaistes veikalam šis risinājums ir visvērtīgākais, pirms kaut kas pārstāj darboties. Pilns disks, izsmelta atmiņa, pieaugošs atbildes laiks vai gandrīz sasniegts datubāzes savienojumu pūla ierobežojums parasti vispirms atstāj pēdas metrikās. Pakalpojums pašlaik var darboties, taču diagramma jau vēsta nākamo stāsta daļu.
Ko dara Prometheus un Grafana
Prometheus ir laikrindu uzraudzības sistēma. Tā regulāri iegūst metrikas no mērķiem, pievieno šiem mērījumiem etiķetes un saglabā tos pieejamus vaicājumiem. Tā ir īpaši piemērota serveru un lietotņu uzraudzībai, jo tādas metrikas kā CPU noslodze, atmiņas noslodze, pieprasījumu biežums, latentums un failu sistēmas ietilpība dabiski atbilst tās modelim.
Grafana ir vizualizācijas un brīdinājumu slānis. Tā izmanto Prometheus kā datu avotu, ļauj veidot paneļus, izmantojot PromQL vaicājumus, un sakārtot šos paneļus informācijas paneļos. Labam Grafana informācijas panelim nav jābūt dekoratīvam. Tā uzdevums ir ātri atbildēt uz praktiskiem jautājumiem: vai serveris darbojas pareizi? Kurš pakalpojums izmanto resursus? Vai veiktspēja pasliktinās? Vai plkst. 14.00 veiktā izvietošana kaut ko mainīja?
Prometheus pats var novērtēt brīdinājumu noteikumus, savukārt Alertmanager apstrādā paziņojumu grupēšanu, maršrutēšanu un apklusināšanu. Grafana var arī izveidot brīdinājumus no informācijas paneļa vaicājumiem. Der abas pieejas. Brīdinājumiem, kas aptver visu infrastruktūru un tiek pārvaldīti ar kodu, Prometheus noteikumus un Alertmanager bieži ir vieglāk standartizēt. Konkrēta pakalpojuma informācijas panelim var būt ērti izmantot Grafana pārvaldītus brīdinājumus. Izvairieties palaist abus tieši vienam un tam pašam nosacījumam, ja vien dublēti brīdinājumi plkst. 3 naktī. nav daļa no plāna.
Prometheus un Grafana integrācija: praktiska arhitektūra
Saprātīga sākuma arhitektūra ir neliela. Ja iespējams, Prometheus un Grafana darbiniet uzraudzības VPS, kas ir atsevišķi no uzraugāmā servera vai lietotnes. Uzraugāmajās sistēmās instalējiet eksportētājus. Eksportētāji nodrošina piekļuvi metrikām HTTP galapunktā, un Prometheus tās iegūst pēc noteikta grafika.
Linux serveriem parasti pirmā izvēle ir Node Exporter. Tas nodrošina piekļuvi resursdatora līmeņa mērījumiem, tostarp CPU, atmiņai, vidējai slodzei, diska lietojumam, tīkla datplūsmai un failu sistēmas statistikai. Datubāzu eksportētāji var sniegt papildu pārskatāmību par MySQL, PostgreSQL, Redis un citiem pakalpojumiem. Lietotnes metrikas var iegūt no Prometheus iebūvētā galapunkta, ietvara bibliotēkas vai rūpīgi izvēlēta eksportētāja.
Datu plūsma ir vienkārša:
- Eksportētājs nodrošina piekļuvi servera, datubāzes vai lietotnes metrikām.
- Prometheus iegūst datus no galapunkta un saglabā laikrindu datus.
- Grafana veic vaicājumus Prometheus un attēlo rezultātus.
- Brīdinājumu noteikumi novērtē sliekšņvērtības vai neparastu uzvedību un nosūta paziņojumus, izmantojot izvēlēto kanālu.
Šis vienkāršais attēlojums ir svarīgs, jo tas atvieglo arī problēmu novēršanu. Ja Grafana panelis ir tukšs, pārbaudiet, vai Grafana var veikt vaicājumus Prometheus. Ja Prometheus nav datu, pārbaudiet mērķu lapu un eksportētāja galapunktu. Ja mērķis nav pieejams, pārbaudiet piekļuvi tīklam, ugunsmūra noteikumus, pakalpojuma statusu un eksportētāja konfigurāciju. Tagad žurnāli parasti vēsta to pašu stāstu.
Sāciet ar metrikām, kas palīdz rīkoties
Visu pieejamo metriku apkopošana rada lieku troksni, aizņem krātuvi un veido informācijas paneļus, ko neviens neatver. Sāciet ar metrikām, kas palīdz pieņemt skaidrus operatīvos lēmumus. Lielākajai daļai serveru tās ir CPU izmantošana un slodze, pieejamā atmiņa, mijmaiņas vietas aktivitāte, diska vieta un inode lietojums, diska I/O latentums, tīkla kļūdas, procesu pieejamība un sistēmas darbības laiks.
Tīmekļa lietotnēm pievienojiet HTTP pieprasījumu biežumu, kļūdu biežumu, pieprasījumu ilgumu, aktīvo savienojumu skaitu un, ja attiecināms, rindas garumu. Datubāzēm sekojiet līdzi savienojumu skaitam, lēnajiem vaicājumiem, replikācijas statusam, kešatmiņas efektivitātei, bloķēšanām un krātuves apjoma pieaugumam. E-komercijas vietnei var būt ļoti svarīgi norēķinu kļūdu rādītāji un datubāzes latentums, savukārt izstrādes aģentūra par prioritāti var noteikt klientu vides darbības laiku un dublējumkopiju izveides sekmes. Tas ir atkarīgs no darba slodzes, nevis no tā, kurš informācijas panelis izskatās iespaidīgāks.
Etiķetes izmantojiet apdomīgi. Etiķetes ļauj filtrēt pēc vides, servera lomas, klienta, reģiona vai lietotnes. Tās var arī radīt lielu skaitu atšķirīgu laikrindu, ja tajās iekļautas vērtības, kas pastāvīgi mainās, piemēram, lietotāju ID, pasūtījumu ID, sesiju pilnvaras vai pieprasījumu ceļi ar dinamiskiem parametriem. Etiķetes ar lielu kardinalitāti ir nemanāms veids, kā likt Prometheus strādāt daudz vairāk, nekā nepieciešams.
Iestatiet datu apkopošanu, neradot jaunus riskus
Prometheus konfigurācijā ir nepieciešams mērķu saraksts. Node Exporter mērķa konfigurācijas piemērs:
``\`yaml scrape_configs:
- job_name: node
static_configs:
- targets: ['10.0.0.15:9100']
labels: environment: production role: web ``\`
Nelielā vidē statiskie mērķi ir skaidri un uzticami. Infrastruktūrai augot, piemērotāka parasti ir pakalpojumu noteikšana, jo mērķi tiek pievienoti un noņemti automātiski. Neatkarīgi no izvēlētās metodes, ja iespējams, gādājiet, lai uzraudzības galapunkti būtu privāti. Neatstājiet eksportētāju portus plaši pieejamus publiskajā internetā tikai tāpēc, ka informācijas panelim ir nepieciešami dati.
Ja nepieciešams, izmantojiet privātu tīklu, ugunsmūra atļauto sarakstus, VPN vai reverso starpniekserveri ar autentifikāciju. Šifrējiet datplūsmu, ja metrikas tiek pārsūtītas pa neuzticamiem tīkliem. Prometheus metrikās var būt ietverti resursdatoru nosaukumi, iekšējo pakalpojumu nosaukumi, darba slodzes modeļi un versiju informācija. Tie ir operatīvie dati, nevis publisks rotājums.
Iestatiet datu glabāšanas periodu atbilstoši vajadzībām, kas saistītas ar incidentiem un jaudas plānošanu. Daudzām nelielām instalācijām pietiek ar piecpadsmit līdz trīsdesmit dienām, lai noteiktu nesenās izmaiņas un īstermiņa tendences. Ilgāks glabāšanas periods palīdz analizēt sezonālo pieprasījumu un pakāpenisku jaudas pieaugumu, taču palielina diska vietas prasības. Ilgtermiņa vēsturiskajiem pārskatiem apsveriet attālo krātuvi, nevis neierobežotu datu glabāšanu tajā pašā VPS, kurā darbojas Grafana.
Veidojiet informācijas paneļus ātrai diagnostikai
Vispirms izveidojiet vienu pārskata informācijas paneli. Tajā jāparāda svarīgāko sistēmu stāvoklis, nevis visas kataloga metrikas. Noderīgā pārskata panelī bieži ir iekļauta servera pieejamība, CPU, atmiņa, diska lietojums, tīkla datplūsma, HTTP kļūdu biežums un pieprasījumu latentums. Izmantojiet mainīgos resursdatoram, videi un pakalpojumam, lai viens informācijas panelis būtu izmantojams vairākās sistēmās un nepārvērstos par kopēšanas un ielīmēšanas muzeju.
Pēc tam izveidojiet konkrētiem pakalpojumiem paredzētus informācijas paneļus. Datub āzes informācijas panelim ir nepieciešami citi paneļi nekā tīmekļa servera informācijas panelim. Fona darba izpildītāja informācijas panelī jāparāda rindas garums, apstrādes laiks, atkārtotie mēģinājumi un kļūmes. Izmantojiet tiešus paneļu nosaukumus: “Brīvā diska vieta /var”, “HTTP 5xx kļūdu biežums” un “Aktīvie PostgreSQL savienojumi” ir labāki par asprātīgiem nosaukumiem, kas jātulko pašā nepiemērotākajā brīdī.
Ir vērts pievienot anotācijas par izvietošanu, apkopes periodiem un konfigurācijas izmaiņām. Ja latentums palielinās neilgi pēc laidiena, anotācija pārvērš aizdomīgu diagrammu noderīgā diskusijā. Tā nepierāda cēloņsakarību, taču sniedz izmeklēšanai saprātīgu sākumpunktu.
Izveidojiet brīdinājumus par simptomiem, nevis katru skaitli
CPU brīdinājums pie 80% var būt noderīgs vienam serverim un bezjēdzīgs citam. Pakešu apstrādes mezgls pēc plāna var stundām darboties ar lielu noslodzi, savukārt pēkšņs API latentuma pieaugums var uzreiz ietekmēt klientus pat tad, ja CPU noslodze ir mērena. Brīdinājumu noteikumos jāņem vērā ietekme un paredzamā uzvedība.
Sāciet ar brīdinājumiem par apstākļiem, kuros nepieciešama rīcība: eksportētājs vai pakalpojums nav sasniedzams, drīz beigsies diska vieta, dublējumkopiju izveides uzdevumi neizdodas, atmiņas noslodze izraisa mijmaiņas vietas izmantošanu, pieaug kļūdu biežums, tuvojas sertifikātu derīguma termiņa beigas vai nedarbojas datubāzes replikācija. Nosakiet ilgumu, lai īslaicīgi kāpumi nevajadzīgi nevienu nepamodinātu. Piemēram, ilgstoši maz brīvas vietas diskā piecpadsmit minūšu garumā parasti ir noderīgāks signāls nekā piecu sekunžu kritums.
Katram brīdinājumam jāatbild uz trim jautājumiem: kas nav kārtībā, kur tas notiek un kas atbildīgajai personai vispirms jāpārbauda? Brīdinājuma anotācijā norādiet servera nosaukumu, vidi, pakalpojumu un īsu norādi uz rīcības rokasgrāmatu. Ar “Maz diska vietas” nepietiek, ja ir divdesmit serveru un kāds lasa ziņojumu tālrunī.
Paziņojumu apklusināšana un apkopes periodi ir veselīgas brīdinājumu sistēmas sastāvdaļa, nevis veids, kā slēpt problēmas. Izmantojiet tos plānotajiem darbiem un pēc darbu pabeigšanas atceliet. Aizmirsta paziņojumu apklusināšana ir ļoti slikta laika izjūta.
Uzturiet uzraudzības steku viegli pārvaldāmu
Uzskatiet informācijas paneļus, brīdinājumu noteikumus un Prometheus konfigurāciju par operatīvajiem resursiem. Veidojiet to dublējumkopijas, pārskatiet tos pēc incidentiem un, ja jūsu komanda to var droši darīt, glabājiet konfigurāciju versiju vadības sistēmā. Ik pa laikam pārbaudiet brīdinājumus. Paziņojumu kanāls, kas nekad nav pārbaudīts, ir tikai cerību pilna teorija.
Uzraugiet arī pašu uzraudzības sistēmu. Prometheus ir nepieciešama pietiekama atmiņa un krātuve, Grafana konfigurācijas un datubāzes dublējumkopijas, savukārt eksportētājiem jāpaliek sasniedzamiem arī pēc ugunsmūra vai tīkla izmaiņām. Sekojiet līdzi datu iegūšanas ilgumam, neveiksmīgām datu iegūšanas reizēm, krātuves ietilpībai un neveiksmīgai brīdinājumu piegādei. Ja uzraudzības serveris ir pārslogots, tā diagrammas var izskatīties mierīgas, kamēr tas nemanāmi palaiž garām jums vajadzīgos pierādījumus.
Komandām, kas vēlas saņemt operatīvu palīdzību līdztekus infrastruktūrai, kodu.cloud var palīdzēt ar uzraudzītām VPS un serveru vidēm, bet jūs varat turpināt sekot savai uzņēmējdarbībai svarīgajām metrikām. Mērķis nav padarīt uzraudzību noslēpumainu. Mērķis ir padarīt nākamo problēmu mazāku, pamanīt to agrāk un atvieglot tās novēršanu.
Labi pielāgota Prometheus un Grafana konfigurācija nenovērš incidentus. Tā ļauj jūsu komandai laikus saņemt brīdinājumus, iegūt skaidrāku kontekstu un incidenta laikā pieņemt mazāk lēmumu, trūkstot informācijai. Sāciet ar vienu serveri, vienu informācijas paneli un nelielu skaitu brīdinājumu, uz kuriem cilvēki patiešām rīkosies. Tad pakalpojuma darbība atkal kļūst mierīga.
Andres Saar, klientu atbalsta inženieris