Lielākā daļa datubāzu paneļu ir veidoti ap CPU, atmiņas un diska izmantojumu. Tos sekot nav nepareizi — bet līdz brīdim, kad kāds no tiem kļūst sarkans, incidents parasti jau ir sācies. Signāli, kas patiešām sniedz brīdinājumu, atrodas tālāk pa straumi, un tie reti parādās noklusējuma panelī.
1. Replikācijas aizture — kā tendence, nevis momentuzņēmums
Viena aiztures nolasīšana "12 sekundes" pati par sevi pasaka gandrīz neko. Svarīga ir tendence: vai aizture ir stabila, vai tā aug? Replika, kas pie tāda paša darba slodzes pastāvīgi atpaliek arvien vairāk, norāda, ka tai trūkst rezerves — vai nu I/O, vai apply-worker caurlaidspējas, vai kaut kas cits sacenšas par tiem pašiem resursiem. Līdz brīdim, kad aizture ir redzami uzlēkusi, replika parasti jau kādu laiku ir degradējusies.
2. Bloķēšanas gaidīšanas laiks un bloķēto vaicājumu skaits
Ilgi strādājošas transakcijas, kas tur bloķēšanas, ir viens no biežākajiem kaskādes kļūmes priekšvēstnešiem — viens lēns vaicājums bloķē vēl vairākus, tie sarindo savienojumus rindā, tas izsmeļ pūlu, un lēns vaicājums pārvēršas par pilnu dīkstāvi. Bloķēto vaicājumu skaita un kopējā bloķēšanas gaidīšanas laika sekošana laika gaitā atklāj šo modeli labu laiku pirms savienojumu izsmelšanas faktiski notiek.
3. Autovacuum parāds
Miruša rindu (dead tuple) skaits, tabulas uzpūšanās (bloat) un tas, cik tālu autovacuum ir atpalicis jūsu noslogotākajās tabulās, ir vadošie, nevis kavējošie indikatori. Tabula, kas uzkrāj mirušās rindas ātrāk, nekā autovacuum spēj tās iztīrīt, galu galā izpaudīsies kā degradēti vaicājumu plāni, uzpūsti indeksi un — sliktākajā gadījumā — transakciju ID pārpildes (wraparound) risks. Tas viss ir redzams jau labu laiku iepriekš, ja kāds skatās.
4. Vaicājumu plānu regresijas
Salīdzinot pg_stat_statements momentuzņēmumus laika gaitā — ne tikai skatoties uz pašreizējiem top vaicājumiem, bet salīdzinot ar pagājušās nedēļas datiem — atklāj plānu regresijas, pirms tās kļūst par incidentu. Vaicājums, kuram pēkšņi nepieciešams secīgs skenējums (sequential scan) tur, kur agrāk tika izmantots indekss (bieži pēc statistikas atjaunināšanas, datu sadalījuma izmaiņām vai parameter sniffing problēmas), šeit parādās ilgi pirms tas parādās kā izsaukums.
5. Savienojumu piesātinājums attiecībā pret pūla limitiem
Absolūts savienojumu skaits pats par sevi maz ko nozīmē bez saucēja. Svarīgs ir tas, cik tuvu aktīvo savienojumu skaits ir konfigurētajam pūla limitam un cik ātri šī atstarpe samazinās. Tā ir viena no vienkāršākajām metrikām, ko sekot, un viena no biežāk ignorētajām, jo "savienojumi: 340" neizskatās trauksmaini, kamēr nezini, ka limits ir 350.
Kopīgais pavediens visos piecos: neviens no tiem nav noderīgs kā vienreizējs, konkrēta brīža rādījums. Tie ir noderīgi kā tendences, sekotas nepārtraukti, ar brīdinājumiem par izmaiņu tempu, nevis fiksētiem sliekšņiem. Izsaukt trauksmi par "disks pilns 80%" kā vienu absolūtu slieksni bieži vien jau ir par vēlu — trauksme par "diska izmantojums pieaug 3 reizes ātrāk nekā tā 30 dienu vidējais rādītājs" dod jums laiku rīkoties.
Brīdinājumu nogurums ir projektēšanas problēma, nevis regulēšanas problēma
Komandas, kas izsūta brīdinājumu par katru metriku, kas šķērso fiksētu slieksni, mēdz dažu mēnešu laikā sākt ignorēt brīdinājumus pavisam. Risinājums nav mazāk metriku — tas ir labāk izstrādāti brīdinājumi: mazāk absolūtu sliekšņu, vairāk tendenču un izmaiņu tempa noteikšana un skaidra eskalācija, lai patiešām steidzams signāls nepazustu simts zemas prioritātes brīdinājumu troksnī.
Galvenās atziņas
- Sekojiet replikācijas aizturei, bloķēšanas gaidīšanai, autovacuum parādam, vaicājumu plānu izmaiņām un savienojumu piesātinājumam kā tendencēm — nevis atsevišķiem nolasījumiem.
- Kur iespējams, izsūtiet brīdinājumus par izmaiņu tempu, nevis tikai par fiksētiem sliekšņiem.
- Līdz brīdim, kad CPU vai atmiņas grafiki kļūst sarkani, šie pieci signāli parasti jau kādu laiku ir bijuši degradācijā.