Основи на мониторинга на PostgreSQL. Алексей Лесовски

Предлагам да се запознаете с разшифровката на доклада на Алексей Лесовски от Data Egret "Основи на мониторинга на PostgreSQL"

В този доклад Алексей Лесовски ще разкаже за ключовите моменти от PostgreSQL статистиката, какво означават те и защо трябва да присъстват в мониторинга; за графиките, които трябва да бъдат в мониторинга, как да ги добавите и как да ги интерпретирате. Докладът ще бъде полезен на администраторите на бази данни, системните администратори и разработчиците, които се интересуват от отстраняването на проблеми с Postgres.

Казвам се Алексей Лесовски, представям компанията Data Egret.

Несколко думи за себе си. Започнах преди много време като системен администратор.

Администрирах различни Linux системи, занимавах се с много неща, свързани с Linux, т.е. виртуализация, мониторинг, работих с проксита и т.н. Но в един момент започнах да се занимавам повече с бази данни, PostgreSQL. Хареса ми много. И в определен момент започнах да отделям основната част от работното си време за PostgreSQL. Така постепенно стана PostgreSQL DBA.

През цялата си кариера винаги съм се интересувал от теми на статистиката, мониторинга, извличането на телеметрия. Когато бях системен администратор, работех много с Zabbix. Написах малък набор от скриптове, наречени zabbix-extensions. Той беше доста популярен за времето си. И там можеше да се наблюдават много важни неща, не само Linux, но и различни компоненти.

Сега се занимавам с PostgreSQL. Пиша нов инструмент, който позволява работа с PostgreSQL статистиката. Той се нарича pgCenter (статия на хабра — Postgres статистика без нерви и усилия).

Няколко основни въведения. Какви ситуации се срещат при нашите клиенти? Настъпва някаква повреда, свързана с базата данни. И когато базата данни вече е възстановена, идва ръководителят на отдела или ръководителят на разработката и казва: «Приятели, трябва да наблюдаваме базата данни, защото се случи нещо лошо и трябва да предотвратим подобни инциденти в бъдеще». И тук започва интересният процес на избор на система за мониторинг или адаптиране на съществуваща такава, за да можем да наблюдаваме нашата база данни – PostgreSQL, MySQL или други. Колегите започват да предлагат: «Чух, че съществува такава база данни. Нека да я използваме». Колегите започват да спорят помежду си. И в крайна сметка избираме някаква база данни, но мониторингът на PostgreSQL в нея е представен доста слабо и винаги трябва да доразвиваме нещо. Взимаме някакви репозитории от GitHub, клонираме ги, адаптираме скриптове, така че да ги конфигурираме. И в крайна сметка това се превръща в ръчен труд.

Затова в този доклад ще се опитам да ви предоставя знания как да избирате мониторинг не само за PostgreSQL, но и за база данни. И да ви дам знания, които ще ви позволят да подобрите вашия мониторинг, за да получите от него полза, за да можете да наблюдавате базата си данни по полезен начин и навреме да предупреждавате за бъдещи инциденти, които могат да възникнат.

И идеите, които ще бъдат в този доклад, могат директно да се адаптират към всяка база данни, независимо дали става дума за СУБД или noSQL. Затова тук не става дума само за PostgreSQL, но ще има много рецепти как да направите това в PostgreSQL. Ще има примери за заявки, примери за същности, които съществуват в PostgreSQL за мониторинг. И ако вашата СУБД има същите функции, които позволяват да се включат в мониторинга, можете да ги адаптирате, да добавите и всичко ще бъде наред.

В доклада няма да
разказвам как да доставяте и съхранявате метрики. Няма да споменавам нищо за пост-обработка на данни и предоставянето им на потребителя. Няма да говоря за уведомяването.
В хода на разказа ще показвам различни скрийншотове на съществуващи мониторинги и ще ги критикувам. Все пак, ще се постарая да не споменавам марки, за да не създавам реклама или антиреклама на тези продукти. Поради това всички съвпадения са случайни и остават на вашето въображение.

Започваме с обяснение какво е мониторинг. Мониторингът е изключително важна система, която всеки трябва да притежава. Всички го разбират. Но в същото време, мониторингът не е бизнес продукт и не оказва пряко влияние върху печалбата на компанията, затова на мониторинга винаги се отделя време по остатъчен принцип. Ако имаме време, занимаваме се с мониторинг, ако нямаме, добре, оставяме го в бэклог и някой ден ще се върнем към тези задачи.

Следователно, от нашия опит, когато се явим при клиенти, мониторингът често е недоразвит и не притежава интересни функции, които биха могли да ни помогнат да подобрим работата с базата данни. Затова мониторингът винаги трябва да бъде подобряван.

Базите данни са сложни системи, които също трябва да бъдат мониторирани, тъй като базите данни са хранилище на информация. Информацията е много важна за компанията и не може да бъде загубена по никакъв начин. Но в същото време базите данни са изключително сложни части от софтуера. Те се състоят от много компоненти. И много от тези компоненти трябва да бъдат наблюдавани.

Ако говорим конкретно за PostgreSQL, можем да си го представим като схема, която се състои от много компоненти. Тези компоненти взаимодействат помежду си. И в същото време, в PostgreSQL има т. нар. подсистема Stats Collector, която събира статистика за работата на тези подсистеми и предоставя интерфейс на администратора или потребителя, за да може да преглежда тази статистика.

Тази статистика е представена като набор от функции и вюта (view). Могат да се нарекат и таблици. Т.е. с помощта на стандартния psql клиент можете да се свържете с базата данни, да изпълните select на тези функции и вюта и да получите конкретни данни за работата на подсистемите на PostgreSQL.

Можете да добавите тези данни в любимата си система за мониторинг, да нарисувате графики, да добавите функции и да получите аналитика в дългосрочен план.

Но в този доклад няма да разглеждам всичките тези функции подробно, защото това може да отнеме цял ден. Ще се фокусирам буквално на две-три-четири неща и ще обясня как те помагат за подобряване на мониторинга.

И когато става въпрос за мониторинг на базата, какво точно трябва да следим? На първо място, трябва да следим достъпността, защото базата е услуга, която предоставя достъп до данни на клиентите и е необходимо да следим достъпността, както и определени качествени и количествени характеристики.

Също така трябва да следим клиентите, които се свързват с нашата база, тъй като те могат да бъдат както нормални клиенти, така и злонамерени, които могат да нанесат щета на базата данни. И техната дейност също трябва да бъде наблюдавана.

Когато клиентите се свързват с базата данни, очевидно е, че започват да работят с нашите данни, затова трябва да следим как клиентите работят с данните: с кои таблици, а в по-малка степен с кои индекси. Т.е. трябва да оценим натоварването (workload), което нашите клиенти генерират.

Но и натоварването се състои, разбира се, от заявки. Приложенията се свързват с базата и заявяват данни чрез заявки, затова е важно да оценим какви заявки имаме в базата данни, да проследим тяхната адекватност, да се уверим, че не са написани неправилно, и да видим дали някои опции трябва да бъдат пренаписани, за да работят по-бързо и с по-добра производителност.

И тъй като говорим за базата данни, тя винаги включва фонови процеси. Фоновите процеси позволяват поддържането на производителността на базата данни на добро ниво, така че за тяхната работа са необходими определен брой ресурси. В същото време те могат да се припокриват с ресурсите на клиентските заявки, затова агресивната работа на фоновите процеси може пряко да влияе на производителността на клиентските заявки. Следователно и тях трябва да наблюдаваме и да следим за евентуални нарушения във фоновите процеси.

И всичко това относно мониторинга на базата данни остава в системната метрика. Но като се има предвид, че в голямата си част нашата инфраструктура преминава в облаците, системните метрики на отделен хост винаги отстъпват на заден план. Но в базите данни те все пак са актуални и е необходимо да се наблюдават системните метрики.

Системните метрики в повече или по-малко са в добро състояние, всички съвременни системи за мониторинг вече поддържат тези метрики, но като цяло не са достатъчни някои компоненти и трябва да добавим определени неща. Също така ще се спра на тях, ще има няколко слайда по тях.

Първата точка от плана е наличността. Какво е наличност? За мен наличността е способността на базата да обслужва връзки, т.е. базата е активирана, тя, като услуга, приема връзки от клиенти. И тази наличност може да се оценява чрез някои характеристики. Тези характеристики е много удобно да се изнесат на таблата за управление.

Всеки знае какво е таблата за управление. Това е, когато хвърлите един поглед на екрана, на който е събрана необходимата информация. И вие вече можете веднага да установите – има ли проблем в базата или не.
Съответно, наличността на базата данни и другите ключови характеристики винаги трябва да се изнасят на таблата за управление, за да е информацията под ръка и винаги да е близо до вас. Някои допълнителни детайли, които вече помагат при разследването на инциденти, при разследването на извънредни ситуации, трябва да се изнасят на вторични табла за управление или да се скриват в линкове за drilldown, които водят към външни системи за мониторинг.

Пример за една известна система за мониторинг. Това е много страхотна система за мониторинг. Тя събира много данни, но от моя гледна точка, тя има странно разбиране за таблата за управление. Има линк "създаване на табло за управление". Но когато създавате табло за управление, вие създавате списък, състоящ се от две колони, определен списък с графики. И когато искате да видите нещо, започвате да кликате с мишката, да прелиствате, да търсите нужната графика. И за това отива време, тоест, табла за управление, както такива, няма. Има само списъци с графики.

Какво трябва да добавим в тези табла за управления? Може да започнем с характеристиката време за реакция. В PostgreSQL има изглед pg_stat_statements. По подразбиране той е деактивиран, но това е един от важните системни изгледи, които винаги трябва да активирате и използвате. Той съхранява информация за всички изпълнявани заявки, които са били извършени в базата данни.

Следователно можем да се основаем на това, че можем да вземем общото време за изпълнение на всички заявки и да го разделим на броя на заявките с помощта на приведените по-горе полета. Но това е такава средна температура по болниците. Можем да се основаем на други полета – минимално време за извършване на заявки, максимално и медианно. И дори можем да изградим перцентили, в PostgreSQL има съответни функции за това. И можем да получим някакви цифри, които характеризират времето за реакция на нашата база на базата на вече извършените заявки, т.е. не извършваме фалшива заявка ‘select 1’ и гледаме времето за реакция, а анализираме времето за отговор по вече извършените заявки и представяме или с отделна цифра, или по нея изграждаме график.

Също така е важно да следим броя на грешките, които системата генерира в момента. И за това можем да използваме изгледа pg_stat_database. Ориентираме се на полето xact_rollback. Това поле показва не само броя на rollback-ите, които се случват в базата, но също така отчита броя на грешките. Условно казано, можем да изведем това число в нашето табло за управление и да следим колко грешки имаме в момента. Ако грешките са много, това е добър повод да погледнем в логовете и да видим какви са тези грешки и защо се случват, а след това да изследваме и да ги решим.

Можем да добавим нещо като тахометър. Това е броят на транзакции в секунда и броят на заявки в секунда. Условно казано, можете да използвате тези числа като текуща производителност на вашата база данни и да наблюдавате дали има пикове на заявки, пикове на транзакции или, обратно, базата е недостигната, защото някакъв backend е паднал. Тази цифра е важно винаги да се следи и да се помни, че за нашия проект такава производителност е нормална, а стойности над и под нея вече са проблемни и неясни, и значи, е необходимо да се провери защо са такива цифри.

За да оценим броя на транзакциите, отново можем да се обърнем към изгледа pg_stat_database. Можем да съберем броя на commit и броя на rollback и да получим броя на транзакции в секунда.

Всеки разбира, че в една транзакция могат да се съберат няколко запитвания? Затова TPS и QPS са малко различни.

Броят запитвания в секунда може да бъде получен от pg_stat_statements и просто да се пресметне сумата на всички изпълнени запитвания. Ясно е, че сравняваме текущата стойност с предишната, изваждаме я, получаваме делтата, получаваме количеството.

Мога да добавя допълнителни метрики по желание, които също помагат да оценим наличността на нашата база и да проследим – имало ли е някакво време на неработоспособност.

Една от тези метрики е uptime. Но uptime в PostgreSQL е малко хитра работа. Ще обясня защо. Когато PostgreSQL стартира, започва да се отчита uptime. Но ако в някакъв момент, например през нощта, се изпълняваше някаква задача, която принудително прекрати OOM-killer, то в такъв случай PostgreSQL прекратява връзките на всички клиенти, нулира областта на шардираната памет и започва възстановяване от последната контрольна точка. И докато продължава това възстановяване от контрольната точка, базата не приема връзки, т.е. тази ситуация може да се оцени като downtime. Но в същото време броячът на uptime няма да се нулира, защото отчита времето от старта на postmaster от самия първи момент. Ето защо такива ситуации могат да бъдат пропуснати.

Също така трябва да се следи броя на работниците на вакуума. Всички знаят какво е autovacuum в PostgreSQL? Това е интересна подсистема в PostgreSQL. Написани са много статии за нея, направени са много докладки. Има много дискусии за вакуум, за това как трябва да работи. Много хора го считат за неизбежно зло. Но това е така. Това е аналог на сборщик на отпадъци, който чисти остарелите версии на редове, които не са нужни на нито една от транзакциите и освобождава място в таблиците и индекси за нови редове.

Защо трябва да се следи? Защото вакуум понякога нанася сериозни щети. Той отнема голямо количество ресурси и клиентските запитвания започват да страдат от това.

Наблюдавайте за ним, използвайки вюхата pg_stat_activity, за която ще говоря в следващия раздел. Тази вюха показва текущата активност в базата данни. Чрез тази активност можем да следим броя на вакуумите, които работят в момента. Можем да следим вакуумите и да видим, че ако надвишим лимита, това е повод да погледнем настройките на PostgreSQL и да оптимизираме работата на вакуума.

Друга особеност на PostgreSQL е, че той много страда от дълги транзакции. Особено от транзакции, които дълго време са висящи и не правят нищо. Това са така наречените статични idle-in-transaction. Тази транзакция задържа блокировки, като пречи на работата на вакуума. И в следствие на това – таблиците нарастват, увеличават размера си. И запитванията, които работят с тези таблици, започват да работят по-бавно, защото трябва да преместват всички стари версии на редовете от паметта на диска и обратно. Затова е необходимо да следим времето, дължината на най-дългите транзакции, най-дългите запитвания на вакуума. Ако видим процеси, които работят вече много дълго, от повече от 10-20-30 минути за OLTP натоварване, трябва да обърнем внимание на тях и да ги завършим принудително или да оптимизираме приложението, за да не се предполагат и да не висят толкова дълго. За аналитично натоварване 10-20-30 минути е нормално, понякога дори се явяват и по-дълги.

Следва вариантът с свързаните клиенти. Когато вече сме формирали таблото за управление, показали сме ключовите метрики за наличност, можем също да добавим допълнителна информация за свързаните клиенти.

Информацията за свързаните клиенти е важна, защото, от гледна точка на PostgreSQL, клиентите могат да бъдат различни. Има добри клиенти и лоши клиенти.

Прост пример. Под клиент разбирам приложението. Приложението се свързва с базата данни и започва веднага да изпраща своите запитвания, базата данни ги обработва и изпълнява, резултатите се връщат на клиента. Това са добри и правилни клиенти.

Има ситуации, в които клиентът се е свързал, но задържа конект, без да прави нищо. Той се намира в състояние idle.

Но понякога има лоши клиенти. Например, същият клиент се свърза, откри транзакция, направи нещо в базата и после отиде в кода, да речем, за да се свърже с външен източник или за да обработи получените данни. Но той не затвори транзакцията. И транзакцията остава отворена в базата и задържа блокировка на реда. Това е лошо състояние. И ако приложението случайно се срине по време на ексепшън (Exception), то транзакцията може да остане отворена за много дълго време. И това пряко влияе на производителността на PostgreSQL. PostgreSQL ще работи по-бавно. Затова е важно да се следят такива клиенти и да се завършва работата им принудително навреме. И е необходимо да се оптимизира приложението, за да не се случват такива ситуации.

Други лоши клиенти са клиенти в изчакване. Но те стават лоши заради обстоятелствата. Например, например проста транзакция, която оставя блокировка: може да отвори транзакция, да вземе блокировки на определени редове, а после някъде в кода тя да се срине, оставайки висяща транзакция. Друг клиент ще дойде, ще поиска същите данни, но той ще се сблъска с блокировка, защото висящата транзакция вече задържа блокировки на нужните редове. И втората транзакция ще виси в изчакване, докато първата транзакция не завърши или администраторът ѝ не я затвори принудително. По този начин, чакащите транзакции могат да се натрупват и да превишават лимита на свързванията към базата данни. И когато лимитът бъде превишен, приложението вече не може да работи с базата. Това е аварийна ситуация за проекта. Затова е необходимо да се следят лошите клиенти и да им се реагира своевременно.

Друг пример за мониторинг. И тук вече имаме приличен дашборд. Има информация за свързванията отгоре. DB connection – 8 броя. И това е всичко. Нямаме информация за активните клиенти, кои клиенти просто са неактивни и нищо не правят. Нямаме информация за висящите транзакции и за изчакващите свързвания, т.е. това е число, което показва количеството свързвания и нищо повече. А по-нататък отгатвайте сами.

Съответно, за да добавим тази информация в мониторинга, трябва да се обърнем към системната изглед pg_stat_activity. Ако прекарвате много време в PostgreSQL, това е много добър изглед, който трябва да стане ваш приятел, защото показва текущата активност в PostgreSQL, т.е. какво се случва в него. За всеки процес има отделен ред, който показва информация за този процес: от кой хост е осъществено свързването, под кое потребителско име, под кое име, кога е стартирана транзакцията, каква заявка в момента се изпълнява, каква заявка е била изпълнена последно. И, съответно, състоянието на клиента можем да оценим по полето stat. Условно казано, можем да направим групиране по това поле и да получим тези stats-ове, които в момента са в базата данни и броя на конекциите, които с този stat в базата данни. И вече получените цифри можем да изпратим в нашия мониторинг и да нарисуваме по тях графики.
Също така е важно да оценяваме продължителността на транзакцията. Аз вече казах, че е важно да се оценява продължителността на вакуумите, но и транзакциите се оценяват по същия начин. Има полета xact_start и query_start. Те, условно казано, показват времето на стартиране на транзакцията и времето на стартиране на заявката. Вземаме функцията now(), която показва текущата времева отметка, и изваждаме timestamp на транзакцията и заявката. И получаваме продължителността на транзакцията, продължителността на заявката.

Ако виждаме дълги транзакции, трябва да ги завършваме. За OLTP натоварване дългите транзакции са вече над 1-2-3 минути.. За OLAP натоварване дългите транзакции са нормални, но ако те се изпълняват повече от два часа, то това също е признак, че някъде имаме изкривяване.

Когато клиентите се свържат с базата данни, те започват да работят с нашите данни. Те се обръщат към таблиците, те се обръщат към индексите, за да получат данни от таблицата. И е важно да оценяваме как клиентите работят с тези данни.

Това е необходимо, за да оценим нашия работен товар и да имаме представа кои таблици са най-'горещи'. Например, това е нужно в ситуации, когато искаме 'горещите' таблици да поставим на бързо SSD хранилище. Например, някои архивни таблици, които отдавна не използваме, могат да бъдат изнесени на 'студен' архив, на SATA дискове, и те да си живеят там, а достъпът до тях да става по необходимост.

Също така, това е полезно за откриване на аномалии след различни релизи и деплойване. Да кажем, проектът е внедрил нова функция. Например, добавена е нова функционалност за работа с базата. И ако изградим графики за използването на таблиците, на тези графики лесно ще можем да открием аномалиите. Например, пик на обновления или пик на изтривания. Това ще се вижда много добре.

Също така можем да открием аномалии на 'поплъзналата' статистика. Какво означава това? В PostgreSQL има много мощен и добър планировчик на запитвания. И разработчиците отделят много време за неговото развитие. Как работи той? За да построи добри планове, PostgreSQL на определени интервали събира статистика за разпределението на данните в таблиците. Това са най-честите стойности: брой уникални стойности, информация за NULL в таблицата, много информация.

На базата на тази статистика, планировчикът изгражда няколко запитвания, избира най-оптималното и използва този план на запитването за изпълнението на запитването и връщането на данните.

И понякога статистиката 'плъзга'. Качеството и количеството на данните се променят в таблицата, но статистиката не е била събрана. И образуваните планове могат да се окажат неоптимални. И ако имаме неоптимални планове според събрания мониторинг, спрямо таблиците, можем да видим тези аномалии. Например, ако качествено данните са се променили и вече индексът е започнал да използва последователен проход по таблицата, т.е. ако запитването трябва да върне само 100 реда (с ограничение limit 100), то за това запитване ще се извърши пълен обход. И това винаги влияе много негативно на производителността.

И ние ще можем да видим това в мониторинга. И вече да разгледаме тази заявка, да изпълним explain за нея, да съберем статистика, да изградим нов допълнителен индекс. И вече да реагираме на този проблем. Затова е важно.

Друг пример за мониторинг. Мисля, че много от вас го познават, защото е много популярен. Кой го използва в проектите си. Prometheus? А кто использует этот продукт совместно с Prometheus? Дело в том, что в стандартном репозитории этого мониторинга есть дашборд для работы с PostgreSQL – postgres_exporter Prometheus. Но тук има един лош детайл.

Има няколко графика. И като единица са посочени байтове, т.е. там са 5 графика. Това са Insert data, Update data, Delete data, Fetch data и Return data. Като измервателна единица са посочени байтовете. Но фактът е, че статистиката в PostgreSQL връща данни в tuple (редове). И, съответно, тези графики – това е много добър начин да занижите натоварването си в няколко пъти, дори десетки, защото tuple – това не е байт, tuple – това е ред, това е много байтове и той винаги е с променлива дължина. Т.е. да изчислите натоварването в байтове с помощта на tuples – това е нереална задача или много сложна. Затова, когато използвате таблото за управление или вградения мониторинг, винаги е важно да разберете, че то работи правилно и ви предоставя коректно оценени данни.

Как да получим статистика по тези таблици? За това в PostgreSQL има няколко вьюта. И основната вьюха – това е pg_stat_user_tables. User_tables означава, че таблиците са създадени от потребителя. В противовес на това има системни вьюта, които се използват от самия PostgreSQL. И има обобщаваща таблица Alltables, която включва и системни, и потребителски. Можете да се основавате на която и да е от тях, която ви харесва най-много.

С помощта на посочените по-горе полета можете да оцените броя insert, update и delete. Примерът с таблото за управление, който използвах, точно използва тези полета за оценка на характеристиките на натоварването. Затова можем да се съсредоточим и върху тях. Но трябва да помним, че това са tuples, а не байтове, така че не можем просто да го превърнем в байтове.

На базата на тези данни можем да изградим така наречените TopN-таблици. Например, Top-5, Top-10. И можем да следим горещите таблици, които се използват повече от другите. Например, 5 „горещи“ таблици по вставка. И с тези TopN-таблици оценяваме нашето натоварване и можем да оценяваме изблиците на натоварването след различни релизи, актуализации и деплоя.

Също така е важно да оцените размерите на таблицата, тъй като понякога разработчиците пускат нова функция и нашите таблици започват да се увеличават значително, защото решават да добавят допълнителни обеми данни, без да предвидят как това ще се отрази на размера на базата данни. Подобни случаи също могат да бъдат изненада за нас.

И сега един малък въпрос за вас. Какъв въпрос възниква, когато забележите натоварване на сървъра с базата данни? Какъв е следващият въпрос, който ви хрумва?

Но всъщност въпросът е следният. Какви заявки предизвикват натоварването? Т.е. не е интересно да се наблюдават процесите, които предизвикват натоварване. Ясно е, че ако имаме хост с база данни, то там работи база данни и е очевидно, че само базата данни ще генерира натоварване. Ако отворим Top, ще видим списък с процеси в PostgreSQL, които извършват нещо. От Top не е ясно какво правят.

Съответно, необходимо е да открием тези заявки, които предизвикват най-голямо натоварване, тъй като настроенето на заявки обикновено носи повече полза, отколкото настройването на конфигурацията на PostgreSQL или операционната система, или дори хардуера. По моя преценка – това е около 80-85-90%. И това става значително по-бързо. По-лесно е да поправите заявка, отколкото да промените конфигурацията, да планирате рестарт, особено ако не можете да рестартирате базата или да добавите хардуер. По-просто е да пренапишете заявка или да добавите индекс, за да получите по-добри резултати от тази заявка.

Съответно, необходимо е да се наблюдават заявките и тяхната адекватност. Да вземем друг пример за мониторинг. И тук също изглежда, че мониторингът е прекрасен. Има информация за репликацията, има информация за пропускната способност, блокировките, утилизацията на ресурсите. Всичко е прекрасно, но няма информация за заявките. Не е ясно какви заявки се изпълняват в нашата база данни, колко време отнемат, колко от тези заявки. Винаги трябва да имаме тази информация в мониторинга.

И за получаване на тази информация можем да използваме модула pg_stat_statements. На негова основа могат да се изградят най-различни графики. Например, можем да получим информация за най-честите заявки, т.е. за онези заявки, които се изпълняват най-често. Да, след деплойме също е много полезно да го прегледаме и да разберем дали има някакъв скок в заявките.

Можем да наблюдаваме най-дългите заявки, т.е. онези заявки, които се изпълняват най-дълго. Те работят на процесора, потребяват вход-изход. Можем да оценим и това по полетата total_time, mean_time, blk_write_time и blk_read_time.

Можем да оценяваме и наблюдаваме най-натоварващите заявки що се отнася до използването на ресурси, т.е. тези, които четат от диска, работят с паметта или, обратно, създават някакво записващо натоварване.

Можем да оценяваме и най-щедрите заявки. Това са онези заявки, които връщат голямо количество редове. Например, това може да бъде заявка, в която е забравено да се зададе лимит. И тя просто връща всичкото съдържание на таблицата или заявката за исканите таблици.

И можем също така да наблюдаваме заявките, които използват временни файлове или временни таблици.

И остават фонова процеси. Фоновите процеси – това на първо място са чекпойнтовете, или както още ги наричат контрольни точки, autovacuum и репликация.

Друг пример за мониторинг. Отляво е разделът Maintenance, преминаваме на него и се надяваме да видим нещо полезно. Но тук е само времето за работа на вакуума и събиране на статистика, нищо повече. Това е много оскъдна информация, затова винаги трябва да имаме информация за това как работят фонова процеси в нашата база данни и дали има проблеми от тяхната работа.

Когато разглеждаме контрольни точки, трябва да помним, че контрольните точки изхвърлят „мръсните“ страници от областта на шардирната памет на диска, след което създават контрольна точка. И тази контрольна точка след това може да се използва като някакво място при възстановяване, ако по някаква причина PostgreSQL е бил прекратен аварийно.

Съответно, за да се освободят всички "замърсени" страници на диска, трябва да се извърши определено количество запис. И, обикновено, на системи с голям обем памет – това е много. И ако checkpoint-ите се извършват много често за кратък интервал, дисковата производителност ще страда значително. Клиентските заявки ще страдат от недостиг на ресурси. Те ще се борят за ресурси и ще им липсва производителност.

Съответно, чрез pg_stat_bgwriter по указаните полета можем да наблюдаваме броя на възникващите checkpoint-и. И ако за определен период от време (например 10-15-20 минути, половин час) имаме много checkpoint-и, например 3-4-5, това вече може да бъде проблем. И трябва да се погледне в базата данни, да се провери конфигурацията, какво предизвиква такова изобилие от checkpoint-и. Може би има някакъв голям запис. По натоварването можем да оценим, защото графиките на натоварването вече са добавени. Можем да настройваме параметрите на контрольните точки и да направим така, че те да не влияят силно на производителността на заявките.

Отново се връщам към autovacuum, защото това е нещо, както вече казах, което може да повлияе на производителността както на дисковете, така и на заявките, затова винаги е важно да оценяваме количеството на autovacuum.

Броят на работниците autovacuum в базата данни е ограничен. По подразбиране те са три, така че ако постоянно работят три работника в базата, то това означава, че autovacuum не е конфигуриран правилно, трябва да се увеличат лимитите, да се прегледат настройките на autovacuum и да се преразгледа конфигурацията.
Важно е да оценяваме кои работници на вакуума работят. Или е стартиран от потребител, 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-та версия бяха добавени редове, които конкретно показват закъснението. Това са write lag, flush lag, replay lag. Тоест, е важно да се следят тези параметри. Ако виждаме, че имаме закъснение в репликацията, трябва да проучим защо се е появило, откъде идва и да решим проблема.

Системните метрики са практически в ред. Когато започва да се създава мониторинг, той започва със системни метрики. Това е употребата на процесори, памет, swap, мрежа и диск. Въпреки това, много параметри отсъстват по подразбиране.

Ако всичко е наред с употребата на процесора, то с употребата на диска има проблеми. Обикновено разработчиците на мониторинг добавят информация за пропускната способност. Тя може да бъде в IOPS или байтове. Но те забравят за латентността и употребата на дисковите устройства. Това са по-важни параметри, които позволяват да оценим колко натоварени са дисковете и колко забавят. Ако имаме висока латентност, то това означава, че има проблеми с дисковете. Ако имаме висока употреба, то това означава, че дисковете не се справят. Това са по-качествени характеристики от пропускната способност.

Въпреки че тази статистика може също да се получи от файловата система /proc, както се прави за употребата на процесорите. Защо тази информация не се добавя в мониторингите, не знам. Но въпреки това е важно да я имате в своя мониторинг.

Същото важи и за мрежовите интерфейси. Има информация за пропускната способност на мрежата в пакети, в байтове, но все пак няма информация за латентността и няма информация за употребата, въпреки че това също е полезна информация.

Всички мониторинги имат недостатъци. И каквото и мониторинг да изберете, винаги ще бъде несъответстващо на някакви критерии. Но все пак те се развиват, добавят се нови функции, нови неща, затова изберете нещо и доразвийте.

И за да доразвивате, трябва винаги да имате представа какво означава предоставената статистика и как с нейна помощ можете да решавате проблеми.

И няколко ключови момента:

• Винаги трябва да следите за наличността, да имате табла за управление, за да можете бързо да оцените, че с базата всичко е наред.
• Винаги трябва да имате представа за това, кои клиенти работят с вашата база данни, за да можете да отсеете лошите клиенти и да ги изключите.
• Важно е да оценявате как тези клиенти работят с данните. Нужно е да имате представа за вашия работен товар.
• Важно е да оценявате как се формира този работен товар, с какви заявки. Можете да оценявате заявките, да ги оптимизирате, да ги рефакторирате, да изграждате индекси за тях. Това е много важно.
• Фоновите процеси могат да влияят негативно на клиентските заявки, затова е важно да следите, за да не използват твърде много ресурси.
• Системните метрики ви позволяват да правите планове за мащабиране, за увеличаване на капацитета на вашите сървъри, затова е важно също да ги наблюдавате и оценявате.

Ако ви интересува тази тема, можете да разгледате тези линкове.
http://bit.do/stats_collector — това е официалната документация с колектор на статистиката. Там има описание на всички статистически изгледи и описание на всички полета. Можете да ги прочетете, разберете и анализирате. И на базата на тях да изградите своите графици, да ги добавите в своите мониторинги.

Примери за заявки:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Това е корпоративният ни репозиторий и моят собствен. В тях има примери на заявки. Няма заявки от типа select* from нещо. Има готови заявки с join-ове, с интересни функции, които позволяват да се преобразуват суровите числа в четими и удобни стойности, т.е. байтове, време. Можете да ги проучвате, да ги анализирате, да ги добавяте в своите мониторинги, да изграждате свои на база тях.

Въпроси

Въпрос: Казахте, че няма да рекламирате марки, но все пак ми е интересно – какви табла за управление използвате в проектите си?
Отговор: Различно. Понякога отиваме при клиента и той вече има свой мониторинг. Консултираме клиента какво трябва да добави в мониторинга си. Най-лошо е с Zabbiх. Защото няма възможност за изграждане на TopN-графици. Ние сами използваме Okmeter, защото консултирахме тези момчета по мониторинга. Те създадоха мониторинг за PostgreSQL на базата на нашето ТЗ. Пиша своя pet-project, който събира данни чрез Prometheus и ги визуализира в Grafana. Имам задача да направя свой експортер в Prometheus и после това да визуализирам всичко в Grafana.

Въпрос: Има ли аналози на AWR отчетите или ... агрегацията? Знаете ли нещо повече за това?
Отговор: Да, знам какво е AWR, това е страхотен инструмент. В момента има най-различни решения, които реализират подобна модел. На определени интервали от време се записват определени baseline данни в същия PostgreSQL или в отделно хранилище. Можете да ги намерите в интернет, те съществуват. Един от разработчиците на такова решение е активен на форума sql.ru в темата за PostgreSQL. Можете да го намерите там. Да, такива решения съществуват и могат да се използват. Освен това и в моя pgCenter аз също пиша нещо, което позволява да се прави същото.

P.S.1 Ако използвате postgres_exporter, какъв dashboard ползвате? Има няколко. Те вече са остарели. Може би общността да създаде обновен шаблон?

P.S.2 Премахнах pganalyze, тъй като е собственост на SaaS предложение, което се фокусира върху мониторинг на производителността и автоматични предложения за настройка.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.

Кой self-hosted мониторинг на PostgreSQL (с dashboard) смятате за най-добрия?

• 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 потребители.

Източник: habr.com