Bazele monitorizării PostgreSQL. Alexei Lesovski

Vă sugerez să citiți transcrierea raportului lui Alexey Lesovsky de la Data Egret „Fundamentals of PostgreSQL monitoring”

În acest raport, Alexey Lesovsky va vorbi despre punctele cheie ale statisticilor post-gres, ce înseamnă acestea și de ce ar trebui să fie prezente în monitorizare; despre ce grafice ar trebui să fie în monitorizare, cum să le adăugați și cum să le interpretați. Raportul va fi util administratorilor de baze de date, administratorilor de sistem și dezvoltatorilor care sunt interesați de depanarea Postgres.

Numele meu este Alexey Lesovsky, reprezint compania Data Egret.

Câteva cuvinte despre mine. Am început cu mult timp în urmă ca administrator de sistem.

Am administrat tot felul de sisteme Linux diferite, am lucrat la diverse lucruri legate de Linux, adică virtualizare, monitorizare, am lucrat cu proxy-uri etc. Dar la un moment dat am început să lucrez mai mult cu baze de date, PostgreSQL. Mi-a plăcut foarte mult de el. Și la un moment dat am început să lucrez la PostgreSQL cea mai mare parte a timpului meu de lucru. Și așa, treptat, am devenit un DBA PostgreSQL.

Și de-a lungul carierei mele, am fost întotdeauna interesat de subiectele de statistică, monitorizare și telemetrie. Și când eram administrator de sistem, am lucrat foarte strâns cu Zabbix. Și am scris un set mic de scenarii de genul zabbix-extensii. Era destul de popular la vremea lui. Și acolo a fost posibil să se monitorizeze lucruri importante foarte diferite, nu numai Linux, ci și diverse componente.

Acum lucrez la PostgreSQL. Deja scriu un alt lucru care vă permite să lucrați cu statistici PostgreSQL. Se numeste pgCenter (articol despre Habré - Statistici post-gres fără nervi și tensiune).

O mică notă introductivă. Ce situații au clienții noștri, clienții noștri? Există un fel de accident legat de baza de date. Și când baza de date a fost deja restaurată, șeful departamentului sau șeful de dezvoltare vine și spune: „Prieteni, trebuie să monitorizăm baza de date, pentru că s-a întâmplat ceva rău și trebuie să prevenim ca acest lucru să se întâmple în viitor”. Și aici începe procesul interesant de alegere a unui sistem de monitorizare sau de adaptare a unui sistem de monitorizare existent astfel încât să vă puteți monitoriza baza de date - PostgreSQL, MySQL sau altele. Și colegii încep să sugereze: „Am auzit că există așa și o bază de date. Să-l folosim.” Colegii încep să se certe între ei. Și până la urmă se dovedește că selectăm un fel de bază de date, dar monitorizarea PostgreSQL este prezentată în ea destul de prost și trebuie întotdeauna să adăugăm ceva. Luați niște depozite din GitHub, clonați-le, adaptați scripturile și personalizați-le cumva. Și până la urmă ajunge să fie un fel de muncă manuală.

Prin urmare, în această discuție voi încerca să vă ofer câteva cunoștințe despre cum să alegeți monitorizarea nu numai pentru PostgreSQL, ci și pentru baza de date. Și să vă ofere cunoștințele care vă vor permite să vă finalizați monitorizarea pentru a obține un anumit beneficiu de pe urma acesteia, astfel încât să vă puteți monitoriza baza de date cu beneficii, pentru a preveni cu promptitudine orice situații de urgență viitoare care ar putea apărea.

Iar ideile care vor fi în acest raport pot fi adaptate direct oricărei baze de date, fie că este vorba de un DBMS sau noSQL. Prin urmare, nu există doar PostgreSQL, ci vor exista multe rețete despre cum să faceți acest lucru în PostgreSQL. Vor fi exemple de interogări, exemple de entități pe care PostgreSQL le are pentru monitorizare. Și dacă DBMS-ul tău are aceleași lucruri care îți permit să le pui în monitorizare, poți și să le adaptezi, să le adaugi și va fi bine.

Nu voi fi în raport
discutați despre cum să livrați și să stocați valorile. Nu voi spune nimic despre post-procesarea datelor și prezentarea acestora către utilizator. Și nu voi spune nimic despre alertare.
Dar pe măsură ce povestea progresează, voi arăta diferite capturi de ecran ale monitorizării existente și le voi critica cumva. Dar, cu toate acestea, voi încerca să nu denumesc mărci pentru a nu crea reclamă sau anti-reclamă pentru aceste produse. Prin urmare, toate coincidențele sunt întâmplătoare și sunt lăsate la imaginația ta.

Mai întâi, să ne dăm seama ce este monitorizarea. Monitorizarea este un lucru foarte important de avut. Toată lumea înțelege asta. Dar, în același timp, monitorizarea nu are legătură cu un produs de afaceri și nu afectează direct profitul companiei, așa că timpul este întotdeauna alocat monitorizării pe bază reziduală. Dacă avem timp, atunci facem monitorizare dacă nu avem timp, atunci OK, o vom pune în restanță și într-o zi vom reveni la aceste sarcini.

Prin urmare, din practica noastră, atunci când venim la clienți, monitorizarea este adesea incompletă și nu are lucruri interesante care să ne ajute să facem o treabă mai bună cu baza de date. Și, prin urmare, monitorizarea trebuie să fie întotdeauna finalizată.

Bazele de date sunt lucruri atât de complexe care trebuie, de asemenea, monitorizate, deoarece bazele de date sunt un depozit de informații. Iar informațiile sunt foarte importante pentru companie, nu pot fi pierdute în niciun fel. Dar, în același timp, bazele de date sunt componente software foarte complexe. Ele constau dintr-un număr mare de componente. Și multe dintre aceste componente trebuie monitorizate.

Dacă vorbim în mod specific despre PostgreSQL, atunci acesta poate fi reprezentat sub forma unei scheme care constă dintr-un număr mare de componente. Aceste componente interacționează între ele. Și, în același timp, PostgreSQL are așa-numitul subsistem Stats Collector, care vă permite să colectați statistici despre funcționarea acestor subsisteme și să oferiți un fel de interfață administratorului sau utilizatorului, astfel încât acesta să poată vizualiza aceste statistici.

Aceste statistici sunt prezentate sub forma unui anumit set de funcții și vederi. Ele pot fi numite și tabele. Adică, folosind un client psql obișnuit, vă puteți conecta la baza de date, puteți selecta aceste funcții și vederi și puteți obține câteva numere specifice despre funcționarea subsistemelor PostgreSQL.

Puteți adăuga aceste numere la sistemul dvs. de monitorizare preferat, puteți să desenați grafice, să adăugați funcții și să obțineți analize pe termen lung.

Dar în acest raport nu voi acoperi în totalitate toate aceste funcții, deoarece ar putea dura toată ziua. Voi aborda literalmente două, trei sau patru lucruri și vă voi spune cum acestea ajută la îmbunătățirea monitorizării.

Și dacă vorbim despre monitorizarea bazelor de date, atunci ce trebuie monitorizat? În primul rând, trebuie să monitorizăm disponibilitatea, deoarece baza de date este un serviciu care oferă acces la date clienților și trebuie să monitorizăm disponibilitatea și, de asemenea, să oferim câteva dintre caracteristicile calitative și cantitative ale acesteia.

De asemenea, trebuie să monitorizăm clienții care se conectează la baza noastră de date, deoarece aceștia pot fi atât clienți normali, cât și clienți dăunători care pot dăuna bazei de date. De asemenea, trebuie să fie monitorizați și activitățile lor urmărite.

Când clienții se conectează la baza de date, este evident că încep să lucreze cu datele noastre, așa că trebuie să monitorizăm modul în care clienții lucrează cu datele: cu ce tabele și, într-o măsură mai mică, cu ce indici. Adică, trebuie să evaluăm volumul de muncă creat de clienții noștri.

Dar volumul de muncă constă, desigur, și în solicitări. Aplicațiile se conectează la baza de date, accesează datele folosind interogări, de aceea este important să evaluăm ce interogări avem în baza de date, să le monitorizăm adecvarea, că nu sunt scrise greșit, că unele opțiuni trebuie rescrise și făcute astfel încât să funcționeze mai repede si cu performante mai bune.

Și din moment ce vorbim despre o bază de date, baza de date este întotdeauna procese de fundal. Procesele de fundal ajută la menținerea performanței bazei de date la un nivel bun, astfel încât acestea necesită o anumită cantitate de resurse pentru a funcționa. Și, în același timp, se pot suprapune cu resursele de solicitare a clienților, astfel încât procesele de fundal lacome pot afecta direct performanța solicitărilor clienților. Prin urmare, trebuie să fie monitorizate și urmărite, astfel încât să nu existe distorsiuni în ceea ce privește procesele de fundal.

Și toate acestea în ceea ce privește monitorizarea bazei de date rămân în metrica sistemului. Dar având în vedere că cea mai mare parte a infrastructurii noastre se mută în cloud, valorile de sistem ale unei gazde individuale trec întotdeauna în fundal. Dar în bazele de date sunt încă relevante și, bineînțeles, este și necesar să se monitorizeze metricile sistemului.

Totul este mai mult sau mai puțin în regulă cu metricile de sistem, toate sistemele moderne de monitorizare acceptă deja aceste metrici, dar, în general, unele componente încă nu sunt suficiente și unele lucruri trebuie adăugate. Voi atinge și ele, vor fi câteva diapozitive despre ele.

Primul punct al planului este accesibilitatea. Ce este accesibilitatea? Disponibilitatea din punctul meu de vedere este capacitatea bazei de a deservi conexiuni, adică baza este ridicată, aceasta, ca serviciu, acceptă conexiuni de la clienți. Și această accesibilitate poate fi evaluată prin anumite caracteristici. Este foarte convenabil să afișați aceste caracteristici pe tablouri de bord.

Toată lumea știe ce sunt tablourile de bord. Acesta este momentul în care ați aruncat o privire la ecranul pe care sunt rezumate informațiile necesare. Și puteți determina imediat dacă există sau nu o problemă în baza de date.
În consecință, disponibilitatea bazei de date și a altor caracteristici cheie ar trebui să fie întotdeauna afișate pe tablouri de bord, astfel încât aceste informații să fie la îndemână și întotdeauna la dispoziție. Câteva detalii suplimentare care ajută deja la investigarea incidentelor, atunci când investighăm unele situații de urgență, acestea trebuie deja plasate pe tablouri de bord secundare, sau ascunse în link-uri de drilldown care duc la sisteme de monitorizare terțe.

Un exemplu de sistem de monitorizare bine-cunoscut. Acesta este un sistem de monitorizare foarte cool. Ea colectează o mulțime de date, dar din punctul meu de vedere, are un concept ciudat de tablouri de bord. Există un link pentru „crearea unui tablou de bord”. Dar când creați un tablou de bord, creați o listă de două coloane, o listă de grafice. Și când trebuie să te uiți la ceva, începi să dai clic cu mouse-ul, să defilezi, să cauți graficul dorit. Și acest lucru necesită timp, adică nu există tablouri de bord ca atare. Există doar liste de diagrame.

Ce ar trebui să adăugați la aceste tablouri de bord? Puteți începe cu o caracteristică precum timpul de răspuns. PostgreSQL are vizualizarea pg_stat_statements. Este dezactivat implicit, dar este una dintre vederile importante ale sistemului care ar trebui să fie întotdeauna activată și utilizată. Acesta stochează informații despre toate interogările care rulează care au fost executate în baza de date.

În consecință, putem pleca de la faptul că putem lua timpul total de execuție al tuturor solicitărilor și îl putem împărți la numărul de solicitări folosind câmpurile de mai sus. Dar aceasta este temperatura medie din spital. Putem începe de la alte câmpuri - timp minim de execuție a interogării, maxim și median. Și putem chiar să construim percentile PostgreSQL are funcții corespunzătoare pentru aceasta. Și putem obține câteva numere care caracterizează timpul de răspuns al bazei noastre de date pentru cererile deja finalizate, adică nu executăm cererea falsă „select 1” și ne uităm la timpul de răspuns, ci analizăm timpul de răspuns pentru cererile deja finalizate și desenăm fie o figură separată, fie construim un grafic pe baza ei.

De asemenea, este important să monitorizați numărul de erori care sunt generate în prezent de sistem. Și pentru aceasta puteți folosi vizualizarea pg_stat_database. Ne concentrăm pe câmpul xact_rollback. Acest câmp arată nu numai numărul de rollback-uri care apar în baza de date, dar ia în considerare și numărul de erori. Relativ vorbind, putem afișa această cifră în tabloul de bord și să vedem câte erori avem în prezent. Dacă există o mulțime de erori, atunci acesta este un motiv bun pentru a căuta în jurnalele și a vedea ce fel de erori sunt și de ce apar, apoi investiți și rezolvați-le.

Puteți adăuga așa ceva ca un tahometru. Acestea sunt numărul de tranzacții pe secundă și numărul de solicitări pe secundă. Relativ vorbind, puteți utiliza aceste numere ca performanță curentă a bazei de date și puteți observa dacă există vârfuri în cereri, vârfuri în tranzacții sau, dimpotrivă, dacă baza de date este subîncărcată deoarece un backend a eșuat. Este important să ne uităm întotdeauna la această cifră și să ne amintim că pentru proiectul nostru acest tip de performanță este normal, dar valorile de mai sus și de mai jos sunt deja un fel de problematice și de neînțeles, ceea ce înseamnă că trebuie să ne uităm de ce sunt aceste numere. atât de sus.

Pentru a estima numărul de tranzacții, ne putem referi din nou la vizualizarea pg_stat_database. Putem adăuga numărul de comiteri și numărul de rollback și obținem numărul de tranzacții pe secundă.

Înțelege toată lumea că într-o singură tranzacție se pot încadra mai multe cereri? Prin urmare, TPS și QPS sunt ușor diferite.

Numărul de cereri pe secundă poate fi obținut din pg_stat_statements și pur și simplu calculați suma tuturor solicitărilor finalizate. Este clar că comparăm valoarea curentă cu cea anterioară, o scădem, obținem delta și obținem cantitatea.

Puteți adăuga valori suplimentare, dacă doriți, care ajută, de asemenea, la evaluarea disponibilității bazei de date și la monitorizarea dacă a existat vreo perioadă de nefuncționare.

Una dintre aceste valori este timpul de funcționare. Dar timpul de funcționare în PostgreSQL este puțin complicat. Îți voi spune de ce. Când PostgreSQL a pornit, timpul de funcționare începe să raporteze. Dar dacă la un moment dat, de exemplu, o sarcină rula noaptea, a venit un ucigaș OOM și a încheiat forțat procesul copil PostgreSQL, atunci în acest caz PostgreSQL încheie conexiunea tuturor clienților, resetează zona de memorie fragmentată și începe recuperarea de la ultimul punct de control. Și cât timp durează această recuperare de la punctul de control, baza de date nu acceptă conexiuni, adică această situație poate fi evaluată ca timp de nefuncționare. Dar contorul de timp de funcționare nu va fi resetat, deoarece ia în considerare timpul de pornire postmaster din primul moment. Prin urmare, astfel de situații pot fi omise.

De asemenea, ar trebui să monitorizați numărul de lucrători în vid. Știe toată lumea ce este autovacuum în PostgreSQL? Acesta este un subsistem interesant în PostgreSQL. S-au scris multe articole despre ea, s-au făcut multe relatări. Există o mulțime de discuții despre vid și cum ar trebui să funcționeze. Mulți îl consideră un rău necesar. Dar așa este. Acesta este un fel de analog al unui colector de gunoi care curăță versiunile învechite ale rândurilor care nu sunt necesare pentru nicio tranzacție și eliberează spațiu în tabele și indici pentru rânduri noi.

De ce trebuie să-l monitorizezi? Pentru că uneori vidul doare foarte mult. Consumă o cantitate mare de resurse și cererile clienților încep să sufere ca urmare.

Și ar trebui monitorizat prin vizualizarea pg_stat_activity, despre care voi vorbi în secțiunea următoare. Această vizualizare arată activitatea curentă din baza de date. Și prin această activitate putem urmări numărul de aspiratoare care funcționează chiar acum. Putem urmări vacuumurile și să vedem că, dacă am depășit limita, atunci acesta este un motiv pentru a ne uita la setările PostgreSQL și a optimiza cumva funcționarea vacuumului.

Un alt lucru despre PostgreSQL este că PostgreSQL este foarte sătul de tranzacții lungi. Mai ales din tranzacții care stau mult timp și nu fac nimic. Aceasta este așa-numita stat idle-in-tranzacție. O astfel de tranzacție deține încuietori și împiedică funcționarea vidului. Și ca urmare, mesele se umflă și cresc în dimensiune. Iar interogările care funcționează cu aceste tabele încep să funcționeze mai lent, deoarece trebuie să treci cu lopata toate versiunile vechi de rânduri din memorie pe disc și înapoi. Prin urmare, trebuie monitorizate și timpul, durata celor mai lungi tranzacții, cele mai lungi cereri de vid. Și dacă vedem unele procese care rulează de foarte mult timp, deja mai mult de 10-20-30 de minute pentru o încărcare OLTP, atunci trebuie să le acordăm atenție și să le încheiem cu forță sau să optimizăm aplicația astfel încât să nu sunt chemați și nu stau atât de mult timp. Pentru o sarcină analitică, 10-20-30 de minute sunt și altele mai lungi.

În continuare avem opțiunea cu clienții conectați. Când am creat deja un tablou de bord și am postat valori cheie de disponibilitate pe acesta, putem adăuga și informații suplimentare despre clienții conectați acolo.

Informațiile despre clienții conectați sunt importante deoarece, din perspectiva PostgreSQL, clienții sunt diferiți. Sunt clienți buni și clienți răi.

Un exemplu simplu. După client, înțeleg aplicația. Aplicația s-a conectat la baza de date și imediat începe să-și trimită cererile acolo, baza de date le procesează și le execută și returnează rezultatele clientului. Aceștia sunt clienți buni și corecti.

Sunt situații în care clientul s-a conectat, el ține conexiunea, dar nu face nimic. Este în stare de repaus.

Dar există clienți răi. De exemplu, același client s-a conectat, a deschis o tranzacție, a făcut ceva în baza de date și apoi a intrat în cod, de exemplu, pentru a accesa o sursă externă sau pentru a procesa datele primite acolo. Dar nu a încheiat tranzacția. Și tranzacția se blochează în baza de date și este ținută într-un lacăt pe linie. Aceasta este o stare proastă. Și dacă dintr-o dată o aplicație undeva în interiorul ei eșuează cu o excepție, atunci tranzacția poate rămâne deschisă pentru o perioadă foarte lungă de timp. Și acest lucru afectează direct performanța PostgreSQL. PostgreSQL va fi mai lent. Prin urmare, este important să urmăriți astfel de clienți în timp util și să le încetați cu forță munca. Și trebuie să vă optimizați aplicația, astfel încât astfel de situații să nu apară.

Alți clienți răi sunt clienți în așteptare. Dar devin rele din cauza circumstanțelor. De exemplu, o simplă tranzacție inactivă: poate deschide o tranzacție, poate lua blocuri pe unele linii, apoi undeva în cod va eșua, lăsând o tranzacție suspendată. Un alt client va veni și va cere aceleași date, dar va întâlni o blocare, deoarece tranzacția suspendată deține deja blocaje pe unele rânduri necesare. Iar a doua tranzacție va rămâne în așteptare ca prima tranzacție să se finalizeze sau să o închidă forțat de către administrator. Prin urmare, tranzacțiile în așteptare se pot acumula și umple limita de conexiune la baza de date. Și când limita este plină, aplicația nu mai poate funcționa cu baza de date. Aceasta este deja o situație de urgență pentru proiect. Prin urmare, clienții răi trebuie urmăriți și la care se răspunde în timp util.

Un alt exemplu de monitorizare. Și există deja un tablou de bord decent aici. Există informații despre conexiuni de mai sus. Conexiune DB – 8 bucăți. Și e tot. Nu avem informații despre care clienți sunt activi, care sunt doar inactivi, fără a face nimic. Nu există informații despre tranzacțiile în așteptare și conexiunile în așteptare, adică aceasta este o cifră care arată numărul de conexiuni și atât. Și apoi ghiciți singur.

În consecință, pentru a adăuga aceste informații la monitorizare, trebuie să accesați vizualizarea sistemului pg_stat_activity. Dacă petreci mult timp în PostgreSQL, atunci aceasta este o vizualizare foarte bună care ar trebui să devină prietenul tău, deoarece arată activitatea curentă în PostgreSQL, adică ceea ce se întâmplă în ea. Pentru fiecare proces există o linie separată care arată informații despre acest proces: de la ce gazdă a fost realizată conexiunea, sub ce utilizator, sub ce nume, când a început tranzacția, ce cerere rulează în prezent, ce cerere a fost executată ultima dată. Și, în consecință, putem evalua starea clientului folosind câmpul statistic. Relativ vorbind, putem grupa după acest câmp și obține acele statistici care sunt în prezent în baza de date și numărul de conexiuni care au această statistică în baza de date. Și putem trimite numerele deja primite către monitorizarea noastră și putem desena grafice pe baza acestora.
De asemenea, este important să se evalueze durata tranzacției. Am spus deja că este important să evaluăm durata vidurilor, dar tranzacțiile sunt evaluate în același mod. Există câmpuri xact_start și query_start. Ele, relativ vorbind, arată ora de începere a tranzacției și ora de începere a cererii. Luăm funcția now(), care arată marca temporală curentă, și scadem marca temporală a tranzacției și a cererii. Și obținem durata tranzacției, durata cererii.

Dacă vedem tranzacții lungi, ar trebui să le finalizam deja. Pentru o încărcare OLTP, tranzacțiile lungi sunt deja mai mari de 1-2-3 minute. Pentru o sarcină de lucru OLAP, tranzacțiile lungi sunt normale, dar dacă durează mai mult de două ore pentru a fi finalizate, atunci acesta este și un semn că avem o înclinare undeva.

Odată ce clienții s-au conectat la baza de date, încep să lucreze cu datele noastre. Ei accesează tabele, accesează indecși pentru a obține date din tabel. Și este important să evaluăm modul în care clienții interacționează cu aceste date.

Acest lucru este necesar pentru a ne evalua volumul de lucru și pentru a înțelege aproximativ care tabel sunt cele mai „fierbinte” pentru noi. De exemplu, acest lucru este necesar în situațiile în care dorim să plasăm mese „fierbinte” pe un fel de stocare SSD rapidă. De exemplu, unele tabele de arhivă pe care nu le-am folosit de mult timp pot fi mutate într-un fel de arhivă „rece”, pe unități SATA și lăsate să trăiască acolo, vor fi accesate după cum este necesar.

Acest lucru este util și pentru detectarea anomaliilor după orice lansare și implementare. Să presupunem că proiectul a lansat o funcție nouă. De exemplu, am adăugat o nouă funcționalitate pentru lucrul cu baza de date. Și dacă trasăm grafice de utilizare a tabelelor, putem detecta cu ușurință aceste anomalii pe aceste grafice. De exemplu, actualizați rafale sau ștergeți rafale. Va fi foarte vizibil.

De asemenea, puteți detecta anomalii în statisticile „plutitoare”. Ce înseamnă? PostgreSQL are un programator de interogări foarte puternic și foarte bun. Și dezvoltatorii dedică mult timp dezvoltării sale. Cum lucrează? Pentru a face planuri bune, PostgreSQL colectează statistici privind distribuția datelor în tabele la un anumit interval de timp și cu o anumită frecvență. Acestea sunt cele mai comune valori: numărul de valori unice, informații despre NULL în tabel, multe informații.

Pe baza acestor statistici, planificatorul construiește mai multe interogări, o selectează pe cea mai optimă și folosește acest plan de interogare pentru a executa interogarea în sine și pentru a returna date.

Și se întâmplă că statisticile „plutesc”. Datele de calitate și cantitate s-au schimbat cumva în tabel, dar statisticile nu au fost colectate. Iar planurile formate pot să nu fie optime. Și dacă planurile noastre se dovedesc a fi suboptime pe baza monitorizării colectate, pe baza tabelelor, vom putea vedea aceste anomalii. De exemplu, undeva datele s-au schimbat calitativ și în locul indexului a început să fie folosită o trecere secvențială prin tabel, adică. dacă o interogare trebuie să returneze doar 100 de rânduri (există o limită de 100), atunci se va efectua o căutare completă pentru această interogare. Și acest lucru are întotdeauna un efect foarte rău asupra performanței.

Și putem vedea acest lucru în monitorizare. Și uitați-vă deja la această interogare, rulați o explicație pentru ea, colectați statistici, construiți un nou index suplimentar. Și răspunde deja la această problemă. De aceea este important.

Un alt exemplu de monitorizare. Cred că mulți l-au recunoscut pentru că este foarte popular. Cine îl folosește în proiectele lor Prometeu? Cine folosește acest produs împreună cu Prometheus? Faptul este că în depozitul standard al acestei monitorizări există un tablou de bord pentru lucrul cu PostgreSQL - postgres_exporter Prometeu. Dar există un detaliu rău.

Există mai multe grafice. Și octeții sunt indicați ca unitate, adică există 5 grafice. Acestea sunt Inserarea datelor, Actualizarea datelor, Ștergerea datelor, Preluarea datelor și Returnarea datelor. Unitatea de măsură este de octeți. Dar lucrul este că statisticile din PostgreSQL returnează date în tuplu (rânduri). Și, în consecință, aceste grafice sunt o modalitate foarte bună de a-ți subestima volumul de lucru de mai multe ori, de zeci de ori, pentru că un tuplu nu este un octet, un tuplu este un șir, este mulți octeți și este întotdeauna de lungime variabilă. Adică, calcularea sarcinii de lucru în octeți folosind tupluri este o sarcină nerealistă sau foarte dificilă. Prin urmare, atunci când utilizați un tablou de bord sau o monitorizare încorporată, este întotdeauna important să înțelegeți că funcționează corect și vă returnează datele corect evaluate.

Cum să obțineți statistici despre aceste tabele? În acest scop, PostgreSQL are o anumită familie de vizualizări. Și perspectiva principală este pg_stat_user_tables. User_tables - aceasta înseamnă tabele create în numele utilizatorului. În schimb, există vederi de sistem care sunt folosite de PostgreSQL însuși. Și există un tabel rezumativ Alltables, care le include atât pe cele de sistem, cât și pe cele de utilizator. Puteți începe de la oricare dintre ele care vă place cel mai mult.

Folosind câmpurile de mai sus puteți estima numărul de inserări, actualizări și ștergeri. Exemplul unui tablou de bord pe care l-am folosit folosește aceste câmpuri pentru a evalua caracteristicile unei sarcini de lucru. Prin urmare, putem construi și pe ele. Dar merită să ne amintim că acestea sunt tupluri, nu octeți, așa că nu o putem face doar în octeți.

Pe baza acestor date, putem construi așa-numitele tabele TopN. De exemplu, Top-5, Top-10. Și puteți urmări acele mese fierbinți care sunt reciclate mai mult decât altele. De exemplu, 5 tabele „fierbinți” pentru inserare. Și folosind aceste tabele TopN ne evaluăm volumul de lucru și putem evalua exploziile de sarcină de lucru după orice lansări, actualizări și implementări.

De asemenea, este important să evaluăm dimensiunea tabelului, deoarece uneori dezvoltatorii lansează o nouă caracteristică, iar tabelele noastre încep să se umfle în dimensiunile lor mari, pentru că au decis să adauge o cantitate suplimentară de date, dar nu au prezis cum ar fi acest lucru. afectează dimensiunea bazei de date. Astfel de cazuri vin și ca surprize pentru noi.

Și acum o mică întrebare pentru tine. Ce întrebare apare când observați încărcarea serverului dumneavoastră de baze de date? Care este următoarea întrebare pe care o ai?

Dar de fapt întrebarea se pune după cum urmează. Ce solicitări provoacă încărcarea? Adică, nu este interesant să ne uităm la procesele care sunt cauzate de încărcare. Este clar că dacă gazda are o bază de date, atunci baza de date rulează acolo și este clar că doar bazele de date vor fi eliminate acolo. Dacă deschidem Top, vom vedea acolo o listă de procese în PostgreSQL care fac ceva. Nu va fi clar din partea de sus ce fac.

În consecință, trebuie să găsiți acele interogări care provoacă cea mai mare încărcare, deoarece interogările de reglare, de regulă, oferă mai mult profit decât reglarea PostgreSQL sau configurația sistemului de operare sau chiar reglarea hardware-ului. Conform estimării mele, aceasta este aproximativ 80-85-90%. Și asta se face mult mai repede. Este mai rapid să corectați o solicitare decât să corectați configurația, să programați o repornire, mai ales dacă baza de date nu poate fi repornită sau să adăugați hardware. Este mai ușor să rescrieți interogarea undeva sau să adăugați un index pentru a obține un rezultat mai bun din această interogare.

În consecință, este necesar să se monitorizeze cererile și caracterul adecvat al acestora. Să luăm un alt exemplu de monitorizare. Și aici pare să existe o monitorizare excelentă. Există informații despre replicare, există informații despre debit, blocare, utilizarea resurselor. Totul este în regulă, dar nu există informații despre solicitări. Nu este clar ce interogări rulează în baza noastră de date, cât timp rulează, câte dintre aceste interogări sunt. Trebuie să avem întotdeauna aceste informații în monitorizarea noastră.

Și pentru a obține aceste informații putem folosi modulul pg_stat_statements. Pe baza acestuia, puteți construi o varietate de grafice. De exemplu, puteți obține informații despre cele mai frecvente interogări, adică despre acele interogări care sunt executate cel mai des. Da, după implementări, este, de asemenea, foarte util să îl priviți și să înțelegeți dacă există o creștere a cererilor.

Puteți monitoriza cele mai lungi interogări, adică acele interogări care durează cel mai mult pentru a fi finalizate. Ele rulează pe procesor, consumă I/O. De asemenea, putem evalua acest lucru folosind câmpurile total_time, mean_time, blk_write_time și blk_read_time.

Putem evalua și monitoriza cele mai grele solicitări în ceea ce privește utilizarea resurselor, cele care citesc de pe disc, care funcționează cu memorie sau, dimpotrivă, creează un fel de încărcare de scriere.

Putem evalua cele mai generoase cereri. Acestea sunt interogările care returnează un număr mare de rânduri. De exemplu, aceasta ar putea fi o cerere în care au uitat să stabilească o limită. Și pur și simplu returnează întregul conținut al tabelului sau al interogării peste tabelele interogate.

De asemenea, puteți monitoriza interogările care utilizează fișiere temporare sau tabele temporare.

Și mai avem procese de fundal. Procesele de fundal sunt în primul rând puncte de control sau sunt numite și puncte de control, acestea sunt autovacuum și replicare.

Un alt exemplu de monitorizare. Există o filă Întreținere în stânga, accesați ea și sper să vedeți ceva util. Dar aici este doar timpul funcționării în vid și al colectării statisticilor, nimic mai mult. Acestea sunt informații foarte slabe, așa că trebuie să avem întotdeauna informații despre modul în care procesele de fundal funcționează în baza noastră de date și dacă există probleme din activitatea lor.

Când ne uităm la punctele de control, ar trebui să ne amintim că punctele de control șterg paginile murdare din zona de memorie fragmentată pe disc, apoi creează un punct de control. Și acest punct de control poate fi apoi folosit ca loc de recuperare dacă PostgreSQL a fost oprit brusc în caz de urgență.

În consecință, pentru a șterge toate paginile „murdare” pe disc, trebuie să scrieți o anumită cantitate. Și, de regulă, pe sistemele cu cantități mari de memorie, acest lucru este mult. Și dacă facem puncte de control foarte des într-un interval scurt, atunci performanța discului va scădea foarte semnificativ. Iar cererile clienților vor avea de suferit din cauza lipsei de resurse. Vor concura pentru resurse și vor lipsi de productivitate.

În consecință, prin pg_stat_bgwriter folosind câmpurile specificate putem monitoriza numărul de puncte de control care apar. Și dacă avem o mulțime de puncte de control într-o anumită perioadă de timp (în 10-15-20 de minute, într-o jumătate de oră), de exemplu, 3-4-5, atunci aceasta poate fi deja o problemă. Și deja trebuie să te uiți în baza de date, să te uiți în configurație, ceea ce provoacă o asemenea abundență de puncte de control. Poate că are loc un fel de mare înregistrare. Putem evalua deja volumul de lucru, deoarece am adăugat deja grafice ale volumului de lucru. Putem deja să modificăm parametrii punctului de control și să ne asigurăm că aceștia nu afectează foarte mult performanța interogării.

Mă întorc din nou la autovacuum pentru că este un astfel de lucru, așa cum am spus, care poate adăuga cu ușurință atât performanța discului, cât și a interogării, așa că este întotdeauna important să estimăm cantitatea de autovacuum.

Numărul de lucrători cu autovacuum din baza de date este limitat. În mod implicit, există trei dintre ele, așa că dacă avem întotdeauna trei lucrători care lucrează în baza de date, aceasta înseamnă că autovacuum-ul nostru nu este configurat, trebuie să creștem limitele, să revizuim setările de autovacuum și să intrăm în configurație.
Este important să evaluăm ce lucrători în vid avem. Fie a fost lansat de la utilizator, a venit DBA și a lansat manual un fel de vid, iar asta a creat o încărcare. Avem un fel de problemă. Sau acesta este numărul de viduri care deșurubează contorul de tranzacții. Pentru unele versiuni de PostgreSQL acestea sunt aspiratoare foarte grele. Și pot adăuga cu ușurință performanța deoarece citesc întregul tabel, scanează toate blocurile din acel tabel.

Și, desigur, durata vidurilor. Dacă avem aspiratoare de lungă durată care funcționează pentru o perioadă foarte lungă de timp, atunci aceasta înseamnă că trebuie să acordăm din nou atenție configurației vacuumului și poate să-i reconsiderăm setările. Pentru că poate apărea o situație când aspiratorul funcționează pe masă mult timp (3-4 ore), dar în timpul în care a funcționat aspiratorul, o cantitate mare de rânduri moarte au reușit să se acumuleze din nou în masă. Și de îndată ce vidul este finalizat, trebuie să aspire din nou această masă. Și ajungem la o situație - un vid nesfârșit. Și în acest caz, vidul nu își face treaba, iar tabelele încep să se umfle treptat în dimensiune, deși volumul de date utile din el rămâne același. Prin urmare, în timpul vidurilor lungi, ne uităm mereu la configurație și încercăm să o optimizăm, dar în același timp pentru ca performanța solicitărilor clienților să nu aibă de suferit.

În zilele noastre practic nu există nicio instalare PostgreSQL care să nu aibă replicare în flux. Replicarea este procesul de mutare a datelor de la un master la o replică.

Replicarea în PostgreSQL se face printr-un jurnal de tranzacții. Expertul generează un jurnal de tranzacții. Jurnalul de tranzacții se deplasează prin conexiunea de rețea către replică, apoi este reprodus pe replică. E simplu.

În consecință, vizualizarea pg_stat_replication este utilizată pentru a monitoriza decalajul de replicare. Dar nu totul este simplu cu ea. În versiunea 10, vizualizarea a suferit mai multe modificări. În primul rând, unele câmpuri au fost redenumite. Și unele câmpuri au fost adăugate. În versiunea 10 au apărut câmpuri care vă permit să estimați întârzierea de replicare în secunde. Este foarte confortabil. Înainte de versiunea 10, era posibil să se estimeze decalajul de replicare în octeți. Această opțiune rămâne în versiunea 10, adică puteți alege ce este mai convenabil pentru dvs. - estimați decalajul în octeți sau estimați decalajul în secunde. Mulți oameni le fac pe amândouă.

Dar, cu toate acestea, pentru a evalua decalajul de replicare, trebuie să cunoașteți poziția jurnalului în tranzacție. Și aceste poziții ale jurnalului de tranzacții sunt exact în vizualizarea pg_stat_replication. Relativ vorbind, putem lua două puncte în jurnalul de tranzacții folosind funcția pg_xlog_location_diff(). Calculați delta dintre ele și obțineți decalajul de replicare în octeți. Este foarte comod și simplu.

În versiunea 10, această funcție a fost redenumită în pg_wal_lsn_diff(). În general, în toate funcțiile, vizualizările și utilitățile în care a apărut cuvântul „xlog”, acesta a fost înlocuit cu valoarea „wal”. Acest lucru se aplică atât vizualizărilor, cât și funcțiilor. Aceasta este o astfel de inovație.

În plus, în versiunea 10, au fost adăugate linii care arată în mod specific decalajul. Acestea sunt întârziere de scriere, întârziere de culoare, întârziere de reluare. Adică este important să monitorizezi aceste lucruri. Dacă vedem că avem un decalaj de replicare, atunci trebuie să investigăm de ce a apărut, de unde a venit și să remediem problema.

Aproape totul este în ordine cu valorile sistemului. Când începe orice monitorizare, aceasta începe cu valorile sistemului. Aceasta este eliminarea procesoarelor, memoriei, swap-ului, rețelei și discului. Cu toate acestea, mulți parametri nu există în mod implicit.

Dacă totul este în ordine cu procesul de reciclare, atunci există probleme cu reciclarea discurilor. De regulă, dezvoltatorii de monitorizare adaugă informații despre debit. Poate fi în iops sau octeți. Dar ei uită de latența și utilizarea dispozitivelor de disc. Aceștia sunt parametrii mai importanți care ne permit să evaluăm cât de încărcate sunt discurile noastre și cât de lente sunt. Dacă avem o latență mare, atunci asta înseamnă că există unele probleme cu discurile. Dacă avem o utilizare ridicată, înseamnă că discurile nu fac față. Acestea sunt caracteristici mai bune decât debitul.

Mai mult, aceste statistici pot fi obținute și din sistemul de fișiere /proc, așa cum se face pentru procesoarele de reciclare. Nu știu de ce aceste informații nu sunt adăugate la monitorizare. Dar, cu toate acestea, este important să aveți acest lucru în monitorizarea dvs.

Același lucru este valabil și pentru interfețele de rețea. Există informații despre debitul rețelei în pachete, în octeți, dar cu toate acestea nu există informații despre latență și nicio informație despre utilizare, deși aceasta este și informație utilă.

Orice monitorizare are dezavantaje. Și indiferent de ce fel de monitorizare veți efectua, nu va îndeplini întotdeauna anumite criterii. Dar, cu toate acestea, se dezvoltă, se adaugă noi funcții și lucruri noi, așa că alegeți ceva și terminați-l.

Și pentru a termina, trebuie să aveți întotdeauna o idee despre ce înseamnă statisticile furnizate și cum le puteți folosi pentru a rezolva probleme.

Și câteva puncte cheie:

• Ar trebui să monitorizați întotdeauna disponibilitatea și să aveți tablouri de bord, astfel încât să puteți evalua rapid că totul este în ordine cu baza de date.
• Întotdeauna trebuie să aveți o idee despre ce clienți lucrează cu baza de date pentru a elimina clienții răi și a-i doborî.
• Este important să evaluăm modul în care acești clienți lucrează cu datele. Trebuie să aveți o idee despre volumul de muncă.
• Este important să evaluăm modul în care se formează acest volum de muncă, cu ajutorul ce interogări. Puteți evalua interogări, puteți să le optimizați, să le refactorizați, să construiți indici pentru ele. Este foarte important.
• Procesele de fundal pot avea un impact negativ asupra cererilor clienților, așa că este important să monitorizați dacă aceștia nu folosesc prea multe resurse.
• Valorile de sistem vă permit să faceți planuri pentru scalarea și creșterea capacității serverelor dvs., așa că este important să le urmăriți și să le evaluați.

Dacă ești interesat de acest subiect, atunci poți urma aceste link-uri.
http://bit.do/stats_collector - aceasta este documentație oficială de la colectorul de statistici. Există o descriere a tuturor vizualizărilor statistice și o descriere a tuturor câmpurilor. Le puteți citi, înțelege și analiza. Și pe baza lor, construiește-ți graficele și adaugă-le la monitorizarea ta.

Solicitați exemple:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Acesta este depozitul nostru corporativ și al meu. Acestea conțin exemple de interogări. Nu există interogări din selecția* din seria de acolo. Există deja interogări gata făcute cu îmbinări, folosind funcții interesante care vă permit să transformați numerele brute în valori lizibile, convenabile, adică acestea sunt octeți, timp. Puteți să le ridicați, să le priviți, să le analizați, să le adăugați la monitorizarea dvs., să vă construiți monitorizarea pe baza lor.

întrebări

Întrebare: Ați spus că nu veți face publicitate mărcilor, dar sunt încă curioasă - ce fel de tablouri de bord folosiți în proiectele dvs.?
Răspuns: variază. Se întâmplă să venim la un client și acesta are deja propria lui monitorizare. Și sfătuim clientul cu privire la ceea ce trebuie adăugat la monitorizarea lor. Cea mai proastă situație este cu Zabbix. Pentru că nu are capacitatea de a construi grafice TopN. Noi înșine folosim Okmetru, pentru că ne-am consultat cu acești tipi în ceea ce privește monitorizarea. Ei au monitorizat PostgreSQL pe baza specificațiilor noastre tehnice. Îmi scriu propriul proiect pentru animale de companie, care colectează date prin Prometheus și le redă grafana. Sarcina mea este să îmi creez propriul exportator în Prometheus și apoi să reda totul în Grafana.

Întrebare: Există analogi ale rapoartelor AWR sau... agregare? Știi despre așa ceva?
Răspuns: Da, știu ce este AWR, este un lucru mișto. În acest moment există o varietate de biciclete care implementează aproximativ următorul model. La un anumit interval de timp, unele linii de bază sunt scrise în același PostgreSQL sau într-o stocare separată. Le poți căuta pe google pe internet, sunt acolo. Unul dintre dezvoltatorii unui astfel de lucru se află pe forumul sql.ru în firul PostgreSQL. Îl poți prinde acolo. Da, există astfel de lucruri, pot fi folosite. Plus în ea pgCenter De asemenea, scriu un lucru care îți permite să faci același lucru.

PS1 Dacă utilizați postgres_exporter, ce tablou de bord utilizați? Sunt mai multe dintre ele. Sunt deja învechite. Poate comunitatea va crea un șablon actualizat?

PS2 a fost eliminat pganalyze deoarece este o ofertă SaaS proprietară care se concentrează pe monitorizarea performanței și sugestiile de reglare automată.

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

Care monitorizare postgresql auto-găzduită (cu tablou de bord) o considerați cea mai bună?

• 30,0%Zabbix + adăugiri de la Alexey Lesovsky sau zabbix 4.4 sau libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze este un SaaS proprietar - nu îl pot șterge1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

Au votat 10 utilizatori. 26 utilizatori s-au abținut.

Sursa: www.habr.com