Като модерна RDBMS, PostgreSQL идва с много параметри за фина настройка. Една от областите, които трябва да разгледате, е как PostgreSQL трябва да регистрира своите дейности. Регистрирането често се пренебрегва в управлението на базата данни на Postgres и ако не се игнорира, обикновено се задава погрешно. Това се случва, защото през повечето време целта на регистрирането е неясна. Разбира се, основната причина за регистрирането е добре известна, но това, което понякога липсва, е разбирането за това как ще се използват регистрационните файлове.
Изискванията за регистриране на всяка организация са уникални и следователно начина, по който трябва да се конфигурира регистрирането на PostgreSQL, също ще бъде различен. Това, което една компания за финансови услуги трябва да улови в своите регистрационни файлове на базата данни, ще бъде различно от това, което трябва да записва една компания, занимаваща се с критична здравна информация. И в някои случаи те също могат да бъдат подобни.
В тази статия ще разгледам някои основни практики, за да извлечете най-доброто от PostgreSQL регистрационните файлове. Този блог не е твърда и бърза книга с правила; читателите са повече от добре дошли да споделят своите мисли в секцията за коментари. Въпреки това, за да извлечем най-добрата стойност от него, моля читателя да помисли как иска да използва регистрационните файлове на сървъра на база данни PostgreSQL:
- Причина за спазване на законите, при която трябва да бъде заснета конкретна информация
- Одит на сигурността, където трябва да присъстват конкретни подробности за събитието
- Отстраняване на неизправности при производителността, където трябва да се записват заявките и техните параметри
- Ежедневна оперативна поддръжка, при която трябва да се наблюдава определен брой показатели.
С това казано, да започнем.
Не правете ръчни промени в postgresql.conf
Всички промени във файла postgresql.conf трябва да се правят с помощта на система за управление на конфигурацията като Puppet, Ansible или Chef. Това гарантира, че промените са проследими и могат безопасно да бъдат върнати към предишна версия, ако е необходимо. Това е вярно, когато правите промени в параметрите за регистриране.
DBA често създават множество копия на файла postgresql.conf, всяко с малко различни параметри, всяко за различна цел. Ръчното управление на различни конфигурационни файлове е тромава задача, ако не е склонна към грешки. От друга страна, може да бъде направена система за управление на конфигурацията да преименува и използва различни версии на файла postgresql.conf въз основа на прехвърлен към него параметър. Този параметър ще диктува целта на текущата версия. Когато необходимостта е завършена, старият конфигурационен файл може да бъде върнат, като промените същия входен параметър.
Например, ако искате да регистрирате всички изрази, изпълнявани на вашия PostgreSQL екземпляр, може да се използва конфигурационен файл със стойността на параметъра “log_statement=all”. Когато не е необходимо да се записват всички изявления – може би след упражнение за отстраняване на неизправности – предишният конфигурационен файл може да бъде възстановен.
Използвайте отделни регистрационни файлове за PostgreSQL
Препоръчвам да активирате собствения колектор за регистриране на PostgreSQL по време на нормални операции. За да активирате естественото регистриране на PostgreSQL, задайте следния параметър на включено:
logging_collector = onИма две причини за това:
На първо място, в натоварени системи, операционната система може да не записва последователно PostgreSQL съобщения в syslog (ако приемем инсталация, базирана на nix) и често да изпуска съобщения. С естественото регистриране на PostgreSQL отделен демон се грижи за записването на събитията. Когато PostgreSQL е зает, този процес ще отложи записването в регистрационните файлове, за да позволи на нишките на заявките да завършат. Това може да блокира цялата система, докато не бъде записано събитието в журнала. Ето защо е полезно да записвате по-малко подробни съобщения в дневника (както ще видим по-късно) и да използвате съкратени префикси на редове на дневника.
Второ – и както ще видим по-късно – регистрационните файлове трябва да се събират, анализират, индексират и анализират с помощна програма за управление на регистрационни файлове. Това, че PostgreSQL записва своите събития в syslog, ще означава създаване на допълнителен слой от филтриране и съвпадение на шаблони в частта за управление на лог, за да филтрирате всички „шумни съобщения“. Специалните регистрационни файлове могат лесно да бъдат анализирани и индексирани за събития от повечето инструменти.
Задайте цел на регистрационния файл на stderr
Нека разгледаме параметъра „log_destination“. Може да има четири стойности:
log_destination = stderr | syslog | csv | eventlog
Освен ако няма основателна причина да записвате регистрационни събития във формат, разделен със запетая, или регистър на събития в Windows, препоръчвам да зададете този параметър на stderr. Това е така, защото с дестинация на CSV файл, персонализирана стойност на параметъра „log_line_prefix“ няма да има никакъв ефект и все пак префиксът може да бъде направен така, че да съдържа ценна информация.
От друга страна обаче, CSV дневник може лесно да бъде импортиран в таблица на база данни и по-късно да бъде запитан с помощта на стандартен SQL. Някои потребители на PostgreSQL го намират за по-удобно от обработката на необработени лог файлове. Както ще видим по-късно, съвременните решения за управление на журнали могат да анализират логовете на PostgreSQL и автоматично да създават смислени прозрения от тях. При CSV отчитането и визуализацията трябва да се извършват ръчно от потребителя.
В крайна сметка всичко се свежда до вашия избор. Ако ви е удобно да създавате свой собствен тръбопровод за поглъщане на данни, за да заредите CSV регистрационните файлове в таблици на базата данни, да изчистите и трансформирате данните и да създадете персонализирани отчети, които отговарят на нуждите на вашия бизнес, тогава се уверете, че „log_destination“ е настроен на CSV.
Използвайте смислени имена на регистрационни файлове
Когато регистрационните файлове на PostgreSQL се записват локално, следването на стил на именуване може да не изглежда необходимо. Стилът на името на файла по подразбиране е „postgresql-%Y-%m-%d_%H%M%S.log“ за не-CSV форматирани регистрационни файлове, което е достатъчно за повечето случаи.
Именуването става важно, когато записвате регистрационни файлове от множество сървъри на централно място като специален лог сървър, монтиран NFS том или S3 кофа. Препоръчвам да използвате два параметъра в такъв случай:
log_directory log_filename
За да съхранявате регистрационни файлове от множество екземпляри на едно място, първо създайте отделна йерархия на директории за всеки екземпляр. Това може да бъде нещо като следното:
/<Application_Name>/<Environment_Name>/<Instance_Name>
След това „log_directory“ на всеки PostgreSQL екземпляр може да бъде насочена към определената от него папка.
След това всеки екземпляр може да използва същата стойност на параметъра „log_filename“. Стойността по подразбиране ще създаде файл като
postgresql_2020-08-25_2359.log
За да използвате по-смислено име, задайте „log_filename“ на нещо подобно:
log_filename = "postgresql_%A-%d-%B_%H%M"
След това регистрационните файлове ще бъдат наречени така:
postgresql_Saturday-23-August_2230
Използвайте значим префикс на регистрационния ред
Префиксите на регистрационния ред на PostgreSQL могат да съдържат най-ценната информация освен самото съобщение. Документацията на Postgres показва няколко escape символа за конфигурация на префикса на събитието в журнала. Тези escape последователности се заменят с различни стойности на състоянието по време на изпълнение. Някои приложения като pgBadger очакват специфичен префикс на регистрационния ред.
Препоръчвам да включите следната информация в префикса:
- Часът на събитието (без милисекунди):%t
- Име на отдалечен клиент или IP адрес:%h
- Потребителско име:%u
- Достъп до базата данни:%d
- Име на приложението:%a
- Идентификатор на процеса:%p
- Прекратяване на изхода на несесийния процес:%q
- Номерът на регистрационния ред за всяка сесия или процес, започващ от 1:%l
За да разберем какво представлява всяко поле в префикса, можем да добавим малък литерален низ преди полето. И така, стойността на ID на процеса може да бъде предшествана от литерала „PID=“, името на базата данни може да бъде с префикс „db=“ и т.н. Ето един пример:
log_line_prefix = 'time=%t, pid=%p %q db=%d, usr=%u, client=%h , app=%a, line=%l '
В зависимост от това откъде идва събитието, префиксът на регистрационния ред ще показва различни стойности. Както фоновите процеси, така и потребителските процеси ще записват своите съобщения в регистрационния файл. За системни процеси съм посочил %q, който ще потиска всеки текст след идентификатора на процеса (%p). Всяка друга сесия ще покаже името на базата данни, потребителското име, клиентския адрес, името на приложението и номериран ред за всяко събитие.
Освен това включих едно пространство след префикса на реда на дневника. Това пространство разделя префикса на събитието в журнала от действителното съобщение за събитие. Не е задължително да е символ за интервал – може да се използва нещо като двойно двоеточие (::), тире (-) или друг смислен разделител.
Също така задайте параметъра „log_hostname“ на 1:
log_hostname = 1
Без това ще се показва само IP адресът на клиента. В производствените системи това обикновено ще бъде адресът на прокси сървъра, балансира на натоварването или пула на връзки. Освен ако не знаете IP адресите на тези системи наизуст, може да си струва да регистрирате имената им на хостове. Въпреки това, търсенето на DNS също ще добави допълнително време за записване на демона във файла във файла.
Друг параметър, който трябва да бъде зададен заедно с „log_line_prefix“ е „log_timezone“. Задаването на това на местната часова зона на сървъра ще гарантира, че регистрираните събития са лесни за проследяване от техния времеви печат, вместо първо да се преобразува в местно време. В кодовия фрагмент по-долу задаваме log_timzeone на австралийска източна стандартна часова зона:
log_timezone = 'Australia/Sydney'
Само регистрационни връзки
Два параметъра контролират как PostgreSQL записва клиентски връзки и прекъсвания. И двата параметъра са изключени по подразбиране. Въз основа на изискванията за сигурност на вашата организация може да искате да зададете едно от тях на 1, а другото на 0 (освен ако не използвате инструмент като pgBadger – повече за това по-късно).
log_connections = 1 log_disconnections = 0
Задаването на log_connections на 1 ще записва всички разрешени връзки, както и опит връзки. Това очевидно е добре за одит на сигурността:атака с груба сила може лесно да бъде идентифицирана от регистрационните файлове. Въпреки това, с активирана тази настройка, натоварена PostgreSQL среда с хиляди или дори стотици краткотрайни валидни връзки може да види как регистрационният файл се залива.
Независимо от това, той може също да идентифицира проблеми с приложението, които иначе може да не са очевидни. Голям брой опити за свързване от много различни валидни клиентски адреси може да означават, че екземплярът се нуждае от балансиране на натоварването или услуга за обединяване на връзки пред него. Голям брой опити за свързване от един клиентски адрес може да разкрият приложение с твърде много нишки, които се нуждаят от някакъв вид регулация.
Регистрирайте само DDL и DML операции
Има много дебати около това какво трябва да бъде записано в дневника на Postgres – т.е. каква трябва да бъде стойността на параметъра „log_statement“. Може да има три стойности:
log_statement = 'off' | 'ddl' | 'mod' | 'all'
Може да е изкушаващо да зададете това на „всички“, за да улови всеки SQL израз, изпълняван на сървъра, но това може да не винаги е добра идея в действителност.
Натоварените производствени системи изпълняват предимно оператори SELECT, понякога хиляди такива на час. Екземплярът може да работи перфектно, без проблеми с производителността. Задаването на този параметър на „всички“ в такива случаи би натоварило ненужно демона за регистриране, тъй като той трябва да запише всички тези изрази във файла.
Това, което искате да уловите обаче, е повреда на данните или промени в структурата на базата данни, които са причинили някакъв вид проблем. Нежеланите или неоторизирани промени в базата данни причиняват повече проблеми с приложението, отколкото при избора на данни; ето защо препоръчвам да зададете този параметър на „mod“. С тази настройка PostgreSQL ще записва всички промени в DDL и DML в регистрационния файл.
Ако вашият PostgreSQL екземпляр е умерено зает (десетки заявки на час), не се колебайте да зададете този параметър на „всички“. Когато отстранявате неизправности при бавно изпълняващи се SELECT заявки или търсите неоторизиран достъп до данни, можете също да зададете това на „всички“ временно. Някои приложения като pgBadger също очакват да зададете това на „всички“.
Регистрирайте „Предупредителни“ съобщения и нагоре
Ако параметърът „log_statement“ реши какъв тип изрази ще бъдат записани, следните два параметъра диктуват колко подробно ще бъде съобщението:
log_min_messages log_min_error_statement
Всяко събитие на PostgreSQL има свързано ниво на съобщение. Нивото на съобщението може да бъде всичко от подробен DEBUG до кратка PANIC. Колкото по-ниско е нивото, толкова по-подробно е съобщението. Стойността по подразбиране за параметъра “log_min_messages” е “WARNING”. Препоръчвам да го запазите на това ниво, освен ако не искате и информационните съобщения да се записват.
Параметърът “log_min_error_statement” контролира кои SQL изрази, хвърлящи грешка, ще бъдат регистрирани. Подобно на „log_min_message“, всеки SQL израз с ниво на тежест на грешка, равно или над стойността, посочена в „log_min_error_statement“, ще бъде записан. Стойността по подразбиране е „ГРЕШКА“ и препоръчвам да запазите стойността по подразбиране.
Запазете параметрите за продължителност на дневника по подразбиране
Тогава имаме следните два параметъра:
log_duration log_min_duration_statement
Параметърът „log_duration“ приема булева стойност. Когато е настроен на 1, продължителността на всеки завършен оператор ще се регистрира. Ако е зададено на 0, продължителността на изявлението няма да се регистрира. Това е стойността по подразбиране и препоръчвам да я запазите на 0, освен ако не отстранявате проблеми с производителността. Изчисляването и записването на продължителността на инструкциите кара механизма на базата данни да извършва допълнителна работа (без значение колко малка) и когато се екстраполира към стотици или хиляди заявки, спестяванията могат да бъдат значителни.
И накрая, имаме параметъра „log_min_duration_statement“. Когато този параметър е зададен (без никакви единици, той се приема като милисекунди), продължителността на който и да е израз, равна на или по-дълга от стойността на параметъра, ще бъде регистрирана. Задаването на стойността на този параметър на 0 ще записва продължителността на всички завършени оператори. Задаването на това на -1 ще деактивира регистрирането на продължителността на израза. Това е стойността по подразбиране и препоръчвам да я запазите така.
Единственият път, когато искате да зададете този параметър на 0, е когато искате да създадете базова линия за производителност за често изпълнявани заявки. Имайте предвид обаче, че ако е зададен параметърът „log_statement“, отчетите, които се записват, няма да се повтарят в съобщенията в журнала, показващи продължителност. Така че ще трябва да заредите регистрационните файлове в таблица на база данни, след което да присъедините стойностите на идентификатора на процеса и сесията от префиксите на реда на регистрационния файл, за да идентифицирате свързани изрази и тяхната продължителност.
Каквито и да са средствата, след като имате базова линия за всяка често изпълнявана заявка, можете да зададете параметъра „log_min_duration_statement“ на най-високата от базовите стойности. Сега всяка заявка, която работи по-дълго от най-високата базова стойност, ще бъде кандидат за фина настройка.
Запазете многословността на съобщението за грешка по подразбиране
Параметърът “log_error_verbosity” може да има три възможни стойности:
log_error_verbosity = terse | standard | verbose
Този параметър контролира количеството информация, която PostgreSQL ще запише за всяко събитие, записано в регистрационния файл. Освен ако не извършвате отстраняване на грешки в приложение за база данни, този параметър е най-добре да запазите „по подразбиране“. Подробният режим ще бъде полезен, когато трябва да заснемете името на файла или функцията и номера на реда там, който е генерирал грешката. Задаването на това на „кратко“ ще потисне регистрирането на заявката, което също може да не е полезно.
Намерете политика за ротация на регистрационни файлове, която работи за вашата Случай на използване
Препоръчвам да създадете политика за ротация на регистрационни файлове въз основа на размера или възрастта на регистрационния файл, но не и на двете. Два конфигурационни параметъра на PostgreSQL диктуват колко стари регистрационни файлове се архивират и как се създават нови:
log_rotation_age = <number of minutes> log_rotation_size = <number of kilobytes>
Стойността по подразбиране за „log_rotration_age“ е 24 часа, а стойността по подразбиране за „log_rotation_size“ е 10 мегабайта.
В повечето случаи наличието на политика за ротация на размера не винаги гарантира, че последното регистрационно съобщение в архивирания регистрационен файл се съдържа изцяло само в този файл.
Ако „log_rotation_age“ се запази на стойността по подразбиране от 24 часа, всеки файл може лесно да бъде идентифициран и индивидуално разгледан, тъй като всеки файл ще съдържа събития за един ден. Това обаче също не гарантира, че всеки файл ще бъде самостоятелна единица от регистрационни файлове от последните 24 часа. Понякога една бавно изпълняваща се заявка може да отнеме повече от 24 часа, за да завърши; събития може да се случват, когато старият файл е затворен и новият се генерира. Това може да се случи по време на нощно групово задание, което води до записване на някои части от заявките в един файл, а останалите в друг.
Нашата препоръка е да намерите период на ротация на регистрационните файлове, който работи за вашата случай на употреба. Проверете разликата във времето между два последователни периода на най-ниска активност (например между една събота до следващата). След това можете да зададете стойността „log_rotation_age“ на тази времева разлика и през един от тези периоди да рестартирате услугата PostgreSQL. По този начин PostgreSQL ще завърти текущия лог файл, когато настъпи следващият период на затишие. Въпреки това, ако трябва да рестартирате услугата между тези периоди, ротацията на журнала отново ще бъде изкривена. След това ще трябва да повторите този процес. Но както много други неща в PostgreSQL, опитът и грешката ще диктуват най-добрата стойност. Освен това, ако използвате помощна програма за управление на регистрационни файлове, възрастта или размерът на регистрационните файлове няма да има значение, тъй като агентът на мениджъра на регистрационни файлове ще поглъща всяко събитие от файла при добавянето му.
Използвайте инструменти като pgBadger
pgBadger е мощен PostgreSQL лог анализатор, който може да създаде много полезна информация от лог файловете на Postgres. Това е инструмент с отворен код, написан на Perl с много малък отпечатък в машината, на която работи. Инструментът се стартира от командния ред и се предлага с голям брой опции. Той ще приеме един или повече регистрационни файлове като вход и може да създаде HTML отчет с подробна статистика за:
- Най-често чакащи заявки.
- Заявки, генериращи повечето временни файлове или най-големите временни файлове
- Най-бавно изпълнявани заявки
- Средна продължителност на заявката
- Най-често изпълнявани заявки
- Най-честите грешки в заявките
- Потребители и приложения, които изпълняват заявки
- Статистика на контролните точки.
- Автоматично вакуумиране и автоматичен анализ на статистическите данни.
- Статистика за заключване
- Събития за грешки (паника, фатални, грешка и предупреждение).
- Профили за връзка и сесии (по база данни, потребител, приложение)
- Профили на сесия
- Профили на заявки (типове заявки, заявки по база данни/приложение)
- I/O статистика
- и др.
Както споменах по-рано, някои от конфигурационните параметри, свързани с регистрационните файлове, трябва да бъдат активирани, за да уловят всички събития в регистрационния файл, така че pgBadger да може ефективно да анализира тези регистрационни файлове. Тъй като това може да доведе до големи регистрационни файлове с много събития, pgBadger трябва да се използва само за създаване на сравнителни показатели или за отстраняване на проблеми с производителността. След като подробните регистрационни файлове бъдат генерирани, параметрите на конфигурацията могат да бъдат променени обратно към първоначалните им стойности. За непрекъснат анализ на регистрационни файлове е най-добре да използвате специално приложение за управление на регистрационни файлове.
Ако ви е по-удобно да правите неща в командния ред и да използвате системни изгледи, бихте искали да използвате pg_stat_statements. Всъщност това трябва да бъде активирано във всяка производствена инсталация на PostgreSQL.
pg_stat_statements е разширение на PostgreSQL и с инсталация по подразбиране сега. За да го активирате, конфигурационният параметър „shared_preload_libraries“ трябва да има pg_stat_statements като една от стойностите си. След това може да се инсталира като всяко друго разширение с помощта на командата „CREATE EXTENSION“. Разширението създава изгледа pg_stat_statement, който предоставя ценна информация, свързана със заявката.
Използвайте приложение за управление на регистрационни файлове, за да получите информация
На пазара има много помощни програми за управление на журнали и повечето организации използват една или повече в наши дни. Какъвто и инструмент да има, препоръчвам да го използвате за събиране и управление на регистрационни файлове на PostgreSQL.
Има няколко причини за това:
Много по-лесно е да анализирате, анализирате и филтрирате шума от лог файловете с автоматизиран инструмент. Понякога едно събитие може да обхваща множество регистрационни файлове въз основа на продължителността на събитието и възрастта или размера на ротацията на регистрационните файлове. Наличието на мениджър на журнали прави много по-лесно представянето на тази информация като цяло.
Решенията за управление на журнали днес обикновено идват с вградена способност за анализиране на регистрационни файлове на PostgreSQL. Някои идват и с табла за управление, които могат да показват най-често срещаните показатели, извлечени от тези регистрационни файлове.
Повечето съвременни приложения за управление на регистрационни файлове също предлагат мощно търсене, филтриране, съпоставяне на шаблони, корелация на събития и функции за анализ на тенденциите с AI. Това, което не се вижда от обикновените очи, може лесно да стане очевидно от тези инструменти.
И накрая, използването на лог мениджър за съхраняване на PostgreSQL регистрационни файлове също ще означава, че събитията се запазват за потомство, дори ако оригиналните файлове са изтрити случайно или злонамерено.
Въпреки че има очевидни предимства от използването на приложение за управление на регистрационни файлове, много организации имат ограничения относно къде трупите им могат да живеят. Това е типичен случай с базирани на SaaS решения, при които регистрационните файлове често се записват извън географските граници на организацията – нещо, което може да не е в съответствие с регулаторните изисквания.
В такива случаи препоръчвам да изберете доставчик с локален център за данни – ако е възможно – или да използвате самоуправляващ се мениджър на журнали, хостван в мрежата на организацията, като например стек ELK.
Последни думи
Реговете на сървъра на PostgreSQL могат да бъдат златна мина на информация, когато са правилно конфигурирани. Номерът е да определите какво да регистрирате и колко да регистрирате, и по-важното, да тествате дали регистрационните файлове могат да предоставят правилната информация, когато е необходимо. Това ще бъде въпрос на опит и грешка, но това, което обсъдих тук днес, трябва да даде доста прилично начало. Както казах в началото, ще се радвам да чуя за вашия опит в конфигурирането на PostgreSQL регистриране за оптимални резултати.
