Grundlæggende om PostgreSQL-overvågning. Alexey Lesovsky

Jeg foreslår, at du læser udskriften af ​​rapporten af ​​Alexey Lesovsky fra Data Egret "Basics of PostgreSQL Monitoring"

I denne rapport vil Alexey Lesovsky fortælle om nøglepunkterne i postgres-statistikker, hvad de betyder, og hvorfor de bør inkluderes i overvågningen; om hvilke diagrammer der skal være i overvågning, hvordan man tilføjer dem og hvordan man tolker. Rapporten vil være nyttig for databaseadministratorer, systemadministratorer og udviklere, der er interesserede i Postgres fejlfinding.

Mit navn er Alexey Lesovsky, jeg repræsenterer Data Egret.

Et par ord om mig selv. Jeg startede for længe siden som systemadministrator.

Jeg administrerede alle mulige forskellige Linux, lavede forskellige ting relateret til Linux, dvs. virtualisering, overvågning, arbejdede med proxyer osv. Men på et tidspunkt blev jeg mere involveret i databaser, PostgreSQL. Jeg kunne virkelig godt lide ham. Og på et tidspunkt begyndte jeg at beskæftige mig med PostgreSQL det meste af min arbejdstid. Og så efterhånden blev jeg en PostgreSQL DBA.

Og gennem hele min karriere har jeg altid været interesseret i emnerne statistik, overvågning, telemetri. Og da jeg var systemadministrator, arbejdede jeg meget hårdt på Zabbix. Og skrev et lille sæt scripts som f.eks zabbix-udvidelser. Han var ret populær i sin tid. Og der var det muligt at overvåge meget forskellige vigtige ting, ikke kun Linux, men også forskellige komponenter.

Nu laver jeg allerede PostgreSQL. Jeg skriver allerede en anden ting, der giver dig mulighed for at arbejde med PostgreSQL-statistikker. Det kaldes pgCenter (artikel om Habré - Postgres stat uden nerver og spændinger).

En lille introduktion. Hvad er situationen med vores kunder, med vores kunder? Der er en form for ulykke forbundet med databasen. Og når databasen allerede er gendannet, kommer afdelingslederen eller udviklingschefen og siger: "Venner, vi bør overvåge databasen, for der er sket noget slemt, og det er nødvendigt, at det ikke sker i fremtiden." Og her starter den interessante proces med at vælge et overvågningssystem eller tilpasse et eksisterende overvågningssystem, så du kan overvåge din database - PostgreSQL, MySQL eller nogle andre. Og kollegerne begynder at byde ind: ”Jeg har hørt, at der findes sådan en database. Lad os bruge det." Kolleger begynder at skændes med hinanden. Og i sidste ende viser det sig, at vi vælger en form for database, men PostgreSQL-overvågning er ret dårligt repræsenteret i den, og vi skal altid gøre noget færdigt. Tag nogle repositories fra GitHub, klon dem, tilpas scripts, juster dem på en eller anden måde. Og i sidste ende falder det ud i en form for manuelt arbejde.

Derfor vil jeg i denne rapport forsøge at give dig lidt viden om, hvordan du vælger overvågning ikke kun til PostgreSQL, men også til databasen. Og for at give den viden, der gør, at du kan afslutte din overvågning for at få noget udbytte af den, så du med fordel kan overvåge din database for at forhindre eventuelle kommende nødsituationer, der kan opstå i tide.

Og de ideer, der vil være i denne rapport, de kan tilpasses direkte til enhver database, det være sig en DBMS eller noSQL. Derfor er det ikke kun PostgreSQL her, men der vil være mange opskrifter på hvordan man gør dette i PostgreSQL. Der vil være eksempler på forespørgsler, eksempler på entiteter som PostgreSQL har til overvågning. Og hvis dit DBMS har de samme ting, som giver dig mulighed for at sætte dem i overvågning, kan du også tilpasse dem, tilføje dem, og det vil være fint.

Jeg vil ikke anmelde
tale om, hvordan man leverer og gemmer metrics. Jeg vil ikke sige noget om efterbehandling af data og udlevering til brugeren. Og jeg vil ikke sige noget om alarmering.
Men i løbet af historien vil jeg vise forskellige skærmbilleder af eksisterende overvågninger, på en eller anden måde vil jeg kritisere dem. Ikke desto mindre vil jeg forsøge ikke at navngive mærker for ikke at skabe reklame eller anti-reklame for disse produkter. Derfor er alle tilfældigheder tilfældige og forbliver på din fantasi.

Lad os først forstå, hvad overvågning er. Overvågning er en meget vigtig ting at have. Alle forstår dette. Men samtidig er overvågning ikke relateret til et erhvervsprodukt og påvirker ikke direkte virksomhedens overskud, så overvågningen gives altid tid på restbasis. Hvis vi har tid, så er vi i gang med overvågning, hvis der ikke er tid, så OK, vi lægger det i efterslæbet og en dag vender vi tilbage til disse opgaver.

Derfor, fra vores praksis, når vi kommer til kunder, er overvågning ofte underudviklet og har ikke nogle interessante ting, der ville hjælpe os med at gøre et bedre stykke arbejde med databasen. Og derfor skal overvågningen altid være færdig.

Databaser er så komplekse ting, at du også skal overvåge, fordi databaser er et lager af information. Og informationen er meget vigtig for virksomheden, den kan ikke gå tabt på nogen måde. Men samtidig er databaser meget komplekse stykker software. De består af mange komponenter. Og mange af disse komponenter skal overvåges.

Hvis vi taler specifikt om PostgreSQL, så kan det repræsenteres som et sådant skema, der består af et stort antal komponenter. Disse komponenter interagerer med hinanden. Og samtidig har PostgreSQL det såkaldte Stats Collector-undersystem, som giver dig mulighed for at indsamle statistik om driften af ​​disse undersystemer og give en grænseflade til administratoren eller brugeren, så denne kan se disse statistikker.

Denne statistik præsenteres i form af et sæt funktioner og visninger (visning). De kan også kaldes borde. Det vil sige, at du ved at bruge en almindelig psql-klient kan oprette forbindelse til databasen, vælge disse funktioner og visninger og få nogle specifikke tal om driften af ​​PostgreSQL-undersystemer.

Du kan tilføje disse tal til dit foretrukne overvågningssystem, tegne grafer, tilføje funktioner og få analyser i det lange løb.

Men i denne rapport vil jeg ikke dække alle disse funktioner uden undtagelse, for det kan tage en hel dag. Jeg vil bogstaveligt talt henvise til to, tre eller fire ting, og jeg vil fortælle dig, hvordan de hjælper med at gøre overvågningen bedre.

Og hvis vi taler om overvågning af databasen, hvad skal så overvåges? Først og fremmest skal vi overvåge tilgængelighed, fordi databasen er en tjeneste, der giver adgang til data til kunder, og vi skal overvåge tilgængelighed og også levere nogle af dens kvalitative og kvantitative karakteristika.

Vi skal også overvåge de klienter, der forbinder til vores database, fordi de kan være både normale klienter og skadelige klienter, der kan skade databasen. De skal også overvåges og spores.

Når klienter opretter forbindelse til databasen, er det tydeligt, at de begynder at arbejde med vores data, så vi skal overvåge, hvordan klienter arbejder med data: med hvilke tabeller, i mindre grad med hvilke indekser. Det vil sige, at vi skal evaluere den arbejdsbyrde, der skabes af vores kunder.

Men arbejdsbyrden består naturligvis også af forespørgsler. Applikationer forbinder til databasen, får adgang til data ved hjælp af forespørgsler, så det er vigtigt at evaluere, hvilke forespørgsler vi har i databasen, overvåge deres tilstrækkelighed, at de ikke er skævt skrevet, at nogle muligheder skal omskrives og laves, så de virker hurtigere og med bedre ydeevne.

Og da vi taler om databasen, er databasen altid baggrundsprocesser. Baggrundsprocesser holder databasens ydeevne på et godt niveau, så de kræver en vis mængde ressourcer for sig selv at køre. Og samtidig kan de overlappe med klientanmodningsressourcer, så det grådige arbejde med baggrundsprocesser kan direkte påvirke udførelsen af ​​klientanmodninger. Derfor skal de også overvåges og spores, så der ikke opstår forvrængninger i forhold til baggrundsprocesser.

Og det er alt hvad angår databaseovervågning forbliver i systemmetrikken. Men i betragtning af, at for det meste hele vores infrastruktur går til skyerne, forsvinder systemmålingerne for en individuel vært altid i baggrunden. Men i databaser er de stadig relevante, og det er selvfølgelig også nødvendigt at overvåge systemmålinger.

Med systemmetrikker er alt mere eller mindre fint, alle moderne overvågningssystemer understøtter allerede disse metrikker, men generelt er nogle komponenter stadig ikke nok, og nogle ting skal tilføjes. Dem vil jeg også komme ind på, flere slides vil handle om dem.

Planens første punkt er tilgængelighed. Hvad er tilgængelighed? Tilgængelighed efter min forståelse er basens evne til at betjene forbindelser, det vil sige, at basen hæves, den som en service accepterer forbindelser fra klienter. Og denne tilgængelighed kan vurderes ud fra nogle karakteristika. Disse egenskaber er meget praktiske at vise på dashboards.

Alle ved, hvad dashboards er. Det var her, du tog et blik på skærmen, som opsummerede de nødvendige oplysninger. Og du kan allerede med det samme afgøre, om der er et problem i databasen eller ej.
Derfor bør tilgængeligheden af ​​databasen og andre nøglekarakteristika altid placeres på dashboards, så disse oplysninger er lige ved hånden, altid med dig. Nogle yderligere detaljer, der allerede hjælper i undersøgelsen af ​​hændelser, i undersøgelsen af ​​nogle nødsituationer, de skal allerede placeres på sekundære dashboards eller skjules i detaljerede links, der fører til tredjeparts overvågningssystemer.

Et eksempel på et kendt overvågningssystem. Dette er et meget cool overvågningssystem. Den samler en masse data, men fra mit synspunkt har den et mærkeligt koncept med dashboards. Der er et link "Create Dashboard". Men når du opretter et dashboard, opretter du en to-kolonne liste, en liste over diagrammer. Og når du skal se på noget, begynder du at klikke, rulle, lede efter det ønskede diagram med musen. Og det tager tid, dvs. der er ingen dashboards som sådan. Der er kun lister over grafer.

Hvad skal føjes til disse dashboards? Du kan starte med en sådan karakteristik som responstid. PostgreSQL har visningen pg_stat_statements. Det er deaktiveret som standard, men det er en af ​​de vigtige systemvisninger, der altid bør aktiveres og bruges. Den gemmer information om alle kørende forespørgsler, der blev udført i databasen.

Derfor kan vi tage udgangspunkt i, at vi kan tage den samlede eksekveringstid for alle anmodninger og dividere med antallet af anmodninger ved hjælp af ovenstående felter. Men det er sådan en gennemsnitstemperatur på hospitalet. Vi kan bygge på andre felter - minimum forespørgsels eksekveringstid, maksimum og medianen. Og vi kan endda bygge percentiler, PostgreSQL har de tilsvarende funktioner til dette. Og vi kan få nogle tal, der karakteriserer responstiden i vores database for allerede gennemførte forespørgsler, dvs. vi udfører ikke den falske 'vælg 1'-forespørgsel og ser responstiden, men vi analyserer svartiden for allerede gennemførte forespørgsler og trækker enten en separat figur, eller vi bygger en graf ud fra den.

Det er også vigtigt at holde styr på antallet af fejl, som systemet i øjeblikket genererer. Og til dette kan du bruge pg_stat_database-visningen. Vi målretter mod xact_rollback-feltet. Dette felt viser ikke kun antallet af rollbacks, der sker i databasen, men tager også højde for antallet af fejl. Relativt set kan vi vise dette tal i vores dashboard og se, hvor mange fejl vi har i øjeblikket. Hvis der er mange fejl, så er det allerede en god grund til at kigge i loggene og se, hvad det er for fejl, og hvorfor de opstår, og så investere og løse dem.

Du kan tilføje sådan en ting som en omdrejningstæller. Disse er antallet af transaktioner pr. sekund og antallet af anmodninger pr. sekund. Relativt set kan du bruge disse tal som den aktuelle ydelse af din database og observere, om der er peaks i anmodninger, peaks i transaktioner, eller omvendt, databasen er underbelastet, fordi en form for backend faldt af. Det er vigtigt altid at se på denne figur og huske, at for vores projekt er en sådan præstation normal, og værdierne ovenfor og nedenfor er allerede en slags problematisk og uforståelig, hvilket betyder, at vi er nødt til at se på, hvorfor sådanne tal .

For at estimere antallet af transaktioner kan vi igen henvise til pg_stat_database-visningen. Vi kan tilføje antallet af commits og antallet af rollbacks for at få antallet af transaktioner pr. sekund.

Alle forstår, at flere anmodninger kan passe ind i en transaktion? Derfor er TPS og QPS lidt forskellige.

Antallet af forespørgsler pr. sekund kan fås fra pg_stat_statements og blot beregne summen af ​​alle udførte forespørgsler. Det er klart, at vi sammenligner den aktuelle værdi med den foregående, trækker fra, får deltaet, får beløbet.

Du kan tilføje yderligere metrics, hvis du ønsker det, som også hjælper med at vurdere tilgængeligheden af ​​vores database og spore, om der var nedetid.

En af disse målinger er oppetid. Men oppetid i PostgreSQL er lidt vanskelig. Jeg skal fortælle dig hvorfor. Når PostgreSQL starter op, begynder den at rapportere oppetid. Men hvis der på et tidspunkt, f.eks. en opgave kørte om natten, kom en OOM-morder og tvangsafbryde PostgreSQL børneprocessen, så afslutter PostgreSQL i dette tilfælde forbindelsen til alle klienter, nulstiller det shardede hukommelsesområde og starter gendannelse fra det sidste kontrolpunkt. Og mens denne gendannelse fra kontrolpunktet varer, accepterer databasen ikke forbindelser, det vil sige, at denne situation kan vurderes som nedetid. Men dette vil ikke nulstille oppetidstælleren, fordi den tager højde for det tidspunkt, hvor postmesteren blev startet fra det allerførste øjeblik. Derfor kan sådanne situationer springes over.

Du bør også overvåge antallet af vakuumarbejdere. Alle ved, hvad der er autovacuum i PostgreSQL? Dette er et interessant undersystem i PostgreSQL. Der er skrevet mange artikler om det, mange rapporter er blevet lavet. Masser af diskussion om vakuum, hvordan det skal fungere. Mange anser det for et nødvendigt onde. Men det er. Dette er en slags skraldopsamler, der rydder op i forældede versioner af rækker, der ikke er nødvendige for nogen af ​​transaktionerne, og frigør plads i tabeller og indekser til nye rækker.

Hvorfor skal det overvåges? Fordi vakuumet nogle gange gør meget ondt. Det bruger en stor mængde ressourcer, og klientanmodninger begynder at lide under dette.

Og det bør overvåges gennem pg_stat_activity-visningen, som jeg vil tale om i næste afsnit. Denne visning viser den aktuelle aktivitet i databasen. Og gennem denne aktivitet kan vi spore antallet af støvsugere, der virker lige nu. Vi kan overvåge vakuum og se, at hvis vi har overskredet grænsen, så er dette en anledning til at kigge nærmere på PostgreSQL-indstillingerne og på en eller anden måde optimere driften af ​​vakuumet.

Et andet træk ved PostgreSQL er, at PostgreSQL er meget træt af lange transaktioner. Især fra transaktioner, der hænger i lang tid og ikke gør noget. Disse er de såkaldte stat idle-in-transaction. En sådan transaktion holder låse, det forhindrer vakuumet i at virke. Og som et resultat - tabellerne svulmer, de øges i størrelse. Og forespørgsler, der fungerer med disse tabeller, de begynder at arbejde langsommere, fordi du skal skovle alle de gamle versioner af rækker fra hukommelse til disk og tilbage. Derfor skal tiden, varigheden af ​​de længste transaktioner, de længste vakuumanmodninger også overvåges. Og hvis vi ser nogle processer, der har kørt i meget lang tid, i mere end 10-20-30 minutter for en OLTP-belastning, så skal vi være opmærksomme på dem og tvinge dem til at afslutte, eller optimere applikationen, så de hedder ikke og hænger ikke så længe. For en analytisk belastning er 10-20-30 minutter normalt, der er også længere.

Dernæst har vi muligheden med tilsluttede klienter. Når vi allerede har dannet et dashboard og lagt vigtige tilgængelighedsmetrics på det, kan vi også tilføje yderligere oplysninger om tilsluttede klienter der.

Oplysningerne om tilsluttede klienter er vigtige, fordi der fra PostgreSQL's synspunkt er forskellige typer klienter. Der er gode kunder, og der er dårlige kunder.

Et simpelt eksempel. Med klient mener jeg applikationen. Applikationen har oprettet forbindelse til databasen og begynder straks at sende sine anmodninger dertil, databasen behandler og eksekverer dem og returnerer resultaterne til klienten. Det er gode og rigtige kunder.

Der er situationer, hvor klienten er forbundet, den bevarer forbindelsen, men gør ingenting. Den er i inaktiv tilstand.

Men der er dårlige kunder. For eksempel tilsluttede den samme klient sig, åbnede en transaktion, lavede noget i databasen og gik derefter ind i koden, for eksempel for at få adgang til en ekstern kilde eller for at behandle de modtagne data der. Men samtidig lukkede han ikke handlen. Og transaktionen hænger i databasen og holder låsen på linjen. Dette er en dårlig tilstand. Og hvis applikationen pludselig et sted inde i den falder af en undtagelse (undtagelse), så kan transaktionen forblive åben i meget lang tid. Og dette påvirker direkte ydeevnen af ​​PostgreSQL. PostgreSQL vil køre langsommere. Derfor er det vigtigt at spore sådanne kunder i tide og afslutte deres arbejde med magt. Og du skal optimere din applikation, så der ikke er sådanne situationer.

Andre dårlige kunder er ventende kunder. Men de bliver dårlige på grund af omstændighederne. For eksempel en simpel inaktiv transaktion: den kan åbne en transaktion, tage låse på nogle linjer, så falder den et sted i koden og efterlader en hængende transaktion. En anden klient vil komme, anmode om de samme data, men den vil støde på en lås, fordi den hængende transaktion allerede har låse på nogle nødvendige rækker. Og den anden transaktion vil hænge i forventning, når den første transaktion er gennemført, eller dens administrator tvangslukker den. Afventende transaktioner kan således akkumulere og overskride grænsen for databaseforbindelse. Og når grænsen er fuld, kan applikationen ikke længere arbejde med databasen. Dette er allerede en nødsituation for projektet. Derfor skal dårlige kunder spores og reageres rettidigt.

Endnu et eksempel på overvågning. Og her er et anstændigt dashboard. Der er oplysninger om forbindelser fra oven. DB tilslutning - 8 stk. Og det er det hele. Vi har ingen information om, hvilke klienter der er aktive, hvilke klienter der bare er inaktive og ikke gør noget. Der er ingen oplysninger om hængende transaktioner og afventende forbindelser, dvs. det er sådan en figur, der viser antallet af forbindelser, og det er det. Og så gæt selv.

For at tilføje disse oplysninger til overvågning skal du følgelig henvise til systemvisningen pg_stat_activity. Hvis du bruger meget tid i PostgreSQL, så er dette en meget god visning, der bør blive din ven, fordi den viser den aktuelle aktivitet i PostgreSQL, altså hvad der sker i den. Der er en separat linje for hver proces, der viser information om denne proces: fra hvilken vært forbindelsen blev oprettet, under hvilken bruger, under hvilket navn, hvornår transaktionen blev startet, hvilken anmodning, der i øjeblikket udføres, hvilken anmodning, der sidst blev udført. Og derfor kan vi evaluere klientens tilstand ved hjælp af stat-feltet. Relativt set kan vi gruppere efter dette felt og få de statistikker, der nu er i databasen, og antallet af forbindelser, der er med denne statistik i databasen. Og vi kan sende de allerede modtagne tal til vores overvågning og tegne grafer på dem.
Det er også vigtigt at vurdere varigheden af ​​transaktionen. Jeg har allerede sagt, at det er vigtigt at evaluere varigheden af ​​vakuum, men transaktioner evalueres også på samme måde. Der er felter xact_start og query_start. De viser relativt set starttidspunktet for transaktionen og starttidspunktet for anmodningen. Vi tager funktionen now(), som viser det aktuelle tidsstempel, og trækker transaktionen fra og anmoder om tidsstempler. Og vi får varigheden af ​​transaktionen, varigheden af ​​anmodningen.

Hvis vi ser lange transaktioner, bør vi allerede gennemføre dem. For en OLTP-belastning er lange transaktioner allerede mere end 1-2-3 minutter. For en OLAP-belastning er lange transaktioner normalt, men hvis de løber i mere end to timer, så er det også et tegn på, at vi har en skævhed et sted.

Når kunderne har tilsluttet sig databasen, begynder de at arbejde med vores data. De får adgang til tabeller, de får adgang til indekser for at få data fra en tabel. Og det er vigtigt at evaluere, hvordan kunderne arbejder med disse data.

Dette er nødvendigt for at kunne evaluere vores arbejdsbyrde og groft forstå, hvilke tabeller vi har de "hotteste". Dette er for eksempel nødvendigt i situationer, hvor vi ønsker at placere "varme" borde på en form for hurtig SSD-lagring. For eksempel kan nogle arkivtabeller, som vi ikke har brugt i lang tid, overføres til en form for "koldt" arkiv, til SATA-diske og lade dem leve der, de vil blive tilgået efter behov.

Det er også nyttigt til at opdage uregelmæssigheder efter eventuelle udgivelser og implementeringer. Lad os sige, at projektet udrullede nogle nye funktioner. For eksempel tilføjede vi ny funktionalitet til at arbejde med databasen. Og hvis vi bygger grafer til brug af tabeller, kan vi nemt opdage disse anomalier på disse grafer. Opdater f.eks. bursts eller slet bursts. Det vil være meget synligt.

Det er også muligt at opdage uregelmæssigheder i "flydende" statistikker. Hvad betyder det? PostgreSQL har en meget stærk og meget god query planner. Og udviklerne bruger meget tid på dets udvikling. Hvordan arbejder han? For at opbygge gode planer indsamler PostgreSQL statistik om fordelingen af ​​data i tabeller med et vist tidsinterval, med en vis periodicitet. Disse er de hyppigste værdier: antallet af unikke værdier, information om NULL i tabellen, en masse information.

Baseret på disse statistikker bygger planlæggeren flere forespørgsler, vælger den mest optimale og bruger denne forespørgselsplan til at udføre selve forespørgslen og returnere data.

Og det sker, at statistikken "flyder". Kvalitets- og mængdedataene ændrede sig på en eller anden måde i tabellen, men statistikken blev ikke indsamlet. Og de dannede planer er måske ikke optimale. Og hvis vores planer viser sig at være suboptimale i forhold til den overvågning, der indsamles, vil vi ifølge tabellerne kunne se disse anomalier. For eksempel et sted ændrede dataene sig kvalitativt, og i stedet for indekset begyndte man at bruge en sekventiel passage gennem tabellen, dvs. hvis forespørgslen kun skal returnere 100 rækker (der er en grænse på 100), vil en fuld opregning blive udført for denne forespørgsel. Og det har altid en meget dårlig effekt på ydeevnen.

Og vi kan se det i overvågningen. Og se allerede på denne forespørgsel, udfør forklaring for det, indsaml statistik, opbyg et nyt ekstra indeks. Og allerede reagere på dette problem. Derfor er det vigtigt.

Endnu et eksempel på overvågning. Jeg tror, ​​at mange mennesker genkender ham, fordi han er meget populær. Hvem bruger i deres projekter Prometheus? Og hvem bruger dette produkt sammen med Prometheus? Faktum er, at i standardlageret for denne overvågning er der et dashboard til at arbejde med PostgreSQL - postgres_eksportør Prometheus. Men der er en dårlig detalje her.

Der er flere diagrammer. Og bytes er angivet som enhed, dvs. der er 5 grafer. Disse er Indsæt data, Opdater data, Slet data, Hent data og Returner data. Bytes er angivet som enhedsdimensionen. Men faktum er, at statistik i PostgreSQL returnerer data i tuple (rækker). Og derfor er disse grafer en meget god måde at undervurdere din arbejdsbyrde flere gange, snesevis af gange, fordi en tupel ikke er en byte, en tuple er en streng, den er mange bytes, og den er altid af variabel længde. Det vil sige, at beregne arbejdsbyrden i bytes ved hjælp af tuples er en urealistisk eller meget vanskelig opgave. Når du bruger et dashboard eller indbygget overvågning, er det derfor altid vigtigt at forstå, at det fungerer korrekt og returnerer korrekt evaluerede data til dig.

Hvordan får man statistik på disse tabeller? For at gøre dette har PostgreSQL en familie af synspunkter. Og hovedsynet er pg_stat_user_tables. User_tables - dette betyder, at tabellerne er oprettet på vegne af brugeren. I modsætning hertil er der systemvisninger, som bruges af PostgreSQL selv. Og der er en oversigtstabel Alltables, som omfatter både system og bruger. Du kan starte fra enhver af dem, som du bedst kan lide.

Ovenstående felter kan bruges til at estimere antallet af indsættelser, opdateringer og sletninger. Det eksempel på dashboard, som jeg brugte, bruger disse felter til at evaluere arbejdsbyrdens egenskaber. Derfor kan vi også bygge videre på dem. Men det er værd at huske på, at disse er tuples, ikke bytes, så vi kan ikke tage det og lave det til bytes.

Ud fra disse data kan vi bygge de såkaldte TopN-tabeller. For eksempel Top-5, Top-10. Og du kan holde styr på de varme borde, der bliver brugt mere end andre. For eksempel 5 "varme" borde til indsættelse. Og ifølge disse TopN-tabeller evaluerer vi vores arbejdsbyrde og kan evaluere udbrud af arbejdsbyrde efter eventuelle udgivelser og opdateringer og implementeringer.

Det er også vigtigt at evaluere bordets størrelse, fordi nogle gange udvikler udviklere en ny funktion, og vores tabeller begynder at svulme op i deres store størrelser, fordi de besluttede at tilføje en ekstra mængde data, men ikke forudsagde, hvordan dette ville påvirke størrelsen af ​​databasen. Sådanne sager kommer også som overraskelser for os.

Og nu et lille spørgsmål til dig. Hvad er spørgsmålet, når du bemærker belastningen på databaseserveren? Hvad er dit næste spørgsmål?

Men det egentlige spørgsmål er følgende. Hvilke anmodninger forårsager belastningen? Det vil sige, at det ikke er interessant at se de processer, som belastningen forårsager. Det er klart, at hvis værten er med en database, så kører databasen der, og det er klart, at kun databaser vil blive bortskaffet der. Hvis vi åbner Top, vil vi se der en liste over PostgreSQL-processer, der gør noget. Fra toppen vil det ikke være klart, hvad de laver.

Derfor er du nødt til at finde de forespørgsler, der forårsager den største belastning, fordi forespørgselsjustering som regel giver mere overskud end PostgreSQL-konfiguration eller tuning af operativsystemer, eller endda hardwaretuning. Ifølge mit skøn er det omkring 80-85-90%. Og dette gøres meget hurtigere. Det er hurtigere at rette anmodningen end at rette konfigurationen, planlægge en genstart, især hvis databasen ikke kan genstartes, eller tilføje hardware. Det er nemmere at omskrive forespørgslen et sted eller tilføje et indeks for at få et bedre resultat af denne forespørgsel.

Det er derfor nødvendigt at overvåge anmodninger og deres tilstrækkelighed. Lad os tage et andet eksempel på overvågning. Og her ser det også ud til at være fremragende overvågning. Der er information om replikering, der er information om gennemløb, blokering, ressourceudnyttelse. Alt er fint, men der er ingen oplysninger om forespørgsler. Det er ikke klart, hvilke forespørgsler der kører i vores database, hvor længe de kører, hvor mange af disse forespørgsler. Vi skal altid have disse oplysninger i overvågningen.

Og for at få disse oplysninger kan vi bruge modulet pg_stat_statements. På dets grundlag kan du bygge en række forskellige grafikker. For eksempel kan du få information om de hyppigste forespørgsler, det vil sige om de forespørgsler, der udføres oftest. Ja, efter implementering er det også meget nyttigt at se på det og forstå, om der er nogen stigning i anmodninger.

Du kan overvåge de længste forespørgsler, dvs. de forespørgsler, der kører længst. De kører på processoren, de forbruger I/O. Vi kan også evaluere dette ved felterne total_time, mean_time, blk_write_time og blk_read_time.

Vi kan evaluere og overvåge de største anmodninger med hensyn til ressourceforbrug, dem der læser fra disk, dem der arbejder med hukommelse, eller tværtimod skabe en form for skrivebelastning.

Vi kan vurdere de mest generøse anmodninger. Det er de forespørgsler, der returnerer et stort antal rækker. Det kan for eksempel være en form for anmodning, hvor de har glemt at sætte en grænse. Og det returnerer bare hele indholdet af tabellen eller forespørgslen på de anmodede tabeller.

Og du kan også overvåge forespørgsler, der bruger midlertidige filer eller midlertidige tabeller.

Og vi har stadig baggrundsprocesser. Baggrundsprocesser er primært checkpoints eller de kaldes også checkpoints, disse er autovakuum og replikering.

Endnu et eksempel på overvågning. Der er fanen Vedligeholdelse til venstre, gå til den og håber at se noget nyttigt. Men her er det kun tidspunktet for vakuumet og indsamlingen af ​​statistikker, intet andet. Det er meget dårlig information, så du skal altid have information om, hvordan baggrundsprocesser fungerer i vores database, og om der er problemer med deres arbejde.

Når vi ser på checkpoints, skal det huskes, at vores checkpoints skyller "beskidte" sider fra det sønderdelte hukommelsesområde til disk, og derefter opretter et checkpoint. Og dette kontrolpunkt kan allerede bruges som et sted under genopretning, hvis PostgreSQL pludselig blev afsluttet i en nødsituation.

Derfor, for at skylle alle de "beskidte" sider til disken, skal du skrive en vis mængde. Og som regel er dette meget på systemer med en stor mængde hukommelse. Og hvis vi laver checkpoints meget ofte i et kort interval, så vil diskens ydeevne synke meget. Og kundernes anmodninger vil lide under mangel på ressourcer. De vil konkurrere om ressourcer og mangler produktivitet.

Derfor kan vi gennem pg_stat_bgwriter på de angivne felter overvåge antallet af checkpoints, der forekommer. Og hvis vi har mange kontrolpunkter i en vis periode (i 10-15-20 minutter, i en halv time), for eksempel 3-4-5, så kan dette allerede være et problem. Og du skal allerede se i databasen, se i konfigurationen, hvad der forårsager sådan en overflod af kontrolpunkter. Måske er der en stor rekord på vej. Vi kan allerede evaluere arbejdsbyrden, fordi vi allerede har tilføjet arbejdsbelastningsdiagrammer. Vi kan allerede justere breakpoint-parametrene og sikre, at de ikke i høj grad påvirker forespørgselsydelsen.

Jeg går tilbage til autovakuum igen, fordi det som sagt er den slags ting, der nemt kan tilføje både disk- og forespørgselsydelse, så det er altid vigtigt at måle mængden af ​​autovakuum.

Antallet af autovakuumarbejdere i databasen er begrænset. Som standard er der tre af dem, så hvis vi har tre arbejdere, der arbejder i databasen hele tiden, betyder det, at vores autovakuum er underkonfigureret, vi skal hæve grænserne, revidere autovakuumindstillingerne og allerede klatre ind i konfigurationen.
Det er vigtigt at vurdere, hvilke vakuumarbejdere der arbejder for os. Enten blev det lanceret fra brugeren, DBA kom ind og lancerede en form for vakuum med hænderne, og det skabte en belastning. Vi har et eller andet problem. Eller dette er antallet af støvsugere, der skruer transaktionstælleren af. For nogle versioner af PostgreSQL er disse meget tunge støvsugere. Og de kan nemt tilføje ydeevne, fordi de trækker hele tabellen fra og scanner alle blokkene i denne tabel.

Og selvfølgelig varigheden af ​​støvsugere. Hvis vi har lange støvsugere, der kører i meget lang tid, så betyder det, at vi igen skal være opmærksomme på konfigurationen af ​​støvsugeren og måske genoverveje dens indstillinger. Fordi der kan opstå en situation, når vakuumet arbejder på bordet i lang tid (3-4 timer), men i løbet af den tid, hvor vakuumet virkede, lykkedes det igen at samle sig en stor mængde døde rækker i bordet. Og så snart vakuumet er forbi, skal han støvsuge dette bord igen. Og vi kommer til en situation – et uendeligt vakuum. Og i dette tilfælde klarer vakuumet ikke sit arbejde, og tabellerne begynder gradvist at svulme i størrelse, selvom mængden af ​​nyttige data i det forbliver den samme. Derfor ser vi i lange vakuum altid på konfigurationen og forsøger at optimere den, men samtidig så udførelsen af ​​klientforespørgsler ikke lider.

Nu er der praktisk talt ingen PostgreSQL-installation, hvor der ikke var nogen streamingreplikering. Replikering er processen med at overføre data fra en master til en replika.

Replikering i PostgreSQL er arrangeret gennem en transaktionslog. Masteren genererer en transaktionslog. Transaktionsloggen på netværksforbindelsen går til replikaen, derefter gengives den på replikaen. Alt er enkelt.

Følgelig bruges pg_stat_replikeringsvisningen til at overvåge replikeringsforsinkelsen. Men det er ikke nemt for hende. I version 10 har visningen gennemgået flere ændringer. Først er nogle af felterne blevet omdøbt. Og nogle af felterne er tilføjet. I den 10. version dukkede felter op, der giver dig mulighed for at evaluere replikeringsforsinkelsen på få sekunder. Det er meget behageligt. Før version 10 var det muligt at estimere replikationsforsinkelsen i bytes. Denne funktion forblev i den 10. version, dvs. du kan vælge, hvad der er mere bekvemt for dig - evaluer forsinkelsen i bytes eller evaluer forsinkelsen i sekunder. Mange gør begge dele.

Men for at evaluere replikeringsforsinkelsen skal du kende loggens position i transaktionen. Og disse positioner i transaktionsloggen er kun i pg_stat_replikeringsvisningen. Relativt set kan vi bruge funktionen pg_xlog_location_diff() til at tage to punkter i transaktionsloggen. Beregn deltaet mellem dem og få replikationsforsinkelsen i bytes. Det er meget praktisk og enkelt.

I version 10 blev denne funktion omdøbt til pg_wal_lsn_diff(). Generelt, i alle funktioner, visninger, hjælpeprogrammer, hvor ordet "xlog" blev stødt på, blev det erstattet med værdien "wal". Dette er både i visninger og i funktioner. Dette er sådan en nyskabelse.

Plus, i den 10. version blev der tilføjet linjer, der specifikt viser forsinkelsen. Disse er skrivelag, flush lag, replay lag. Det vil sige, at det er vigtigt at overvåge disse ting. Hvis vi ser, at vi har en replikationsforsinkelse, så skal vi undersøge, hvorfor den dukkede op, hvor den kom fra og løse problemet.

Med systemmålinger er næsten alt i orden. Når enhver overvågning er født, starter den med systemmålinger. Dette er udnyttelsen af ​​processorer, hukommelse, swap, netværk og disk. Men ikke desto mindre er mange parametre der ikke som standard.

Hvis alt er i orden med bortskaffelsen af ​​processen, er der problemer med bortskaffelsen af ​​disken. Som regel tilføjer overvågningsudviklere båndbreddeoplysninger. Det kan være i iops eller bytes. Men de glemmer latens og diskenhedsudnyttelse. Disse er vigtigere parametre, der giver os mulighed for at evaluere, hvor indlæste vores diske er, og hvor meget de bremser. Hvis vi har høj latency, betyder det, at der er nogle problemer med diskene. Hvis vi har høj udnyttelse, så betyder det, at diskene ikke kan klare sig. Disse er mere kvalitative egenskaber end båndbredde.

Disse statistikker kan dog også hentes fra /proc-filsystemet, som det gøres for processorgenbrug. Hvorfor disse oplysninger ikke er tilføjet til overvågningen, ved jeg ikke. Men det er stadig vigtigt at have det med i din overvågning.

Det samme gælder for netværksgrænseflader. Der er information om netværksbåndbredde i pakker, i bytes, men ikke desto mindre er der ingen information om latens og ingen information om udnyttelse, selvom dette også er nyttig information.

Enhver overvågning har sine ulemper. Og uanset hvilken slags overvågning du tager, vil den altid ikke opfylde visse kriterier. Men ikke desto mindre udvikler de sig, nye funktioner tilføjes, nye ting, så vælg noget og gør det færdigt.

Og for at afslutte, skal du altid have en idé om, hvad den givne statistik betyder, og hvordan du kan løse problemer med den.

Og et par nøglepunkter:

• Du skal altid overvåge tilgængelighed, have dashboards, så du hurtigt kan vurdere, at alt er i orden med basen.
• Du skal altid have en ide om, hvilke kunder der arbejder med din database for at luge ud af dårlige kunder og skyde dem.
• Det er vigtigt at evaluere, hvordan disse klienter arbejder med data. Du skal have en idé om din arbejdsbyrde.
• Det er vigtigt at vurdere, hvordan denne arbejdsbyrde er dannet, ved hjælp af hvilke forespørgsler. Du kan evaluere forespørgsler, du kan optimere dem, refaktorisere dem, bygge indekser til dem. Det er meget vigtigt.
• Baggrundsprocesser kan påvirke klientanmodninger negativt, så det er vigtigt at sikre, at de ikke bruger for mange ressourcer.
• Systemmålinger giver dig mulighed for at lave planer for skalering, for at øge kapaciteten på dine servere, så det er vigtigt også at spore og evaluere dem.

Hvis du er interesseret i dette emne, så kan du følge disse links.
http://bit.do/stats_collector er den officielle dokumentation fra statistikindsamleren. Der er en beskrivelse af alle statistiske visninger og en beskrivelse af alle felter. Du kan læse, forstå og analysere dem. Og på grundlag af dem, byg dine egne diagrammer, føj til din overvågning.

Eksempler på anmodning:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Dette er vores virksomhedsdepot og mit eget. De har prøveanmodninger. Der er ingen forespørgsler fra udvalg* fra serien, noget der. Der er allerede færdige anmodninger med joinforbindelser, der bruger interessante funktioner, der giver dig mulighed for at lave læsbare, bekvemme værdier fra rå tal, det vil sige, disse er bytes, tid. Du kan vælge dem, se dem, analysere dem, tilføje dem til dine overvågninger, bygge dine egne overvågninger baseret på dem.

R'RѕRїSЂRѕSЃS <

Spørgsmål: Du sagde, at du ikke ville annoncere for brands, men jeg spekulerer stadig på - hvilken slags dashboards bruger du i dine projekter?
Svar: På forskellige måder. Det sker, at vi kommer til kunden, og han har allerede sin egen overvågning. Og vi rådgiver kunden om, hvad der skal tilføjes til hans overvågning. Den værste situation er med Zabbix. Fordi det ikke har mulighed for at bygge TopN-grafik. Vi bruger selv Okmeterfordi vi konsulterede disse fyre om overvågning. De lavede PostgreSQL-overvågning baseret på vores TOR. Jeg skriver mit eget kæledyrsprojekt, som indsamler data gennem Prometheus og trækker det ind grafana. Min opgave er at lave min egen eksportør i Prometheus og så tegne alt i Grafana.

Spørgsmål: Er der nogen analoger til AWR-rapporter eller ... sammenlægninger? Er du klar over sådan noget?
Svar: Ja, jeg ved hvad AWR er, det er en fed ting. I øjeblikket er der en række forskellige cykler, der implementerer omtrent følgende model. Med et eller andet tidsinterval skrives nogle basislinjer til den samme PostgreSQL eller til et separat lager. Du kan google dem på internettet, det er de. En af udviklerne af sådan en ting sidder på sql.ru-forummet i PostgreSQL-tråden. Du kan fange ham der. Ja, der er sådanne ting, de kan bruges. plus i sin pgCenter Jeg skriver også en ting, der giver dig mulighed for at gøre det samme.

PS1 Hvis du bruger postgres_exporter, hvilket dashboard bruger du så? Der er flere af dem. De er allerede forældede. Kan fællesskabet oprette en opdateret skabelon?

PS2 Fjernet pganalyze, da det er et proprietært SaaS-tilbud, der fokuserer på præstationsovervågning og automatiserede indstillingsforslag.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Hvilken selvhostet postgresql-overvågning (med dashboard) synes du er den bedste?

• 30,0 %Zabbix + tilføjelser fra Alexey Lesovsky eller zabbix 4.4 eller 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 er en proprietær SaaS - kan ikke slette1

• 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

10 brugere stemte. 26 brugere undlod at stemme.

Kilde: www.habr.com