Мен сизге Алексей Лесовскийдин Эгреттин "PostgreSQL мониторингинин негиздери" баяндамасынын стенограммасын окууну сунуштайм.
Бул баяндамада Алексей Лесовский пост-гресс статистикасынын негизги пункттары, алар эмнени билдирери жана эмне үчүн мониторингде болушу керектиги жөнүндө айтып берет; мониторингде кандай графиктер болушу керек, аларды кантип кошуу керек жана аларды кантип чечмелөө керектиги жөнүндө. Отчет маалымат базасынын администраторлору, системалык администраторлор жана Postgres көйгөйлөрүн чечүүгө кызыккан иштеп чыгуучулар үчүн пайдалуу болот.
Менин атым Алексей Лесовский, мен Data Egret компаниясынын өкүлүмүн.
Өзүм жөнүндө бир нече сөз. Мен көп убакыт мурун системалык администратор болуп иштей баштагам.
Мен ар кандай Linux системаларын башкардым, Linux менен байланышкан ар кандай нерселердин үстүндө иштедим, б.а. виртуалдаштыруу, мониторинг, проксилер менен иштедим. Мен аны абдан жакшы көрчүмүн. Жана кайсы бир убакта мен жумуш убактымдын көбүн PostgreSQLде иштей баштадым. Ошентип, акырындык менен мен PostgreSQL DBA болуп калдым.
Ал эми карьерам бою мен ар дайым статистика, мониторинг жана телеметрия темаларына кызыкчумун. Жана мен системалык администратор болуп турганда, мен Zabbix менен абдан тыгыз иштештим. Жана мен сыяктуу кичинекей сценарийлерди жаздым . Ал өз убагында абдан популярдуу болгон. Жана ал жерде бир гана Linux эмес, ар кандай компоненттерди да ар кандай маанилүү нерселерди көзөмөлдөөгө мүмкүн болгон.
Азыр мен PostgreSQLде иштеп жатам. Мен PostgreSQL статистикасы менен иштөөгө мүмкүндүк берген дагы бир нерсени жазып жатам. деп аталат (Habré боюнча макала - ).
Бир аз кириш сөз. Биздин кардарларда, биздин кардарларда кандай жагдайлар бар? Маалымат базасына байланыштуу кандайдыр бир кырсык бар. Ал эми маалымат базасы калыбына келтирилип бүткөндөн кийин, бөлүмдүн башчысы же өнүктүрүү бөлүмүнүн башчысы келип: "Достор, биз маалымат базасын көзөмөлдөшүбүз керек, анткени бир жаман нерсе болуп кетти жана келечекте мындай болбошу керек" дейт. Бул жерде сиз өзүңүздүн маалымат базаңызды - PostgreSQL, MySQL же башкаларды көзөмөлдөй алгыдай кылып мониторинг тутумун тандоонун же учурдагы мониторинг тутумун адаптациялоонун кызыктуу процесси башталат. Ал эми кесиптештери: «Баланча база бар деп уктум. Келгиле, колдонолу”. Кесиптештер бири-бири менен талаша башташат. Акыр-аягы, биз кандайдыр бир маалымат базасын тандайбыз, бирок PostgreSQL мониторинги анда начар көрсөтүлөт жана биз ар дайым бир нерсе кошууга туура келет. GitHub'дан бир нече репозиторийлерди алыңыз, аларды клондоңуз, скрипттерди ыңгайлаштырыңыз жана кандайдыр бир жол менен аларды ыңгайлаштырыңыз. Акыр-аягы, бул кандайдыр бир кол эмгеги менен аяктайт.
Ошондуктан, бул баяндамада мен сизге PostgreSQL үчүн гана эмес, маалымат базасы үчүн да мониторингди кантип тандоо керектиги боюнча билим берүүгө аракет кылам. Жана сизге кандайдыр бир пайда алуу үчүн мониторингиңизди аягына чыгарууга мүмкүндүк бере турган билимди бериңиз, ошондо сиз өзүңүздүн маалымат базаңызды пайда менен көзөмөлдөй аласыз, келип чыгышы мүмкүн болгон ар кандай өзгөчө кырдаалдардын алдын алуу үчүн.
Жана бул отчетто боло турган идеяларды DBMS же noSQL болобу, каалаган маалымат базасына түздөн-түз ылайыкташтырса болот. Ошондуктан, PostgreSQL гана эмес, PostgreSQLде муну кантип жасоо боюнча көптөгөн рецепттер болот. Сурамдардын мисалдары, PostgreSQLде мониторинг жүргүзүү үчүн болгон объекттердин мисалдары болот. Эгерде сиздин DBMS сизди мониторингге коюуга мүмкүндүк берген нерселерге ээ болсо, сиз аларды ыңгайлаштырып, кошуп койсоңуз болот, бул жакшы болот.
Мен баяндамага катышпайм
көрсөткүчтөрдү кантип жеткирүү жана сактоо жөнүндө сүйлөшкүлө. Маалыматтарды кайра иштетүү жана колдонуучуга көрсөтүү жөнүндө эч нерсе айтпайм. Ал эми эскертүү жөнүндө эч нерсе айтпайм.
Бирок окуянын жүрүшү менен, мен учурдагы мониторингдин ар кандай скриншотторун көрсөтүп, кандайдыр бир жол менен аларды сындайм. Бирок, ошентсе да, мен бул продуктылар үчүн жарнама же антиреклама жаратпоо үчүн бренддерди атабаганга аракет кылам. Ошондуктан, бардык кокустуктар туш келди жана сиздин элестетүүңүзгө калтырылган.
Биринчиден, мониторинг деген эмне экенин аныктап алалы. Мониторинг - бул өтө маанилүү нерсе. Муну баары түшүнөт. Бирок, ошол эле учурда, мониторинг бизнес продуктуга тиешелүү эмес жана түздөн-түз компаниянын киреше таасир этпейт, ошондуктан, убакыт ар дайым калдык негизде мониторинг үчүн бөлүнгөн. Эгерде бизде убакыт бар болсо, анда биз мониторинг жүргүзөбүз; эгерде бизде убакыт жок болсо, анда макул, биз аны артта калтырабыз жана качандыр бир күнү бул иштерге кайтып келебиз.
Ошондуктан, биздин практикадан, биз кардарларга келгенде, мониторинг көп учурда толук эмес жана маалымат базасы менен жакшыраак иштөөгө жардам бере турган кызыктуу нерселер жок. Ошентип, мониторинг ар дайым аякташы керек.
Берилиштер базалары - бул өтө татаал нерселер, аларды да көзөмөлдөө керек, анткени маалымат базалары маалыматтын репозиторийси. Ал эми маалымат компания үчүн абдан маанилүү, аны эч кандай жоготууга болбойт. Бирок, ошол эле учурда, маалымат базалары программалык камсыздоонун өтө татаал бөлүгү. Алар көп сандагы компоненттерден турат. Жана бул компоненттердин көбү мониторинг жүргүзүү керек.
Эгерде биз атайын PostgreSQL жөнүндө сөз кыла турган болсок, анда ал көп сандагы компоненттерден турган схема түрүндө көрсөтүлүшү мүмкүн. Бул компоненттер бири-бири менен өз ара аракеттенет. Ошол эле учурда PostgreSQLде Stats Collector деп аталган подсистема бар, ал бул подсистемалардын иштеши жөнүндө статистиканы чогултууга жана администраторго же колдонуучуга бул статистиканы көрө алышы үчүн кандайдыр бир интерфейсти берүүгө мүмкүндүк берет.
Бул статистика функциялардын жана көз караштардын белгилүү бир жыйындысы түрүндө берилген. Аларды үстөл деп да атоого болот. Башкача айтканда, кадимки psql кардарын колдонуп, сиз маалымат базасына туташып, бул функцияларды жана көрүнүштөрдү тандап, PostgreSQL подсистемаларынын иштеши жөнүндө конкреттүү сандарды ала аласыз.
Сиз бул сандарды сүйүктүү мониторинг тутумуңузга кошуп, графиктерди тартып, функцияларды кошуп, узак мөөнөттүү келечекте аналитика ала аласыз.
Бирок бул баяндамада мен бул функциялардын баарын толук камтыбайм, анткени ал бүт күндү талап кылышы мүмкүн. Мен түзмө-түз эки, үч же төрт нерсеге кайрылам жана алар мониторингди жакшыртууга кандайча жардам берерин айтып берем.
Ал эми маалымат базасына мониторинг жөнүндө сөз кыла турган болсок, анда эмнеге мониторинг жүргүзүү керек? Биринчиден, биз жеткиликтүүлүгүн көзөмөлдөшүбүз керек, анткени маалымат базасы кардарларга маалыматтарга жетүүнү камсыз кылган кызмат жана биз жеткиликтүүлүгүн көзөмөлдөшүбүз керек, ошондой эле анын айрым сапаттык жана сандык мүнөздөмөлөрүн беришибиз керек.
Биз ошондой эле биздин маалымат базасына туташкан кардарларды көзөмөлдөшүбүз керек, анткени алар кадимки кардарлар жана маалымат базасына зыян келтире турган зыяндуу кардарлар болушу мүмкүн. Ошондой эле аларга мониторинг жүргүзүү жана алардын ишмердүүлүгүнө көз салуу керек.
Кардарлар маалымат базасына туташканда, алар биздин маалыматтар менен иштей баштаары анык, ошондуктан биз кардарлар маалыматтар менен кандай иштеп жатканын көзөмөлдөшүбүз керек: кайсы таблицалар менен, кайсыл индекстер менен. Башкача айтканда, биздин кардарлар тарабынан түзүлгөн иш жүгүн баалоо керек.
Бирок жумуштун жүгү, албетте, суроо-талаптардан турат. Тиркемелер маалымат базасына туташып, сурамдардын жардамы менен маалыматтарга кире алышат, андыктан бизде маалымат базасында кандай суроо бар экенине баа берүү, алардын адекваттуулугун көзөмөлдөө, алар кыйшык жазылбаганын, кээ бир варианттарды кайра жазып, тезирээк иштеши үчүн жасоо керек. жана жакшыраак аткаруу менен.
Жана биз маалымат базасы жөнүндө сөз болуп жаткандыктан, маалымат базасы ар дайым фон процесстери болуп саналат. Фондук процесстер маалымат базасынын иштешин жакшы деңгээлде кармап турууга жардам берет, ошондуктан алар иштеши үчүн белгилүү бир көлөмдөгү ресурстарды талап кылат. Ошол эле учурда, алар кардарлардын суроо-талап ресурстары менен дал келиши мүмкүн, ошондуктан ач көздүк процесстер кардар суроо-талаптарынын аткарылышына түздөн-түз таасир этиши мүмкүн. Ошондуктан, алар да фон процесстери жагынан эч кандай бурмалоолор болбошу үчүн мониторинг жана байкоо жүргүзүү керек.
Ал эми маалымат базасына мониторинг жүргүзүү жагынан мунун баары системалык метрикада кала берет. Бирок биздин инфраструктурабыздын көбү булуттарга өтүп жатканын эске алганда, жеке хосттун системалык көрсөткүчтөрү ар дайым арткы планга өтүп кетет. Бирок маалымат базаларында алар дагы эле актуалдуу жана, албетте, системалык көрсөткүчтөрдү көзөмөлдөө керек.
Системалык көрсөткүчтөр менен бардыгы аздыр-көптүр жакшы, бардык заманбап мониторинг системалары бул көрсөткүчтөрдү колдойт, бирок жалпысынан, кээ бир компоненттер дагы эле жетишсиз жана кээ бир нерселерди кошуу керек. Мен аларга да токтолом, алар тууралуу бир нече слайддар болот.
Пландын биринчи пункту - жеткиликтүүлүк. Жеткиликтүүлүк деген эмне? Менин түшүнүгүмдө жеткиликтүүлүк - бул базанын байланыштарды тейлөө мүмкүнчүлүгү, б.а. база көтөрүлөт, ал сервис катары кардарлардын байланыштарын кабыл алат. Жана бул жеткиликтүүлүк белгилүү бир мүнөздөмөлөр менен бааланышы мүмкүн. Бул мүнөздөмөлөрдү башкаруу панелдеринде көрсөтүү абдан ыңгайлуу.
Баардыгы тактайлар эмне экенин билет. Бул сиз керектүү маалымат жалпыланган экранды бир карап алганыңызда. Ал эми маалымат базасында көйгөй бар же жок экенин дароо аныктай аласыз.
Демек, маалымат базасынын болушу жана башка негизги мүнөздөмөлөр ар дайым тактайларда көрсөтүлүшү керек, ошондуктан бул маалымат колуңузда жана ар дайым сизге жеткиликтүү. Инциденттерди иликтөөгө жардам берген кээ бир кошумча деталдар, кээ бир өзгөчө кырдаалдарды иликтөөдө, алар буга чейин эле экинчи такталарга жайгаштырылышы керек, же үчүнчү тараптын мониторинг системаларына алып баруучу бургулоо шилтемелеринде жашырылышы керек.
Бир белгилүү мониторинг системасынын мисалы. Бул абдан сонун мониторинг системасы болуп саналат. Ал көп маалыматтарды чогултат, бирок менин көз карашым боюнча, анын башкаруу панелдеринин кызыктай түшүнүгү бар. "Көрмөлөр тактасын түзүү" шилтемеси бар. Бирок сиз аспаптар тактасын түзүп жатканда, сиз эки мамычанын тизмесин, графиктердин тизмесин түзөсүз. Жана бир нерсени карап чыгуу керек болгондо, сиз чычкан менен басып, сыдырып, керектүү диаграмманы издей баштайсыз. Ал эми бул убакытты талап кылат, башкача айтканда, башкаруу такталары жок. Диаграммалардын тизмелери гана бар.
Бул панелдерге эмне кошуу керек? Сиз жооп берүү убактысы сыяктуу өзгөчөлүктөн баштасаңыз болот. PostgreSQL pg_stat_statements көрүнүшүнө ээ. Ал демейки боюнча өчүрүлгөн, бирок ал ар дайым иштетилип жана колдонулушу керек болгон маанилүү система көрүнүштөрүнүн бири. Ал маалымат базасында аткарылган бардык иштеп жаткан суроо-талаптар жөнүндө маалыматты сактайт.
Демек, биз бардык суроо-талаптарды аткаруунун жалпы убактысын алып, аны жогорудагы талааларды колдонуу менен суроо-талаптардын санына бөлө алабыз дегенден баштасак болот. Бирок бул ооруканадагы орточо температура. Биз башка талаалардан баштасак болот - суроону аткаруунун минималдуу убактысы, максималдуу жана медианасы. Жана биз пайызтилдерди түзө алабыз; PostgreSQL бул үчүн тиешелүү функцияларга ээ. Ал эми биз толукталган суроо-талаптар үчүн биздин базанын жооп берүү убактысын мүнөздөгөн кээ бир сандарды ала алабыз, башкача айтканда, биз "1ди танда" деген жасалма суроо-талапты аткарбайбыз жана жооп берүү убактысын карабайбыз, бирок биз буга чейин аткарылган суроо-талаптар үчүн жооп берүү убактысын талдап, сызабыз. же өзүнчө фигура, же анын негизинде график түзөбүз.
Ошондой эле учурда система тарабынан түзүлгөн каталардын санын көзөмөлдөө маанилүү. Жана бул үчүн сиз pg_stat_database көрүнүшүн колдоно аласыз. Биз xact_rollback талаасына көңүл бурабыз. Бул талаа маалымат базасында пайда болгон артка кайтаруулардын санын гана көрсөтпөстөн, каталардын санын да эске алат. Салыштырмалуу айтсак, биз бул көрсөткүчтү тактабызда көрсөтүп, учурда канча ката бар экенин көрө алабыз. Эгерде каталар көп болсо, анда бул журналдарды карап чыгуу жана алар кандай каталар жана эмне үчүн пайда болгонун көрүп, анан аларды инвестициялап, чечүү үчүн жакшы себеп.
Тахометр сыяктуу нерсени кошо аласыз. Бул секундасына транзакциялардын саны жана секундасына суроо-талаптардын саны. Салыштырмалуу айтканда, сиз бул сандарды маалымат базасынын учурдагы көрсөткүчү катары колдоно аласыз жана суроо-талаптардын чокусу, транзакциялардын чокусу же, тескерисинче, кээ бир бэкенддер иштебей калгандыктан, маалымат базасы аз жүктөлүп калганбы же жокпу байкай аласыз. Бул көрсөткүчтү ар дайым карап туруу маанилүү жана биздин долбоор үчүн мындай көрсөткүч нормалдуу экенин эстен чыгарбоо керек, бирок жогорудагы жана төмөнкү баалуулуктар кандайдыр бир көйгөйлүү жана түшүнүксүз болуп саналат, демек, бул сандар эмне үчүн экенин карап чыгышыбыз керек. ушунчалык бийик.
Транзакциялардын санын баалоо үчүн, биз кайрадан pg_stat_database көрүнүшүнө кайрылсак болот. Биз милдеттенмелердин санын жана артка кайтаруулардын санын кошуп, секундасына транзакциялардын санын ала алабыз.
Ар бир адам бир нече суроо-талаптар бир транзакцияга туура келерин түшүнөбү? Ошондуктан TPS жана QPS бир аз башкача.
секундасына суроо-талаптардын санын pg_stat_statements алууга болот жана жөн гана бардык аткарылган суроо-талаптардын суммасын эсептөө. Учурдагы маанини мурунку менен салыштырып, аны кемитип, дельтаны алып, санды алганыбыз түшүнүктүү.
Кааласаңыз, кошумча көрсөткүчтөрдү кошо аласыз, алар биздин маалымат базасынын жеткиликтүүлүгүн баалоого жана токтоп калуулар болгон-болбогонун көзөмөлдөөгө жардам берет.
Бул көрсөткүчтөрдүн бири иштөө убактысы. Бирок PostgreSQLде иштөө убактысы бир аз татаал. Мен сага эмне үчүн айтам. PostgreSQL башталганда, иштөө убактысы отчет бере баштайт. Бирок, эгер кандайдыр бир учурда, мисалы, түн ичинде кандайдыр бир тапшырма иштеп жатса, OOM өлтүргүч келип, PostgreSQL бала процессин мажбурлап токтотсо, анда бул учурда PostgreSQL бардык кардарлардын байланышын токтотуп, эс тутумдун сынык аймагын баштапкы абалга келтирип, калыбына келтирүүнү баштайт. акыркы текшерүү пункту. Ал эми текшерүү пунктунан бул калыбына келтирүү созулуп жатканда, маалымат базасы байланыштарды кабыл албайт, башкача айтканда, бул абалды токтоп калуу катары баалоого болот. Бирок иштөө убактысынын эсептегичи баштапкы абалга келтирилбейт, анткени ал биринчи учурдан тартып почта мастеринин ишке киргизүү убактысын эске алат. Ошондуктан, мындай жагдайларды өткөрүп жиберүүгө болот.
Сиз ошондой эле вакуумдук жумушчулардын санын көзөмөлдөө керек. PostgreSQLде автовакуум деген эмне экенин бардыгы билеби? Бул PostgreSQLдеги кызыктуу подсистема. Ал жөнүндө көптөгөн макалалар жазылды, көптөгөн баяндамалар жасалды. Вакуум жана анын кантип иштеши керектиги жөнүндө көп талкуулар бар. Көптөр муну зарыл жамандык деп эсептешет. Бирок ушундай. Бул кандайдыр бир транзакцияга кереги жок катарлардын эскирген версияларын тазалаган жана жадылар үчүн таблицаларда жана индекстерде орун бошотуучу таштанды жыйноочу аналогунун бир түрү.
Эмне үчүн ага мониторинг жүргүзүү керек? Анткени вакуум кээде катуу ооруйт. Ал көп сандагы ресурстарды талап кылат жана натыйжада кардарлардын суроо-талаптары азап тарта баштайт.
Ал pg_stat_activity көрүнүшү аркылуу көзөмөлдөнүшү керек, мен кийинки бөлүмдө сүйлөшөм. Бул көрүнүш маалымат базасындагы учурдагы аракетти көрсөтөт. Жана бул иш аркылуу биз азыр иштеп жаткан вакуумдардын санын байкай алабыз. Биз вакуумдарга көз салып, эгер биз чектен ашып кеткен болсок, анда бул PostgreSQL жөндөөлөрүн карап чыгууга жана кандайдыр бир жол менен вакуумдун иштешин оптималдаштырууга негиз экенин көрө алабыз.
PostgreSQL жөнүндө дагы бир нерсе - PostgreSQL узак транзакциялардан абдан кыйналат. Айрыкча, узак убакыт бою эч нерсе кылбаган транзакциялардан. Бул транзакциядагы статистика деп аталган нерсе. Мындай транзакция кулпуларды кармап турат жана вакуумдун иштешине жол бербейт. Натыйжада, столдор шишип, көлөмү көбөйөт. Жана бул таблицалар менен иштеген суроо-талаптар жайыраак иштей баштайт, анткени саптардын бардык эски версияларын эстутумдан дискке жана артка сүрүшүңүз керек. Ошондуктан, эң узак транзакциялардын убактысы, узактыгы, эң узак вакуумдук суроо-талаптар да көзөмөлдөнүшү керек. И если мы видим какие-то процессы, которые работают уже очень долго, уже больше 10-20-30 минут для OLTP-нагрузки, то на них нужно уже обращать внимание и завершать принудительно, либо оптимизировать приложение, чтобы они не вызывались и не висели ушунча узакпы. Аналитикалык жүктөө үчүн 10-20-30 мүнөт нормалдуу, андан да узунураактары бар.
Кийинки бизде туташкан кардарлар менен опция бар. Биз аспаптар тактасын түзүп, ага негизги жеткиликтүүлүк көрсөткүчтөрүн жайгаштырганыбызда, ал жерге туташкан кардарлар тууралуу кошумча маалыматты кошо алабыз.
Туташкан кардарлар жөнүндө маалымат маанилүү, анткени PostgreSQL көз карашынан алганда, кардарлар ар башка. Жакшы кардарлар бар, жаман кардарлар бар.
Жөнөкөй мисал. Кардар менен мен колдонмону түшүнөм. Тиркеме маалымат базасына туташып, ошол замат өзүнүн суроо-талаптарын ошол жакка жөнөтө баштайт, маалымат базасы аларды иштетип, аткарат жана натыйжаларды кардарга кайтарып берет. Бул жакшы жана туура кардарлар.
Кардар туташкан учурлар бар, ал байланышты кармап турат, бирок эч нерсе кылбайт. Ал иштебей турган абалда.
Бирок жаман кардарлар бар. Мисалы, ошол эле кардар туташып, транзакция ачып, маалымат базасында бир нерсе кылып, анан кодго кирип, мисалы, тышкы булакка жетүү үчүн же ал жерде алынган маалыматтарды иштетүү үчүн. Бирок ал бүтүмдү жапкан жок. Ал эми транзакция маалымат базасында илинип турат жана линиядагы кулпуда кармалат. Бул жаман абал. Жана эгер күтүлбөгөн жерден кандайдыр бир тиркеме өзүнүн ичинде кандайдыр бир өзгөчөлүк менен ишке ашпай калса, анда транзакция узак убакыт бою ачык бойдон кала берет. Бул түздөн-түз PostgreSQL иштешине таасир этет. PostgreSQL жайыраак болот. Ошондуктан, мындай кардарларды өз убагында көзөмөлдөө жана алардын ишин күч менен токтотуу маанилүү. Жана мындай жагдайлар болбошу үчүн колдонмоңузду оптималдаштырышыңыз керек.
Башка жаман кардарлар кардарларды күтүп жатышат. Бирок алар жагдайдан улам жаман болуп калышат. Мисалы, жөнөкөй бош транзакция: ал транзакцияны ача алат, кээ бир саптарда кулпуларды алат, андан кийин коддун бир жеринде ал ишке ашпай калат, асылып бүтүм калтырат. Дагы бир кардар келип, ошол эле маалыматтарды сурайт, бирок ал кулпуга туш болот, анткени ал асма транзакцияда кээ бир талап кылынган катарларда кулпулар бар. Ал эми экинчи транзакция биринчи транзакциянын аягына чейин же администратор аны мажбурлап жабууну күтүп туруп калат. Ошондуктан, күтүлүп жаткан транзакциялар маалымат базасына туташуу чегин топтоп, толтурушу мүмкүн. Ал эми лимит толгондо, тиркеме мындан ары маалымат базасы менен иштей албайт. Бул долбоор үчүн ансыз деле өзгөчө кырдаал болуп саналат. Ошондуктан, жаман кардарларды көзөмөлдөө жана өз убагында жооп берүү керек.
Мониторингдин дагы бир мисалы. Ал эми бул жерде буга чейин татыктуу башкаруу тактасы бар. Жогорудагы байланыштар боюнча маалымат бар. МБ байланышы – 8 даана. Жана мунун баары. Бизде кайсы кардарлар активдүү, кайсы кардарлар эч нерсе кылбай бош жүргөнү тууралуу маалыматыбыз жок. Күтүүдөгү транзакциялар жана күтүлүп жаткан байланыштар жөнүндө маалымат жок, башкача айтканда, бул байланыштардын санын көрсөткөн цифра жана бүттү. Анан өзүң ойлоп көр.
Демек, бул маалыматты мониторингге кошуу үчүн pg_stat_activity тутумунун көрүнүшүнө кирүү керек. Эгерде сиз PostgreSQLде көп убакыт өткөрсөңүз, анда бул сиздин досуңузга айланган абдан жакшы көрүнүш, анткени ал PostgreSQLдеги учурдагы активдүүлүктү, б.а. анда эмне болуп жатканын көрсөтөт. Ар бир процесс үчүн бул процесс тууралуу маалыматты көрсөткөн өзүнчө сап бар: туташуу кайсы хосттон жасалган, кайсы колдонуучу менен, кандай ат менен, транзакция качан башталган, кайсы суроо-талап учурда иштеп жатат, кандай суроо-талап акыркы жолу аткарылган. Жана, ошого жараша, биз кардардын абалын stat талаасынын жардамы менен баалай алабыз. Салыштырмалуу айтканда, биз бул талаа боюнча топтоп, учурда маалымат базасында болгон статистиканы жана маалымат базасында бул статистикага ээ болгон байланыштардын санын ала алабыз. Ал эми биз буга чейин алынган сандарды мониторингибизге жөнөтүп, алардын негизинде графиктерди түзө алабыз.
Бул бүтүмдүн узактыгын баалоо үчүн да маанилүү болуп саналат. Мен буга чейин вакуумдардын узактыгын баалоо маанилүү экенин айттым, бирок транзакциялар да ошондой бааланат. xact_start жана query_start талаалары бар. Алар, салыштырмалуу айтканда, бүтүмдүн баштоо убактысын жана суроо-талаптын башталышын көрсөтөт. Учурдагы убакыт белгисин көрсөткөн now() функциясын алып, транзакцияны жана суроонун убакыт белгисин алып салабыз. Ал эми биз транзакциянын узактыгын, суроо-талаптын узактыгын алабыз.
Эгерде биз узак транзакцияларды көрсөк, анда биз аларды мурунтан эле бүтүрүшүбүз керек. OLTP жүктөө үчүн, узак транзакциялар 1-2-3 мүнөттөн ашык убакытты түзөт. OLAP иш жүгү үчүн узак транзакциялар нормалдуу, бирок аларды аягына чыгаруу үчүн эки сааттан ашык убакыт талап кылынса, анда бул дагы бизде бир жерде кыйшаюу бар экендигинин белгиси.
Кардарлар маалымат базасына туташкандан кийин, алар биздин маалыматтар менен иштей башташат. Алар таблицаларга, таблицадан маалыматтарды алуу үчүн индекстерге кире алышат. Ал эми кардарлар бул маалыматтар менен өз ара кандай баа берүү маанилүү.
Бул биздин иш жүктөмдү баалоо жана биз үчүн кайсы таблицалар "эң ысык" экенин так түшүнүү үчүн зарыл. Мисалы, бул биз кандайдыр бир тез SSD сактагычка "ысык" үстөлдөрдү жайгаштыргыбыз келген учурларда керек. Мисалы, биз көптөн бери колдонбогон кээ бир архивдик таблицаларды кандайдыр бир "муздак" архивге, SATA дисктерине жылдырып, ошол жерде жашашына уруксат берсек болот, алар керек болсо жеткиликтүү болот.
Бул ар кандай чыгарылыштардан жана жайылтуулардан кийин аномалияларды аныктоо үчүн да пайдалуу. Долбоор жаңы функцияларды чыгарды дейли. Мисалы, биз маалымат базасы менен иштөө үчүн жаңы функцияларды коштук. Эгерде биз үстөлдү колдонуу графиктерин түзсөк, анда биз бул графиктерде бул аномалияларды оңой эле аныктай алабыз. Мисалы, жарылууларды жаңыртуу же жарылууларды жок кылуу. Бул абдан көрүнүктүү болот.
Сиз ошондой эле "сүзүүчү" статистикадагы аномалияларды таба аласыз. Бул эмнени билдирет? PostgreSQL абдан күчтүү жана абдан жакшы суроо пландоочусу бар. Ал эми иштеп чыгуучулар аны өнүктүрүүгө көп убакыт бөлүшөт. Ал кантип иштейт? Жакшы пландарды түзүү үчүн, PostgreSQL белгилүү бир убакыт аралыгында жана белгилүү бир жыштык менен таблицаларда маалыматтарды бөлүштүрүү боюнча статистиканы чогултат. Бул эң кеңири таралган баалуулуктар: уникалдуу маанилердин саны, таблицадагы NULL жөнүндө маалымат, көп маалымат.
Бул статистиканын негизинде пландоочу бир нече суроону түзөт, эң оптималдуусун тандап алат жана бул суроо планын суроонун өзүн аткаруу жана маалыматтарды кайтаруу үчүн колдонот.
Ал эми статистика "сүзүп" болот. Таблицада сапат жана сандык маалыматтар кандайдыр бир жол менен өзгөргөн, бирок статистика чогултулган эмес. Ал эми түзүлгөн пландар оптималдуу болбой калышы мүмкүн. Ал эми чогултулган мониторингдин, таблицалардын негизинде биздин пландар оптималдуу эмес болуп чыкса, биз бул аномалияларды көрө алабыз. Мисалы, кайсы бир жерде маалыматтар сапаттык жактан өзгөрүп, индекстин ордуна таблица аркылуу ырааттуу өтүү колдонула баштады, б.а. эгерде суроо 100 сапты гана кайтарышы керек болсо (100 чеги бар), анда бул суроо үчүн толук издөө жүргүзүлөт. Жана бул ар дайым аткарууга абдан жаман таасирин тийгизет.
А биз муну мониторингден көрө алабыз. Бул суроону карап көрүңүз, ага түшүндүрмө бериңиз, статистика чогултуңуз, жаңы кошумча индекс түзүңүз. Жана буга чейин бул көйгөйгө жооп. Ошондуктан бул маанилүү.
Мониторингдин дагы бир мисалы. Менимче, аны көп адамдар тааныды, анткени ал абдан популярдуу. Ким өз долбоорлорунда колдонот ? Бул продуктуну Prometheus менен бирге ким колдонот? Чындыгында, бул мониторингдин стандарттык репозиторийинде PostgreSQL менен иштөө үчүн башкаруу тактасы бар - Прометей. Бирок бир жаман детал бар.
Бир нече графиктер бар. Жана байттар бирдик катары көрсөтүлөт, башкача айтканда 5 график бар. Булар: Маалыматтарды киргизүү, Дайындарды жаңыртуу, Дайындарды жок кылуу, Дайындарды алуу жана Берилиштерди кайтаруу. Өлчөм бирдиги байт. Бирок, PostgreSQLдеги статистика маалыматтарды кортежде (катарда) кайтарат. Жана, ошого жараша, бул графиктер сиздин иш жүгүңүздү бир нече жолу, ондогон жолу баалабай коюунун эң жакшы жолу, анткени кортеж байт эмес, кортеж сап, ал көп байт жана ал ар дайым өзгөрүлмө узундукта. Башкача айтканда, кортеждерди колдонуу менен байттарда жумуш жүгүн эсептөө реалдуу эмес иш же өтө кыйын. Ошондуктан, сиз аспаптар тактасын же орнотулган мониторингди колдонгондо, анын туура иштеп, туура бааланган маалыматтарды кайтарып берерин түшүнүү дайыма маанилүү.
Бул таблицалар боюнча статистиканы кантип алууга болот? Ушул максатта, PostgreSQL белгилүү бир үй-бүлөгө ээ. Ал эми негизги көрүнүш . User_tables - бул колдонуучунун атынан түзүлгөн таблицаларды билдирет. Ал эми, PostgreSQL өзү колдонгон системалык көрүнүштөр бар. Ал эми Alltables жыйынды таблицасы бар, ал системаны да, колдонуучуну да камтыйт. Сиз алардын каалаганынан баштасаңыз болот.
Жогорудагы талааларды колдонуу менен сиз киргизүүлөрдүн, жаңыртуулардын жана жок кылуулардын санын эсептей аласыз. Мен колдонгон башкаруу тактасынын мисалы бул талааларды жумуш жүктөмүнүн мүнөздөмөлөрүн баалоо үчүн колдонот. Ошондуктан, биз да аларга таяна алабыз. Бирок бул байт эмес, кортеждер экенин эстен чыгарбоо керек, андыктан биз муну байт менен эле жасай албайбыз.
Бул маалыматтардын негизинде биз TopN деп аталган таблицаларды түзө алабыз. Мисалы, Топ-5, Топ-10. Жана сиз башкаларга караганда кайра иштетилген ысык үстөлдөрдү көзөмөлдөй аласыз. Мисалы, киргизүү үчүн 5 "ысык" үстөл. Жана бул TopN таблицаларын колдонуу менен биз иш жүгүбүздү баалайбыз жана ар кандай чыгарылыштардан, жаңыртуулардан жана жайылтуулардан кийин жумуш жүгүн баалайбыз.
Столдун көлөмүн баалоо да маанилүү, анткени кээде иштеп чыгуучулар жаңы функцияны чыгарышат жана биздин таблицалар чоң өлчөмдөрдө шишип баштайт, анткени алар кошумча көлөмдөгү маалыматтарды кошууну чечишкен, бирок бул кандай болорун алдын ала айтышкан эмес. маалымат базасынын өлчөмүнө таасир этет. Мындай учурлар биз үчүн да таң калыштуу.
Эми сизге кичинекей суроо. Маалыматтар базасынын серверине жүктөмдү байкаганыңызда кандай суроо туулат? Кийинки сурооңуз кандай?
Бирок чындыгында төмөнкүдөй суроо туулат. Жүктөө кандай суроо-талаптарды жаратат? Башкача айтканда, жүктүн айынан пайда болгон процесстерди кароо кызык эмес. Эгерде хостто маалымат базасы бар болсо, анда маалымат базасы ошол жерде иштеп жатканы түшүнүктүү жана ал жерде маалымат базалары гана жок кылынары анык. Эгерде биз Topду ачсак, анда PostgreSQLде бир нерсе кылып жаткан процесстердин тизмесин көрөбүз. Эмне кылып жатышканы Топтон билинбейт.
Демек, сиз эң чоң жүктөмдү пайда кылган суроо-талаптарды табышыңыз керек, анткени тюнинг сурамдары, эреже катары, PostgreSQL же операциялык системанын конфигурациясын жөндөөдөн, жада калса аппараттык камсыздоону жөндөөдөн көбүрөөк пайда берет. Менин эсебим боюнча, бул болжол менен 80-85-90% түзөт. Жана бул алда канча тезирээк жасалат. Конфигурацияны оңдоого, кайра баштоону пландаштырууга, айрыкча маалымат базасын кайра баштоого же аппараттык камсыздоону кошууга караганда суроону оңдоо тезирээк. Бул суроодон жакшыраак натыйжа алуу үчүн суроону бир жерге кайра жазуу же индексти кошуу оңой.
Ошого жараша суроо-талаптарга жана алардын шайкештигине мониторинг жүргүзүү зарыл. Мониторингдин дагы бир мисалын алалы. Бул жерде да эң сонун мониторинг бар окшойт. Репликация жөнүндө маалымат бар, өткөрүү жөндөмдүүлүгү, бөгөттөө, ресурстарды пайдалануу боюнча маалымат бар. Баары жакшы, бирок кайрылуулар боюнча маалымат жок. Биздин базада кандай сурамдар иштеп жатканы, алар канча убакытка созулуп жатканы, бул сурамдардын канчасы экени белгисиз. Биздин мониторингибизде бул маалымат дайыма болушу керек.
Жана бул маалыматты алуу үчүн pg_stat_statements модулун колдоно алабыз. Анын негизинде сиз ар кандай графиктерди түзө аласыз. Мисалы, сиз эң көп берилген суроо-талаптар боюнча, башкача айтканда, эң көп аткарылган сурамдар боюнча маалымат ала аласыз. Ооба, жайгаштыруудан кийин аны карап чыгуу жана суроо-талаптардын көбөйүшүн түшүнүү абдан пайдалуу.
Сиз эң узун сурамдарды, башкача айтканда, эң көп убакытты талап кылган суроолорду көзөмөлдөй аласыз. Алар процессордо иштешет, киргизүү/чыгаруу керектелет. Муну жалпы_убакыт, орточо_убакыт, blk_write_time жана blk_read_time талаалары аркылуу да баалай алабыз.
Биз ресурстарды пайдалануу жагынан эң оор суроо-талаптарды, дисктен окугандарды, эстутум менен иштегендерди, же тескерисинче, кандайдыр бир жазуу жүгүн түзө алабыз.
Биз эң жоомарт өтүнүчтөрдү баалай алабыз. Бул көп сандагы саптарды кайтарган сурамдар. Мисалы, бул чектөө коюуну унутуп калган кээ бир өтүнүч болушу мүмкүн. Ал жөн гана суралган таблицалар боюнча таблицанын же суроонун бүт мазмунун кайтарат.
Ошондой эле сиз убактылуу файлдарды же убактылуу таблицаларды колдонгон сурамдарды көзөмөлдөй аласыз.
Ал эми бизде дагы эле фон процесстери бар. Фондук процесстер биринчи кезекте өткөрүү пункттары же аларды текшерүү пункттары деп да аташат, булар автовакуум жана репликация.
Мониторингдин дагы бир мисалы. Сол жакта Тейлөө өтмөгү бар, ага өтүңүз жана пайдалуу нерсени көрөм деп үмүттөнөбүз. Бирок бул жерде вакуумдук операция жана статистиканы чогултуу убактысы гана, башка эч нерсе эмес. Бул абдан начар маалымат, андыктан биздин маалымат базасында фондо процесстер кандайча иштээри жана алардын ишинде кандайдыр бир көйгөйлөр бар же жок экендиги тууралуу маалыматка ээ болушубуз керек.
Биз текшерүү пункттарын караганыбызда, текшерүү пункттары кир барактарын эс тутум аймагынан дискке жууп, андан кийин текшерүү пунктун түзөрүн эстен чыгарбашыбыз керек. Жана бул текшерүү пункту, эгерде PostgreSQL чукул кырдаалда күтүүсүздөн токтотулса, калыбына келтирүү үчүн жер катары колдонулушу мүмкүн.
Демек, дискке бардык "кир" барактарды тазалоо үчүн, сиз белгилүү бир көлөмдөгү жазууларды жасашыңыз керек. Ал эми, эреже катары, эс тутуму чоң системаларда, бул көп. Эгерде биз текшерүү пункттарын кыска аралыкта өтө тез-тез жасасак, анда дисктин иштеши абдан төмөндөйт. Ал эми кардарлардын суроо-талаптары ресурстардын жетишсиздигинен жабыркайт. Олар ресурслар угрунда ярышярлар ве онумчилиге етмезчилик эдйэрлер.
Демек, pg_stat_bgwriter аркылуу көрсөтүлгөн талааларды колдонуп, биз болгон текшерүү пункттарынын санын көзөмөлдөй алабыз. Ал эми бизде белгилүү бир убакыттын ичинде (10-15-20 мүнөттө, жарым саатта), мисалы, 3-4-5-те көп сандагы көзөмөл-өткөрүү пункттары болсо, анда бул мурунтан эле көйгөй болушу мүмкүн. Ал эми сиз буга чейин базаны карап, конфигурацияны карап чыгышыңыз керек, текшерүү пункттарынын мынчалык көп болушуна эмне себеп болот. Балким, кандайдыр бир чоң жаздыруу жүрүп жаткандыр. Биз буга чейин эле иш жүктөмүн баалоого болот, анткени биз буга чейин эле иш жүктөмү графиктерин кошкон. Биз мурунтан эле текшерүү пунктунун параметрлерин чыңдап, алар сурамдын аткаруусуна чоң таасирин тийгизбей турганын текшере алабыз.
Мен кайрадан автовакуумга кайтып келем, анткени бул, мен айткандай, дискти да, сурамдардын иштешин да оңой эле кошо ала турган нерсе, андыктан автовакуумдун көлөмүн баалоо дайыма маанилүү.
Базада автовакуумда иштегендердин саны чектелүү. Демейки боюнча, алардын үчөө бар, ошондуктан бизде ар дайым маалымат базасында үч жумушчу болсо, бул биздин автовакуум конфигурацияланбаганын билдирет, биз чектөөлөрдү көтөрүп, автовакуум орнотууларын кайра карап чыгып, конфигурацияга киришибиз керек.
Бизде кандай вакуумдук жумушчулар бар экенине баа берүү маанилүү. Же ал колдонуучудан ишке киргизилди, DBA келип, кол менен кандайдыр бир вакуумду ишке киргизди жана бул жүктү жаратты. Бизде кандайдыр бир көйгөй бар. Же бул транзакция эсептегичти бурап турган вакуумдардын саны. PostgreSQLдин кээ бир версиялары үчүн бул өтө оор вакуумдар. Жана алар аткарууну оңой эле кошо алышат, анткени алар бүт таблицаны окуп, ошол таблицадагы бардык блокторду сканерлейт.
Жана, албетте, вакуумдардын узактыгы. Эгерде бизде узак убакытка созулган вакуумдар болсо, анда бул вакуум конфигурациясына кайрадан көңүл бурушубуз жана балким анын жөндөөлөрүн кайра карап чыгышыбыз керек дегенди билдирет. Анткени вакуум үстөлдүн үстүндө узак убакытка (3-4 саат) иштегенде кырдаал келип чыгышы мүмкүн, бирок вакуум иштеген убакыттын ичинде үстөлгө кайрадан көп сандагы өлүк катарлар топтолуп калган. Ал эми вакуум бүтөөрү менен бул үстөлдү кайрадан сорушу керек. Ал эми биз кырдаалга келдик - чексиз вакуум. Жана бул учурда, вакуум өзүнүн иши менен күрөшө албайт жана таблицалар акырындык менен чоңоюп баштайт, бирок андагы пайдалуу маалыматтардын көлөмү ошол эле бойдон калат. Ошондуктан, узак вакуумда биз ар дайым конфигурацияны карап, аны оптималдаштырууга аракет кылабыз, бирок ошол эле учурда кардарлардын суроо-талаптарынын аткарылышы жабыркабашы үчүн.
Бүгүнкү күндө агымдык репликациясы жок PostgreSQL орнотуулары дээрлик жок. Репликация – бул маалыматтарды мастерден репликага жылдыруу процесси.
PostgreSQLде репликация транзакциялар журналы аркылуу ишке ашырылат. Устат транзакция журналын түзөт. Транзакциялар журналы тармак байланышы аркылуу репликага өтөт, андан кийин ал репликада кайра чыгарылат. Баары оңой.
Демек, pg_stat_replication көрүнүшү репликациянын артта калышын көзөмөлдөө үчүн колдонулат. Бирок аны менен баары жөнөкөй эмес. 10-версияда көрүнүш бир нече өзгөрүүлөргө дуушар болгон. Биринчиден, кээ бир талаалардын аталышы өзгөртүлдү. Жана кээ бир талаалар кошулду. 10-версияда репликациянын артта калышын секундалар ичинде баалоого мүмкүндүк берген талаалар пайда болду. Бул абдан ыңгайлуу. 10-версияга чейин репликациянын артта калышын байт менен баалоого мүмкүн болгон. Бул параметр 10-версияда кала берет, башкача айтканда, сиз үчүн кайсынысы ыңгайлуураак экенин тандай аласыз - артта калууга байт менен баа бериңиз же секундалардагы артта калууга баа бериңиз. Көп адамдар экөөнү тең кылышат.
Бирок, ошентсе да, репликациянын артта калышын баалоо үчүн, транзакциядагы журналдын ордун билишиңиз керек. Жана бул транзакциялар журналынын позициялары так pg_stat_replication көрүнүшүндө. Салыштырмалуу айтканда, pg_xlog_location_diff() функциясын колдонуп транзакциялар журналынан эки пунктту алсак болот. Алардын ортосундагы дельтаны эсептеп, байт менен репликациянын артта калуусун алыңыз. Бул абдан ыңгайлуу жана жөнөкөй.
10-версияда бул функция pg_wal_lsn_diff() деп өзгөртүлгөн. Жалпысынан, "xlog" деген сөз пайда болгон бардык функцияларда, көрүнүштөрдө жана утилиталарда ал "wal" маанисине алмаштырылган. Бул көрүнүшкө да, функцияга да тиешелүү. Бул ушундай жаңычылдык.
Мындан тышкары, 10-версияда артта калгандарды көрсөткөн саптар кошулган. Булар жазуу лагы, флеш лагы, кайталоо лагы. Башкача айтканда, бул нерселерди көзөмөлдөө маанилүү. Эгерде бизде репликация лагы бар экенин көрсөк, анда ал эмне үчүн пайда болгонун, кайдан келгенин иликтеп, көйгөйдү чечишибиз керек.
Дээрлик бардыгы системалык көрсөткүчтөр менен туура келет. Кандайдыр бир мониторинг башталганда, ал системалык көрсөткүчтөр менен башталат. Бул процессорлорду, эстутумду, свопту, тармакты жана дискти жок кылуу. Бирок, көптөгөн параметрлер демейки боюнча жок.
Эгерде бардыгы кайра иштетүү процессине ылайык келсе, анда дискти кайра иштетүүдө көйгөйлөр бар. Эреже катары, мониторинг иштеп чыгуучулар өткөрүү жөндөмдүүлүгү жөнүндө маалымат кошуу. Бул iops же байт болушу мүмкүн. Бирок алар кечигүү жана диск түзүлүштөрүн колдонуу жөнүндө унутуп коюшат. Бул биздин дисктер канчалык жүктөлгөнүн жана алардын канчалык жай экенин баалоого мүмкүндүк берген маанилүү параметрлер. Эгерде бизде күтүү мөөнөтү жогору болсо, анда бул дисктерде кандайдыр бир көйгөйлөр бар экенин билдирет. Эгерде бизде жогорку пайдалануу болсо, бул дисктер туруштук бере албай жатат дегенди билдирет. Бул өткөрүү жөндөмдүүлүгүнө караганда жакшыраак мүнөздөмөлөр.
Мындан тышкары, бул статистиканы кайра иштетүүчү процессорлор үчүн жасалгандай эле /proc файл тутумунан да алса болот. Эмне үчүн бул маалымат мониторингге кошулбаганын билбейм. Бирок, бул сиздин мониторингиңизде болушу маанилүү.
Ошол эле тармак интерфейстерине да тиешелүү. Тармактын өткөрүү жөндөмдүүлүгү жөнүндө пакеттерде, байттарда маалымат бар, бирок кечигүү жөнүндө маалымат жок жана колдонуу жөнүндө маалымат жок, бирок бул да пайдалуу маалымат.
Ар кандай мониторинг кемчиликтери бар. Кандай гана мониторинг жүргүзбөңүз, ал кандайдыр бир критерийлерге жооп бербейт. Бирок, ошентсе да, алар өнүгүп жатат, жаңы функциялар жана жаңы нерселер кошулуп жатат, ошондуктан бир нерсени тандап, аны бүтүрүңүз.
Жана бүтүрүү үчүн, сиз ар дайым берилген статистика эмнени билдирерин жана көйгөйлөрдү чечүү үчүн аларды кантип колдонсоңуз болору жөнүндө түшүнүккө ээ болушуңуз керек.
Жана бир нече негизги пункттар:
- Сиз ар дайым жеткиликтүүлүгүн көзөмөлдөшүңүз керек жана маалымат тактасына ээ болушуңуз керек, андыктан баары маалымат базасына ылайык экенине тез баа бере аласыз.
- Жаман кардарларды жок кылуу жана аларды жок кылуу үчүн ар дайым кардарларыңыз сиздин маалымат базаңыз менен иштеп жаткандыгы жөнүндө түшүнүккө ээ болушуңуз керек.
- Бул кардарлар маалыматтар менен кантип иштээрин баалоо маанилүү. Сиздин жумуш жүгү жөнүндө түшүнүк болушу керек.
- Бул иш жүгү кандай суроонун жардамы менен, кандайча түзүлгөнүн баалоо маанилүү. Сиз суроо-талаптарды баалай аласыз, аларды оптималдаштырып, рефакциялай аласыз, алар үчүн индекстерди түзө аласыз. Бул өтө маанилүү.
- Фондук процесстер кардарлардын суроо-талаптарына терс таасирин тийгизиши мүмкүн, андыктан алар өтө көп ресурстарды колдонбой жатканын көзөмөлдөө маанилүү.
- Системалык көрсөткүчтөр серверлериңиздин көлөмүн кеңейтүү жана көбөйтүү боюнча пландарды түзүүгө мүмкүндүк берет, андыктан аларды көзөмөлдөө жана баалоо да маанилүү.
Эгерде сизди бул тема кызыктырса, анда бул шилтемелер аркылуу өтсөңүз болот.
- бул статистикалык жыйноочу расмий документация. Бардык статистикалык көрүнүштөрдүн сүрөттөлүшү жана бардык талаалардын сүрөттөлүшү бар. Аларды окуп, түшүнүп, талдай аласыз. Жана алардын негизинде графиктериңизди түзүңүз жана аларды мониторингиңизге кошуңуз.
Сурамдын мисалдары:
Бул биздин корпоративдик репозиторийим жана меники. Алар мисал сурамдарды камтыйт. Ал жердеги сериялардан* эч кандай суроо жок. Чийки сандарды окула турган, ыңгайлуу маанилерге, б.а. бул байт, убакытка айлантууга мүмкүндүк берүүчү кызыктуу функцияларды колдонуу менен кошулган даяр сурамдар бар. Сиз аларды тандап, карап, анализдеп, мониторингиңизге кошуп, алардын негизинде мониторингиңизди кура аласыз.
суроолор
Суроо: Сиз бренддерди жарнамалабайм деп айттыңыз, бирок мен дагы эле кызыкмын - долбоорлоруңузда кандай панелдерди колдоносуз?
Жооп: Бул ар кандай. Биз кардарга келип, анын өзүнүн мониторинги бар. Жана биз кардарга алардын мониторингине эмнелерди кошуу керектиги боюнча кеңеш беребиз. Эң начар абал Zabbix менен. Анткени анын TopN графиктерин түзүүгө мүмкүнчүлүгү жок. Өзүбүз колдонобуз , анткени биз мониторинг боюнча бул балдар менен кеңешип жатканбыз. Алар биздин техникалык мүнөздөмөлөрдүн негизинде PostgreSQLге мониторинг жүргүзүштү. Мен Prometheus аркылуу маалыматтарды чогултуп, аны чагылдырган өзүмдүн үй-долбоорумду жазып жатам . Менин милдетим Прометейде өзүмдүн экспортеримди түзүү, анан баарын Графанада көрсөтүү.
Суроо: AWR отчетторунун аналогдору же... топтоо барбы? Ушул сыяктуу бир нерсе жөнүндө билесизби?
Жооп: Ооба, мен AWR деген эмне экенин билем, бул сонун нерсе. Азыркы учурда болжол менен төмөнкү моделди ишке ашырууга велосипед ар түрдүү бар. Кээ бир убакыт аралыгында кээ бир базалык көрсөткүчтөр ошол эле PostgreSQLге же өзүнчө сактагычка жазылат. Сиз аларды интернеттен гуглдан издесеңиз болот, алар ошол жерде. Мындай нерсени иштеп чыгуучулардын бири PostgreSQL жипиндеги sql.ru форумунда отурат. Сен аны ошол жерден кармай аласың. Ооба, андай нерселер бар, аларды колдонсо болот. Анын ичинде плюс Мен да ошол эле нерсени жасоого мүмкүндүк берген нерсени жазып жатам.
PS1 Эгерде сиз postgres_exporter колдонуп жатсаңыз, кайсы панелди колдонуп жатасыз? Алардын бир нечеси бар. Алар мурунтан эле эскирген. Балким, коомчулук жаңыланган шаблонду түзөөр?
PS2 pganalyze алынып салынды, анткени бул проприетардык SaaS сунушу, ал аткарууну көзөмөлдөөгө жана автоматташтырылган жөндөө сунуштарына багытталган.
Сурамжылоого катталган колдонуучулар гана катыша алышат. , өтүнөмүн.
Кайсы өз алдынча жайгаштырылган postgresql мониторинги (башкарма тактасы менен) сиз мыкты деп эсептейсиз?
-
30,0%Алексей Лесовскийден Zabbix + толуктоолору же zabbix 4.4 же 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 - бул проприетардык SaaS - мен аны жок кыла албайм1
-
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 колдонуучу добуш берди. 26 колдонуучу добуш берүүдөн баш тартты.
Source: www.habr.com