Awgrymaf ichi ddarllen trawsgrifiad yr adroddiad gan Alexey Lesovsky o Data Egret “Hanfodion monitro PostgreSQL”
Yn yr adroddiad hwn, bydd Alexey Lesovsky yn siarad am bwyntiau allweddol ystadegau ôl-fynediad, yr hyn y maent yn ei olygu, a pham y dylent fod yn bresennol wrth fonitro; am ba graffiau ddylai fod yn y monitro, sut i'w hychwanegu a sut i'w dehongli. Bydd yr adroddiad yn ddefnyddiol i weinyddwyr cronfa ddata, gweinyddwyr system a datblygwyr sydd â diddordeb mewn datrys problemau Postgres.
Fy enw i yw Alexey Lesovsky, rwy'n cynrychioli cwmni Data Egret.
Ychydig eiriau amdanaf fy hun. Dechreuais amser maith yn ôl fel gweinyddwr system.
Roeddwn yn gweinyddu pob math o systemau Linux gwahanol, yn gweithio ar wahanol bethau yn ymwneud â Linux, h.y. rhithwiroli, monitro, gweithio gyda dirprwyon, ac ati. Ond ar ryw adeg dechreuais weithio mwy gyda chronfeydd data, PostgreSQL. Roeddwn i'n hoff iawn ohono. Ac ar ryw adeg dechreuais weithio ar PostgreSQL y rhan fwyaf o fy amser gwaith. Ac felly yn raddol deuthum yn DBA PostgreSQL.
A thrwy gydol fy ngyrfa, rwyf bob amser wedi bod â diddordeb ym mhynciau ystadegau, monitro, a thelemetreg. A phan oeddwn yn weinyddwr system, gweithiais yn agos iawn gyda Zabbix. Ac ysgrifennais set fach o sgriptiau fel . Yr oedd yn bur boblogaidd yn ei amser. Ac yno roedd yn bosibl monitro pethau pwysig gwahanol iawn, nid yn unig Linux, ond hefyd amrywiol gydrannau.
Nawr rwy'n gweithio ar PostgreSQL. Rwyf eisoes yn ysgrifennu peth arall sy'n eich galluogi i weithio gydag ystadegau PostgreSQL. Fe'i gelwir (erthygl ar Habré - ).
Nodyn rhagarweiniol bach. Pa sefyllfaoedd sydd gan ein cwsmeriaid, ein cleientiaid? Mae rhyw fath o ddamwain yn gysylltiedig â'r gronfa ddata. A phan fydd y gronfa ddata eisoes wedi’i hadfer, daw pennaeth yr adran neu’r pennaeth datblygu i ddweud: “Gyfeillion, mae angen inni fonitro’r gronfa ddata, oherwydd digwyddodd rhywbeth drwg ac mae angen atal hyn rhag digwydd yn y dyfodol.” Ac yma mae'r broses ddiddorol o ddewis system fonitro neu addasu system fonitro bresennol yn dechrau fel y gallwch fonitro'ch cronfa ddata - PostgreSQL, MySQL neu rai eraill. Ac mae cydweithwyr yn dechrau awgrymu: “Clywais fod cronfa ddata o'r fath. Gadewch i ni ei ddefnyddio." Mae cydweithwyr yn dechrau dadlau â'i gilydd. Ac yn y diwedd mae'n troi allan ein bod yn dewis rhyw fath o gronfa ddata, ond mae monitro PostgreSQL yn cael ei gyflwyno ynddo braidd yn wael ac mae'n rhaid i ni ychwanegu rhywbeth bob amser. Cymerwch rai ystorfeydd o GitHub, eu clonio, addasu sgriptiau, a'u haddasu rywsut. Ac yn y diwedd mae'n rhyw fath o waith llaw.
Felly, yn y sgwrs hon byddaf yn ceisio rhoi rhywfaint o wybodaeth i chi ar sut i ddewis monitro nid yn unig ar gyfer PostgreSQL, ond hefyd ar gyfer y gronfa ddata. A rhoi'r wybodaeth i chi a fydd yn caniatáu ichi gwblhau'ch monitro er mwyn cael rhywfaint o fudd ohono, fel y gallwch fonitro'ch cronfa ddata gyda budd, er mwyn atal yn brydlon unrhyw sefyllfaoedd brys a allai godi.
A gellir addasu'r syniadau a fydd yn yr adroddiad hwn yn uniongyrchol i unrhyw gronfa ddata, boed yn DBMS neu noSQL. Felly, nid yn unig PostgreSQL, ond bydd llawer o ryseitiau ar sut i wneud hyn yn PostgreSQL. Bydd enghreifftiau o ymholiadau, enghreifftiau o endidau sydd gan PostgreSQL ar gyfer monitro. Ac os oes gan eich DBMS yr un pethau sy'n caniatáu ichi eu rhoi mewn monitro, gallwch chi hefyd eu haddasu, eu hychwanegu a bydd yn dda.
Ni fyddaf yn yr adroddiad
siarad am sut i gyflwyno a storio metrigau. Ni ddywedaf unrhyw beth am ôl-brosesu'r data a'i gyflwyno i'r defnyddiwr. Ac ni ddywedaf unrhyw beth am rybuddio.
Ond wrth i'r stori fynd yn ei blaen, byddaf yn dangos sgrinluniau gwahanol o fonitro presennol ac yn eu beirniadu rywsut. Ond serch hynny, byddaf yn ceisio peidio ag enwi brandiau er mwyn peidio â chreu hysbysebion neu wrth-hysbysebu ar gyfer y cynhyrchion hyn. Felly, mae pob cyd-ddigwyddiad yn hap ac yn cael ei adael i'ch dychymyg.
Yn gyntaf, gadewch i ni ddarganfod beth yw monitro. Mae monitro yn beth pwysig iawn i'w gael. Mae pawb yn deall hyn. Ond ar yr un pryd, nid yw monitro yn ymwneud â chynnyrch busnes ac nid yw'n effeithio'n uniongyrchol ar elw'r cwmni, felly mae amser bob amser yn cael ei ddyrannu i fonitro ar sail weddilliol. Os oes gennym ni amser, yna rydyn ni'n monitro; os nad oes gennym ni amser, yna iawn, byddwn ni'n ei roi yn yr ôl-groniad a rhyw ddydd byddwn ni'n dychwelyd at y tasgau hyn.
Felly, o'n harfer, pan ddown at gleientiaid, mae monitro yn aml yn anghyflawn ac nid oes ganddo unrhyw bethau diddorol a fyddai'n ein helpu i wneud gwaith gwell gyda'r gronfa ddata. Ac felly mae angen cwblhau monitro bob amser.
Mae cronfeydd data yn bethau mor gymhleth y mae angen eu monitro hefyd, oherwydd bod cronfeydd data yn gadwrfa o wybodaeth. Ac mae gwybodaeth yn bwysig iawn i'r cwmni; ni ellir ei cholli mewn unrhyw ffordd. Ond ar yr un pryd, mae cronfeydd data yn ddarnau cymhleth iawn o feddalwedd. Maent yn cynnwys nifer fawr o gydrannau. Ac mae angen monitro llawer o'r cydrannau hyn.
Os ydym yn sôn yn benodol am PostgreSQL, yna gellir ei gynrychioli ar ffurf cynllun sy'n cynnwys nifer fawr o gydrannau. Mae'r cydrannau hyn yn rhyngweithio â'i gilydd. Ac ar yr un pryd, mae gan PostgreSQL yr is-system Stats Collector, fel y'i gelwir, sy'n eich galluogi i gasglu ystadegau am weithrediad yr is-systemau hyn a darparu rhyw fath o ryngwyneb i'r gweinyddwr neu'r defnyddiwr fel y gall weld yr ystadegau hyn.
Cyflwynir yr ystadegau hyn ar ffurf set benodol o swyddogaethau a safbwyntiau. Gellir eu galw hefyd yn dablau. Hynny yw, gan ddefnyddio cleient psql rheolaidd, gallwch gysylltu â'r gronfa ddata, dewis y swyddogaethau a'r golygfeydd hyn, a chael rhai rhifau penodol am weithrediad is-systemau PostgreSQL.
Gallwch ychwanegu'r niferoedd hyn at eich hoff system fonitro, llunio graffiau, ychwanegu swyddogaethau a chael dadansoddeg yn y tymor hir.
Ond yn yr adroddiad hwn ni fyddaf yn ymdrin â'r holl swyddogaethau hyn yn llwyr, oherwydd gallai gymryd y diwrnod cyfan. Byddaf yn llythrennol yn mynd i'r afael â dau, tri neu bedwar o bethau ac yn dweud wrthych sut y maent yn helpu i wella monitro.
Ac os ydym yn siarad am fonitro cronfa ddata, yna beth sydd angen ei fonitro? Yn gyntaf oll, mae angen inni fonitro argaeledd, oherwydd mae’r gronfa ddata yn wasanaeth sy’n darparu mynediad at ddata i gleientiaid ac mae angen inni fonitro argaeledd, a hefyd yn darparu rhai o’i nodweddion ansoddol a meintiol.
Mae angen i ni hefyd fonitro cleientiaid sy'n cysylltu â'n cronfa ddata, oherwydd gallant fod yn gleientiaid arferol ac yn gleientiaid niweidiol a all niweidio'r gronfa ddata. Mae angen eu monitro hefyd ac olrhain eu gweithgareddau.
Pan fydd cleientiaid yn cysylltu â'r gronfa ddata, mae'n amlwg eu bod yn dechrau gweithio gyda'n data, felly mae angen inni fonitro sut mae cleientiaid yn gweithio gyda'r data: gyda pha dablau, ac i raddau llai, â pha fynegeion. Hynny yw, mae angen inni werthuso'r llwyth gwaith sy'n cael ei greu gan ein cleientiaid.
Ond mae llwyth gwaith hefyd, wrth gwrs, yn cynnwys ceisiadau. Mae cymwysiadau'n cysylltu â'r gronfa ddata, yn cyrchu data gan ddefnyddio ymholiadau, felly mae'n bwysig gwerthuso pa ymholiadau sydd gennym yn y gronfa ddata, monitro eu digonolrwydd, nad ydynt wedi'u hysgrifennu'n gam, bod angen ailysgrifennu a gwneud rhai opsiynau fel eu bod yn gweithio'n gyflymach. a chyda gwell perfformiad.
A chan ein bod yn sôn am gronfa ddata, mae'r gronfa ddata bob amser yn brosesau cefndir. Mae prosesau cefndir yn helpu i gynnal perfformiad cronfa ddata ar lefel dda, felly mae angen rhywfaint o adnoddau arnynt eu hunain i weithredu. Ac ar yr un pryd, gallant orgyffwrdd ag adnoddau cais cleientiaid, felly gall prosesau cefndir barus effeithio'n uniongyrchol ar berfformiad ceisiadau cleientiaid. Felly, mae angen eu monitro a’u holrhain hefyd fel nad oes unrhyw ystumiadau o ran prosesau cefndir.
Ac mae hyn i gyd o ran monitro cronfa ddata yn parhau yn y system fetrig. Ond o ystyried bod y rhan fwyaf o'n seilwaith yn symud i'r cymylau, mae metrigau system gwesteiwr unigol bob amser yn pylu i'r cefndir. Ond mewn cronfeydd data maent yn dal yn berthnasol ac, wrth gwrs, mae angen monitro metrigau system hefyd.
Mae popeth fwy neu lai yn iawn gyda metrigau system, mae'r holl systemau monitro modern eisoes yn cefnogi'r metrigau hyn, ond yn gyffredinol, nid yw rhai cydrannau'n ddigon o hyd ac mae angen ychwanegu rhai pethau. Byddaf hefyd yn cyffwrdd â nhw, bydd sawl sleid amdanynt.
Pwynt cyntaf y cynllun yw hygyrchedd. Beth yw hygyrchedd? Argaeledd yn fy nealltwriaeth i yw gallu’r sylfaen i gysylltiadau gwasanaeth, h.y. codir y sylfaen, mae, fel gwasanaeth, yn derbyn cysylltiadau gan gleientiaid. A gellir asesu'r hygyrchedd hwn yn ôl nodweddion penodol. Mae'n gyfleus iawn arddangos y nodweddion hyn ar ddangosfyrddau.
Mae pawb yn gwybod beth yw dangosfyrddau. Dyma pryd y cymeroch un olwg ar y sgrin lle mae'r wybodaeth angenrheidiol yn cael ei chrynhoi. A gallwch chi benderfynu ar unwaith a oes problem yn y gronfa ddata ai peidio.
Yn unol â hynny, dylai argaeledd y gronfa ddata a nodweddion allweddol eraill bob amser gael eu harddangos ar ddangosfyrddau fel bod y wybodaeth hon wrth law a bob amser ar gael i chi. Rhai manylion ychwanegol sydd eisoes yn helpu i ymchwilio i ddigwyddiadau, wrth ymchwilio i rai sefyllfaoedd brys, mae angen eu gosod eisoes ar ddangosfyrddau eilaidd, neu eu cuddio mewn dolenni drilio sy'n arwain at systemau monitro trydydd parti.
Enghraifft o un system fonitro adnabyddus. Mae hon yn system fonitro cŵl iawn. Mae hi'n casglu llawer o ddata, ond o'm safbwynt i, mae ganddi gysyniad rhyfedd o ddangosfyrddau. Mae dolen i “greu dangosfwrdd”. Ond pan fyddwch chi'n creu dangosfwrdd, rydych chi'n creu rhestr o ddwy golofn, rhestr o graffiau. A phan fydd angen i chi edrych ar rywbeth, rydych chi'n dechrau clicio gyda'r llygoden, sgrolio, chwilio am y siart a ddymunir. Ac mae hyn yn cymryd amser, h.y. nid oes dangosfyrddau fel y cyfryw. Dim ond rhestrau o siartiau sydd.
Beth ddylech chi ei ychwanegu at y dangosfyrddau hyn? Gallwch chi ddechrau gyda nodwedd o'r fath ag amser ymateb. Mae gan PostgreSQL y golwg pg_stat_statements. Mae'n anabl yn ddiofyn, ond mae'n un o'r golygfeydd system pwysig y dylid ei alluogi a'i ddefnyddio bob amser. Mae'n storio gwybodaeth am yr holl ymholiadau rhedeg sydd wedi'u gweithredu yn y gronfa ddata.
Yn unol â hynny, gallwn ddechrau o'r ffaith y gallwn gymryd cyfanswm amser gweithredu pob cais a'i rannu â nifer y ceisiadau gan ddefnyddio'r meysydd uchod. Ond dyma'r tymheredd cyfartalog yn yr ysbyty. Gallwn ddechrau o feysydd eraill - isafswm amser gweithredu ymholiad, uchafswm a chanolrif. A gallwn hyd yn oed adeiladu canraddau; Mae gan PostgreSQL swyddogaethau cyfatebol ar gyfer hyn. A gallwn gael rhai niferoedd sy'n nodweddu amser ymateb ein cronfa ddata ar gyfer ceisiadau sydd eisoes wedi'u cwblhau, h.y. nid ydym yn gweithredu'r cais ffug 'dewis 1' ac yn edrych ar yr amser ymateb, ond rydym yn dadansoddi'r amser ymateb ar gyfer ceisiadau sydd eisoes wedi'u cwblhau ac yn tynnu llun. naill ai ffigur ar wahân, neu rydym yn adeiladu graff yn seiliedig arno.
Mae hefyd yn bwysig monitro nifer y gwallau a gynhyrchir gan y system ar hyn o bryd. Ac ar gyfer hyn gallwch ddefnyddio'r olwg pg_stat_database. Rydym yn canolbwyntio ar y maes xact_rollback. Mae'r maes hwn yn dangos nid yn unig nifer y dychweliadau sy'n digwydd yn y gronfa ddata, ond mae hefyd yn ystyried nifer y gwallau. Yn gymharol siarad, gallwn arddangos y ffigur hwn yn ein dangosfwrdd a gweld faint o wallau sydd gennym ar hyn o bryd. Os oes llawer o wallau, yna mae hwn yn reswm da i edrych i mewn i'r logiau a gweld pa fath o wallau ydyn nhw a pham maen nhw'n digwydd, ac yna buddsoddi a'u datrys.
Gallwch chi ychwanegu'r fath beth â thachomedr. Dyma nifer y trafodion yr eiliad a nifer y ceisiadau yr eiliad. Yn gymharol siarad, gallwch ddefnyddio'r niferoedd hyn fel perfformiad cyfredol eich cronfa ddata ac arsylwi a oes brigau mewn ceisiadau, uchafbwynt mewn trafodion, neu, i'r gwrthwyneb, a yw'r gronfa ddata wedi'i thanlwytho oherwydd bod rhywfaint o ôl-wyneb wedi methu. Mae'n bwysig edrych ar y ffigur hwn bob amser a chofio bod y math hwn o berfformiad yn normal ar gyfer ein prosiect, ond mae'r gwerthoedd uchod ac isod eisoes yn rhyw fath o broblematig ac annealladwy, sy'n golygu bod angen inni edrych ar pam mae'r niferoedd hyn. mor uchel.
Er mwyn amcangyfrif nifer y trafodion, gallwn eto gyfeirio at y golwg pg_stat_database. Gallwn ychwanegu nifer yr ymrwymiadau a nifer y dychweliadau a chael nifer y trafodion yr eiliad.
A yw pawb yn deall y gall sawl cais ffitio i mewn i un trafodiad? Felly mae TPS a QPS ychydig yn wahanol.
Gellir cael nifer y ceisiadau yr eiliad o pg_stat_statements a chyfrifo swm yr holl geisiadau a gwblhawyd. Mae'n amlwg ein bod yn cymharu'r gwerth cyfredol â'r un blaenorol, yn ei dynnu, yn cael y delta, ac yn cael y swm.
Gallwch ychwanegu metrigau ychwanegol os dymunir, sydd hefyd yn helpu i werthuso argaeledd ein cronfa ddata a monitro a fu unrhyw amseroedd segur.
Un o'r metrigau hyn yw uptime. Ond mae uptime yn PostgreSQL ychydig yn anodd. Byddaf yn dweud wrthych pam. Pan fydd PostgreSQL wedi dechrau, mae uptime yn dechrau adrodd. Ond os, ar ryw adeg, er enghraifft, bod rhywfaint o dasg yn rhedeg yn y nos, daeth lladdwr OOM a dod â phroses plentyn PostgreSQL i ben yn rymus, yna yn yr achos hwn mae PostgreSQL yn terfynu cysylltiad yr holl gleientiaid, yn ailosod yr ardal cof wedi'i dorri ac yn dechrau adferiad o y pwynt gwirio olaf. Ac er bod yr adferiad hwn o'r pwynt gwirio yn para, nid yw'r gronfa ddata yn derbyn cysylltiadau, h.y. gellir asesu'r sefyllfa hon fel amser segur. Ond ni fydd y cownter uptime yn cael ei ailosod, oherwydd mae'n ystyried amser cychwyn y postfeistr o'r eiliad gyntaf. Felly, gellir hepgor sefyllfaoedd o'r fath.
Dylech hefyd fonitro nifer y gweithwyr gwactod. Ydy pawb yn gwybod beth yw awto-wactod yn PostgreSQL? Mae hon yn is-system ddiddorol yn PostgreSQL. Mae llawer o erthyglau wedi'u hysgrifennu amdani, mae llawer o adroddiadau wedi'u gwneud. Mae llawer o drafodaethau am wactod a sut y dylai weithio. Mae llawer yn ei ystyried yn ddrwg angenrheidiol. Ond dyna fel y mae. Mae hwn yn fath o analog o gasglwr sbwriel sy'n glanhau fersiynau hen ffasiwn o resi nad oes eu hangen ar unrhyw drafodiad ac yn rhyddhau lle mewn tablau a mynegeion ar gyfer rhesi newydd.
Pam mae angen i chi ei fonitro? Oherwydd bod y gwactod weithiau'n brifo llawer. Mae'n defnyddio llawer iawn o adnoddau ac mae ceisiadau cleientiaid yn dechrau dioddef o ganlyniad.
A dylid ei fonitro trwy'r olwg pg_stat_activity, y byddaf yn siarad amdano yn yr adran nesaf. Mae'r wedd hon yn dangos y gweithgaredd cyfredol yn y gronfa ddata. A thrwy'r gweithgaredd hwn gallwn olrhain nifer y gwactodau sy'n gweithio ar hyn o bryd. Gallwn olrhain gwactodau a gweld, os ydym wedi mynd y tu hwnt i'r terfyn, yna mae hyn yn rheswm i edrych i mewn i'r gosodiadau PostgreSQL a rhywsut optimeiddio gweithrediad y gwactod.
Nodwedd arall o PostgreSQL yw bod PostgreSQL yn boenus iawn gyda thrafodion hir. Yn enwedig o drafodion sy'n hongian o gwmpas am amser hir ac yn gwneud dim byd. Dyma'r hyn a elwir yn stat segur-mewn-trafodiad. Mae trafodiad o'r fath yn dal cloeon ac yn atal y gwactod rhag gweithio. Ac o ganlyniad, mae'r tablau'n chwyddo ac yn cynyddu mewn maint. Ac mae ymholiadau sy'n gweithio gyda'r tablau hyn yn dechrau gweithio'n arafach, oherwydd mae angen i chi rhawio'r holl hen fersiynau o resi o'r cof i'r ddisg ac yn ôl. Felly, mae angen monitro'r amser, hyd y trafodion hiraf, y ceisiadau gwactod hiraf hefyd. Ac os gwelwn rai prosesau sydd wedi bod yn rhedeg am amser hir iawn, eisoes yn fwy na 10-20-30 munud ar gyfer llwyth OLTP, yna mae angen inni roi sylw iddynt a'u terfynu'n rymus, neu wneud y gorau o'r cais fel eu bod yn cael eu galw ac nid ydynt yn hongian cyhyd. Ar gyfer llwyth gwaith dadansoddol, mae 10-20-30 munud yn normal; mae yna rai hirach hefyd.
Nesaf mae gennym yr opsiwn gyda chleientiaid cysylltiedig. Pan fyddwn eisoes wedi creu dangosfwrdd ac wedi postio metrigau argaeledd allweddol arno, gallwn hefyd ychwanegu gwybodaeth ychwanegol am gleientiaid cysylltiedig yno.
Mae gwybodaeth am gleientiaid cysylltiedig yn bwysig oherwydd, o safbwynt PostgreSQL, mae cleientiaid yn wahanol. Mae cleientiaid da ac mae cleientiaid drwg.
Enghraifft syml. Gan y cleient rwy'n deall y cais. Mae'r cais wedi cysylltu â'r gronfa ddata ac yn syth yn dechrau anfon ei geisiadau yno, mae'r gronfa ddata yn prosesu ac yn eu gweithredu, ac yn dychwelyd y canlyniadau i'r cleient. Mae'r rhain yn gleientiaid da a chywir.
Mae yna sefyllfaoedd pan fydd y cleient wedi cysylltu, mae'n dal y cysylltiad, ond nid yw'n gwneud dim. Mae mewn cyflwr segur.
Ond mae yna gleientiaid drwg. Er enghraifft, cysylltodd yr un cleient, agorodd drafodiad, gwnaeth rywbeth yn y gronfa ddata ac yna aeth i mewn i'r cod, er enghraifft, i gael mynediad at ffynhonnell allanol neu i brosesu'r data a dderbyniwyd yno. Ond ni chauodd y trafodiad. Ac mae'r trafodiad yn hongian yn y gronfa ddata ac yn cael ei gadw mewn clo ar y llinell. Mae hwn yn gyflwr gwael. Ac os yn sydyn mae cais rhywle y tu mewn iddo'i hun yn methu ag eithriad, yna gall y trafodiad aros ar agor am amser hir iawn. Ac mae hyn yn effeithio'n uniongyrchol ar berfformiad PostgreSQL. Bydd PostgreSQL yn arafach. Felly, mae'n bwysig olrhain cleientiaid o'r fath mewn modd amserol a dod â'u gwaith i ben yn rymus. Ac mae angen i chi wneud y gorau o'ch cais fel na fydd sefyllfaoedd o'r fath yn digwydd.
Mae cleientiaid drwg eraill yn gleientiaid aros. Ond maen nhw'n mynd yn ddrwg oherwydd amgylchiadau. Er enghraifft, trafodiad segur syml: gall agor trafodiad, cymryd cloeon ar rai llinellau, yna rhywle yn y cod bydd yn methu, gan adael trafodiad hongian. Bydd cleient arall yn dod i ofyn am yr un data, ond bydd yn dod ar draws clo, oherwydd bod y trafodiad crog hwnnw eisoes yn dal cloeon ar rai rhesi gofynnol. A bydd yr ail drafodiad yn aros am y trafodiad cyntaf i'w gwblhau neu ei gau'n orfodol gan y gweinyddwr. Felly, gall trafodion arfaethedig gronni a llenwi'r terfyn cysylltiad cronfa ddata. A phan fydd y terfyn yn llawn, ni all y cais weithio gyda'r gronfa ddata mwyach. Mae hon eisoes yn sefyllfa o argyfwng ar gyfer y prosiect. Felly, mae angen olrhain cleientiaid drwg ac ymateb iddynt mewn modd amserol.
Enghraifft arall o fonitro. Ac mae dangosfwrdd gweddus yma eisoes. Mae gwybodaeth am gysylltiadau uchod. Cysylltiad DB - 8 darn. Ac mae'r cyfan. Nid oes gennym unrhyw wybodaeth ynghylch pa gleientiaid sy'n weithgar, pa gleientiaid sy'n segur, yn gwneud dim. Nid oes unrhyw wybodaeth am drafodion arfaethedig a chysylltiadau arfaethedig, h.y. mae hwn yn ffigur sy’n dangos nifer y cysylltiadau a dyna ni. Ac yna dyfalwch drosoch eich hun.
Yn unol â hynny, i ychwanegu'r wybodaeth hon at fonitro, mae angen i chi gael mynediad i'r olwg system pg_stat_activity. Os ydych chi'n treulio llawer o amser yn PostgreSQL, yna mae hon yn olygfa dda iawn a ddylai ddod yn ffrind i chi, oherwydd mae'n dangos y gweithgaredd presennol yn PostgreSQL, h.y. beth sy'n digwydd ynddo. Ar gyfer pob proses mae llinell ar wahân sy'n dangos gwybodaeth am y broses hon: o ba westeiwr y gwnaed y cysylltiad, o dan ba ddefnyddiwr, o dan ba enw, pryd y cychwynnwyd y trafodiad, pa gais sy'n rhedeg ar hyn o bryd, pa gais a weithredwyd ddiwethaf. Ac, yn unol â hynny, gallwn werthuso cyflwr y cleient gan ddefnyddio'r maes stat. Yn gymharol siarad, gallwn grwpio yn ôl y maes hwn a chael yr ystadegau hynny sydd yn y gronfa ddata ar hyn o bryd a nifer y cysylltiadau sydd â'r stat hwn yn y gronfa ddata. A gallwn anfon y niferoedd a dderbyniwyd eisoes i'n monitro a llunio graffiau yn seiliedig arnynt.
Mae hefyd yn bwysig gwerthuso hyd y trafodiad. Dywedais eisoes ei bod yn bwysig gwerthuso hyd gwactodau, ond mae trafodion yn cael eu gwerthuso yn yr un modd. Mae yna feysydd xact_start a query_start. Maent, yn gymharol siarad, yn dangos amser cychwyn y trafodiad ac amser cychwyn y cais. Rydym yn cymryd y swyddogaeth now(), sy'n dangos y stamp amser cyfredol, ac yn tynnu'r stamp amser trafodiad a chais. Ac rydym yn cael hyd y trafodiad, hyd y cais.
Os gwelwn drafodion hir, dylem eu cwblhau eisoes. Ar gyfer llwyth OLTP, mae trafodion hir eisoes yn fwy na 1-2-3 munud. Ar gyfer llwyth gwaith OLAP, mae trafodion hir yn normal, ond os ydyn nhw'n cymryd mwy na dwy awr i'w cwblhau, yna mae hyn hefyd yn arwydd bod gennym ni sgiw yn rhywle.
Unwaith y bydd cleientiaid wedi cysylltu â'r gronfa ddata, maent yn dechrau gweithio gyda'n data. Maent yn cyrchu tablau, maent yn cyrchu mynegeion i gael data o'r tabl. Ac mae'n bwysig gwerthuso sut mae cleientiaid yn rhyngweithio â'r data hwn.
Mae hyn yn angenrheidiol er mwyn gwerthuso ein llwyth gwaith a deall yn fras pa dablau yw'r “poethaf” i ni. Er enghraifft, mae angen hyn mewn sefyllfaoedd lle rydym am osod byrddau “poeth” ar ryw fath o storfa SSD cyflym. Er enghraifft, gellir symud rhai tablau archif nad ydym wedi'u defnyddio ers amser maith i ryw fath o archif “oer”, i yriannau SATA a gadael iddynt fyw yno, byddant yn cael eu cyrchu yn ôl yr angen.
Mae hyn hefyd yn ddefnyddiol ar gyfer canfod anghysondebau ar ôl unrhyw ryddhau a defnyddio. Gadewch i ni ddweud bod y prosiect wedi rhyddhau rhywfaint o nodwedd newydd. Er enghraifft, fe wnaethom ychwanegu swyddogaeth newydd ar gyfer gweithio gyda'r gronfa ddata. Ac os ydym yn plotio graffiau defnydd tabl, gallwn ganfod yr anghysondebau hyn yn hawdd ar y graffiau hyn. Er enghraifft, diweddaru pyliau neu ddileu pyliau. Bydd yn weladwy iawn.
Gallwch hefyd ganfod anghysondebau mewn ystadegau “fel y bo'r angen”. Beth mae'n ei olygu? Mae gan PostgreSQL drefnydd ymholiadau cryf a da iawn. Ac mae'r datblygwyr yn neilltuo llawer o amser i'w ddatblygiad. Sut mae e'n gweithio? Er mwyn gwneud cynlluniau da, mae PostgreSQL yn casglu ystadegau ar ddosbarthiad data mewn tablau ar gyfnod penodol o amser a chydag amlder penodol. Dyma'r gwerthoedd mwyaf cyffredin: nifer y gwerthoedd unigryw, gwybodaeth am NULL yn y tabl, llawer o wybodaeth.
Yn seiliedig ar yr ystadegau hyn, mae'r cynlluniwr yn llunio sawl ymholiad, yn dewis yr un mwyaf optimaidd, ac yn defnyddio'r cynllun ymholiad hwn i weithredu'r ymholiad ei hun a dychwelyd data.
Ac mae'n digwydd bod yr ystadegau'n “arnofio”. Newidiodd y data ansawdd a maint yn y tabl rywsut, ond ni chasglwyd yr ystadegau. Ac efallai na fydd y cynlluniau a ffurfiwyd yn optimaidd. Ac os bydd ein cynlluniau yn troi allan i fod yn is-optimaidd yn seiliedig ar y monitro a gasglwyd, yn seiliedig ar y tablau, byddwn yn gallu gweld yr anghysondebau hyn. Er enghraifft, yn rhywle newidiodd y data yn ansoddol ac yn lle’r mynegai, dechreuwyd defnyddio llwybr dilyniannol drwy’r tabl, h.y. os oes angen i ymholiad ddychwelyd dim ond 100 rhes (mae cyfyngiad o 100), yna bydd chwiliad cyflawn yn cael ei wneud ar gyfer yr ymholiad hwn. Ac mae hyn bob amser yn cael effaith wael iawn ar berfformiad.
A gallwn weld hyn wrth fonitro. Ac yn barod edrychwch ar yr ymholiad hwn, rhedeg esboniad ar ei gyfer, casglu ystadegau, adeiladu mynegai ychwanegol newydd. Ac eisoes yn ymateb i'r broblem hon. Dyna pam ei fod yn bwysig.
Enghraifft arall o fonitro. Rwy'n meddwl bod llawer o bobl yn ei adnabod oherwydd ei fod yn boblogaidd iawn. Pwy sy'n ei ddefnyddio yn eu prosiectau ? Pwy sy'n defnyddio'r cynnyrch hwn ar y cyd â Prometheus? Y ffaith yw bod yna ddangosfwrdd yn ystorfa safonol y monitro hwn ar gyfer gweithio gyda PostgreSQL - Prometheus. Ond mae un manylyn gwael.
Mae yna sawl graff. A nodir beit fel undod, h.y. mae 5 graff. Y rhain yw Mewnosod data, Diweddaru data, Dileu data, Nôl data a data Dychwelyd. Beit yw mesuriad yr uned. Ond y peth yw bod ystadegau yn PostgreSQL yn dychwelyd data mewn tuple (rhesi). Ac, yn unol â hynny, mae'r graffiau hyn yn ffordd dda iawn o danamcangyfrif eich llwyth gwaith sawl gwaith, ddegau o weithiau, oherwydd nid beit yw tuple, llinyn yw tuple, mae'n llawer o beit ac mae hyd amrywiol bob amser. Hynny yw, mae cyfrifo llwyth gwaith mewn bytes gan ddefnyddio tuples yn dasg afrealistig neu'n anodd iawn. Felly, pan fyddwch yn defnyddio dangosfwrdd neu fonitro adeiledig, mae bob amser yn bwysig deall ei fod yn gweithio'n gywir ac yn dychwelyd data a aseswyd yn gywir i chi.
Sut i gael ystadegau ar y tablau hyn? At y diben hwn, mae gan PostgreSQL deulu penodol o safbwyntiau. A'r brif olygfa yw . User_tables - mae hyn yn golygu tablau a grëwyd ar ran y defnyddiwr. Mewn cyferbyniad, mae yna farn system a ddefnyddir gan PostgreSQL ei hun. Ac mae tabl crynodeb Alltables, sy'n cynnwys rhai system a defnyddwyr. Gallwch chi ddechrau o unrhyw un ohonyn nhw rydych chi'n ei hoffi orau.
Gan ddefnyddio'r meysydd uchod gallwch amcangyfrif nifer y mewnosodiadau, diweddariadau a dileadau. Mae'r enghraifft o ddangosfwrdd a ddefnyddiais yn defnyddio'r meysydd hyn i werthuso nodweddion llwyth gwaith. Felly, gallwn hefyd adeiladu arnynt. Ond mae'n werth cofio mai tuples yw'r rhain, nid beit, felly ni allwn ei wneud mewn beit yn unig.
Yn seiliedig ar y data hwn, gallwn adeiladu tablau TopN fel y'u gelwir. Er enghraifft, Top-5, Top-10. A gallwch olrhain y byrddau poeth hynny sy'n cael eu hailgylchu yn fwy nag eraill. Er enghraifft, 5 bwrdd “poeth” i'w gosod. A chan ddefnyddio'r tablau TopN hyn rydym yn gwerthuso ein llwyth gwaith a gallwn werthuso pyliau o lwyth gwaith ar ôl unrhyw ddatganiadau, diweddariadau a defnydd.
Mae hefyd yn bwysig gwerthuso maint y tabl, oherwydd weithiau bydd datblygwyr yn cyflwyno nodwedd newydd, ac mae ein tablau'n dechrau chwyddo yn eu meintiau mawr, oherwydd penderfynasant ychwanegu swm ychwanegol o ddata, ond nid oeddent yn rhagweld sut y byddai hyn. effeithio ar faint y gronfa ddata. Mae achosion o'r fath hefyd yn peri syndod i ni.
Ac yn awr cwestiwn bach i chi. Pa gwestiwn sy'n codi pan sylwch ar y llwyth ar eich gweinydd cronfa ddata? Beth yw'r cwestiwn nesaf sydd gennych chi?
Ond mewn gwirionedd mae'r cwestiwn yn codi fel a ganlyn. Pa geisiadau y mae'r llwyth yn eu hachosi? Hynny yw, nid yw'n ddiddorol edrych ar y prosesau a achosir gan y llwyth. Mae'n amlwg, os oes gan y gwesteiwr gronfa ddata, yna mae'r gronfa ddata yn rhedeg yno ac mae'n amlwg mai dim ond y cronfeydd data fydd yn cael eu gwaredu yno. Os byddwn yn agor Top, fe welwn fod rhestr o brosesau yn PostgreSQL sy'n gwneud rhywbeth. Ni fydd yn glir o Top beth maent yn ei wneud.
Yn unol â hynny, mae angen ichi ddod o hyd i'r ymholiadau hynny sy'n achosi'r llwyth uchaf, oherwydd mae ymholiadau tiwnio, fel rheol, yn rhoi mwy o elw na thiwnio'r PostgreSQL neu gyfluniad y system weithredu, neu hyd yn oed tiwnio'r caledwedd. Yn ôl fy amcangyfrif, mae hyn oddeutu 80-85-90%. Ac mae hyn yn cael ei wneud yn llawer cyflymach. Mae'n gyflymach cywiro cais na chywiro'r ffurfweddiad, amserlennu ailgychwyn, yn enwedig os na ellir ailgychwyn y gronfa ddata, neu ychwanegu caledwedd. Mae'n haws ailysgrifennu'r ymholiad yn rhywle neu ychwanegu mynegai i gael canlyniad gwell o'r ymholiad hwn.
Yn unol â hynny, mae angen monitro ceisiadau a'u digonolrwydd. Gadewch i ni gymryd enghraifft arall o fonitro. Ac yma, hefyd, mae'n ymddangos bod monitro rhagorol. Mae yna wybodaeth am ddyblygu, mae yna wybodaeth am trwygyrch, blocio, defnyddio adnoddau. Mae popeth yn iawn, ond nid oes unrhyw wybodaeth am geisiadau. Nid yw'n glir pa ymholiadau sy'n rhedeg yn ein cronfa ddata, pa mor hir y maent yn rhedeg, faint o'r ymholiadau hyn sydd. Mae angen i ni gael y wybodaeth hon yn ein monitro bob amser.
Ac i gael y wybodaeth hon gallwn ddefnyddio'r modiwl pg_stat_statements. Yn seiliedig arno, gallwch chi adeiladu amrywiaeth o graffiau. Er enghraifft, gallwch gael gwybodaeth am yr ymholiadau mwyaf aml, hynny yw, am yr ymholiadau hynny a gyflawnir amlaf. Ydy, ar ôl defnyddio, mae hefyd yn ddefnyddiol iawn edrych arno a deall a oes unrhyw ymchwydd mewn ceisiadau.
Gallwch fonitro'r ymholiadau hiraf, hynny yw, yr ymholiadau hynny sy'n cymryd yr hiraf i'w cwblhau. Maen nhw'n rhedeg ar y prosesydd, maen nhw'n defnyddio I / O. Gallwn hefyd werthuso hyn gan ddefnyddio'r meysydd total_time, mean_time, blk_write_time a blk_read_time.
Gallwn werthuso a monitro'r ceisiadau trymaf o ran defnydd adnoddau, y rhai sy'n darllen o ddisg, sy'n gweithio gyda'r cof, neu, i'r gwrthwyneb, yn creu rhyw fath o lwyth ysgrifennu.
Gallwn werthuso'r ceisiadau mwyaf hael. Dyma'r ymholiadau sy'n dychwelyd nifer fawr o resi. Er enghraifft, gallai hyn fod yn gais lle maent wedi anghofio gosod terfyn. Ac yn syml, mae'n dychwelyd holl gynnwys y tabl neu'r ymholiad ar draws y tablau a holwyd.
A gallwch hefyd fonitro ymholiadau sy'n defnyddio ffeiliau dros dro neu dablau dros dro.
Ac mae gennym ni brosesau cefndir o hyd. Pwyntiau gwirio yw prosesau cefndir yn bennaf neu fe'u gelwir hefyd yn bwyntiau gwirio, sef autovacuum ac atgynhyrchu.
Enghraifft arall o fonitro. Mae tab Cynnal a Chadw ar y chwith, ewch iddo a gobeithio gweld rhywbeth defnyddiol. Ond dim ond amser gweithredu gwactod a chasglu ystadegau yw yma, dim byd mwy. Mae hon yn wybodaeth wael iawn, felly mae angen i ni bob amser gael gwybodaeth am sut mae prosesau cefndir yn gweithio yn ein cronfa ddata ac a oes unrhyw broblemau o'u gwaith.
Pan edrychwn ar bwyntiau gwirio, dylem gofio bod pwyntiau gwirio yn fflysio tudalennau budr o'r ardal cof wedi'i dorri i ddisg, ac yna'n creu pwynt gwirio. Ac yna gellir defnyddio'r pwynt gwirio hwn fel lle i wella pe bai PostgreSQL yn cael ei derfynu'n sydyn mewn argyfwng.
Yn unol â hynny, er mwyn fflysio'r holl dudalennau “budr” i ddisg, mae angen i chi wneud rhywfaint o ysgrifennu. Ac, fel rheol, ar systemau gyda llawer iawn o gof, mae hyn yn llawer. Ac os byddwn yn gwneud pwyntiau gwirio yn aml iawn mewn cyfnod byr, yna bydd perfformiad disg yn gostwng yn sylweddol iawn. A bydd ceisiadau cleientiaid yn dioddef o ddiffyg adnoddau. Byddant yn cystadlu am adnoddau ac yn brin o gynhyrchiant.
Yn unol â hynny, trwy pg_stat_bwriter gan ddefnyddio'r meysydd penodedig gallwn fonitro nifer y pwyntiau gwirio sy'n digwydd. Ac os oes gennym lawer o bwyntiau gwirio dros gyfnod penodol o amser (mewn 10-15-20 munud, mewn hanner awr), er enghraifft, 3-4-5, yna gall hyn fod yn broblem eisoes. Ac mae angen i chi edrych yn y gronfa ddata eisoes, edrychwch yn y ffurfweddiad, beth sy'n achosi cymaint o bwyntiau gwirio. Efallai bod rhyw fath o recordiad mawr yn digwydd. Gallwn werthuso'r llwyth gwaith eisoes, oherwydd rydym eisoes wedi ychwanegu graffiau llwyth gwaith. Gallwn eisoes addasu paramedrau'r pwynt gwirio a sicrhau nad ydynt yn effeithio'n fawr ar berfformiad ymholiad.
Rwy'n dod yn ôl at awto-wactod eto oherwydd mae'n gymaint o beth, fel y dywedais, sy'n gallu adio perfformiad disgiau ac ymholiad yn hawdd, felly mae bob amser yn bwysig amcangyfrif faint o wactod awtomataidd.
Mae nifer y gweithwyr gwactod yn y gronfa ddata yn gyfyngedig. Yn ddiofyn, mae tri ohonyn nhw, felly os oes gennym ni dri gweithiwr yn gweithio yn y gronfa ddata bob amser, mae hyn yn golygu nad yw ein autovacuum wedi'i ffurfweddu, mae angen i ni godi'r terfynau, adolygu'r gosodiadau autovacuum a mynd i mewn i'r ffurfweddiad.
Mae'n bwysig gwerthuso pa weithwyr gwactod sydd gennym. Naill ai fe'i lansiwyd gan y defnyddiwr, daeth y DBA a lansio rhyw fath o wactod â llaw, a chreodd hyn lwyth. Mae gennym ni ryw fath o broblem. Neu dyma nifer y gwactodau sy'n dadsgriwio'r cownter trafodion. Ar gyfer rhai fersiynau o PostgreSQL mae'r rhain yn wactod trwm iawn. A gallant adio'r perfformiad yn hawdd oherwydd eu bod yn darllen y tabl cyfan, yn sganio'r holl flociau yn y tabl hwnnw.
Ac, wrth gwrs, hyd gwactodau. Os oes gennym ni wactod hirhoedlog sy'n rhedeg am amser hir iawn, yna mae hyn yn golygu bod angen inni roi sylw eto i'r cyfluniad gwactod ac efallai ailystyried ei osodiadau. Oherwydd y gall sefyllfa godi pan fydd y gwactod yn gweithio ar y bwrdd am amser hir (3-4 awr), ond yn ystod yr amser roedd y gwactod yn gweithio, llwyddodd llawer iawn o resi marw i gronni yn y bwrdd eto. A chyn gynted ag y bydd y gwactod wedi'i gwblhau, mae angen iddo wactod y bwrdd hwn eto. Ac rydym yn dod i sefyllfa - gwactod diddiwedd. Ac yn yr achos hwn, nid yw'r gwactod yn gwneud ei waith, ac mae'r tablau'n dechrau chwyddo o ran maint yn raddol, er bod cyfaint y data defnyddiol ynddo yn aros yr un fath. Felly, yn ystod gwactod hir, rydym bob amser yn edrych ar y ffurfweddiad ac yn ceisio ei optimeiddio, ond ar yr un pryd fel nad yw perfformiad ceisiadau cleientiaid yn dioddef.
Y dyddiau hyn nid oes bron unrhyw osodiad PostgreSQL nad oes ganddo ddyblygiad ffrydio. Dyblygiad yw'r broses o symud data o feistr i atgynhyrchiad.
Gwneir atgynhyrchu yn PostgreSQL trwy log trafodion. Mae'r dewin yn cynhyrchu log trafodion. Mae'r log trafodion yn teithio dros y cysylltiad rhwydwaith i'r replica, ac yna mae'n cael ei atgynhyrchu ar y replica. Mae'n syml.
Yn unol â hynny, defnyddir y golwg pg_stat_replication i fonitro'r oedi wrth ddyblygu. Ond nid yw popeth yn syml gyda hi. Yn fersiwn 10, mae'r olygfa wedi mynd trwy sawl newid. Yn gyntaf, mae rhai meysydd wedi'u hail-enwi. Ac mae rhai meysydd wedi'u hychwanegu. Yn fersiwn 10, ymddangosodd meysydd sy'n eich galluogi i amcangyfrif yr oedi wrth ddyblygu mewn eiliadau. Mae'n gyfforddus iawn. Cyn fersiwn 10, roedd yn bosibl amcangyfrif yr oedi wrth ddyblygu mewn beit. Mae'r opsiwn hwn yn aros yn fersiwn 10, h.y. gallwch ddewis yr hyn sy'n fwy cyfleus i chi - amcangyfrif yr oedi mewn beitiau neu amcangyfrif yr oedi mewn eiliadau. Mae llawer o bobl yn gwneud y ddau.
Ond serch hynny, er mwyn gwerthuso'r oedi wrth ddyblygu, mae angen i chi wybod lleoliad y log yn y trafodiad. Ac mae'r safleoedd log trafodion hyn yn union yn y golwg pg_stat_replication. Yn gymharol siarad, gallwn gymryd dau bwynt yn y log trafodion gan ddefnyddio'r swyddogaeth pg_xlog_location_diff(). Cyfrifwch y delta rhyngddynt a chael yr oedi atgynhyrchu mewn beit. Mae'n gyfleus iawn ac yn syml.
Yn fersiwn 10, ailenwyd y swyddogaeth hon yn pg_wal_lsn_diff(). Yn gyffredinol, ym mhob swyddogaeth, golygfa a chyfleustodau lle ymddangosodd y gair “xlog”, fe'i disodlwyd gan y gwerth “wal”. Mae hyn yn berthnasol i safbwyntiau a swyddogaethau. Mae hwn yn gymaint o arloesi.
Hefyd, yn fersiwn 10, ychwanegwyd llinellau sy'n dangos yr oedi yn benodol. Y rhain yw oedi ysgrifennu, oedi fflysio, oedi ailchwarae. Hynny yw, mae'n bwysig monitro'r pethau hyn. Os gwelwn fod oedi wrth atgynhyrchu, yna mae angen inni ymchwilio i pam yr ymddangosodd, o ble y daeth a datrys y broblem.
Mae bron popeth mewn trefn gyda metrigau system. Pan fydd unrhyw fonitro yn dechrau, mae'n dechrau gyda metrigau system. Dyma waredu proseswyr, cof, cyfnewid, rhwydwaith a disg. Fodd bynnag, nid yw llawer o baramedrau yno yn ddiofyn.
Os yw popeth mewn trefn gyda'r broses ailgylchu, yna mae problemau gydag ailgylchu disg. Fel rheol, mae datblygwyr monitro yn ychwanegu gwybodaeth am trwygyrch. Gall fod mewn iops neu beit. Ond maent yn anghofio am hwyrni a'r defnydd o ddyfeisiau disg. Mae'r rhain yn baramedrau pwysicach sy'n ein galluogi i werthuso pa mor lwythog yw ein disgiau a pha mor araf ydyn nhw. Os oes gennym hwyrni uchel, yna mae hyn yn golygu bod rhai problemau gyda'r disgiau. Os oes gennym ddefnydd uchel, mae'n golygu nad yw'r disgiau'n ymdopi. Mae'r rhain yn nodweddion gwell na thrwybwn.
At hynny, gellir cael yr ystadegau hyn hefyd o'r system ffeiliau /proc, fel y gwneir ar gyfer proseswyr ailgylchu. Nid wyf yn gwybod pam nad yw'r wybodaeth hon yn cael ei hychwanegu at fonitro. Ond serch hynny, mae'n bwysig cael hyn yn eich monitro.
Mae'r un peth yn berthnasol i ryngwynebau rhwydwaith. Mae gwybodaeth am fewnbwn rhwydwaith mewn pecynnau, mewn bytes, ond serch hynny nid oes unrhyw wybodaeth am hwyrni a dim gwybodaeth am ddefnydd, er bod hon hefyd yn wybodaeth ddefnyddiol.
Mae anfanteision i unrhyw fonitro. Ac ni waeth pa fath o fonitro a gymerwch, ni fydd bob amser yn bodloni rhai meini prawf. Ond serch hynny, maen nhw'n datblygu, mae nodweddion newydd a phethau newydd yn cael eu hychwanegu, felly dewiswch rywbeth a'i orffen.
Ac er mwyn gorffen, rhaid i chi bob amser gael syniad o'r hyn y mae'r ystadegau a ddarperir yn ei olygu a sut y gallwch eu defnyddio i ddatrys problemau.
Ac ychydig o bwyntiau allweddol:
- Dylech bob amser fonitro argaeledd a chael dangosfyrddau fel y gallwch asesu'n gyflym bod popeth mewn trefn gyda'r gronfa ddata.
- Mae angen i chi bob amser gael syniad o'r hyn y mae cleientiaid yn gweithio gyda'ch cronfa ddata er mwyn chwynnu cleientiaid drwg a'u saethu i lawr.
- Mae'n bwysig gwerthuso sut mae'r cleientiaid hyn yn gweithio gyda data. Mae angen i chi gael syniad am eich llwyth gwaith.
- Mae'n bwysig gwerthuso sut mae'r llwyth gwaith hwn yn cael ei ffurfio, gyda chymorth pa ymholiadau. Gallwch werthuso ymholiadau, gallwch eu hoptimeiddio, eu hailffactorio, adeiladu mynegeion ar eu cyfer. Mae'n bwysig iawn.
- Gall prosesau cefndir gael effaith negyddol ar geisiadau cleientiaid, felly mae'n bwysig monitro nad ydynt yn defnyddio gormod o adnoddau.
- Mae metrigau system yn caniatáu ichi wneud cynlluniau ar gyfer graddio a chynyddu gallu eich gweinyddwyr, felly mae'n bwysig eu holrhain a'u gwerthuso hefyd.
Os oes gennych ddiddordeb yn y pwnc hwn, yna gallwch ddilyn y dolenni hyn.
- dogfennaeth swyddogol gan y casglwr ystadegau yw hon. Ceir disgrifiad o'r holl safbwyntiau ystadegol a disgrifiad o bob maes. Gallwch eu darllen, eu deall a'u dadansoddi. Ac yn seiliedig arnynt, adeiladwch eich graffiau a'u hychwanegu at eich monitro.
Ceisiadau enghreifftiol:
Dyma ein cadwrfa gorfforaethol a fy un i. Maent yn cynnwys ymholiadau enghreifftiol. Nid oes unrhyw ymholiadau gan y detholiad* o'r gyfres yno. Mae yna ymholiadau parod eisoes gydag uniadau, gan ddefnyddio swyddogaethau diddorol sy'n eich galluogi i droi rhifau crai yn werthoedd darllenadwy, cyfleus, h.y. beit yw'r rhain, amser. Gallwch eu codi, edrych arnynt, eu dadansoddi, eu hychwanegu at eich monitro, adeiladu eich monitro yn seiliedig arnynt.
cwestiynau
Cwestiwn: Dywedasoch na fyddwch yn hysbysebu brandiau, ond rwy'n dal yn chwilfrydig - pa fath o ddangosfyrddau ydych chi'n eu defnyddio yn eich prosiectau?
Ateb: Mae'n amrywio. Mae'n digwydd ein bod yn dod at gwsmer ac mae ganddo ei fonitro ei hun eisoes. Ac rydym yn cynghori'r cwsmer ar yr hyn sydd angen ei ychwanegu at eu monitro. Mae'r sefyllfa waethaf gyda Zabbix. Oherwydd nad oes ganddo'r gallu i adeiladu graffiau TopN. Rydym ni ein hunain yn defnyddio , oherwydd ein bod yn ymgynghori â'r dynion hyn ar fonitro. Buont yn monitro PostgreSQL yn seiliedig ar ein manylebau technegol. Rwy'n ysgrifennu fy mhrosiect anifeiliaid anwes fy hun, sy'n casglu data trwy Prometheus ac yn ei gyflwyno . Fy nhasg yw creu fy allforiwr fy hun yn Prometheus ac yna rendro popeth yn Grafana.
Cwestiwn: A oes unrhyw analogau o adroddiadau AWR neu... agregu? Ydych chi'n gwybod am rywbeth fel hyn?
Ateb: Ydw, dwi'n gwybod beth yw AWR, mae'n beth cŵl. Ar hyn o bryd mae amrywiaeth o feiciau sy'n gweithredu tua'r model canlynol. Ar ryw ysbaid o amser, ysgrifennir rhai llinellau sylfaen i'r un PostgreSQL neu i storfa ar wahân. Gallwch chi eu google ar y Rhyngrwyd, maen nhw yno. Mae un o ddatblygwyr y fath beth yn eistedd ar y fforwm sql.ru yn yr edefyn PostgreSQL. Gallwch chi ei ddal yno. Oes, mae yna bethau o'r fath, gellir eu defnyddio. Byd Gwaith yn ei Rydw i hefyd yn ysgrifennu peth sy'n caniatáu i chi wneud yr un peth.
PS1 Os ydych chi'n defnyddio postgres_exporter, pa ddangosfwrdd ydych chi'n ei ddefnyddio? Mae yna sawl un ohonyn nhw. Maent eisoes wedi dyddio. Efallai y bydd y gymuned yn creu templed wedi'i ddiweddaru?
PS2 Dileu pganalyze oherwydd ei fod yn gynnig SaaS perchnogol sy'n canolbwyntio ar fonitro perfformiad ac awgrymiadau tiwnio awtomataidd.
Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. os gwelwch yn dda.
Pa fonitro postgresql hunangynhaliol (gyda dangosfwrdd) ydych chi'n ei ystyried orau?
-
30,0%Zabbix + ychwanegiadau gan Alexey Lesovsky neu zabbix 4.4 neu 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%Mae pganalyze yn SaaS perchnogol - ni allaf ei ddileu1
-
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
Pleidleisiodd 10 o ddefnyddwyr. Ataliodd 26 o ddefnyddwyr.
Ffynhonnell: hab.com