Мен сізге Алексей Лесовскийдің Data Egret «PostgreSQL мониторингінің негіздері» баяндамасының транскрипциясын оқуды ұсынамын.
Бұл баяндамада Алексей Лесовский пост-гресс статистикасының негізгі тұстары, олардың нені білдіретіні және мониторингте неліктен қатысуы керектігі туралы әңгімелейді; мониторингте қандай графиктер болуы керек, оларды қалай қосу және оларды қалай түсіндіру керектігі туралы. Есеп Postgres ақауларын жоюға қызығушылық танытатын дерекқор әкімшілеріне, жүйелік әкімшілерге және әзірлеушілерге пайдалы болады.
Менің атым Алексей Лесовский, мен Data Egret компаниясының өкілімін.
Өзім туралы бірнеше сөз. Мен баяғыда жүйелік әкімші ретінде жұмыс істей бастадым.
Мен әртүрлі Linux жүйелерінің барлық түрлерін басқардым, Linux-қа қатысты әртүрлі нәрселермен жұмыс істедім, яғни виртуализация, мониторинг, прокси-серверлермен жұмыс істедім және т.б. Бірақ бір сәтте мен PostgreSQL деректер базасымен көбірек жұмыс істей бастадым. Маған ол қатты ұнады. Бір кезде мен жұмыс уақытымның көп бөлігін PostgreSQL-де жұмыс істей бастадым. Осылайша мен бірте-бірте PostgreSQL DBA болдым.
Мен өз мансабымда әрқашан статистика, мониторинг және телеметрия тақырыптарына қызығушылық таныттым. Мен жүйелік әкімші болған кезде мен Zabbix-пен өте тығыз жұмыс істедім. Мен сияқты сценарийлердің шағын жиынтығын жаздым . Ол өз уақытында өте танымал болды. Мұнда тек Linux-ты ғана емес, сонымен қатар әртүрлі құрамдас бөліктерді де бақылауға болады.
Қазір мен PostgreSQL-де жұмыс істеймін. Мен PostgreSQL статистикасымен жұмыс істеуге мүмкіндік беретін тағы бір нәрсені жазып жатырмын. деп аталады (Хабре туралы мақала - ).
Кішкене кіріспе жазба. Біздің клиенттерімізде, біздің клиенттерімізде қандай жағдайлар бар? Деректер базасына қатысты қандай да бір апат бар. Мәліметтер қоры қалпына келтіріліп болған кезде, бөлім басшысы немесе әзірлеу бөлімінің басшысы келіп: «Достар, біз дерекқорды бақылауымыз керек, өйткені келеңсіз жағдай болды және болашақта мұндай жағдайдың алдын алуымыз керек», - дейді. Міне, PostgreSQL, MySQL немесе басқа да деректер базасын бақылай алатындай етіп мониторинг жүйесін таңдау немесе бар бақылау жүйесін бейімдеудің қызықты процесі басталады. Әріптестер ұсыныс жасай бастайды: «Мен мынадай база бар деп естідім. Пайдаланайық». Әріптестер бір-бірімен дауласа бастайды. Соңында біз қандай да бір дерекқорды таңдайтынымыз белгілі болды, бірақ PostgreSQL мониторингі онда нашар ұсынылған және біз әрқашан бірдеңе қосуымыз керек. GitHub-тен кейбір репозиторийлерді алыңыз, оларды клондаңыз, сценарийлерді бейімдеңіз және қандай да бір жолмен оларды теңшеңіз. Соңында бұл қандай да бір қол жұмысына айналады.
Сондықтан, бұл баяндамада мен сізге тек PostgreSQL үшін ғана емес, сонымен қатар дерекқор үшін де мониторингті қалай таңдауға болатыны туралы біраз білім беруге тырысамын. Сізге қандай да бір пайда алу үшін бақылауды аяқтауға мүмкіндік беретін білім беріңіз, осылайша сіз өзіңіздің деректер қорыңызды тиімді түрде бақылай аласыз, мүмкін болатын кез келген төтенше жағдайлардың алдын алу үшін.
Бұл есепте болатын идеялар кез келген дерекқорға, мейлі ол ДҚБЖ немесе noSQL болсын, тікелей бейімделуі мүмкін. Сондықтан PostgreSQL ғана емес, PostgreSQL-де мұны қалай жасауға болатыны туралы көптеген рецепттер болады. PostgreSQL бақылауға арналған сұраулардың мысалдары, нысандардың мысалдары болады. Егер сіздің ДҚБЖ-да оларды бақылауға қоюға мүмкіндік беретін бірдей нәрселер болса, сіз оларды бейімдей аласыз, қосыңыз және бұл жақсы болады.
Мен баяндамада болмаймын
көрсеткіштерді жеткізу және сақтау жолы туралы сөйлесіңіз. Мен деректерді кейінгі өңдеу және оны пайдаланушыға ұсыну туралы ештеңе айтпаймын. Мен ескерту туралы ештеңе айтпаймын.
Бірақ оқиға өрбіген сайын мен бар мониторингтің әртүрлі скриншоттарын көрсетіп, қандай да бір түрде оларды сынға аламын. Бірақ соған қарамастан, мен бұл өнімдерге жарнама немесе антижарнама жасамас үшін брендтерді атамауға тырысамын. Сондықтан, барлық кездейсоқтықтар кездейсоқ және сіздің қиялыңызға қалдырылады.
Алдымен мониторинг дегеніміз не екенін анықтап алайық. Бақылау - бұл өте маңызды нәрсе. Мұны бәрі түсінеді. Бірақ сонымен бірге, мониторинг бизнес өніміне қатысты емес және компанияның кірісіне тікелей әсер етпейді, сондықтан уақыт әрқашан қалдық негізде мониторингке бөлінеді. Егер бізде уақыт болса, біз бақылау жасаймыз, егер уақыт жоқ болса, онда біз оны артта қалдырамыз және бір күні бұл тапсырмаларға қайта ораламыз.
Сондықтан, біздің тәжірибемізден, біз клиенттерге келгенде, мониторинг көбінесе толық емес және дерекқормен жақсы жұмыс істеуге көмектесетін қызықты нәрселер жоқ. Сондықтан мониторинг әрқашан аяқталуы керек.
Мәліметтер базасы - бұл сондай-ақ бақылауды қажет ететін күрделі нәрселер, өйткені мәліметтер базасы ақпараттың репозиторийі болып табылады. Ал ақпарат компания үшін өте маңызды, оны ешбір жолмен жоғалтуға болмайды. Бірақ сонымен бірге мәліметтер базасы бағдарламалық қамтамасыз етудің өте күрделі бөліктері болып табылады. Олар көптеген компоненттерден тұрады. Және бұл құрамдастардың көпшілігі бақылауды қажет етеді.
Егер біз 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 ұзақ транзакциялардан қатты ауырады. Әсіресе ұзақ уақыт бойы ілулі тұрған және ештеңе жасамайтын транзакциялардан. Бұл транзакциядағы бос уақыт деп аталады. Мұндай транзакция құлыптарды ұстайды және вакуумның жұмыс істеуіне жол бермейді. Соның салдарынан үстелдер ісініп, көлемі ұлғаяды. Және осы кестелермен жұмыс істейтін сұраулар баяу жұмыс істей бастайды, өйткені жолдардың барлық ескі нұсқаларын жадтан дискіге және кері күрекпен алу керек. Сондықтан уақытты, ең ұзақ транзакциялардың ұзақтығын, ең ұзақ вакуумдық сұрауларды да бақылау қажет. Егер біз OLTP жүктемесі үшін 10-20-30 минуттан асатын өте ұзақ уақыт бойы жұмыс істеп тұрған кейбір процестерді көретін болсақ, онда біз оларға назар аударуымыз керек және оларды күшпен тоқтатуымыз керек немесе қолданбаны оңтайландыруымыз керек. шақырылмайды және ұзақ уақыт ілінбеңіз. Аналитикалық жұмыс жүктемесі үшін 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 файлдық жүйесінен алуға болады. Неліктен бұл ақпарат мониторингке қосылмағанын білмеймін. Дегенмен, бұл сіздің мониторингіңізде болуы маңызды.
Бұл желі интерфейстеріне де қатысты. Желінің өткізу қабілеті туралы пакеттерде, байттарда бар, бірақ соған қарамастан кідіріс және пайдалану туралы ақпарат жоқ, бірақ бұл да пайдалы ақпарат.
Кез келген бақылаудың кемшіліктері бар. Ал сіз қандай мониторинг жүргізсеңіз де, ол әрқашан кейбір критерийлерге сәйкес келмейді. Бірақ соған қарамастан олар дамып жатыр, жаңа мүмкіндіктер мен жаңа нәрселер қосылып жатыр, сондықтан бір нәрсені таңдап, оны аяқтаңыз.
Аяқтау үшін сіз әрқашан берілген статистиканың нені білдіретіні және оларды мәселелерді шешу үшін қалай пайдалануға болатыны туралы түсінікке ие болуыңыз керек.
Және бірнеше негізгі тармақтар:
- Дерекқорға барлығы сәйкес келетінін жылдам бағалау үшін қол жетімділікті үнемі бақылап отыруыңыз керек және бақылау тақталары болуы керек.
- Нашар клиенттерді жою және оларды жою үшін сізде әрқашан деректер базасымен қандай клиенттер жұмыс істейтіні туралы түсінік болуы керек.
- Бұл клиенттердің деректермен қалай жұмыс істейтінін бағалау маңызды. Сіздің жұмыс жүктемеңіз туралы түсінік болуы керек.
- Бұл жұмыс жүктемесінің қалай қалыптасатынын, қандай сұраулардың көмегімен бағалау маңызды. Сұрауларды бағалай аласыз, оларды оңтайландыра аласыз, қайта өңдей аласыз, олар үшін индекстер жасай аласыз. Бұл өте маңызды.
- Фондық процестер клиент сұрауларына теріс әсер етуі мүмкін, сондықтан олардың тым көп ресурстарды пайдаланбағанын бақылау маңызды.
- Жүйелік көрсеткіштер серверлердің көлемін ұлғайту және кеңейту жоспарларын жасауға мүмкіндік береді, сондықтан оларды бақылау және бағалау да маңызды.
Егер сіз осы тақырыпқа қызығушылық танытсаңыз, онда сіз мына сілтемелерді пайдалана аласыз.
- бұл статистика жинаушының ресми құжаты. Барлық статистикалық көріністердің сипаттамасы және барлық өрістердің сипаттамасы бар. Оларды оқып, түсінуге және талдауға болады. Олардың негізінде графиктеріңізді құрыңыз және оларды бақылауға қосыңыз.
Сұраныс мысалдары:
Бұл біздің корпоративтік репозиторийіміз және менің өзімдікі. Олар мысал сұрауларын қамтиды. Сериялардан* таңдаудан сұраулар жоқ. Шикі сандарды оқылатын, ыңғайлы мәндерге айналдыруға мүмкіндік беретін қызықты функцияларды қолданатын біріктірулері бар дайын сұраулар бар, яғни бұл байт, уақыт. Сіз оларды таңдай аласыз, қарай аласыз, талдай аласыз, оларды мониторингіңізге қоса аласыз, олардың негізінде мониторингіңізді жасай аласыз.
Сіздің сұрақтарыңыз
Сұрақ: Сіз брендтерді жарнамаламайтыныңызды айттыңыз, бірақ мені әлі де қызықтырады - жобаларыңызда қандай бақылау тақталарын қолданасыз?
Жауап: Әртүрлі. Біз тұтынушыға келеміз және оның жеке бақылауы бар. Біз тұтынушыға олардың мониторингіне не қосу керектігі туралы кеңес береміз. Ең нашар жағдай Заббикспен байланысты. Өйткені оның TopN графиктерін құру мүмкіндігі жоқ. Өзіміз қолданамыз , өйткені біз мониторинг бойынша осы жігіттермен кеңесіп жүрдік. Олар біздің техникалық сипаттамаларымызға негізделген PostgreSQL-ті бақылаған. Мен Прометей арқылы деректерді жинап, оны бейнелейтін өзімнің жеке жобамды жазып жатырмын . Менің міндетім - Prometheus-те өзімнің экспорттаушымды жасау, содан кейін барлығын Grafana-да көрсету.
Сұрақ: 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 пайдаланушы қалыс қалды.
Ақпарат көзі: www.habr.com