Ech proposéieren Iech den Transkript vum Bericht vum Alexey Lesovsky vun Data Egret "Fundamentals of PostgreSQL Monitoring" ze liesen
An dësem Bericht wäert Alexey Lesovsky iwwer d'Schlësselpunkte vun der Post-gress Statistik schwätzen, wat se bedeiten a firwat se an der Iwwerwaachung präsent sinn; iwwer wéi eng Grafike sollen an der Iwwerwaachung sinn, wéi se se derbäigesat ginn a wéi se se interpretéiere kënnen. De Bericht wäert nëtzlech sinn fir Datebankadministrateuren, Systemadministratoren an Entwéckler, déi un der Postgres Troubleshooting interesséiert sinn.
Mäin Numm ass Alexey Lesovsky, ech representéieren d'Data Egret Firma.
E puer Wierder iwwer mech selwer. Ech hunn viru laanger Zäit als Systemadministrator ugefaang.
Ech hunn all Zorte vu verschiddene Linux Systemer verwalt, op verschidde Saachen am Zesummenhang mat Linux geschafft, dh Virtualiséierung, Iwwerwaachung, geschafft mat Proxyen, etc.. Awer iergendwann hunn ech ugefaang méi mat Datenbanken ze schaffen, PostgreSQL. Ech hunn him wierklech gär. An iergendwann hunn ech ugefaang op PostgreSQL déi meescht vu menger Aarbechtszäit ze schaffen. An esou sinn ech lues a lues e PostgreSQL DBA ginn.
A während menger Carrière war ech ëmmer un d'Themen Statistik, Iwwerwaachung an Telemetrie interesséiert. A wéi ech e Systemadministrator war, hunn ech ganz enk mam Zabbix geschafft. An ech hunn e klenge Set vu Scripte geschriwwen wéi . Hie war zimlech populär a senger Zäit. An do war et méiglech, ganz aner wichteg Saachen ze iwwerwaachen, net nëmmen Linux, mee och verschidde Komponenten.
Elo schaffen ech op PostgreSQL. Ech schreiwen schonn eng aner Saach, déi Iech erlaabt mat PostgreSQL Statistiken ze schaffen. Et gëtt genannt (Artikel iwwer Habré - ).
Eng kleng Aféierungscoursen. Wéi eng Situatiounen hunn eis Clienten, eis Clienten? Et gëtt eng Aart Accident am Zesummenhang mat der Datebank. A wann d'Datebank scho restauréiert ass, kënnt de Chef vum Departement oder de Chef vun der Entwécklung a seet: "Frënn, mir mussen d'Datebank iwwerwaachen, well eppes Schlechtes geschitt ass a mir musse verhënneren datt dat an Zukunft geschitt." An hei fänkt den interessante Prozess un fir en Iwwerwaachungssystem ze wielen oder en existente Iwwerwaachungssystem unzepassen fir datt Dir Är Datebank iwwerwaache kënnt - PostgreSQL, MySQL oder e puer anerer. A Kollegen fänken un ze proposéieren: "Ech hunn héieren datt et esou an esou eng Datebank gëtt. Loosst eis et benotzen." D'Kollege fänken un mateneen ze streiden. An um Enn stellt sech eraus datt mir eng Zort Datebank auswielen, awer d'PostgreSQL-Iwwerwaachung gëtt dran éischter schlecht presentéiert a mir mussen ëmmer eppes derbäisetzen. Huelt e puer Repositories vu GitHub, klon se, passt Skripte un, a personaliséiert se iergendwéi. An um Enn ass et eng Aart vu manueller Aarbecht.
Dofir, an dësem Gespréich probéieren ech Iech e puer Wëssen ze ginn wéi Dir d'Iwwerwaachung net nëmme fir PostgreSQL, awer och fir d'Datebank wielt. A gitt Iech d'Wëssen, déi Iech erlaabt Är Iwwerwaachung ofzeschléissen fir e bëssen Virdeeler dovun ze kréien, sou datt Dir Är Datebank mat Benefice iwwerwaache kënnt, fir direkt eventuell zukünfteg Noutsituatiounen ze verhënneren, déi entstoe kënnen.
An d'Iddien, déi an dësem Bericht sinn, kënnen direkt un all Datebank ugepasst ginn, sief et eng DBMS oder noSQL. Dofir gëtt et net nëmmen PostgreSQL, awer et gi vill Rezepter fir wéi Dir dëst am PostgreSQL maache kënnt. Et ginn Beispiller vu Ufroen, Beispiller vun Entitéiten déi PostgreSQL fir Iwwerwaachung huet. A wann Är DBMS déiselwecht Saachen huet, déi Iech erlaben se an d'Iwwerwaachung ze setzen, kënnt Dir se och adaptéieren, addéieren an et wäert gutt sinn.
Ech wäert net am Rapport sinn
schwätzen iwwer wéi Dir Metriken liwwert a späichert. Ech soen näischt iwwer d'Postveraarbechtung vun den Donnéeën an d'Presentatioun vum Benotzer. An ech wäert näischt iwwer Alarm soen.
Awer wéi d'Geschicht weidergeet, wäert ech verschidde Screenshots vun der existéierender Iwwerwaachung weisen an iergendwéi kritiséieren. Awer trotzdem wäert ech probéieren Marken net ze nennen fir keng Reklammen oder Anti-Reklammen fir dës Produkter ze kreéieren. Dofir sinn all Zoufall zoufälleg a ginn op Är Fantasi iwwerlooss.
Als éischt, loosst eis erausfannen wat Iwwerwaachung ass. Iwwerwaachung ass eng ganz wichteg Saach ze hunn. Jidderee versteet dat. Awer gläichzäiteg ass d'Iwwerwaachung net mat engem Geschäftsprodukt bezunn a beaflosst net direkt de Gewënn vun der Firma, sou datt d'Zäit ëmmer fir d'Iwwerwaachung op enger Reschtbasis zougewisen gëtt. Wa mir Zäit hunn, da maache mir Iwwerwaachung; wa mir keng Zäit hunn, dann OK, mir setzen et an de Réckstand an enges Daags komme mir zréck op dës Aufgaben.
Dofir, aus eiser Praxis, wa mir bei Cliente kommen, ass d'Iwwerwaachung dacks onkomplett an huet keng interessant Saachen, déi eis hëllefen eng besser Aarbecht mat der Datebank ze maachen. An dofir muss d'Iwwerwaachung ëmmer ofgeschloss ginn.
Datenbanken sinn esou komplex Saachen, déi och musse iwwerwaacht ginn, well Datenbanken e Repository vun Informatioun sinn. An Informatioun ass ganz wichteg fir d'Firma; et kann op kee Fall verluer ginn. Awer zur selwechter Zäit sinn Datenbanken ganz komplex Software Stécker. Si besteet aus enger grousser Zuel vu Komponenten. A vill vun dëse Komponente mussen iwwerwaacht ginn.
Wa mir speziell iwwer PostgreSQL schwätzen, da kann et a Form vun engem Schema vertruede sinn, deen aus enger grousser Zuel vu Komponenten besteet. Dës Komponente interagéieren mateneen. A gläichzäiteg huet PostgreSQL de sougenannte Stats Collector Subsystem, deen Iech erlaabt Statistiken iwwer d'Operatioun vun dësen Ënnersystemer ze sammelen an eng Aart Interface un den Administrateur oder de Benotzer ubidden, fir datt hien dës Statistike ka gesinn.
Dës Statistike ginn a Form vun enger bestëmmter Rei vu Funktiounen a Meenungen presentéiert. Si kënnen och Dëscher genannt ginn. Dat ass, andeems Dir e reguläre psql Client benotzt, kënnt Dir mat der Datebank verbannen, e Choix op dës Funktiounen a Meenungen maachen an e puer spezifesch Zuelen iwwer d'Operatioun vun de PostgreSQL Subsystemer kréien.
Dir kënnt dës Zuelen op Äre Liiblings Iwwerwaachungssystem addéieren, Grafike zéien, Funktiounen addéieren a laangfristeg Analyse kréien.
Awer an dësem Bericht wäert ech all dës Funktiounen net komplett ofdecken, well et de ganzen Dag kéint daueren. Ech wäert wuertwiertlech zwou, dräi oder véier Saachen adresséieren an Iech soen wéi se hëllefen d'Iwwerwaachung besser ze maachen.
A wa mir iwwer Datebank Iwwerwaachung schwätzen, wat muss dann iwwerwaacht ginn? Als éischt musse mir d'Disponibilitéit iwwerwaachen, well d'Datebank e Service ass, deen Zougang zu Daten u Clienten ubitt a mir mussen d'Disponibilitéit iwwerwaachen, an och e puer vu senge qualitativen a quantitative Charakteristiken ubidden.
Mir mussen och Clienten iwwerwaachen, déi mat eiser Datebank verbannen, well se souwuel normal Clientë wéi schiedlech Cliente kënne sinn, déi d'Datebank schueden kënnen. Si mussen och iwwerwaacht ginn an hir Aktivitéite verfollegt ginn.
Wann d'Clienten un d'Datebank verbannen, ass et evident datt se ufänken mat eisen Donnéeën ze schaffen, also musse mir iwwerwaachen wéi d'Clientë mat den Donnéeën schaffen: mat wéi enge Dëscher, a manner wéi mat wéi engem Index. Dat ass, mir mussen d'Aarbechtslaascht evaluéieren, déi vun eise Clienten erstallt gëtt.
Awer d'Aarbechtslaascht besteet natierlech och aus Ufroen. D'Applikatioune verbannen mat der Datebank, Zougang zu Daten mat Ufroen, also ass et wichteg ze evaluéieren wéi eng Ufroe mir an der Datebank hunn, hir Adäquatitéit ze iwwerwaachen, datt se net kromme geschriwwe sinn, datt e puer Optioune musse nei geschriwwe ginn a gemaach ginn fir datt se méi séier funktionnéieren a mat besser Leeschtung.
A well mir iwwer eng Datebank schwätzen, ass d'Datebank ëmmer Hannergrondprozesser. Hannergrondprozesser hëllefen d'Datebankleistung op engem gudden Niveau z'erhalen, sou datt se eng gewësse Quantitéit u Ressourcen erfuerderen fir sech selwer ze bedreiwen. A gläichzäiteg kënne se mat Client Ufro Ressourcen iwwerlappen, sou datt giereg Hannergrondprozesser direkt d'Leeschtung vun de Client Ufroe beaflossen. Dofir musse se och iwwerwaacht a verfollegt ginn, sou datt et keng Verzerrungen a punkto Hannergrondprozesser gëtt.
An dat alles wat d'Datebank Iwwerwaachung ugeet bleift an der Systemmetrik. Awer wann Dir bedenkt datt déi meescht vun eiser Infrastruktur op d'Wolleke beweegt, verschwannen d'Systemmetriken vun engem individuellen Host ëmmer an den Hannergrond. Awer an Datenbanken sinn se nach ëmmer relevant an natierlech ass et och noutwendeg fir Systemmetriken ze iwwerwaachen.
Alles ass méi oder manner gutt mat Systemmetriken, all modern Iwwerwaachungssystemer ënnerstëtzen dës Metriken schonn, awer allgemeng sinn e puer Komponenten nach ëmmer net genuch an e puer Saache mussen derbäigesat ginn. Ech wäert se och beréieren, et ginn e puer Rutschen iwwer si.
Den éischte Punkt vum Plang ass Accessibilitéit. Wat ass Accessibilitéit? Disponibilitéit a mengem Verständnis ass d'Fäegkeet vun der Basis fir Verbindungen ze servéieren, dh d'Basis gëtt erhéicht, et, als Service, akzeptéiert Verbindunge vu Clienten. An dës Accessibilitéit kann duerch gewësse Charakteristike bewäert ginn. Et ass ganz bequem dës Charakteristiken op Dashboards ze weisen.
Jidderee weess wat Dashboards sinn. Dëst ass wann Dir e Bléck op den Ecran gemaach hutt, op deem déi néideg Informatioun zesummegefaasst ass. An Dir kënnt direkt bestëmmen ob et e Problem an der Datebank ass oder net.
Deementspriechend sollten d'Disponibilitéit vun der Datebank an aner Schlësselcharakteristiken ëmmer op Dashboards ugewise ginn, sou datt dës Informatioun bei der Hand ass an ëmmer fir Iech verfügbar ass. E puer zousätzlech Detailer déi scho bei der Enquête vun Tëschefäll hëllefen, wann Dir e puer Noutsituatiounen ënnersicht, musse se schonn op sekundären Dashboards plazéiert ginn, oder an Drilldown Links verstoppt ginn, déi zu Drëtt Partei Iwwerwaachungssystemer féieren.
E Beispill vun engem bekannte Iwwerwachungssystem. Dëst ass e ganz coolen Iwwerwaachungssystem. Si sammelt vill Daten, awer aus menger Siicht huet si e komescht Konzept vun Dashboards. Et gëtt e Link fir "en Dashboard erstellen". Awer wann Dir en Dashboard erstellt, erstellt Dir eng Lëscht vun zwou Kolonnen, eng Lëscht vu Grafike. A wann Dir eppes muss kucken, fänkt Dir un mat der Maus ze klicken, ze scrollen, no der gewënschten Diagramm ze sichen. An dat brauch Zäit, also et gi keng Dashboards als solch. Et gi just Lëschte vun Charts.
Wat sollt Dir op dës Dashboards addéieren? Dir kënnt mat esou enger Charakteristik wéi Äntwertzäit ufänken. PostgreSQL huet d'pg_stat_statements Vue. Et ass par défaut deaktivéiert, awer et ass eng vun de wichtege System Meenungen déi ëmmer aktivéiert a benotzt solle ginn. Et späichert Informatioun iwwer all Lafen Ufroen déi an der Datebank ausgefouert goufen.
Deementspriechend kënne mir vun der Tatsaach ufänken datt mir d'total Ausféierungszäit vun all Ufroe kënne huelen an se mat der Unzuel vun Ufroe mat den uewe genannte Felder deelen. Awer dëst ass d'Duerchschnëttstemperatur am Spidol. Mir kënnen aus anere Felder ufänken - Minimum Ufro Ausféierung Zäit, Maximum a Median. A mir kënne souguer Prozenttile bauen; PostgreSQL huet entspriechend Funktiounen dofir. A mir kënnen e puer Zuelen kréien, déi d'Äntwertzäit vun eiser Datebank fir scho ofgeschloss Ufroe charakteriséieren, dh mir maachen net déi gefälscht Ufro 'wielt 1' aus a kucken d'Äntwertzäit, awer mir analyséieren d'Äntwertzäit fir scho fäerdeg Ufroen a zéien entweder eng separat Figur, oder mir bauen eng Grafik baséiert op et.
Et ass och wichteg d'Zuel vun de Feeler ze iwwerwaachen, déi am Moment vum System generéiert ginn. A fir dëst kënnt Dir d'pg_stat_database Vue benotzen. Mir konzentréieren eis op de xact_rollback Feld. Dëst Feld weist net nëmmen d'Zuel vun rollbacks datt an der Datebank geschéien, mä hëlt och Rechnung der Zuel vu Feeler. Relativ gesi kënne mir dës Figur an eisem Dashboard weisen a kucken wéivill Feeler mir am Moment hunn. Wann et vill Feeler ass, dann ass dat e gudde Grond fir an d'Logbicher ze kucken a kucken wéi eng Fehler et sinn a firwat se optrieden, an dann investéieren an se léisen.
Dir kënnt sou eppes wéi en Tachometer derbäi. Dëst sinn d'Zuel vun Transaktiounen pro Sekonn an d'Zuel vun Ufroen pro Sekonn. Relativ gesi kënnt Dir dës Zuelen als déi aktuell Leeschtung vun Ärer Datebank benotzen an beobachten ob et Peaks an Ufroen, Peaks bei Transaktiounen sinn oder, ëmgekéiert, ob d'Datebank ënnerlaascht ass well e puer Backend gescheitert ass. Et ass wichteg ëmmer dës Figur ze kucken an ze erënneren datt fir eise Projet dës Aart vu Leeschtung normal ass, awer d'Wäerter uewen an ënnen si schonn eng Zort problematesch an onverständlech, dat heescht datt mir musse kucken firwat dës Zuelen sinn sou héich.
Fir d'Zuel vun den Transaktiounen ze schätzen, kënne mir erëm op d'pg_stat_database Vue bezéien. Mir kënnen d'Zuel vun de Verpflichtungen an d'Zuel vun de Rollbacks addéieren an d'Zuel vun den Transaktiounen pro Sekonn kréien.
Versteet jiddereen datt verschidde Ufroe kënnen an eng Transaktioun passen? Dofir sinn TPS a QPS liicht anescht.
D'Zuel vun Demanden pro Sekonn kann aus pg_stat_statements kritt ginn an einfach d'Zomm vun all fäerdeg Demanden berechnen. Et ass kloer datt mir den aktuellen Wäert mat der viregter vergläichen, se subtrahéieren, den Delta kréien an d'Quantitéit kréien.
Dir kënnt zousätzlech Metriken addéieren wann Dir wëllt, déi och hëllefen d'Disponibilitéit vun eiser Datebank ze evaluéieren an ze iwwerwaachen ob et Stéierungen goufen.
Ee vun dëse Metriken ass Uptime. Awer Uptime am PostgreSQL ass e bësse komplizéiert. Ech soen Iech firwat. Wann PostgreSQL ugefaang huet, fänkt d'Uptime un ze berichten. Awer wann iergendwann, zum Beispill, eng Aufgab an der Nuecht leeft, ass en OOM-Killer komm an huet de PostgreSQL Kand Prozess gezwongen ofgeschloss, da schléisst PostgreSQL d'Verbindung vun alle Clienten of, reset de sharded Memory Area a fänkt d'Erhuelung un de leschte Kontrollpunkt. A wann dës Erhuelung vum Checkpoint dauert, akzeptéiert d'Datebank keng Verbindungen, dh dës Situatioun kann als Ausdauer bewäert ginn. Awer den Uptime Konter gëtt net zréckgesat, well et d'Startzäit vum Postmaster aus dem éischte Moment berücksichtegt. Dofir kënne sou Situatiounen iwwersprongen ginn.
Dir sollt och d'Zuel vun de Vakuumaarbechter iwwerwaachen. Wësst jiddereen wat Autovakuum am PostgreSQL ass? Dëst ass en interessant Subsystem am PostgreSQL. Vill Artikele sinn iwwer hatt geschriwwen, vill Berichter goufen gemaach. Et gi vill Diskussiounen iwwer Vakuum a wéi et soll funktionnéieren. Vill betruechten et als noutwendegt Béis. Awer esou ass et. Dëst ass eng Aart Analog vun engem Müllsammler, deen al Versioune vu Reihen botzt, déi net vun enger Transaktioun gebraucht ginn, a befreit Plaz an Tabellen an Indexen fir nei Reihen.
Firwat musst Dir et iwwerwaachen? Well de Vakuum deet heiansdo vill wéi. Et verbraucht eng grouss Quantitéit vu Ressourcen a Client Ufroe fänken un als Resultat ze leiden.
An et soll iwwerwaacht ginn duerch d'pg_stat_activity Vue, iwwer déi ech an der nächster Sektioun schwätzen. Dës Vue weist déi aktuell Aktivitéit an der Datebank. An duerch dës Aktivitéit kënne mir d'Zuel vun de Staubsauger verfollegen, déi elo schaffen. Mir kënne Vakuum verfollegen a gesinn datt wa mir d'Limite iwwerschratt hunn, dann ass dëst e Grond fir an d'PostgreSQL Astellungen ze kucken an iergendwéi d'Operatioun vum Vakuum ze optimiséieren.
Eng aner Feature vu PostgreSQL ass datt PostgreSQL ganz schmerzhaf ass mat laangen Transaktiounen. Besonnesch vun Transaktiounen déi laang hänken an näischt maachen. Dëst ass de sougenannte Stat Idle-in-Transaction. Sou eng Transaktioun hält Spären a verhënnert datt de Vakuum funktionnéiert. An als Resultat schwellen d'Dëscher an d'Gréisst vergréisseren. A Ufroen, déi mat dësen Dëscher schaffen, fänken un méi lues ze schaffen, well Dir musst all déi al Versioune vu Reihen vun der Erënnerung op d'Disk an zréck schaafen. Dofir muss d'Zäit, d'Dauer vun de längsten Transaktiounen, déi längste Vakuum Ufroen och iwwerwaacht ginn. A wa mir e puer Prozesser gesinn, déi fir eng ganz laang Zäit lafen, scho méi wéi 10-20-30 Minutten fir eng OLTP-Laascht, da musse mir op se oppassen an se kräfteg ofschléissen, oder d'Applikatioun optimiséieren sou datt se ginn net genannt an hänken net sou laang. Fir eng analytesch Aarbechtsbelaaschtung sinn 10-20-30 Minutten normal; et ginn och méi laang.
Als nächst hu mir d'Optioun mat verbonne Clienten. Wa mir schonn en Dashboard erstallt hunn a Schlësselverfügbarkeetsmetriken drop gepost hunn, kënne mir och zousätzlech Informatioun iwwer verbonne Clienten do addéieren.
Informatioun iwwer verbonne Clienten ass wichteg well, aus enger PostgreSQL Perspektiv, Clienten anescht sinn. Et gi gutt Clienten an et gi schlecht Clienten.
En einfacht Beispill. Mam Client verstinn ech d'Applikatioun. D'Applikatioun huet mat der Datebank ugeschloss an fänkt direkt un hir Ufroen dohinner ze schécken, d'Datebank veraarbecht an ausféiert se, a bréngt d'Resultater un de Client zréck. Dëst si gutt a korrekt Clienten.
Et gi Situatiounen wou de Client ugeschloss huet, et hält d'Verbindung, awer mécht näischt. Et ass am Idle Staat.
Awer et gi schlecht Clienten. Zum Beispill huet dee selwechte Client ugeschloss, eng Transaktioun opgemaach, eppes an der Datebank gemaach an duerno an de Code gaang, zum Beispill, fir Zougang zu enger externer Quell oder fir déi kritt Donnéeën do ze veraarbecht. Awer hien huet d'Transaktioun net zougemaach. An d'Transaktioun hänkt an der Datebank a gëtt an engem Spär op der Linn ofgehalen. Dëst ass e schlechten Zoustand. A wann op eemol eng Applikatioun iergendwou bannen selwer mat enger Ausnam feelt, da kann d'Transaktioun fir eng ganz laang Zäit oppe bleiwen. An dëst beaflosst direkt d'PostgreSQL Leeschtung. PostgreSQL wäert méi lues sinn. Dofir ass et wichteg esou Clienten op eng fristgerecht Manéier ze verfolgen an hir Aarbecht mat Kraaft opzehalen. An Dir musst Är Applikatioun optimiséieren sou datt esou Situatiounen net optrieden.
Aner schlecht Clienten waarden Clienten. Awer si ginn schlecht wéinst Ëmstänn. Zum Beispill, eng einfach Idle Transaktioun: et kann eng Transaktioun opmaachen, Spären op e puer Zeilen huelen, dann iergendwou am Code wäert et versoen, loosst eng hängend Transaktioun. En anere Client wäert kommen an déiselwecht Donnéeën froen, awer hien wäert e Spär begéinen, well dës hängend Transaktioun scho Spären op e puer erfuerderlech Reihen hält. An déi zweet Transaktioun hänke ronderëm a waart bis déi éischt Transaktioun fäerdeg ass oder se vum Administrateur gezwongen zoumaachen. Dofir kënnen ofhängeg Transaktiounen d'Datebankverbindungslimit accumuléieren an ausfëllen. A wann d'Limite voll ass, kann d'Applikatioun net méi mat der Datebank schaffen. Dëst ass schonn eng Noutsituatioun fir de Projet. Dofir musse schlecht Clientë verfollegt ginn a fristgerecht reagéiert ginn.
En anert Beispill vu Iwwerwaachung. An et gëtt schonn en anstännegen Dashboard hei. Et gëtt Informatioun iwwer Verbindungen uewen. DB Verbindung - 8 Stéck. An et ass alles. Mir hu keng Informatioun iwwer wéi eng Clienten aktiv sinn, wéi eng Cliente just Idle sinn, näischt maachen. Et gëtt keng Informatioun iwwer pending Transaktiounen an pending Verbindungen, dh dëst ass eng Figur déi d'Zuel vun de Verbindungen weist an dat ass et. An dann roden Iech selwer.
Deementspriechend, fir dës Informatioun un d'Iwwerwaachung ze addéieren, musst Dir op d'pg_stat_activity System Vue opgoen. Wann Dir vill Zäit am PostgreSQL verbréngt, dann ass dëst eng ganz gutt Vue déi Äre Frënd sollt ginn, well et weist déi aktuell Aktivitéit am PostgreSQL, dh wat dran geschitt. Fir all Prozess gëtt et eng separat Linn déi Informatioun iwwer dëse Prozess weist: vu wéi engem Host d'Verbindung gemaach gouf, ënner wéi engem Benotzer, ënner wéi engem Numm, wéini d'Transaktioun gestart gouf, wéi eng Ufro am Moment leeft, wéi eng Ufro fir d'lescht ausgefouert gouf. An deementspriechend kënne mir de Staat vum Client evaluéieren mam Stat Feld. Relativ gesi kënne mir no dësem Feld gruppéieren an déi Statistiken kréien déi momentan an der Datebank sinn an d'Zuel vun de Verbindungen déi dës Stat an der Datebank hunn. A mir kënnen déi scho kritt Zuelen un eis Iwwerwachung schécken a Grafike zéien baséiert op hinnen.
Et ass och wichteg d'Dauer vun der Transaktioun ze evaluéieren. Ech hu scho gesot datt et wichteg ass d'Dauer vu Vakuum ze evaluéieren, awer Transaktiounen ginn an der selwechter Manéier bewäert. Et gi xact_start a query_start Felder. Si, relativ gesinn, weisen d'Startzäit vun der Transaktioun an d'Startzäit vun der Ufro. Mir huelen d'Funktioun elo (), déi den aktuellen Zäitstempel weist, an d'Transaktioun subtrahéieren an Zäitstempel froen. A mir kréien d'Dauer vun der Transaktioun, d'Dauer vun der Ufro.
Wa mir laang Transaktioune gesinn, solle mir se scho fäerdeg maachen. Fir eng OLTP-Laascht sinn laang Transaktioune scho méi wéi 1-2-3 Minutten. Fir eng OLAP Aarbechtsbelaaschtung sinn laang Transaktiounen normal, awer wa se méi wéi zwou Stonnen daueren fir ze kompletéieren, dann ass dat och en Zeechen datt mir iergendwou e Schief hunn.
Wann d'Clienten un d'Datebank verbonne sinn, fänken se un mat eisen Daten ze schaffen. Si kréien Zougang zu Dëscher, si kréien Zougang zu Indexen fir Daten aus dem Dësch ze kréien. An et ass wichteg ze evaluéieren wéi Cliente mat dësen Donnéeën interagéieren.
Dëst ass néideg fir eis Aarbechtsbelaaschtung ze evaluéieren an ongeféier ze verstoen wéi eng Dëscher déi "waarmst" fir eis sinn. Zum Beispill ass dëst gebraucht a Situatiounen wou mir "waarm" Dëscher op eng Aart vu schnelle SSD-Späichere wëllen placéieren. Zum Beispill, e puer Archivtabellen, déi mir fir eng laang Zäit net benotzt hunn, kënnen op eng Zort "kal" Archiv geplënnert ginn, op SATA fiert a loosst se do liewen, si ginn zougänglech wéi néideg.
Dëst ass och nëtzlech fir Anomalien no all Verëffentlechungen an Deployementer z'entdecken. Loosst eis soen datt de Projet e puer nei Feature verëffentlecht huet. Zum Beispill hu mir nei Funktionalitéit bäigefüügt fir mat der Datebank ze schaffen. A wa mir Tabelle benotzt Grafike plotten, kënne mir dës Anomalien einfach op dëse Grafike entdecken. Zum Beispill update Bursts oder läschen Bursts. Et wäert ganz siichtbar sinn.
Dir kënnt och Anomalien an "floating" Statistiken entdecken. Wat heescht dat? PostgreSQL huet e ganz staarken a ganz gudden Ufroplaner. An d'Entwéckler widmen vill Zäit fir seng Entwécklung. Wéi funktionéiert hien? Fir gutt Pläng ze maachen, sammelt PostgreSQL Statistiken iwwer d'Verdeelung vun Daten an Tabellen zu engem gewëssen Zäitintervall a mat enger gewësser Frequenz. Dëst sinn déi heefegst Wäerter: d'Zuel vun eenzegaartege Wäerter, Informatioun iwwer NULL an der Tabell, vill Informatioun.
Baséierend op dës Statistiken konstruéiert de Planner verschidde Ufroen, wielt déi optimalst a benotzt dësen Ufroplang fir d'Ufro selwer auszeféieren an Daten zréckzeginn.
An et geschitt datt d'Statistiken "schwammen". D'Qualitéit an d'Quantitéitsdaten hunn iergendwéi an der Tabell geännert, awer d'Statistike goufen net gesammelt. An déi geformt Pläng kënnen net optimal sinn. A wann eis Pläng suboptimal ginn op Basis vun der gesammelter Iwwerwaachung, baséiert op den Dëscher, kënne mir dës Anomalien gesinn. Zum Beispill, iergendwou hunn d'Daten qualitativ geännert an amplaz vum Index huet e sequentielle Pass duerch den Dësch ugefaang ze benotzen, d.h. wann eng Ufro just 100 Zeile muss zréckginn (et gëtt eng Limit vun 100), da gëtt eng komplett Sich fir dës Ufro gemaach. An dat huet ëmmer e ganz schlechten Effekt op d'Leeschtung.
A mir kënnen dat an der Iwwerwaachung gesinn. A kuckt schonn op dës Ufro, lafen eng Erklärung dofir, sammelen Statistiken, bauen en neien zousätzlechen Index. A schonn op dëse Problem reagéieren. Dofir ass et wichteg.
En anert Beispill vu Iwwerwaachung. Ech denken, datt vill Leit hien unerkannt hunn, well hie ganz populär ass. Wien et an hire Projeten benotzt ? Wien benotzt dëst Produkt a Verbindung mat Prometheus? D'Tatsaach ass datt am Standard Repository vun dëser Iwwerwaachung en Dashboard ass fir mat PostgreSQL ze schaffen - Prometheus. Awer et gëtt e schlechten Detail.
Et gi verschidde Grafike. A Bytes ginn als Eenheet uginn, dh et gi 5 Grafike. Dëst sinn Daten setzen, Daten aktualiséieren, Daten läschen, Daten erofhuelen an Daten zréckginn. D'Eenheetmiessung ass Bytes. Awer d'Saach ass datt Statistiken am PostgreSQL Daten an Tuple (Reihen) zréckginn. An deementspriechend sinn dës Grafike e ganz gudde Wee fir Är Aarbechtsbelaaschtung e puer Mol, zéng Mol ze ënnerschätzen, well en Tuple ass kee Byte, en Tuple ass e String, et ass vill Bytes an et ass ëmmer vun variabelen Längt. Dat ass, d'Berechnung vun der Aarbechtsbelaaschtung a Bytes mat Tuples ass eng onrealistesch Aufgab oder ganz schwéier. Dofir, wann Dir en Dashboard oder agebaute Iwwerwaachung benotzt, ass et ëmmer wichteg ze verstoen datt et richteg funktionnéiert an Iech korrekt bewäerten Donnéeën zréckginn.
Wéi kréien ech Statistiken op dës Dëscher? Fir dësen Zweck huet PostgreSQL eng gewësse Famill vu Meenungen. An den Haaptgrond Vue ass . User_tables - dat heescht Dëscher am Numm vum Benotzer erstallt. Am Géigesaz, ginn et System Meenungen déi vu PostgreSQL selwer benotzt ginn. An et gëtt e Resumétabel Alltables, déi souwuel System wéi och Benotzer enthält. Dir kënnt vun all vun hinnen ufänken, datt Dir am beschte gefall.
Mat Hëllef vun den uewe genannte Felder kënnt Dir d'Zuel vun Inserts, Updates a Läschen schätzen. D'Beispill vun engem Dashboard, deen ech benotzt hunn, benotzt dës Felder fir d'Charakteristike vun enger Aarbechtslaascht ze evaluéieren. Dofir kënne mir och op hinnen bauen. Awer et ass derwäert ze erënneren datt dëst Tuples sinn, net Bytes, sou datt mir et net nëmmen an Bytes maachen.
Baséierend op dësen Donnéeën kënne mir sougenannte TopN Dëscher bauen. Zum Beispill, Top-5, Top-10. An Dir kënnt déi waarm Dëscher verfollegen, déi méi wéi anerer verwäert ginn. Zum Beispill, 5 "waarm" Dëscher fir Aféierung. A mat dësen TopN Dëscher evaluéieren mir eis Aarbechtsbelaaschtung a kënne Bursts vun der Aarbechtslaascht no all Verëffentlechungen, Updates an Deployementer evaluéieren.
Et ass och wichteg d'Gréisst vum Dësch ze evaluéieren, well heiansdo d'Entwéckler eng nei Feature ausrollen, an eis Dëscher fänken un hir grouss Gréissten ze schwellen, well se decidéiert hunn eng zousätzlech Quantitéit un Daten derbäi ze ginn, awer net virausgesot hunn wéi dëst géif Afloss op d'Gréisst vun der Datebank. Esou Fäll kommen eis och als Iwwerraschung.
An elo eng kleng Fro fir Iech. Wéi eng Fro stellt sech wann Dir d'Laascht op Ärem Datebankserver bemierkt? Wat ass déi nächst Fro déi Dir hutt?
Awer tatsächlech stellt sech d'Fro wéi follegt. Wéi eng Ufroe verursaacht d'Laascht? Dat ass, et ass net interessant d'Prozesser ze kucken, déi duerch d'Laascht verursaacht ginn. Et ass kloer datt wann den Host eng Datebank huet, da leeft d'Datebank do an et ass kloer datt nëmmen d'Datenbanken do entsuergt ginn. Wa mir Top opmaachen, gesi mir do eng Lëscht vu Prozesser am PostgreSQL déi eppes maachen. Et wäert vun Top net kloer sinn wat se maachen.
Deementspriechend musst Dir dës Ufroen fannen, déi déi héchst Belaaschtung verursaachen, well Tuning Ufroen, als Regel, méi Gewënn gëtt wéi d'Konfiguratioun vum PostgreSQL oder d'Betriebssystem, oder souguer d'Hardware ofstëmmen. No menger Schätzung ass dëst ongeféier 80-85-90%. An dat gëtt vill méi séier gemaach. Et ass méi séier eng Ufro ze korrigéieren wéi d'Konfiguratioun ze korrigéieren, e Restart ze plangen, besonnesch wann d'Datebank net nei gestart ka ginn oder Hardware derbäigesat. Et ass méi einfach d'Ufro iergendwou ëmzeschreiwen oder en Index derbäi ze ginn fir e bessert Resultat vun dëser Ufro ze kréien.
Deementspriechend ass et néideg Ufroen an hir Adäquatitéit ze iwwerwaachen. Loosst eis en anert Beispill vun der Iwwerwaachung huelen. An och hei schéngt et eng excellent Iwwerwaachung ze ginn. Et gëtt Informatioun iwwer Replikatioun, et gëtt Informatioun iwwer Duerchsatz, Blockéierung, Ressourcenutzung. Alles ass gutt, awer et gëtt keng Informatioun iwwer Ufroen. Et ass net kloer wéi eng Ufroen an eiser Datebank lafen, wéi laang se lafen, wéi vill vun dësen Ufroe sinn. Mir mussen dës Informatioun ëmmer an eiser Iwwerwaachung hunn.
A fir dës Informatioun ze kréien kënne mir de Modul pg_stat_statements benotzen. Baséierend op et kënnt Dir eng Vielfalt vu Grafike bauen. Zum Beispill kënnt Dir Informatiounen iwwer déi heefegst Ufroen kréien, dat heescht iwwer déi Ufroen déi am meeschten ausgefouert ginn. Jo, no Installatiounen ass et och ganz nëtzlech et ze kucken an ze verstoen ob et e Stroum an Ufroe gëtt.
Dir kënnt déi längste Ufroen iwwerwaachen, dat heescht déi Ufroen déi am längsten daueren fir ze kompletéieren. Si lafen op de Prozessor, si verbrauchen I / O. Mir kënnen dat och mat de Felder total_time, mean_time, blk_write_time an blk_read_time evaluéieren.
Mir kënnen déi schwéierst Ufroe wat d'Ressourceverbrauch ugeet evaluéieren an iwwerwaachen, déi vun der Disk liesen, déi mat Erënnerung schaffen, oder, ëmgekéiert, eng Aart vu Schreiflaascht erstellen.
Mir kënnen déi generéisst Ufroe bewäerten. Dëst sinn d'Ufroen déi eng grouss Zuel vu Reihen zréckginn. Zum Beispill kann dëst eng Ufro sinn, wou se vergiess hunn eng Limit ze setzen. An et gëtt einfach de ganzen Inhalt vun der Tabell oder Ufro iwwer déi ugefrote Dëscher zréck.
An Dir kënnt och Ufroen iwwerwaachen déi temporär Dateien oder temporär Dëscher benotzen.
A mir hunn nach ëmmer Hannergrondprozesser. Hannergrondprozesser si primär Kontrollpunkte oder si ginn och Kontrollpunkte genannt, dëst sinn Autovakuum a Replikatioun.
En anert Beispill vu Iwwerwaachung. Et gëtt en Maintenance Tab op der lénker Säit, gitt dohinner an hoffen eppes nëtzlech ze gesinn. Awer hei ass nëmmen d'Zäit vun der Vakuumoperatioun an der Statistiksammlung, näischt méi. Dëst ass ganz schlecht Informatioun, also musse mir ëmmer Informatioun hunn iwwer wéi Hannergrondprozesser an eiser Datebank funktionnéieren an ob et Problemer aus hirer Aarbecht gëtt.
Wa mir Checkpoints kucken, solle mir drun erënneren datt Checkpoints dreckeg Säiten aus dem sharded Erënnerungsberäich op Scheif spülen, dann e Checkpoint erstellen. An dëse Kontrollpunkt kann dann als Plaz fir Erhuelung benotzt ginn wann PostgreSQL plötzlech an engem Noutfall ofgeschloss gouf.
Deementspriechend, fir all "dreckeg" Säiten op Disk ze spülen, musst Dir e gewësse Betrag u Schreiwen maachen. An, als Regel, op Systemer mat grousse Quantitéiten vun Erënnerung, ass et vill. A wa mir Checkpoints ganz dacks an engem kuerzen Intervall maachen, da wäert d'Performance vun der Disk ganz däitlech erofgoen. A Client Ufroe wäerten ënner Mangel u Ressourcen leiden. Si wäerte fir Ressourcen konkurréiere a Mangel un Produktivitéit.
Deementspriechend, duerch pg_stat_bgwriter déi spezifizéiert Felder benotzt kënne mir d'Zuel vun de Kontrollpunkten iwwerwaachen déi optrieden. A wa mir iwwer eng gewëssen Zäit vill Kontrollpunkten hunn (an 10-15-20 Minutten, an enger hallwer Stonn), zum Beispill 3-4-5, da kann dat schonn e Problem sinn. An Dir musst schonn an der Datebank kucken, kuckt an der Konfiguratioun, wat verursaacht esou en Iwwerfloss vu Kontrollpunkten. Vläicht ass et eng Aart vu groussen Opnahmen lass. Mir kënnen d'Aarbechtslaascht scho evaluéieren, well mir scho Workload Grafike bäigefüügt hunn. Mir kënnen d'Kontrollpunktparameter scho tweaken a sécherstellen datt se d'Queryleistung net vill beaflossen.
Ech kommen erëm op den Autovakuum zréck well et esou eng Saach ass, wéi ech gesot hunn, déi d'Performance vun der Disk an d'Ufroen ganz einfach ka addéieren, also ass et ëmmer wichteg d'Quantitéit vum Autovakuum ze schätzen.
D'Zuel vun den Autovakuumaarbechter an der Datebank ass limitéiert. Par défaut sinn et dräi vun hinnen, also wa mir ëmmer dräi Aarbechter an der Datebank hunn, heescht dat datt eisen Autovakuum net konfiguréiert ass, mir mussen d'Limiten erhéijen, d'Autovakuum-Astellungen iwwerschaffen an an d'Konfiguratioun kommen.
Et ass wichteg ze evaluéieren wéi eng Vakuumaarbechter mir hunn. Entweder gouf et vum Benotzer lancéiert, d'DBA koum an huet manuell eng Aart Vakuum gestart, an dëst huet eng Laascht erstallt. Mir hunn eng Zort Problem. Oder dëst ass d'Zuel vun de Staubsauger déi den Transaktiounszähler ofschrauwen. Fir e puer Versioune vu PostgreSQL sinn dës ganz schwéier Staubsauger. A si kënnen d'Leeschtung ganz einfach addéieren well se de ganzen Dësch liesen, all d'Blöcke an där Tabell scannen.
An, natierlech, d'Dauer vun Vakuums. Wa mir laang dauerhafte Staubsauger hunn, déi ganz laang lafen, heescht dat, datt mir erëm op d'Vakuumkonfiguratioun oppassen a vläicht seng Astellungen iwwerdenken. Well eng Situatioun kann entstoen wann de Vakuum laang op den Dësch funktionnéiert (3-4 Stonnen), awer während der Zäit wou de Vakuum geschafft huet, konnten eng grouss Quantitéit vun doudege Reihen erëm an den Dësch accumuléieren. A soubal de Vakuum fäerdeg ass, muss hien dësen Dësch erëm Vakuum maachen. A mir kommen zu enger Situatioun - en endlosen Vakuum. An an dësem Fall këmmert de Vakuum net mat senger Aarbecht, an d'Dëscher fänken lues a lues an der Gréisst ze schwellen, obwuel de Volume vun nëtzlechen Donnéeën dran d'selwecht bleift. Dofir, während laange Vakuums, kucken mir ëmmer op d'Konfiguratioun a probéieren se ze optimiséieren, awer gläichzäiteg sou datt d'Leeschtung vu Client Ufroen net leiden.
Hautdesdaags gëtt et praktesch keng PostgreSQL Installatioun déi keng Streaming Replikatioun huet. Replikatioun ass de Prozess fir Daten vun engem Master op eng Replika ze réckelen.
Replikatioun am PostgreSQL gëtt duerch e Transaktiounslog gemaach. De Wizard generéiert en Transaktiounsprotokoll. D'Transaktiounsprotokoll reest iwwer d'Netzverbindung op d'Replica, an da gëtt et op der Replik reproduzéiert. Et ass einfach.
Deementspriechend gëtt d'pg_stat_replication Vue benotzt fir d'Replikatiounslag ze iwwerwaachen. Awer net alles ass einfach mat hatt. An der Versioun 10 huet d'Vue verschidde Ännerunge gemaach. Als éischt sinn e puer Felder ëmbenannt ginn. An e puer Felder goufen dobäi. An der Versioun 10 sinn Felder opgetaucht déi Iech erlaben d'Replikatiounslag a Sekonnen ze schätzen. Et ass ganz bequem. Virun Versioun 10 war et méiglech d'Replikatiounslag a Bytes ze schätzen. Dës Optioun bleift an der Versioun 10, dh Dir kënnt wielen wat méi bequem ass fir Iech - schätzt d'Laag an Bytes oder schätzt d'Laag a Sekonnen. Vill Leit maachen souwuel.
Awer trotzdem, fir d'Replikatiounslag ze evaluéieren, musst Dir d'Positioun vum Logbuch an der Transaktioun wëssen. An dës Transaktiounsprotokollpositioune si genee an der pg_stat_replication Vue. Relativ gesinn, kënne mir zwee Punkten am Transaktiounsprotokoll huelen mat der Funktioun pg_xlog_location_diff (). Berechent den Delta tëscht hinnen a kritt d'Replikatiounslag a Bytes. Et ass ganz bequem an einfach.
An der Versioun 10 gouf dës Funktioun op pg_wal_lsn_diff ëmbenannt (). Am Allgemengen, an all Funktiounen, Meenungen an Utilities, wou d'Wuert "xlog" erschéngt, gouf et mam Wäert "wal" ersat. Dëst gëllt souwuel fir Meenungen a Funktiounen. Dëst ass sou eng Innovatioun.
Plus, an der Versioun 10, goufen Linnen bäigefüügt, déi speziell d'Laag weisen. Dëst sinn Schreiflag, Flush Lag, Replay Lag. Dat ass, et ass wichteg dës Saachen ze iwwerwaachen. Wa mir gesinn datt mir eng Replikatiounslag hunn, da musse mir ënnersichen firwat et erschéngt, wou et hierkënnt an de Problem fixéieren.
Bal alles ass an Uerdnung mat System Metriken. Wann all Iwwerwaachung ufänkt, fänkt et mat Systemmetriken un. Dëst ass d'Entsuergung vu Prozessoren, Erënnerung, Swap, Netzwierk an Disk. Wéi och ëmmer, vill Parameteren sinn net standardiséiert.
Wann alles an der Rei ass mam Recyclingprozess, da ginn et Probleemer mat Disk Recycling. Als Regel, Iwwerwachung Entwéckler derbäi Informatiounen iwwert Débit. Et kann an iops oder Bytes sinn. Awer si vergiessen d'Latenz an d'Benotzung vun Disk-Geräter. Dëst si méi wichteg Parameteren déi eis erlaben ze evaluéieren wéi gelueden eis Disks sinn a wéi lues se sinn. Wa mir eng héich latency hunn, heescht dat datt et e puer Probleemer mat den Disken sinn. Wa mir eng héich Notzung hunn, heescht et datt d'Disken net bewältegen. Dëst si besser Charakteristiken wéi Duerchsatz.
Ausserdeem kënnen dës Statistiken och aus dem / proc Dateisystem kritt ginn, sou wéi et fir Recyclingprozessoren gemaach gëtt. Ech weess net firwat dës Informatioun net zur Iwwerwaachung bäigefüügt gëtt. Awer trotzdem ass et wichteg dëst an Ärer Iwwerwaachung ze hunn.
Dat selwecht gëllt fir Netzwierkschnëttplazen. Et gëtt Informatioun iwwer Netzduerchgang a Paketen, a Bytes, awer trotzdem gëtt et keng Informatioun iwwer latency a keng Informatioun iwwer d'Benotzung, obwuel dëst och nëtzlech Informatioun ass.
All Iwwerwaachung huet Nodeeler. An egal wéi eng Iwwerwaachung Dir maacht, et wäert ëmmer e puer Critèren entspriechen. Awer trotzdem entwéckelen se, nei Features an nei Saachen ginn derbäi, also wielt eppes a fäerdeg et.
A fir fäerdeg ze sinn, musst Dir ëmmer eng Iddi hunn wat d'Statistike bedeiten a wéi Dir se benotze kënnt fir Probleemer ze léisen.
An e puer Schlësselpunkten:
- Dir sollt ëmmer d'Disponibilitéit iwwerwaachen an Dashboards hunn, fir datt Dir séier beurteelen kënnt datt alles an der Rei ass mat der Datebank.
- Dir musst ëmmer eng Ahnung hunn wat Cliente mat Ärer Datebank schaffen fir schlecht Clienten erauszekréien an se erof ze schéissen.
- Et ass wichteg ze evaluéieren wéi dës Cliente mat Daten schaffen. Dir musst eng Iddi iwwer Är Aarbechtsbelaaschtung hunn.
- Et ass wichteg ze evaluéieren wéi dës Aarbechtslaascht geformt gëtt, mat der Hëllef vu wéi enger Ufroen. Dir kënnt Ufroen evaluéieren, Dir kënnt se optimiséieren, se refactoréieren, Indexe fir si bauen. Et ass ganz wichteg.
- Hannergrondprozesser kënnen negativ Client Ufroe beaflossen, also ass et wichteg ze iwwerwaachen datt se net ze vill Ressourcen benotzen.
- System Metriken erlaben Iech Pläng ze maachen fir d'Skaléierung an d'Erhéijung vun der Kapazitéit vun Äre Serveren, also ass et wichteg se ze verfolgen an ze evaluéieren.
Wann Dir un dësem Thema interesséiert sidd, da kënnt Dir dës Linken verfollegen.
- dëst ass offiziell Dokumentatioun vum Statistiksammler. Et gëtt eng Beschreiwung vun all statisteschen Usiichten an eng Beschreiwung vun alle Felder. Dir kënnt se liesen, verstoen an analyséieren. A baséiert op hinnen, baut Är Grafike a füügt se op Är Iwwerwaachung.
Beispill Ufroen:
Dëst ass eise Firme Repository a meng eegen. Si enthalen Beispiller Ufroen. Et gi keng Ufroe vun der Auswiel* aus der Serie do. Et gi scho fäerdeg Ufroe mat Joins, mat interessante Funktiounen, déi Iech erlaben rau Zuelen a liesbar, praktesch Wäerter ëmzewandelen, dh dat sinn Bytes, Zäit. Dir kënnt se ophuelen, kucken, analyséieren, addéieren se op Är Iwwerwaachung, bauen Är Iwwerwachung baséiert op hinnen.
Är Froen
Fro: Dir sot Dir wäert Marken net annoncéieren, awer ech sinn ëmmer nach virwëtzeg - wéi eng Dashboards benotzt Dir an Äre Projeten?
Äntwert: Et variéiert. Et geschitt, datt mir zu engem Client kommen an hien huet schonn seng eege Iwwerwachung. A mir beroden de Client iwwer wat fir hir Iwwerwaachung bäigefüügt muss ginn. Déi schlëmmste Situatioun ass mam Zabbix. Well et net d'Fäegkeet huet TopN Grafiken ze bauen. Mir selwer benotzen , well mir mat dëse Kärelen iwwer Iwwerwaachung konsultéiert hunn. Si iwwerwaacht PostgreSQL baséiert op eisen technesche Spezifikatioune. Ech schreiwen mäin eegene Hausdéierprojet, deen Daten iwwer Prometheus sammelt a se erabréngen . Meng Aufgab ass mäin eegenen Exportateur am Prometheus ze kreéieren an dann alles zu Grafana ze maachen.
Fro: Ginn et Analoga vun AWR Berichter oder ... Aggregatioun? Wësst Dir iwwer sou eppes?
Äntwert: Jo, ech weess wat AWR ass, et ass eng cool Saach. Am Moment ginn et eng Vielfalt vu Veloen déi ongeféier de folgende Modell implementéieren. Mat e puer Zäitintervall ginn e puer Baselines op déiselwecht PostgreSQL geschriwwe oder op eng separat Späichere. Dir kënnt se um Internet google, si sinn do. Ee vun den Entwéckler vun esou enger Saach sëtzt um sql.ru Forum am PostgreSQL thread. Dir kënnt hien do fänken. Jo, et ginn esou Saachen, si kënne benotzt ginn. Plus an hirem Ech schreiwen och eng Saach déi Iech erlaabt datselwecht ze maachen.
PS1 Wann Dir postgres_exporter benotzt, wat Dashboard benotzt Dir? Et ginn e puer vun hinnen. Si sinn scho veroudert. Vläicht wäert d'Gemeinschaft eng aktualiséiert Schabloun erstellen?
PS2 Geläscht pganalyze well et eng propriétaire SaaS Offer ass déi sech op Performance Iwwerwaachung an automatiséiert Tuning Suggestiounen konzentréiert.
Nëmme registréiert Benotzer kënnen un der Ëmfro deelhuelen. , wann ech glift.
Wéi eng selbsthostéiert Postgresql Iwwerwaachung (mat Dashboard) mengt Dir am Beschten?
-
30,0%Zabbix + Ergänzunge vum Alexey Lesovsky oder zabbix 4.4 oder 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 ass e propriétaire SaaS - ech kann et net läschen1
-
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 Benotzer hunn gestëmmt. 26 Benotzer hu sech enthalen.
Source: will.com