Пропоную ознайомитися з розшифровкою доповіді Олексій Лесовський із 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, яка дозволяє збирати статистику про роботу цих підсистем і надавати якийсь інтерфейс адміністратору або користувачу, щоб він міг переглядати цю статистику.
Ця статистика представлена у вигляді деякого набору функцій та в'юх (view). Їх можна назвати таблицями. Т. е. за допомогою звичайного psql клієнта ви можете підключитися до бази даних, зробити select до цих функцій і в'юх, і отримати вже якісь конкретні циферки про роботу підсистем PostgreSQL.
Ви можете додати ці циферки до вашої улюбленої системи моніторингу, намалювати графіки, додати функції та отримати аналітику в довгостроковій перспективі.
Але в цій доповіді я не розглядатиму поголовно всі ці функції, тому що це може зайняти цілий день. Я звертатимуся буквально до двох-трьох-чотирьох штук і розповідатиму, як вони допомагають зробити моніторинг кращим.
І якщо говорити про моніторинг бази, то що треба моніторити? Насамперед потрібно моніторити доступність, тому що база – це сервіс, який надає доступ до даних клієнтів і нам потрібно моніторити доступність, а також надає її деякі якісні та кількісні характеристики.
Також потрібно моніторити клієнтів, які підключаються до нашої бази, тому що вони можуть бути як нормальними клієнтами, так і шкідливими клієнтами, які можуть завдавати шкоди базі даних. Їх теж потрібно моніторити та відстежувати їхню діяльність.
Коли клієнти підключаються до бази даних, то очевидно, що вони починають працювати з нашими даними, тому нам потрібно моніторити і те, як клієнти працюють з даними: з якими таблицями меншою мірою з якими індексами. Т. е. нам потрібно оцінити ворклоад (workload), який створюється нашими клієнтами.
Але й ворклоад складається, звичайно, із запитів. Програми підключаються до бази, звертаються до даних за допомогою запитів, тому важливо оцінювати, які запити у нас у базі даних, відстежувати їхню адекватність, що вони не є криво написаними, що якісь опції потрібно переписати і зробити так, щоб вони працювали швидше і з кращою продуктивністю.
І якщо ми говоримо про базу даних, то база даних – це завжди фонові процеси. Фонові процеси дозволяють підтримувати продуктивність бази даних хорошому рівні, тому їх роботи вони вимагають кілька ресурсів собі. І водночас можуть перетинатися з ресурсами клієнтських запитів, тому жадібна робота фонових процесів може безпосередньо проводити продуктивність клієнтських запитів. Тому їх теж потрібно моніторити та відстежувати, що немає жодних перекосів у плані фонових процесів.
І це все щодо моніторингу бази даних залишається в системній метриці. Але з огляду на те, що у нас здебільшого вся інфраструктура їде в хмари, системні метрики окремого хоста завжди відходять на другий план. Але в базах даних вони все ще актуальні та моніторити системні метрики, звичайно, теж потрібно.
З системними метриками більш-менш добре, всі сучасні системи моніторингу вже підтримують ці метрики, але загалом якихось компонентів все-таки недостатньо і потрібно деякі речі додавати. Про них я теж торкнуся, кілька слайдів буде про них.
Перший пункт плану – доступність. Що таке доступність? Доступність у моєму розумінні – це здатність бази обслуговувати підключення, тобто база піднята, вона як сервіс приймає підключення від клієнтів. І це доступність можна оцінювати деякими характеристиками. Ці характеристики дуже зручно виносити на дашборди.
Усі знають, що таке дашборди. Це коли ти кинув один погляд на екран, на якому зведено потрібну інформацію. І ви вже можете одразу визначити – чи є проблема в базі чи ні.
Відповідно доступність бази даних та інші ключові характеристики завжди необхідно виносити на дашборди, щоб ця інформація була під рукою, була завжди поруч. Якісь додаткові деталі, які вже допомагають при розслідуванні інцидентів, при розслідуванні якихось аварійних ситуацій, їх уже потрібно виносити на вторинні дашборди, або приховувати у drilldown-лінках, які ведуть на сторонні системи моніторингу.
Приклад однієї відомої системи моніторингу. Це дуже крута система моніторингу. Вона збирає дуже багато даних, але на мій погляд, у неї дивне поняття дашбордів. Там є посилання "створити дашборд". Але коли ви створюєте дашборд, ви створюєте список, що складається з двох колонок, якийсь список графіків. І коли вам потрібно щось подивитись, ви починаєте мишкою кликати, гортати, шукати потрібний графік. І на це йде час, тобто дашбордів, як таких, немає. Є лише списки графіків.
Що потрібно додавати на ці дашборди? Можна розпочати з такої характеристики, як час відгуку. У PostgreSQL є завірюха pg_stat_statements. За замовчуванням вона відключена, але це одна з важливих системних завірюх, яку завжди необхідно включати та використовувати. Вона зберігає в собі інформацію про всі запити, які виконуються в базі даних.
Відповідно, ми можемо відштовхнутися від того, що можна взяти сумарний час виконання всіх запитів і поділити кількість запитів за допомогою вищенаведених полів. Але це така середня температура лікарні. Ми можемо відштовхнутися від інших полів – мінімальний час виконання запитів, максимальний та медіанний. І навіть можемо будувати перцентілі, у PostgreSQL є відповідні функції для цього. І ми можемо отримати якісь цифри, які характеризують час відгуку нашої бази за вже виконаними запитами, тобто. окремою цифрою, або будуємо за нею графік.
Також важливо відстежувати кількість помилок, що генеруються системою на даний момент. І для цього можна використовувати завірюху pg_stat_database. Ми орієнтуємось на поле xact_rollback. Це поле показує не тільки кількість rollback, яка відбувається в базі, але ще й враховує кількість помилок. Умовно кажучи, ми можемо виводити цю цифру в наш дашборд і дивитися скільки помилок у нас в даний момент. Якщо помилок багато, то це вже добрий привід заглянути в логі і подивитися, що ж це за помилки і чому вони відбуваються, а далі інвестувати і вирішувати їх.
Можна додати таку штуку як Тахометр. Це кількість транзакцій за секунду та кількість запитів за секунду. Умовно кажучи, ви можете використовувати ці цифри як поточну продуктивність вашої бази даних і спостерігати чи є піки запитів, піки транзакцій або, навпаки, база недовантажена, тому що якийсь backend відвалився. Цю цифру важливо завжди дивитися і пам'ятати, що для нашого проекту ось така продуктивність є нормальною, а значення вищі і нижчі вже якісь проблемні та незрозумілі, а отже, треба дивитися, чому такі цифри.
Для того, щоб оцінювати кількість транзакцій, ми знову можемо звернутися до в'юхи 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 є те, що PostgreSQL дуже боляче від довгих транзакцій. Особливо від транзакцій, які довго висять і нічого не роблять. Це так звані stat idle-in-transaction. Така транзакція утримує блокування, вона заважає працювати вакууму. І як наслідок – таблиці пухнуть, вони збільшуються у розмірі. І запити, які працюють із цими таблицями, вони починають працювати повільніше, тому що потрібно лопатити всі старі версії рядків із пам'яті на диск і назад. Тому час, тривалість найдовших транзакцій, найдовших запитів вакууму також потрібно моніторити. І якщо ми бачимо якісь процеси, які працюють дуже довго, вже більше 10-20-30 хвилин для OLTP-навантаження, то на них потрібно вже звертати увагу і завершувати примусово, або оптимізувати додаток, щоб вони не викликалися і не висіли. так довго. Для аналітичного навантаження 10-20-30 хвилин – це нормально, там буває ще й довші.
Далі у нас варіант із підключеними клієнтами. Коли ми вже сформували дашборд, вивісили на нього ключові метрики доступності, ми можемо додати туди і додаткову інформацію про підключених клієнтів.
Інформація про підключених клієнтів є важливою, тому що, з точки зору PostgreSQL, клієнти бувають різними. Бувають добрі клієнти, бувають погані клієнти.
Простий приклад. Під клієнтом я розумію додаток. Додаток підключився до бази даних і починає відразу надсилати туди свої запити, база даних їх обробляє та виконує, результати повертає клієнту. Це хороші та правильні клієнти.
Бувають ситуації, що клієнт підключився, він утримує коннект, але нічого не робить. Він знаходиться у стані idle.
Але бувають погані клієнти. Наприклад, той же клієнт підключився, відкрив транзакцію, щось зробив у базі і потім пішов у код, припустимо, щоб звернутися до зовнішнього джерела або для того, щоб зробити там обробку отриманих даних. Але при цьому він не закрив транзакцію. І транзакція висить у базі та утримує у блокування на рядку. Це поганий стан. І якщо раптом додаток десь усередині впаде по ексепшену (Exception), то транзакція може залишитися відкритою на дуже довгий час. І це безпосередньо впливає на продуктивність PostgreSQL. PostgreSQL працюватиме повільніше. Тому таких клієнтів важливо вчасно відстежувати та завершувати їхню роботу примусово. І потрібно оптимізувати свою програму, щоб не було таких ситуацій.
Іншими поганими клієнтами є клієнти, що очікують. Але вони стають поганими через обставини. Наприклад, проста транзакція, що простоює: може відкрити транзакцію, взяти блокування на якісь рядки, потім десь у коді вона впаде, залишиться транзакція, що висить. Прийде інший клієнт, запросить ті самі дані, але він зіткнеться з блокуванням, тому що та транзакція, що висить, вже утримує блокування на якісь потрібні рядки. І друга транзакція висітиме в очікуванні, коли перша транзакція завершиться або її адміністратор примусово закриє. Таким чином, очікувані транзакції можуть накопичуватися і переповнювати ліміт підключень до бази даних. І коли ліміт переповнений, то програма вже не може працювати з базою. Це вже аварійна ситуація для проекту. Тому поганих клієнтів слід відстежувати та своєчасно на них реагувати.
Інший приклад моніторингу. І тут уже пристойний дашборд. Є інформація щодо коннектів зверху. DB connection – 8 штук. І це все. У нас немає інформації про те, які активні клієнти, які клієнти просто idle, нічого не роблять. Немає інформації про транзакції, що висять, і про очікувані коннекти, тобто це така цифра, яка показує кількість коннектів і все. А далі гадайте самі.
Відповідно, щоб додати цю інформацію до моніторингу, потрібно звернутися до системної в'юхи pg_stat_activity. Якщо ви багато часу проводите в PostgreSQL, то це дуже хороша завірюха, яка має стати вашим другом, тому що вона показує поточну активність у PostgreSQL, тобто, що відбувається в ньому. На кожен процес є окремий рядок, який показує інформацію щодо цього процесу: з якого хоста виконано підключення, під яким користувачем, під яким ім'ям, коли запущена транзакція, який зараз виконується запит, який запит виконувався останнім. І, відповідно, стан клієнта ми можемо оцінювати stat. Умовно кажучи, ми можемо зробити угруповання цим полем і отримати ті stats-и, які є зараз у базі даних і кількість коннектів, які з цим stat-ом у базі даних. І вже отримані цифри ми можемо надсилати до нашого моніторингу та малювати за ними графіки.
Також важливо оцінювати тривалість транзакції. Я вже казав, що важливо оцінювати тривалість вакуумів, але й транзакції оцінюються так само. Є поля xact_start та query_start. Вони, умовно кажучи, показують час старту транзакції та час старту запиту. Ми беремо функцію now(), яка показує поточну позначку часу та віднімаємо timestamp транзакції та запиту. І отримуємо тривалість транзакції, тривалість запиту.
Якщо ми бачимо довгі транзакції, ми маємо їх уже завершувати. Для OLTP-навантаження довгі транзакції – це вже більше 1-2-3 хвилин. Для OLAP-навантаження довгі транзакції є нормальними, але якщо вони виконуються більше двох годин, це теж ознака того, що десь у нас є перекіс.
Коли клієнти підключилися до бази даних, вони починають працювати з нашими даними. Вони звертаються до таблиць, вони звертаються до індексів, щоб отримати дані з таблиці. І важливо оцінювати те, як клієнти працюють із цими даними.
Це потрібно для того, щоб оцінювати наш ворклоад і приблизно розуміти, які таблиці у нас найгарячіші. Наприклад, це потрібно в ситуаціях, коли ми хочемо гарячі таблиці помістити на якесь швидке SSD сховище. Наприклад, якісь архівні таблиці, які ми вже давно не використовуємо, можна винести на якийсь «холодний» архів, на SATA диски і нехай вони там живуть, до них звернення йтиме за потребою.
Також це корисно для виявлення аномалій після будь-яких релізів та деплоїв. Припустимо, проект викотив якусь нову фічу. Наприклад, додали нову функціональність до роботи з базою. І якщо ми збудуємо графіки використання таблиць, ми на цих графіках зможемо легко виявити ці аномалії. Наприклад, сплески update або сплески delete. Це буде добре видно.
Також можна виявити аномалії статистики, що «попливла». Що це означає? У PostgreSQL дуже сильний та дуже хороший планувальник запитів. І розробники багато часу приділяють його розвитку. Як він працює? Для того, щоб будувати хороші плани, PostgreSQL з деяким інтервалом часу з деякою періодичністю збирає статистику про розподіл даних у таблицях. Це найчастіші значення: кількість унікальних значень, інформація про NULL у таблиці, дуже багато інформації.
За підсумками цієї статистики планувальник будує кілька запитів, вибирає найоптимальніший і використовує цей план запиту виконання самого запиту і повернення даних.
І буває, що статистика "пливе". Ці якості, кількості змінилися якось у таблиці, але статистика у своїй не зібралася. І сформовані плани можуть виявитися не оптимальними. І якщо у нас плани виявляться неоптимальними за моніторингом, що збирається, за таблицями, ми зможемо побачити ці аномалії. Наприклад, десь якісно змінилися дані разом індексу став використовуватися послідовний прохід по таблиці, тобто. якщо запиту потрібно повернути лише 100 рядків (коштує обмеження limit 100), то цього запиту буде виконано повний перебір. І це завжди дуже погано позначається на продуктивності.
І ми зможемо побачити це у моніторингу. І вже подивитися на цей запит, виконати для нього explain, зібрати статистику, збудувати новий додатковий індекс. І вже відреагувати на цю проблему. Тож це важливо.
Інший приклад моніторингу. Я думаю, багато хто його дізнався, тому що він дуже популярний. Хто використовує у себе в проектах ? А хто використовує цей продукт разом із Prometheus? Справа в тому, що у стандартному репозиторії цього моніторингу є дашборд для роботи з PostgreSQL. Prometheus. Але тут є одна погана деталь.
Є кілька графіків. І як unity вказані байти, тобто там 5 графіків. Це Insert data, Update data, Delete data, Fetch data та Return data. Як unit вимірювання вказані байти. Але річ у тому, що статистика в PostgreSQL повертає дані у tuple (рядках). І, відповідно, ці графіки – це дуже хороший спосіб занизити ваш ворклоад у кілька разів, у десятки разів, тому що tuple – це не байт, tuple – це рядок, це багато байтів і він завжди змінної довжини. Т. е. Обчислити ворклоад в байтах за допомогою tuples - це нереальна задача або дуже складна. Тому коли ви використовуєте дашборд або вбудований моніторинг, завжди важливо розуміти, що він працює правильно і повертає вам коректно оцінені дані.
Як отримувати статистику за цими таблицями? Для цього в PostgreSQL є деяка родина в'юх. І основна завірюха – це . User_tables – це означає, що таблиці, створені від імені користувача. На противагу є системні завірюхи, які використовуються самим PostgreSQL. І є зведена таблиця Alltables, яка включає і системні, і користувацькі. Ви можете відштовхуватися від будь-якої з них, яка вам найбільше подобається.
За вищевказаними полями можна оцінювати кількість insert, update та delete. Той приклад дашборда, який я використовував, якраз використовує ці поля для оцінки характеристик ворклоаду. Тому ми також можемо відштовхуватись від них. Але варто пам'ятати, що це tuples, а не байти, тому ми не можемо взяти і зробити це байтами.
На основі цих даних ми можемо будувати так звані TopN-таблиці. Наприклад, Top-5, Top-10. І можна відстежувати ті гарячі таблиці, які утилізуються більше за інші. Наприклад, 5 "гарячих" таблиць по вставці. І за цими TopN-таблицями ми оцінюємо наш ворклоад і можемо оцінювати сплески ворклоаду після всяких релізів і апдейтів, і деплоїв.
Також важливо оцінювати розміри таблиці, тому що іноді розробники викочують нову фічу, і в нас таблиці починають пухнути у своїх великих розмірах, тому що вирішили дописати додатковий обсяг даних, але не спрогнозували, як це позначиться на розмірі бази даних. Такі випадки також бувають для нас сюрпризами.
І зараз невелике питання для вас. Яке питання, коли ви помічаєте навантаження на сервері з базою даних? Яке наступне питання у вас виникає?
Але насправді питання виникає таке. Які запити викликає навантаження? Т. е. не цікаво дивитися процеси, які викликає навантаження. Зрозуміло, якщо host з базою даних, то там запущена база даних і зрозуміло, що тільки бази даних там і буде утилізувати. Якщо ми відкриємо Top, побачимо там список процесів у PostgreSQL, які щось роблять. З Top буде незрозуміло, що вони роблять.
Відповідно, потрібно виявити ті запити, які викликають найбільше завантаження, тому що тюнінг запитів, як правило, дає більший прибуток, ніж тюнінг конфігурації PostgreSQL або операційної системи, або навіть тюнінг заліза. За моєю оцінкою – це приблизно 80-85-90%. І це робиться набагато швидше. Швидше виправити запит, ніж виправити конфігурацію, запланувати рестарт, особливо, якщо базу рестартувати не можна, або додавати залізо. Простіше десь переписати запит або додати індекс, щоб отримати найкращий результат від цього запиту.
Відповідно, потрібно моніторити запити та їх адекватність. Візьмемо інший приклад моніторингу. І тут теж начебто чудовий моніторинг. Є інформація щодо реплікації, є інформація щодо пропускної спроможності, блокувань, утилізації ресурсів. Все чудово, але немає інформації щодо запитів. Не зрозуміло, які запити виконуються у нашій базі даних, як довго вони виконуються, скільки цих запитів. Нам потрібно у моніторингу завжди мати цю інформацію.
І для отримання інформації ми можемо використовувати модуль pg_stat_statements. На його основі можна будувати різні графіки. Наприклад, можна отримувати інформацію за найчастішими запитами, тобто за тими запитами, які виконуються найчастіше. Так, після деплоїв теж дуже корисно подивитися на нього та розуміти, чи немає якогось сплеску запитів.
Можна моніторити найдовші запити, тобто ті запити, які виконуються найдовше. Вони працюють на процесорі, вони споживають введення-виведення. Ми це також можемо оцінювати по полях total_time, mean_time, blk_write_time та blk_read_time.
Ми можемо оцінювати і моніторити найважчі запити щодо використання ресурсів, ті, які читають з диска, які працюють з пам'яттю або, навпаки, створюють якесь пишуче навантаження.
Можемо оцінювати найщедріші запити. Це запити, які повертають велику кількість рядків. Наприклад, це може бути якийсь запит, де забули поставити ліміт. І він просто повертає весь вміст таблиці чи запиту за запитаними таблицями.
Можна також моніторити запити, які використовують тимчасові файли або тимчасові таблиці.
І ми залишилися фонові процеси. Фонові процеси – це насамперед чекпоїнти або їх ще називають контрольними точками, це autovacuum та реплікація.
Інший приклад моніторингу. Є ліворуч вкладка Maintenance, переходимо на неї і сподіваємося побачити щось корисне. Але тут лише час роботи вакууму та збору статистики, більше нічого. Це дуже бідна інформація, тому завжди потрібно мати інформацію про те, як працюють фонові процеси у нас у базі даних і чи немає проблем від їхньої роботи.
Коли ми розглядаємо контрольні точки, слід пам'ятати, що контрольні точки у нас скидають «брудні» сторінки з області шардированной пам'яті на диск, потім створюють контрольну точку. І ця контрольна точка вже далі може використовуватися як місце при відновленні, якщо раптом PostgreSQL був завершений в аварійному порядку.
Відповідно, щоб скинути всі «брудні» сторінки на диск, потрібно зробити певний обсяг запису. І, як правило, на системах з великим обсягом пам'яті це дуже багато. І якщо у нас чекпоїнти робляться дуже часто в якийсь короткий інтервал, то дискова продуктивність дуже просідатиме. І клієнтські запити страждатимуть від нестачі ресурсів. Вони боротимуться за ресурси і їм не вистачатиме продуктивності.
Відповідно, через pg_stat_bgwriter за вказаними полями ми можемо моніторити кількість чекпоінтів, що трапляються. І якщо у нас за якийсь проміжок часу (за 10-15-20 хвилин, за півгодини) дуже багато чекпоінтів, наприклад, 3-4-5, то це може бути проблемою. І вже потрібно подивитися в базі даних, подивитися в конфігурації, що викликає таку різноманітність чекпоінтів. Можливо, якийсь великий запис іде. По ворклоаді можемо вже оцінити, тому що у нас графіки ворклоаду вже додані. Ми можемо підтюнити параметри контрольних точок і зробити так, щоб вони не сильно впливали на продуктивність запитів.
Я знову повертаюся до autovacuum, тому що це така штука, як я вже казав, яка запросто може скласти продуктивність як дисків, так і запитів, тому завжди важливо оцінювати кількість autovacuum.
Кількість воркерів autovacuum у базі даних обмежена. За замовчуванням їх три, тому якщо у нас весь час три воркери працюють у базі, то це означає, що у нас autovacuum недоналаштований, потрібно піднімати ліміти, переглядати налаштування autovacuum і вже лізти в конфігурацію.
Важливо оцінювати які у нас працюють воркери вакууму. Або це запущений від користувача, DBA прийшов і руками запустив якийсь вакуум і це створило навантаження. У нас виникла якась проблема. Або це кількість вакуумів, які відкручують лічильник транзакцій. Для деяких версій PostgreSQL це дуже важкі вакууми. І вони можуть просто скласти продуктивність, тому що вони вичитують всю таблицю повністю, сканують всі блоки в цій таблиці.
І, звісно, тривалість вакуумів. Якщо у нас довгі вакууми, які працюють дуже довгий час, це означає, що нам знову варто звернути увагу на конфігурацію вакууму і, можливо, переглянути його налаштування. Тому що може з'явитися ситуація, коли вакуум працює над таблицею довгий час (3-4 години), але за час роботи вакууму в таблиці встигли накопичитися великий обсяг мертвих рядків. І як тільки вакуум завершиться, йому знову потрібно вакуумувати цю таблицю. І ми приходимо до ситуації – нескінченного вакууму. І в такому випадку вакуум не справляється зі своєї роботи, і таблиці починають поступово пухнути в розмірах, хоча обсяг корисних даних у ній залишається тим самим. Тому при довгих вакуумах ми завжди дивимося на конфігурацію і намагаємося оптимізувати її, але при цьому, щоб не страждали на продуктивність клієнтських запитів.
Зараз практично немає інсталяції PostgreSQL, де не було потокової реплікації. Реплікація – це процес перенесення даних із майстра на репліку.
Реплікація в PostgreSQL влаштована через транзакційний журнал. Майстер генерує журнал транзакцій. Журнал транзакції мережним з'єднанням їде на репліку, далі на репліці він відтворюється. Все просто.
Відповідно, для моніторингу лага реплікації використовується завірюха pg_stat_replication. Але з нею не все просто. У версії 10 завірюха зазнала кількох змін. По-перше, частина полів була перейменована. І частину полів було додано. У 10 версії з'явилися поля, які дозволяють оцінювати лаг реплікації в секундах. Це дуже зручно. До версії 10 була можливість оцінювати лаг реплікації у байтах. Така можливість залишилася і в десятій версії, тобто ви можете вибирати, що вам зручніше - оцінювати лаг в байтах або оцінювати лаг в секундах. Багато хто робить і те, і інше.
Проте, щоб оцінювати лаг реплікації, потрібно знати позицію журналу в транзакції. І ці позиції журналу транзакції якраз є у завірюсі pg_stat_replication. Умовно кажучи, за допомогою функції pg_xlog_location_diff() можемо взяти дві точки в журналі транзакції. Порахувати між ними дельту та отримати лаг реплікації у байтах. Це дуже зручно та просто.
У десятій версії ця функція була перейменована на pg_wal_lsn_diff(). Взагалі, у всіх функціях, завірюхах, утилітах, де зустрічалося слово "xlog", воно було замінено на значення "wal". Це і у завірюхах, і в функціях. Це таке нововведення.
Плюс у десятій версії додалися рядки, які безпосередньо демонструють лаг. Це write lag, flush lag, replay lag. Т. е. ці штуки важливо моніторити. Якщо ми бачимо, що у нас є лаг реплікації, то треба дослідити, чому він з'явився, звідки взявся і усувати проблему.
Із системними метриками практично все гаразд. Коли зароджується будь-який моніторинг, він починає із системних метрик. Це утилізація процесорів, пам'яті, swap, мережі та диска. Проте багатьох параметрів там за замовчуванням немає.
Якщо з утилізацією процесу все гаразд, то з утилізацією диска є проблеми. Як правило, розробники моніторингів додають інформацію про пропускну спроможність. Вона може бути у iops або байтах. Але вони забувають про latency та утилізацію дискових пристроїв. Це важливіші параметри, які дозволяють оцінювати, наскільки у нас завантажені диски та наскільки вони гальмують. Якщо у нас високий latency, то це означає, що є якісь проблеми з дисками. Якщо у нас висока утилізація, це означає, що диски не справляються. Це якісніші характеристики, ніж пропускна спроможність.
При тому, що цю статистику можна отримати з файлової системи /proc, як це робиться для утилізації процесорів. Чому цю інформацію не додають до моніторингів, я не знаю. Проте важливо мати це у своєму моніторингу.
Теж саме щодо мережевих інтерфейсів. Є інформація про пропускну спроможність мережі в пакетах, в байтах, проте немає інформації про latency і немає інформації про утилізації, хоча це теж корисна інформація.
Будь-які моніторинги мають недоліки. І який моніторинг ви б не взяли, він завжди не відповідатиме якимось критеріям. Але вони розвиваються, додаються нові фічі, нові речі, тому вибирайте щось і допилюйте.
І для того щоб допилювати, потрібно завжди мати уявлення, що означає статистика, що віддається, і як за допомогою її можна вирішувати проблеми.
І кілька ключових моментів:
- Завжди потрібно моніторити доступність, мати дашборди, щоб ви могли швидко оцінити, що з базою все гаразд.
- Завжди потрібно мати уявлення про те, які клієнти працюють з вашою базою, щоб відсіювати поганих клієнтів і відстрілювати їх.
- Важливо оцінювати те, як ці клієнти працюють із даними. Потрібно мати уявлення про ваш ворклоад.
- Важливо оцінювати, як формується цей ворклоад, за допомогою якихось запитів. Ви можете оцінювати запити, ви можете оптимізувати, рефакторити, будувати для них індекси. Це дуже важливо.
- Фонові процеси можуть негативно впливати на запити клієнта, тому важливо відстежувати, щоб вони не використовують занадто багато ресурсів.
- Системні метрики дозволяють вам робити плани на масштабування, збільшення ємності ваших серверів, тому важливо також їх відстежувати і оцінювати.
Якщо вас зацікавила ця тема, ви можете пройтися за цими посиланнями.
- Це офіційна документація з колектора статистики. Там є опис усіх статистичних в'юх та опис усіх полів. Ви можете їх прочитати, зрозуміти та проаналізувати. І вже на основі них будувати свої графіки, додавати до своїх моніторингів.
Приклади запитів:
Це наш корпоративний репозиторій і мій власний. Вони є приклади запитів. Там немає запитів із серії select* from щось там. Там вже готові запити з джойнами, із застосуванням цікавих функцій, які дозволяють із сирих цифр зробити читані, зручні значення, тобто це байти, час. Ви можете їх колупати, дивитися, аналізувати, додавати до своїх моніторингів, будувати на їх основі свої моніторинги.
Питання
Питання: Ви сказали, що не рекламуватимете бренди, але мені все-таки цікаво – у своїх проектах ви якісь дашборди використовуєте?
Відповідь: По-різному. Буває, що ми приходимо до замовника і має вже свій моніторинг. І ми консультуємо замовника про те, що потрібно додати до його моніторингу. Найгірше справи з Zabbiх. Тому що він не має можливості будувати TopN-графіки. Самі ми використовуємо , тому що ми консультували цих хлопців з моніторингу. Вони робили моніторинг PostgreSQL на основі нашого ТЗ. Я пишу свій pet-project, який дані збирає через Prometheus і малює їх у . У мене завдання зробити в Prometheus свій експортер і далі вже малювати все у Grafana.
Питання: Чи є якісь аналоги AWR-звітів чи … агрегації? Відомо вам про щось таке?
Відповідь: Так, я знаю, що таке AWR, це крута штука. На даний момент є різні велосипеди, які реалізують приблизно наступну модель. З деяким інтервалом часу пишуться деякі baselines в той же PostgreSQL або в окреме сховище. Їх можна погуглити в інтернеті, вони є. Один із розробників такої штуки сидить на форумі sql.ru у гілці PostgreSQL. Його можна там упіймати. Так, такі штуки є, їх можна використати. Плюс у своєму я теж пишу штуку, яка дозволяє робити те саме.
PS1 Якщо ви використовуєте postgres_exporter, який дашборд ви використовуєте? Їх там кілька. Вони вже застарілі. Може спільнота створити оновлений шаблон?
PS2 Прибрав pganalyze, тому що є власним матеріалом SaaS, які фокусуються на ході monitoring and automated tuning suggestions.
Тільки зареєстровані користувачі можуть брати участь в опитуванні. , будь ласка.
Який 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 is a proprietary 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