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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Друга характеристика на PostgreSQL е, че той страда много от дългите транзакции. Особено от транзакции, които висят дълго време и нищо не правят. Това са така наречените stat 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 дискове, и нека те да останат там, достъпът до тях ще е при необходимост.

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

Също така можем да открием аномалии в «поплъзналата» статистика. Какво означава това? В 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 на базата на нашето техническо задание. Пиша своя проект, който събира данни чрез Prometheus и ги визуализира. Grafana. Имам задача да направя свой експортер в Prometheus и след това да визуализирам всичко в Grafana.

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

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

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

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

Кой self-hosted мониторинг на 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 — не мога да го изтрия.

• 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