Grunnleggende om PostgreSQL-overvåking. Alexey Lesovsky

Jeg foreslår at du leser utskriften av rapporten av Alexey Lesovsky fra Data Egret "Fundamentals of PostgreSQL monitoring"

I denne rapporten vil Alexey Lesovsky snakke om nøkkelpunktene i post-gress-statistikk, hva de betyr, og hvorfor de bør være tilstede i overvåking; om hvilke grafer som skal være i overvåkingen, hvordan de skal legges til og hvordan de skal tolkes. Rapporten vil være nyttig for databaseadministratorer, systemadministratorer og utviklere som er interessert i Postgres feilsøking.

Mitt navn er Alexey Lesovsky, jeg representerer Data Egret-selskapet.

Noen få ord om meg selv. Jeg begynte for lenge siden som systemadministrator.

Jeg administrerte alle mulige forskjellige Linux-systemer, jobbet med ulike ting relatert til Linux, dvs. virtualisering, overvåking, jobbet med proxyer osv. Men på et tidspunkt begynte jeg å jobbe mer med databaser, PostgreSQL. Jeg likte ham virkelig. Og på et tidspunkt begynte jeg å jobbe med PostgreSQL mesteparten av arbeidstiden min. Og så gradvis ble jeg en PostgreSQL DBA.

Og gjennom hele min karriere har jeg alltid vært interessert i emnene statistikk, overvåking og telemetri. Og da jeg var systemadministrator jobbet jeg veldig tett med Zabbix. Og jeg skrev et lite sett med manus som zabbix-utvidelser. Han var ganske populær i sin tid. Og der var det mulig å overvåke svært forskjellige viktige ting, ikke bare Linux, men også ulike komponenter.

Nå jobber jeg med PostgreSQL. Jeg skriver allerede en annen ting som lar deg jobbe med PostgreSQL-statistikk. Det kalles pgCenter (artikkel om Habré - Post-gress-statistikk uten nerver og spenning).

Et lite innledende notat. Hvilke situasjoner har våre kunder, våre kunder? Det er en slags ulykke knyttet til databasen. Og når databasen allerede er gjenopprettet, kommer avdelingslederen eller utviklingssjefen og sier: «Venner, vi må overvåke databasen, for noe ille har skjedd, og vi må forhindre at dette skjer i fremtiden.» Og her begynner den interessante prosessen med å velge et overvåkingssystem eller tilpasse et eksisterende overvåkingssystem slik at du kan overvåke databasen din - PostgreSQL, MySQL eller noen andre. Og kolleger begynner å foreslå: «Jeg hørte at det finnes en slik og en database. La oss bruke det." Kolleger begynner å krangle med hverandre. Og til slutt viser det seg at vi velger en slags database, men PostgreSQL-overvåking presenteres i den ganske dårlig, og vi må alltid legge til noe. Ta noen repositories fra GitHub, klon dem, tilpass skript og tilpass dem på en eller annen måte. Og til slutt ender det opp med å bli en slags manuelt arbeid.

Derfor vil jeg i denne foredraget prøve å gi deg litt kunnskap om hvordan du velger overvåking ikke bare for PostgreSQL, men også for databasen. Og gi deg kunnskapen som vil tillate deg å fullføre overvåkingen din for å få litt nytte av den, slik at du kan overvåke databasen med fordel, for raskt å forhindre eventuelle kommende nødsituasjoner som kan oppstå.

Og ideene som vil være i denne rapporten kan tilpasses direkte til enhver database, enten det er en DBMS eller noSQL. Derfor er det ikke bare PostgreSQL, men det vil være mange oppskrifter på hvordan du gjør dette i PostgreSQL. Det vil være eksempler på spørringer, eksempler på entiteter som PostgreSQL har for overvåking. Og hvis DBMS-en din har de samme tingene som gjør at du kan sette dem i overvåking, kan du også tilpasse dem, legge dem til så blir det bra.

Jeg vil ikke være med i rapporten
snakke om hvordan du leverer og lagrer beregninger. Jeg vil ikke si noe om etterbehandling av dataene og presentasjon for brukeren. Og jeg vil ikke si noe om varsling.
Men etter hvert som historien skrider frem, vil jeg vise forskjellige skjermbilder av eksisterende overvåking og på en eller annen måte kritisere dem. Men likevel vil jeg prøve å ikke navngi merkevarer for ikke å lage reklame eller antireklame for disse produktene. Derfor er alle tilfeldigheter tilfeldige og overlates til fantasien din.

La oss først finne ut hva overvåking er. Overvåking er en veldig viktig ting å ha. Alle forstår dette. Men samtidig er overvåking ikke knyttet til et forretningsprodukt og påvirker ikke selskapets resultat direkte, så det avsettes alltid tid til overvåking på restbasis. Hvis vi har tid, overvåker vi; hvis vi ikke har tid, så OK, vi legger det inn i etterslepet og en dag vil vi gå tilbake til disse oppgavene.

Derfor, fra vår praksis, når vi kommer til kunder, er overvåking ofte ufullstendig og har ingen interessante ting som vil hjelpe oss å gjøre en bedre jobb med databasen. Og derfor må overvåking alltid fullføres.

Databaser er så komplekse ting som også må overvåkes, fordi databaser er et arkiv med informasjon. Og informasjon er veldig viktig for bedriften, den kan ikke gå tapt på noen måte. Men samtidig er databaser veldig kompliserte stykker programvare. De består av et stort antall komponenter. Og mange av disse komponentene må overvåkes.

Hvis vi snakker spesifikt om PostgreSQL, kan det representeres i form av et opplegg som består av et stort antall komponenter. Disse komponentene samhandler med hverandre. Og samtidig har PostgreSQL det såkalte Stats Collector-undersystemet, som lar deg samle statistikk om driften av disse undersystemene og gi en slags grensesnitt til administratoren eller brukeren slik at han kan se denne statistikken.

Denne statistikken presenteres i form av et visst sett med funksjoner og visninger. De kan også kalles tabeller. Det vil si at ved å bruke en vanlig psql-klient kan du koble til databasen, velge disse funksjonene og visningene og få noen spesifikke tall om driften av PostgreSQL-delsystemene.

Du kan legge til disse tallene i ditt favorittovervåkingssystem, tegne grafer, legge til funksjoner og få analyser på lang sikt.

Men i denne rapporten vil jeg ikke dekke alle disse funksjonene fullstendig, fordi det kan ta hele dagen. Jeg vil bokstavelig talt ta for meg to, tre eller fire ting og fortelle deg hvordan de bidrar til å gjøre overvåking bedre.

Og hvis vi snakker om databaseovervåking, hva må da overvåkes? Først av alt må vi overvåke tilgjengelighet, fordi databasen er en tjeneste som gir tilgang til data til klienter og vi må overvåke tilgjengelighet, og også gi noen av dens kvalitative og kvantitative egenskaper.

Vi må også overvåke klienter som kobler til databasen vår, fordi de kan være både vanlige klienter og skadelige klienter som kan skade databasen. De må også overvåkes og aktivitetene deres spores.

Når klienter kobler seg til databasen, er det åpenbart at de begynner å jobbe med dataene våre, så vi må overvåke hvordan klientene jobber med dataene: med hvilke tabeller, og i mindre grad, med hvilke indekser. Det vil si at vi må evaluere arbeidsmengden som skapes av våre kunder.

Men arbeidsmengden består selvfølgelig også av forespørsler. Applikasjoner kobles til databasen, får tilgang til data ved hjelp av spørringer, så det er viktig å evaluere hvilke spørringer vi har i databasen, overvåke at de er tilstrekkelige, at de ikke er skjevt skrevet, at noen alternativer må skrives om og lages slik at de fungerer raskere og med bedre ytelse.

Og siden vi snakker om en database, er databasen alltid bakgrunnsprosesser. Bakgrunnsprosesser bidrar til å opprettholde databaseytelsen på et godt nivå, så de krever en viss mengde ressurser for seg selv for å fungere. Og samtidig kan de overlappe med klientforespørselsressurser, så grådige bakgrunnsprosesser kan direkte påvirke ytelsen til klientforespørsler. Derfor må de også overvåkes og spores slik at det ikke oppstår forvrengninger når det gjelder bakgrunnsprosesser.

Og alt dette når det gjelder databaseovervåking forblir i systemmetrikken. Men med tanke på at det meste av infrastrukturen vår flytter til skyene, faller alltid systemberegningene til en individuell vert i bakgrunnen. Men i databaser er de fortsatt relevante, og selvfølgelig er det også nødvendig å overvåke systemmålinger.

Alt er mer eller mindre bra med systemmålinger, alle moderne overvåkingssystemer støtter allerede disse metrikkene, men generelt er noen komponenter fortsatt ikke nok og noen ting må legges til. Jeg skal også berøre dem, det kommer flere lysbilder om dem.

Planens første punkt er tilgjengelighet. Hva er tilgjengelighet? Tilgjengelighet etter min forståelse er basens evne til å betjene forbindelser, dvs. basen er hevet, den, som en tjeneste, aksepterer forbindelser fra klienter. Og denne tilgjengeligheten kan vurderes av visse egenskaper. Det er veldig praktisk å vise disse egenskapene på dashbord.

Alle vet hva dashbord er. Det var da du tok en titt på skjermen der den nødvendige informasjonen er oppsummert. Og du kan umiddelbart finne ut om det er et problem i databasen eller ikke.
Tilgjengeligheten av databasen og andre nøkkelegenskaper bør derfor alltid vises på dashboards slik at denne informasjonen er tilgjengelig og alltid tilgjengelig for deg. Noen tilleggsdetaljer som allerede hjelper i etterforskningen av hendelser, når de undersøker noen nødsituasjoner, må de allerede plasseres på sekundære dashboards, eller skjules i drilldown-lenker som fører til tredjeparts overvåkingssystemer.

Et eksempel på et velkjent overvåkingssystem. Dette er et veldig kult overvåkingssystem. Hun samler mye data, men fra mitt ståsted har hun et merkelig konsept med dashboards. Det er en lenke for å "lage et dashbord". Men når du lager et dashbord, lager du en liste med to kolonner, en liste med grafer. Og når du trenger å se på noe, begynner du å klikke med musen, bla, lete etter ønsket diagram. Og dette tar tid, det vil si at det ikke er noen dashbord som sådan. Det er bare lister over diagrammer.

Hva bør du legge til i disse dashbordene? Du kan starte med en slik egenskap som responstid. PostgreSQL har pg_stat_statements-visningen. Det er deaktivert som standard, men det er en av de viktige systemvisningene som alltid bør være aktivert og brukt. Den lagrer informasjon om alle kjørende spørringer som har blitt utført i databasen.

Følgelig kan vi ta utgangspunkt i det faktum at vi kan ta den totale utførelsestiden for alle forespørsler og dele den på antall forespørsler ved å bruke feltene ovenfor. Men dette er gjennomsnittstemperaturen på sykehuset. Vi kan starte fra andre felt - minimum utførelsestid for spørringer, maksimum og median. Og vi kan til og med bygge persentiler; PostgreSQL har tilsvarende funksjoner for dette. Og vi kan få noen tall som karakteriserer responstiden til databasen vår for allerede fullførte forespørsler, det vil si at vi ikke utfører den falske forespørslen 'velg 1' og ser på responstiden, men vi analyserer responstiden for allerede fullførte forespørsler og trekker enten en egen figur, eller så bygger vi en graf basert på den.

Det er også viktig å overvåke antall feil som for øyeblikket genereres av systemet. Og for dette kan du bruke pg_stat_database-visningen. Vi fokuserer på xact_rollback-feltet. Dette feltet viser ikke bare antall tilbakeføringer som skjer i databasen, men tar også hensyn til antall feil. Relativt sett kan vi vise dette tallet i dashbordet vårt og se hvor mange feil vi har for øyeblikket. Hvis det er mange feil, så er dette en god grunn til å se i loggene og se hva slags feil det er og hvorfor de oppstår, for så å investere og løse dem.

Du kan legge til noe som en turteller. Dette er antall transaksjoner per sekund og antall forespørsler per sekund. Relativt sett kan du bruke disse tallene som gjeldende ytelse til databasen din og observere om det er topper i forespørsler, topper i transaksjoner, eller omvendt, om databasen er underbelastet fordi noen backend har sviktet. Det er viktig å alltid se på denne figuren og huske at for prosjektet vårt er denne typen ytelse normal, men verdiene over og under er allerede en slags problematisk og uforståelig, noe som betyr at vi må se på hvorfor disse tallene er så høy.

For å estimere antall transaksjoner kan vi igjen referere til pg_stat_database-visningen. Vi kan legge til antall forpliktelser og antall tilbakeføringer og få antall transaksjoner per sekund.

Forstår alle at flere forespørsler kan passe inn i en transaksjon? Derfor er TPS og QPS litt forskjellige.

Antall forespørsler per sekund kan hentes fra pg_stat_statements og ganske enkelt beregne summen av alle fullførte forespørsler. Det er klart at vi sammenligner den nåværende verdien med den forrige, trekker den fra, får deltaet og får mengden.

Du kan legge til flere beregninger om ønskelig, som også hjelper til med å evaluere tilgjengeligheten til databasen vår og overvåke om det har vært noen nedetider.

En av disse beregningene er oppetid. Men oppetid i PostgreSQL er litt vanskelig. Jeg skal fortelle deg hvorfor. Når PostgreSQL har startet, begynner oppetiden å rapportere. Men hvis på et tidspunkt, for eksempel en oppgave kjørte om natten, en OOM-morder kom og tvangsavbrutt PostgreSQL-underordnet prosess, så avslutter PostgreSQL i dette tilfellet tilkoblingen til alle klienter, tilbakestiller det sønderdelte minneområdet og begynner gjenoppretting fra det siste sjekkpunktet. Og mens denne gjenopprettingen fra sjekkpunktet varer, godtar ikke databasen tilkoblinger, det vil si at denne situasjonen kan vurderes som nedetid. Men oppetidstelleren vil ikke tilbakestilles, fordi den tar hensyn til postmaster oppstartstid fra første øyeblikk. Derfor kan slike situasjoner hoppes over.

Du bør også overvåke antall vakuumarbeidere. Vet alle hva autovacuum er i PostgreSQL? Dette er et interessant undersystem i PostgreSQL. Det er skrevet mange artikler om henne, mange rapporter er laget. Det er mange diskusjoner om vakuum og hvordan det skal fungere. Mange anser det som et nødvendig onde. Men sånn er det. Dette er en slags analog av en søppelsamler som renser utdaterte versjoner av rader som ikke er nødvendige for noen transaksjon og frigjør plass i tabeller og indekser for nye rader.

Hvorfor trenger du å overvåke det? Fordi vakuumet noen ganger gjør veldig vondt. Det bruker en stor mengde ressurser og klientforespørsler begynner å lide som et resultat.

Og det bør overvåkes gjennom pg_stat_activity-visningen, som jeg vil snakke om i neste avsnitt. Denne visningen viser gjeldende aktivitet i databasen. Og gjennom denne aktiviteten kan vi spore antall støvsugere som fungerer akkurat nå. Vi kan spore vakuum og se at hvis vi har overskredet grensen, så er dette en grunn til å se nærmere på PostgreSQL-innstillingene og på en eller annen måte optimalisere driften av vakuumet.

En annen ting med PostgreSQL er at PostgreSQL er veldig lei av lange transaksjoner. Spesielt fra transaksjoner som henger lenge og ikke gjør noe. Dette er den såkalte stat idle-in-transaction. En slik transaksjon holder låser og hindrer vakuumet i å fungere. Og som et resultat svulmer bordene og øker i størrelse. Og spørringer som fungerer med disse tabellene begynner å fungere tregere, fordi du må måke alle de gamle versjonene av rader fra minne til disk og tilbake. Derfor må tiden, varigheten av de lengste transaksjonene, de lengste vakuumforespørslene også overvåkes. Og hvis vi ser noen prosesser som har kjørt i veldig lang tid, allerede mer enn 10-20-30 minutter for en OLTP-belastning, må vi ta hensyn til dem og avslutte dem kraftig, eller optimere applikasjonen slik at de kalles ikke og henger ikke så lenge. For en analytisk arbeidsmengde er 10-20-30 minutter normalt; det er også lengre.

Deretter har vi muligheten med tilkoblede klienter. Når vi allerede har opprettet et dashbord og lagt ut viktige tilgjengelighetsberegninger på det, kan vi også legge til tilleggsinformasjon om tilkoblede klienter der.

Informasjon om tilkoblede klienter er viktig fordi, fra et PostgreSQL-perspektiv, er klienter forskjellige. Det er gode kunder og det er dårlige kunder.

Et enkelt eksempel. Av klient forstår jeg søknaden. Applikasjonen har koblet seg til databasen og begynner umiddelbart å sende sine forespørsler dit, databasen behandler og utfører dem, og returnerer resultatene til klienten. Dette er gode og riktige kunder.

Det er situasjoner når klienten har koblet til, den holder tilkoblingen, men gjør ingenting. Den er i hviletilstand.

Men det er dårlige kunder. For eksempel koblet den samme klienten til, åpnet en transaksjon, gjorde noe i databasen og gikk deretter inn i koden, for eksempel for å få tilgang til en ekstern kilde eller for å behandle de mottatte dataene der. Men han avsluttet ikke transaksjonen. Og transaksjonen henger i databasen og holdes i en lås på linjen. Dette er en dårlig tilstand. Og hvis plutselig en applikasjon et sted i seg selv mislykkes med et unntak, kan transaksjonen forbli åpen i veldig lang tid. Og dette påvirker PostgreSQL-ytelsen direkte. PostgreSQL vil være tregere. Derfor er det viktig å spore slike klienter i tide og tvinge å avslutte arbeidet deres. Og du må optimalisere applikasjonen din slik at slike situasjoner ikke oppstår.

Andre dårlige kunder er ventende kunder. Men de blir dårlige på grunn av omstendighetene. For eksempel en enkel inaktiv transaksjon: den kan åpne en transaksjon, ta låser på noen linjer, så et sted i koden vil den mislykkes, og etterlate en hengende transaksjon. En annen klient vil komme og be om de samme dataene, men han vil møte en lås, fordi den hengende transaksjonen allerede har låser på noen nødvendige rader. Og den andre transaksjonen vil henge og vente på at den første transaksjonen skal fullføres eller tvangslukke den av administratoren. Derfor kan ventende transaksjoner akkumuleres og fylle grensen for databasetilkobling. Og når grensen er full, kan ikke applikasjonen lenger fungere med databasen. Dette er allerede en nødsituasjon for prosjektet. Derfor må dårlige kunder spores og reageres på i tide.

Et annet eksempel på overvåking. Og det er allerede et anstendig dashbord her. Det er informasjon om tilkoblinger ovenfor. DB-tilkobling – 8 stk. Og det er alt. Vi har ingen informasjon om hvilke klienter som er aktive, hvilke klienter som bare er inaktive og ikke gjør noe. Det er ingen informasjon om ventende transaksjoner og ventende tilkoblinger, det vil si at dette er en figur som viser antall tilkoblinger og det er det. Og så gjett selv.

Følgelig, for å legge til denne informasjonen i overvåking, må du få tilgang til systemvisningen pg_stat_activity. Hvis du bruker mye tid i PostgreSQL, så er dette en veldig god visning som bør bli din venn, fordi den viser gjeldende aktivitet i PostgreSQL, det vil si hva som skjer i den. For hver prosess er det en egen linje som viser informasjon om denne prosessen: fra hvilken vert tilkoblingen ble opprettet, under hvilken bruker, under hvilket navn, når transaksjonen ble startet, hvilken forespørsel som kjører, hvilken forespørsel som sist ble utført. Og følgelig kan vi evaluere klientens tilstand ved å bruke stat-feltet. Relativt sett kan vi gruppere etter dette feltet og få de statistikkene som for øyeblikket er i databasen og antall forbindelser som har denne statistikken i databasen. Og vi kan sende de allerede mottatte tallene til vår overvåking og tegne grafer basert på dem.
Det er også viktig å vurdere varigheten av transaksjonen. Jeg har allerede sagt at det er viktig å evaluere varigheten av vakuum, men transaksjoner evalueres på samme måte. Det er feltene xact_start og query_start. De viser relativt sett starttidspunktet for transaksjonen og starttidspunktet for forespørselen. Vi tar funksjonen now(), som viser gjeldende tidsstempel, og trekker fra transaksjonen og ber om tidsstempel. Og vi får transaksjonens varighet, varigheten av forespørselen.

Hvis vi ser lange transaksjoner, bør vi fullføre dem allerede. For en OLTP-belastning er lange transaksjoner allerede mer enn 1-2-3 minutter. For en OLAP-arbeidsmengde er lange transaksjoner normalt, men hvis de tar mer enn to timer å fullføre, så er dette også et tegn på at vi har en skjevhet et sted.

Når klienter har koblet seg til databasen, begynner de å jobbe med dataene våre. De får tilgang til tabeller, de får tilgang til indekser for å hente data fra tabellen. Og det er viktig å evaluere hvordan klienter samhandler med disse dataene.

Dette er nødvendig for å evaluere arbeidsmengden vår og grovt forstå hvilke tabeller som er de "hotteste" for oss. Dette er for eksempel nødvendig i situasjoner der vi ønsker å plassere "varme" bord på en slags rask SSD-lagring. For eksempel kan noen arkivtabeller som vi ikke har brukt på lenge, flyttes til et slags "kaldt" arkiv, til SATA-stasjoner og la dem bo der, de vil få tilgang til etter behov.

Dette er også nyttig for å oppdage uregelmessigheter etter eventuelle utgivelser og distribusjoner. La oss si at prosjektet har gitt ut en ny funksjon. For eksempel la vi til ny funksjonalitet for arbeid med databasen. Og hvis vi plotter tabellbruksgrafer, kan vi enkelt oppdage disse uregelmessighetene på disse grafene. Oppdater for eksempel serier eller slett serier. Det vil være veldig synlig.

Du kan også oppdage anomalier i "flytende" statistikk. Hva betyr det? PostgreSQL har en veldig sterk og veldig god spørringsplanlegger. Og utviklerne bruker mye tid på utviklingen. Hvordan jobber han? For å legge gode planer samler PostgreSQL inn statistikk over distribusjon av data i tabeller med et visst tidsintervall og med en viss frekvens. Dette er de vanligste verdiene: antall unike verdier, informasjon om NULL i tabellen, mye informasjon.

Basert på denne statistikken, konstruerer planleggeren flere spørringer, velger den mest optimale, og bruker denne spørringsplanen til å utføre selve spørringen og returnere data.

Og det hender at statistikken "flyter". Kvalitets- og kvantitetsdataene endret seg på en eller annen måte i tabellen, men statistikken ble ikke samlet inn. Og planene som dannes er kanskje ikke optimale. Og hvis planene våre viser seg å være suboptimale basert på innsamlet overvåking, basert på tabellene, vil vi kunne se disse anomaliene. For eksempel, et sted endret dataene seg kvalitativt, og i stedet for indeksen begynte en sekvensiell passering gjennom tabellen å bli brukt, dvs. hvis et søk bare trenger å returnere 100 rader (det er en grense på 100), vil et fullstendig søk bli utført for denne spørringen. Og dette har alltid en veldig dårlig effekt på ytelsen.

Og det kan vi se i overvåkingen. Og se allerede på denne spørringen, kjør en forklaring for den, samle inn statistikk, bygg en ny tilleggsindeks. Og allerede svare på dette problemet. Derfor er det viktig.

Et annet eksempel på overvåking. Jeg tror mange kjente ham igjen fordi han er veldig populær. Som bruker det i sine prosjekter Prometheus? Hvem bruker dette produktet sammen med Prometheus? Faktum er at i standardlageret for denne overvåkingen er det et dashbord for å jobbe med PostgreSQL - postgres_exporter Prometheus. Men det er en dårlig detalj.

Det er flere grafer. Og byte er angitt som enhet, det vil si at det er 5 grafer. Disse er Sett inn data, Oppdater data, Slett data, Hent data og Returner data. Enhetsmålet er byte. Men saken er at statistikk i PostgreSQL returnerer data i tuppel (rader). Og følgelig er disse grafene en veldig god måte å undervurdere arbeidsmengden flere ganger, titalls ganger, fordi en tuppel ikke er en byte, en tuppel er en streng, den er mange byte og den har alltid variabel lengde. Det vil si at å beregne arbeidsmengde i byte ved å bruke tupler er en urealistisk oppgave eller veldig vanskelig. Derfor, når du bruker et dashbord eller innebygd overvåking, er det alltid viktig å forstå at det fungerer riktig og returnerer deg korrekt vurderte data.

Hvordan få statistikk på disse tabellene? For dette formålet har PostgreSQL en viss familie av synspunkter. Og hovedsynet er pg_stat_user_tables. User_tables - dette betyr tabeller opprettet på vegne av brukeren. Derimot er det systemvisninger som brukes av PostgreSQL selv. Og det er en oppsummeringstabell Alltables, som inkluderer både system og bruker. Du kan starte fra hvilken som helst av dem du liker best.

Ved å bruke feltene ovenfor kan du anslå antall innsettinger, oppdateringer og slettinger. Eksemplet på et dashbord som jeg brukte, bruker disse feltene til å evaluere egenskapene til en arbeidsbelastning. Derfor kan vi også bygge videre på dem. Men det er verdt å huske at dette er tupler, ikke byte, så vi kan ikke bare gjøre det i byte.

Basert på disse dataene kan vi bygge såkalte TopN-tabeller. For eksempel Topp-5, Topp-10. Og du kan spore de varme bordene som resirkuleres mer enn andre. For eksempel 5 "varme" tabeller for innsetting. Og ved å bruke disse TopN-tabellene evaluerer vi arbeidsmengden vår og kan evaluere utbrudd av arbeidsbelastning etter eventuelle utgivelser, oppdateringer og distribusjoner.

Det er også viktig å vurdere størrelsen på tabellen, fordi noen ganger lanserer utviklere en ny funksjon, og tabellene våre begynner å svulme opp i sine store størrelser, fordi de bestemte seg for å legge til en ekstra mengde data, men forutså ikke hvordan dette ville påvirke størrelsen på databasen. Slike saker kommer også som overraskelser for oss.

Og nå et lite spørsmål til deg. Hvilket spørsmål oppstår når du legger merke til belastningen på databaseserveren din? Hva er det neste spørsmålet du har?

Men faktisk oppstår spørsmålet som følger. Hvilke forespørsler forårsaker belastningen? Det vil si at det ikke er interessant å se på prosessene som er forårsaket av belastningen. Det er klart at hvis verten har en database, så kjører databasen der, og det er klart at bare databasene vil bli avhendet der. Hvis vi åpner Top, vil vi se en liste over prosesser i PostgreSQL som gjør noe. Det vil ikke være klart fra Top hva de gjør.

Følgelig må du finne de spørringene som forårsaker den høyeste belastningen, fordi innstillingsspørringer som regel gir mer fortjeneste enn å justere PostgreSQL- eller operativsystemkonfigurasjonen, eller til og med justere maskinvaren. I følge mitt estimat er dette omtrent 80-85-90%. Og dette gjøres mye raskere. Det er raskere å korrigere en forespørsel enn å korrigere konfigurasjonen, planlegge en omstart, spesielt hvis databasen ikke kan startes på nytt, eller legge til maskinvare. Det er lettere å omskrive spørringen et sted eller legge til en indeks for å få et bedre resultat fra denne spørringen.

Følgelig er det nødvendig å overvåke forespørsler og deres tilstrekkelighet. La oss ta et annet eksempel på overvåking. Og også her ser det ut til å være utmerket overvåking. Det er informasjon om replikering, det er informasjon om gjennomstrømning, blokkering, ressursutnyttelse. Alt er bra, men det er ingen informasjon om forespørsler. Det er ikke klart hvilke spørringer som kjører i databasen vår, hvor lenge de kjører, hvor mange av disse spørringene er. Vi må alltid ha denne informasjonen i vår overvåking.

Og for å få denne informasjonen kan vi bruke modulen pg_stat_statements. Basert på det kan du bygge en rekke grafer. For eksempel kan du få informasjon om de hyppigste spørringene, det vil si om de spørringene som utføres oftest. Ja, etter utplasseringer er det også veldig nyttig å se på det og forstå om det er noen økning i forespørsler.

Du kan overvåke de lengste spørringene, det vil si de spørringene som tar lengst tid å fullføre. De kjører på prosessoren, de bruker I/O. Vi kan også evaluere dette ved å bruke feltene total_time, mean_time, blk_write_time og blk_read_time.

Vi kan evaluere og overvåke de tyngste forespørslene når det gjelder ressursbruk, de som leser fra disk, som jobber med minne, eller omvendt, skaper en slags skrivebelastning.

Vi kan vurdere de mest generøse forespørslene. Dette er spørringene som returnerer et stort antall rader. Dette kan for eksempel være en forespørsel der de har glemt å sette en grense. Og det returnerer ganske enkelt hele innholdet i tabellen eller spørringen på tvers av de spørrede tabellene.

Og du kan også overvåke spørringer som bruker midlertidige filer eller midlertidige tabeller.

Og vi har fortsatt bakgrunnsprosesser. Bakgrunnsprosesser er først og fremst sjekkpunkter eller de kalles også sjekkpunkter, disse er autovakuum og replikering.

Et annet eksempel på overvåking. Det er en Vedlikehold-fane til venstre, gå til den og håper å se noe nyttig. Men her er bare tidspunktet for vakuumdrift og statistikkinnsamling, ikke noe mer. Dette er svært dårlig informasjon, så vi må alltid ha informasjon om hvordan bakgrunnsprosesser fungerer i databasen vår og om det er noen problemer fra arbeidet deres.

Når vi ser på sjekkpunkter, bør vi huske at sjekkpunkter skyller skitne sider fra det sønderdelte minneområdet til disken, og deretter oppretter et sjekkpunkt. Og dette sjekkpunktet kan da brukes som et sted for utvinning hvis PostgreSQL plutselig ble avsluttet i en nødssituasjon.

Følgelig, for å skylle alle de "skitne" sidene til disken, må du skrive en viss mengde. Og som regel, på systemer med store mengder minne, er dette mye. Og hvis vi gjør sjekkpunkter veldig ofte i et kort intervall, vil diskytelsen synke veldig betydelig. Og klientforespørsler vil lide under mangel på ressurser. De vil konkurrere om ressurser og mangler produktivitet.

Følgelig kan vi gjennom pg_stat_bgwriter ved å bruke de angitte feltene overvåke antall sjekkpunkter som oppstår. Og hvis vi har mange sjekkpunkter over en viss tidsperiode (på 10-15-20 minutter, på en halvtime), for eksempel 3-4-5, så kan dette allerede være et problem. Og du må allerede se i databasen, se i konfigurasjonen, hva som forårsaker en slik overflod av sjekkpunkter. Kanskje det er en slags stor innspilling på gang. Vi kan allerede evaluere arbeidsmengden, fordi vi allerede har lagt til arbeidsbelastningsgrafer. Vi kan allerede justere sjekkpunktparametrene og sørge for at de ikke i stor grad påvirker søkeytelsen.

Jeg kommer tilbake til autovakuum igjen fordi det er en slik ting, som sagt, som enkelt kan legge sammen både disk- og spørringsytelse, så det er alltid viktig å estimere mengden autovakuum.

Antall autovakuumarbeidere i databasen er begrenset. Som standard er det tre av dem, så hvis vi alltid har tre arbeidere som jobber i databasen, betyr dette at autovakuumet vårt ikke er konfigurert, vi må heve grensene, revidere autovakuuminnstillingene og komme inn i konfigurasjonen.
Det er viktig å vurdere hvilke vakuumarbeidere vi har. Enten ble det lansert fra brukeren, DBA kom og lanserte manuelt et slags vakuum, og dette skapte en belastning. Vi har et slags problem. Eller dette er antallet støvsugere som skru av transaksjonstelleren. For noen versjoner av PostgreSQL er dette veldig tunge støvsugere. Og de kan enkelt legge sammen ytelsen fordi de leser hele tabellen, skanner alle blokkene i den tabellen.

Og, selvfølgelig, varigheten av vakuum. Hvis vi har langvarige støvsugere som går veldig lenge, betyr dette at vi igjen må ta hensyn til vakuumkonfigurasjonen og kanskje revurdere innstillingene. Fordi det kan oppstå en situasjon når vakuumet jobber på bordet i lang tid (3-4 timer), men i løpet av tiden vakuumet fungerte, klarte en stor mengde døde rader å samle seg i bordet igjen. Og så snart vakuumet er fullført, må han støvsuge dette bordet igjen. Og vi kommer til en situasjon – et endeløst vakuum. Og i dette tilfellet takler ikke vakuumet arbeidet sitt, og tabellene begynner gradvis å svulme i størrelse, selv om volumet av nyttige data i det forblir det samme. Derfor, under lange vakuum, ser vi alltid på konfigurasjonen og prøver å optimalisere den, men samtidig slik at ytelsen til klientforespørsler ikke lider.

I dag er det praktisk talt ingen PostgreSQL-installasjon som ikke har streaming-replikering. Replikering er prosessen med å flytte data fra en master til en replika.

Replikering i PostgreSQL gjøres gjennom en transaksjonslogg. Veiviseren genererer en transaksjonslogg. Transaksjonsloggen går over nettverksforbindelsen til replikaen, og deretter reproduseres den på replikaen. Det er enkelt.

Følgelig brukes pg_stat_replikeringsvisningen til å overvåke replikeringsforsinkelsen. Men ikke alt er enkelt med henne. I versjon 10 har visningen gjennomgått flere endringer. For det første har noen felt fått nytt navn. Og noen felt er lagt til. I versjon 10 dukket det opp felt som lar deg estimere replikeringsforsinkelsen i sekunder. Det er veldig behagelig. Før versjon 10 var det mulig å estimere replikeringsforsinkelsen i byte. Dette alternativet forblir i versjon 10, det vil si at du kan velge hva som er mer praktisk for deg - estimer forsinkelsen i byte eller estimer forsinkelsen i sekunder. Mange gjør begge deler.

Men ikke desto mindre, for å evaluere replikeringsforsinkelsen, må du vite posisjonen til loggen i transaksjonen. Og disse transaksjonsloggposisjonene er nøyaktig i pg_stat_replikeringsvisningen. Relativt sett kan vi ta to punkter i transaksjonsloggen ved å bruke pg_xlog_location_diff() funksjonen. Beregn deltaet mellom dem og få replikasjonsforsinkelsen i byte. Det er veldig praktisk og enkelt.

I versjon 10 ble denne funksjonen omdøpt til pg_wal_lsn_diff(). Generelt, i alle funksjoner, visninger og verktøy der ordet "xlog" dukket opp, ble det erstattet med verdien "wal". Dette gjelder både visninger og funksjoner. Dette er en slik innovasjon.

I tillegg ble det lagt til linjer i versjon 10 som spesifikt viser etterslepet. Disse er skrivelag, flush lag, replay lag. Det vil si at det er viktig å overvåke disse tingene. Hvis vi ser at vi har et replikeringsforsinkelse, må vi undersøke hvorfor det dukket opp, hvor det kom fra og fikse problemet.

Nesten alt er i orden med systemberegninger. Når en eventuell overvåking begynner, starter den med systemmålinger. Dette er avhending av prosessorer, minne, swap, nettverk og disk. Mange parametere er imidlertid ikke der som standard.

Hvis alt er i orden med resirkuleringsprosessen, så er det problemer med diskresirkulering. Som regel legger overvåkingsutviklere til informasjon om gjennomstrømming. Det kan være i iops eller byte. Men de glemmer latens og bruk av diskenheter. Dette er viktigere parametere som lar oss evaluere hvor lastet diskene våre er og hvor trege de er. Hvis vi har høy latens, betyr dette at det er noen problemer med diskene. Hvis vi har høy utnyttelse betyr det at diskene ikke takler. Dette er bedre egenskaper enn gjennomstrømming.

Dessuten kan denne statistikken også hentes fra /proc-filsystemet, slik det gjøres for resirkuleringsprosessorer. Jeg vet ikke hvorfor denne informasjonen ikke legges til overvåking. Men likevel er det viktig å ha dette i overvåkingen.

Det samme gjelder nettverksgrensesnitt. Det er informasjon om nettverksgjennomstrømning i pakker, i byte, men likevel er det ingen informasjon om ventetid og ingen informasjon om utnyttelse, selv om dette også er nyttig informasjon.

Enhver overvåking har ulemper. Og uansett hva slags overvåking du tar, vil den alltid ikke oppfylle noen kriterier. Men ikke desto mindre utvikler de seg, nye funksjoner og nye ting blir lagt til, så velg noe og fullfør det.

Og for å fullføre, må du alltid ha en ide om hva statistikken som gis betyr og hvordan du kan bruke den til å løse problemer.

Og noen hovedpunkter:

• Du bør alltid overvåke tilgjengelighet og ha dashboard slik at du raskt kan vurdere at alt er i orden med databasen.
• Du må alltid ha en ide om hvilke klienter som jobber med databasen din for å luke ut dårlige klienter og skyte dem ned.
• Det er viktig å vurdere hvordan disse klientene jobber med data. Du må ha en ide om arbeidsmengden din.
• Det er viktig å vurdere hvordan denne arbeidsmengden dannes, ved hjelp av hvilke spørringer. Du kan evaluere spørringer, du kan optimalisere dem, refaktorere dem, bygge indekser for dem. Det er veldig viktig.
• Bakgrunnsprosesser kan påvirke klientforespørsler negativt, så det er viktig å overvåke at de ikke bruker for mange ressurser.
• Systemmålinger lar deg lage planer for skalering og øke kapasiteten til serverne dine, så det er viktig å spore og evaluere dem også.

Hvis du er interessert i dette emnet, kan du følge disse lenkene.
http://bit.do/stats_collector – dette er offisiell dokumentasjon fra statistikkinnsamleren. Det er en beskrivelse av alle statistiske visninger og en beskrivelse av alle felt. Du kan lese, forstå og analysere dem. Og basert på dem, bygg grafene dine og legg dem til overvåkingen din.

Eksempel forespørsler:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Dette er vårt bedriftslager og mitt eget. De inneholder eksempelspørsmål. Det er ingen forespørsler fra select* from-serien der. Det er allerede ferdige spørringer med sammenføyninger, ved hjelp av interessante funksjoner som lar deg gjøre rå tall til lesbare, praktiske verdier, det vil si at dette er byte, tid. Du kan plukke dem opp, se på dem, analysere dem, legge dem til overvåkingen din, bygge overvåkingen din basert på dem.

spørsmål

Spørsmål: Du sa at du ikke vil annonsere merkevarer, men jeg er fortsatt nysgjerrig - hva slags dashboard bruker du i prosjektene dine?
Svar: Det varierer. Det hender at vi kommer til en kunde og han har allerede sin egen overvåking. Og vi gir råd til kunden om hva som må legges til overvåkingen deres. Den verste situasjonen er med Zabbix. Fordi den ikke har muligheten til å bygge TopN-grafer. Vi bruker selv Okmeter, fordi vi rådførte oss med disse gutta om overvåking. De overvåket PostgreSQL basert på våre tekniske spesifikasjoner. Jeg skriver mitt eget kjæledyrprosjekt, som samler inn data via Prometheus og gjengir det grafana. Min oppgave er å lage min egen eksportør i Prometheus og deretter gjengi alt i Grafana.

Spørsmål: Finnes det noen analoger til AWR-rapporter eller ... aggregering? Vet du om noe slikt?
Svar: Ja, jeg vet hva AWR er, det er en kul ting. For øyeblikket er det en rekke sykler som implementerer omtrent følgende modell. Med et visst tidsintervall blir noen grunnlinjer skrevet til samme PostgreSQL eller til en separat lagring. Du kan google dem på Internett, de er der. En av utviklerne av en slik ting sitter på sql.ru-forumet i PostgreSQL-tråden. Du kan ta ham der. Ja, det finnes slike ting, de kan brukes. Pluss i sin pgCenter Jeg skriver også en ting som lar deg gjøre det samme.

PS1 Hvis du bruker postgres_exporter, hvilket dashbord bruker du? Det er flere av dem. De er allerede utdaterte. Kanskje fellesskapet vil lage en oppdatert mal?

PS2 Fjernet pganalyze fordi det er et proprietært SaaS-tilbud som fokuserer på ytelsesovervåking og automatiserte innstillingsforslag.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Hvilken selvdrevet postgresql-overvåking (med dashbord) anser du som den beste?

• 30,0%Zabbix + tillegg 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 - jeg kan ikke slette den1

• 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 brukere stemte. 26 brukere avsto.

Kilde: www.habr.com