Ubuntu где логи postgresql
Если в log_destination включено значение csvlog , то протоколирование ведётся в формате CSV (разделённые запятыми значения). Это удобно для программной обработки журнала. Подробнее об этом в Подразделе 19.8.4. Для вывода в формате CSV должен быть включён logging_collector.
Примечание
Примечание
Примечание
При включённом logging_collector , определяет каталог, в котором создаются журнальные файлы. Можно задавать как абсолютный путь, так и относительный от каталога данных кластера. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. Значение по умолчанию pg_log . log_filename ( string )
При включённом logging_collector задаёт имена журнальных файлов. Значение трактуется как строка формата в функции strftime , поэтому в ней можно использовать спецификаторы % для включения в имена файлов информации о дате и времени. (При наличии зависящих от часового пояса спецификаторов % будет использован пояс, заданный в log_timezone.) Поддерживаемые спецификаторы % похожи на те, что перечислены в описании strftime спецификации Open Group. Обратите внимание, что системная функция strftime напрямую не используется. Поэтому нестандартные, специфичные для платформы особенности не будут работать. Значение по умолчанию postgresql-%Y-%m-%d_%H%M%S.log .
Если для задания имени файлов не используются спецификаторы % , то для избежания переполнения диска, следует использовать утилиты для ротации журнальных файлов. В версиях до 8.4, при отсутствии спецификаторов % , PostgreSQL автоматически добавлял время в формате Epoch к имени файла. Сейчас в этом больше нет необходимости.
Если в log_destination включён вывод в формате CSV, то к имени журнального файла будет добавлено расширение .csv . (Если log_filename заканчивается на .log , то это расширение заменится на .csv .)
Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_file_mode ( integer )
В системах Unix задаёт права доступа к журнальным файлам, при включённом logging_collector . (В Windows этот параметр игнорируется.) Значение параметра должно быть числовым, в формате команд chmod и umask . (Для восьмеричного формата, требуется задать лидирующий 0 (ноль).)
Права доступа по умолчанию 0600 , т. е. только владелец сервера может читать и писать в журнальные файлы. Также, может быть полезным значение 0640 , разрешающее чтение файлов членам группы. Однако чтобы установить такое значение, нужно каталог для хранения журнальных файлов (log_directory) вынести за пределы каталога данных кластера. В любом случае нежелательно открывать для всех доступ на чтение журнальных файлов, так как они могут содержать конфиденциальные данные.
Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_rotation_age ( integer )
Определяет максимальное время жизни отдельного журнального файла, при включённом logging_collector . После того как прошло заданное количество минут, создаётся новый журнальный файл. Для запрета создания нового файла по прошествии определённого времени, нужно установить значение 0. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. log_rotation_size ( integer )
Определяет максимальный размер отдельного журнального файла, при включённом logging_collector . После того как заданное количество килобайт записано в текущий файл, создаётся новый журнальный файл. Для запрета создания нового файла при превышении определённого размера, нужно установить значение 0. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_truncate_on_rotation ( boolean )
Если параметр logging_collector включён, PostgreSQL будет перезаписывать существующие журнальные файлы, а не дописывать в них. Однако перезапись при переключении на новый файл возможна только в результате ротации по времени, но не при старте сервера или ротации по размеру файла. При выключенном параметре всегда продолжается запись в существующий файл. Например, включение этого параметра в комбинации с log_filename равным postgresql-%H.log , приведёт к генерации 24-х часовых журнальных файлов, которые циклически перезаписываются. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.
Пример: для хранения журнальных файлов в течение 7 дней, по одному файлу на каждый день с именами вида server_log.Mon , server_log.Tue и т. д., а также с автоматической перезаписью файлов прошлой недели, нужно установить log_filename в server_log.%a , log_truncate_on_rotation в on и log_rotation_age в 1440 .
Пример: для хранения журнальных файлов в течение 24 часов, по одному файлу на час, с дополнительной возможностью переключения файла при превышения 1ГБ, установите log_filename в server_log.%H%M , log_truncate_on_rotation в on , log_rotation_age в 60 и log_rotation_size в 1000000 . Добавление %M в log_filename позволит при переключении по размеру указать другое имя файла в пределах одного часа. syslog_facility ( enum )
При включённом протоколировании в syslog , этот параметр определяет значение « facility » . Допустимые значения LOCAL0 , LOCAL1 , LOCAL2 , LOCAL3 , LOCAL4 , LOCAL5 , LOCAL6 , LOCAL7 . По умолчанию используется LOCAL0 . Подробнее в документации на системный демон syslog . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. syslog_ident ( string )
Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. syslog_split_messages ( boolean )
Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. event_source ( string )
19.8.2. Когда протоколировать
Записывает в журнал продолжительность выполнения всех команд, время работы которых равно или превышает указанное количество миллисекунд. Значение 0 (ноль) заставляет записывать продолжительность работы всех команд. Значение -1 (по умолчанию) запрещает регистрировать продолжительность выполнения операторов. Например, при значении 250ms , все команды, которые выполняются за 250 миллисекунд и дольше будут записаны в журнал сервера. Включение параметра полезно для выявления плохо оптимизированных запросов в приложении. Только суперпользователи могут изменить этот параметр.
Для клиентов, использующих расширенный протокол запросов, будет записываться продолжительность фаз: разбор, связывание и выполнение.
Примечание
19.8.3. Что протоколировать
application_name это любая строка, не превышающая NAMEDATALEN символов (64 символа при стандартной сборке). Обычно устанавливается приложением при подключении к серверу. Значение отображается в представлении pg_stat_activity и добавляется в журнал сервера, при использовании формата CSV. Для прочих форматов, application_name можно добавить в журнал через параметр log_line_prefix. Значение application_name может содержать только печатные ASCII символы. Остальные символы будут заменены знаками вопроса ( ? ). debug_print_parse ( boolean )
debug_print_rewritten ( boolean )
debug_print_plan ( boolean )
Включает протоколирование выполнения контрольных точек и точек перезапуска сервера. При этом записывается некоторая статистическая информация. Например, число записанных буферов и время, затраченное на их запись. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. По умолчанию выключен. log_connections ( boolean )
Включает протоколирование всех попыток подключения к серверу, в том числе успешного завершения аутентификации клиентов. Изменить его можно только в начале сеанса и сделать это могут только суперпользователи. Значение по умолчанию — off .
Примечание
Включает протоколирование завершения сеанса. В журнал выводится примерно та же информация, что и с log_connections , плюс длительность сеанса. Изменить этот параметр можно только в начале сеанса и сделать это могут только суперпользователи. Значение по умолчанию — off . log_duration ( boolean )
Записывает продолжительность каждой завершённой команды. По умолчанию выключен. Только суперпользователи могут изменить этот параметр.
Для клиентов, использующих расширенный протокол запросов, будет записываться продолжительность фаз: разбор, связывание и выполнение.
Примечание
Включение этого параметра не равнозначно установке нулевого значения для log_min_duration_statement. Разница в том, что при превышении значения log_min_duration_statement в журнал записывается текст запроса, а при включении данного параметра — нет. Таким образом при log_duration = on и положительном значении log_min_duration_statement в журнал записывается длительность всех команд, а текст запросов — только для команд с длительностью, превысившей предел. Такое поведение может оказаться полезным при сборе статистики в условиях большой нагрузки.
| Спецсимвол | Назначение | Только для пользовательского процесса |
|---|---|---|
| %a | Имя приложения (application_name) | да |
| %u | Имя пользователя | да |
| %d | Имя базы данных | да |
| %r | Имя удалённого узла или IP-адрес, а также номер порта | да |
| %h | Имя удалённого узла или IP-адрес | да |
| %p | Идентификатор процесса | нет |
| %t | Штамп времени, без миллисекунд | нет |
| %m | Штамп времени, с миллисекундами | нет |
| %n | Штамп времени, с миллисекундами (в виде времени Unix) | нет |
| %i | Тег команды: тип текущей команды в сессии | да |
| %e | Код ошибки SQLSTATE | нет |
| %c | Идентификатор сессии. Подробности ниже | нет |
| %l | Номер строки журнала для каждой сессии или процесса. Начинается с 1 | нет |
| %s | Штамп времени начала процесса | нет |
| %v | Идентификатор виртуальной транзакции (backendID/localXID) | нет |
| %x | Идентификатор транзакции (0 если не присвоен) | нет |
| %q | Ничего не выводит. Непользовательские процессы останавливаются в этой точке. Игнорируется пользовательскими процессами | нет |
| %% | Выводит % | нет |
%c выводит псевдоуникальный номер сессии, состоящий из двух 4-х битных шестнадцатеричных чисел (без лидирующих нулей), разделённых точкой. Эти числа представляют собой время старта процесса и идентификатор процесса, поэтому %c можно использовать для экономии места при записи этих значений. Например, для получения идентификатора сессии из pg_stat_activity , используйте запрос:
Подсказка
Последним символом в log_line_prefix лучше оставлять пробел, чтобы отделить от остальной строки. Можно использовать и символы пунктуации.
Подсказка
Syslog также формирует штамп времени и идентификатор процесса, поэтому вероятно нет смысла использовать соответствующие управляющие последовательности при использовании syslog .
Определяет, нужно ли фиксировать в журнале события, когда сеанс ожидает получения блокировки дольше, чем указано в deadlock_timeout. Это позволяет выяснить, не связана ли низкая производительность с ожиданием блокировок. По умолчанию отключено. Только суперпользователи могут изменить этот параметр. log_statement ( enum )
Управляет тем, какие SQL-команды записывать в журнал. Допустимые значения: none (отключено), ddl , mod и all (все команды). ddl записывает все команды определения данных, такие как CREATE , ALTER , DROP . mod записывает все команды ddl , а также команды изменяющие данные, такие как INSERT , UPDATE , DELETE , TRUNCATE и COPY FROM . PREPARE , EXECUTE и EXPLAIN ANALYZE также записываются, если вызваны для команды соответствующего типа. Если клиент использует расширенный протокол запросов, то запись происходит на фазе выполнения и содержит значения всех связанных переменных (если есть символы одиночных кавычек, то они дублируются).
По умолчанию none . Только суперпользователи могут изменить этот параметр.
Примечание
Включает запись в журнал сервера всех команд репликации. Подробнее о командах репликации можно узнать в Разделе 51.3. Значение по умолчанию — off . Изменить этот параметр могут только суперпользователи. log_temp_files ( integer )
Устанавливает часовой пояс для штампов времени при записи в журнал сервера. В отличие от TimeZone, это значение одинаково для всех баз данных кластера, поэтому для всех сессий используются согласованные значения штампов времени. Встроенное значение по умолчанию GMT , но оно переопределяется в postgresql.conf : initdb записывает в него значение, соответствующее системной среде. Подробнее об этом в Подразделе 8.5.3. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.
19.8.4. Использование вывода журнала в формате CSV
Для загрузки журнального файла в такую таблицу можно использовать команду COPY FROM :
Также можно обратиться к этому файлу как к сторонней таблице, используя поставляемый модуль file_fdw.
Для упрощения загрузки журналов в CSV формате используйте следующее:
Установите для log_filename и log_rotation_age значения, гарантирующие согласованную и предсказуемую схему именования журнальных файлов. Зная, какие имена будут у журнальных файлов, можно определить, когда конкретный файл заполнен и готов к загрузке.
Установите log_rotation_size в 0, чтобы запретить ротацию файлов по достижении определённого размера, так как это делает непредсказуемой схему именования журнальных файлов.
19.8.5. Заголовок процесса
Эти параметры влияют на то, как формируются заголовки серверных процессов. Заголовок процесса обычно можно наблюдать в программах типа ps , а в Windows — в Process Explorer . За подробностями обратитесь к Разделу 28.1.
Задаёт имя кластера, которое отображается в заголовке процесса для всех серверных процессов данного кластера. Это имя может быть любой строкой не длиннее NAMEDATALEN символов (64 символа в стандартной сборке). В строке cluster_name могут использоваться только печатаемые ASCII-символы. Любой другой символ будет заменён символом вопроса ( ? ). Если этот параметр содержит пустую строку '' (это значение по умолчанию), никакое имя не выводится. Этот параметр можно задать только при запуске сервера. update_process_title ( boolean )
Включает изменение заголовка процесса при получении сервером каждой очередной команды SQL. На большинстве платформ он включён (имеет значение on ), но в Windows по умолчанию выключен ( off ) ввиду больших издержек на изменение этого заголовка. Изменить этот параметр могут только суперпользователи.
Как включить ведение журнала всего SQL, выполняемого PostgreSQL 8.3?
Отредактировано (подробнее) Я изменил эти строки:
И перезапустите службу PostgreSQL . но журнал не был создан . Я использую Windows Server 2003.
Кроме того, имейте в виду, что в некоторых дистрибутивах GNU / Linux (например, Debian Jessie) systemctl restart postgresql может фактически не перезапускаться настроенная вами служба PostgreSQL (пока я не понимаю, почему), поэтому изменения в файле конфигурации не будут применены. Это безопаснее использовать pg_ctl (или pg_ctlcluster на Debian). Я только проверил это в Ubuntu 16.04 LTS, с PostgreSQL 9.5, и systemctl reload postgresql , systemctl restart postgresql , service postgresql reload и service postgresql restart все изменения конфигурации делает эффективной.В вашем data/postgresql.conf файле измените log_statement настройку на 'all' .
редактировать
Глядя на вашу новую информацию, я бы сказал, что может быть несколько других параметров для проверки:
- убедитесь, что вы включили log_destination переменную
- убедитесь, что вы включите logging_collector
- также убедитесь, что log_directory каталог уже существует внутри data каталога и что пользователь postgres может писать в него.
Отредактируйте /etc/postgresql/9.3/main/postgresql.conf и измените строки следующим образом.
Примечание : если вы не нашли postgresql.conf файл, просто введите $locate postgresql.conf в терминале
Необязательно : SELECT set_config('log_statement', 'all', true);
sudo /etc/init.d/postgresql restart или sudo service postgresql restart
Пожарный запрос в postgresql select 2+2
Найти текущий логин /var/lib/pgsql/9.2/data/pg_log/
Файлы журналов имеют тенденцию сильно расти со временем и могут убить вашу машину. Для вашей безопасности напишите bash-скрипт, который удалит журналы и перезапустит сервер postgresql.
Основные log файлы Ubuntu
Лог загрузки
Начнем с самого начала. В момент загрузки системы записывается вся основная информация, имеющая к ней отношение. Если у вас будут какие-то ошибки во время старта сервера, вы сможете их увидеть в этом логе. Посмотреть лог загрузки Ubuntu можно следующим образом.
У вас получится очень длинный вывод всего того, что происходило с системой на старте. Если ищите что-то конкретное, то можете сделать фильтрацию вывода с помощью grep. Допустим, вам надо узнать информацию только о диске.
Вы увидите лог загрузки системы ubuntu, содержащий информацию только о диске sda. Аналогичным образом можно фильтровать вывод по другим темам. Например, посмотреть все ошибки, которые были во время загрузки.
И так далее. Информация, которую выводит команда dmesg, хранится в log файле /var/log/dmesg .
Логи авторизации, в том числе ssh
Для того, чтобы узнать, кто и когда проходил авторизацию на сервере ubuntu, можно воспользоваться логами из файла /var/log/auth.log . Авторизация по ssh там будет выглядеть следующим образом.
Не забудьте перезапустить службу sshd для принятия изменений:
После этого логирование подключений по ssh будет более подробное.
Лог локального входа в ubuntu тоже хранится в файле auth.log . Информация о подключении через консоль выглядит следующим образом.
Устройство /dev/tty1 говорит о том, что вход локальный.
Вы можете быстро посмотреть информацию о последних входах в систему с помощью команды last. Эта информация хранится в бинарном логе /var/log/lastlog .
Примерно то же самое можно увидеть с помощью utmpdump.
Логи ошибок в Ubuntu
Рассмотрим теперь вопрос с расположением лога ошибок в Ubuntu. Как такового отдельного error log в традиционных linux системах нет. И Убунта тут не исключение. Ошибки придется искать по системным и программным логам выборкой ключевых слов. Обычно используют следующие фразы:
- error или err
- critical или crit
- debug
- warn
А теперь проверим ошибки в системном логе.
Видим некоторые ошибки в службе systemd-resolved.
Cron logs
Часто хочется проверить лог запуска периодических заданий cron. В Ubuntu, как мне кажется, сделали не удобно. По умолчанию, cron logs не выделены в отдельный файл. Искать их стоит в общем системном логе syslog. Например, в Centos существует отдельный лог-файл /var/log/cron, где собрана вся информация о запущенных заданиях. Предлагаю сделать так же в Ubuntu.
Для этого открываем конфигурационный файл /etc/rsyslog.d/50-default.conf и добавляем туда следующую информацию.
Я добавил в нее cron.none, чтобы логи cron не писались больше в системный лог syslog. После этого перезапустите службы rsyslog и cron и проверяйте изменения.
Теперь у нас все логи Cron в Ubuntu будут в отдельном файле.
Лог действий пользователя
Мне часто задают вопросы, как посмотреть лог действий пользователя в системе или как узнать, какие программы он запускал. По умолчанию, такие действия не логируются в ubuntu. Для этого нужно устанавливать какое-то дополнительное программное обеспечение. Я даже не знаю, кто умеет это делать. Обычно если надо фиксировать действия пользователя, включается лог работы sudo.
Для того, чтобы включить логирование действий пользователя через sudo, редактируем файл /etc/sudoers . Добавляем туда строку.
Теперь выполните какую-нибудь команду через sudo.
Выполненная команда пользователя сохранена в логе sudo.log. Теперь никто не сможет выполнить незаметно административные действия на сервере. Конечно, человек с полными правами сможет изменить любой лог файл, удалив свои действия при желании. Для этого важные логи нужно отправлять куда-то в другое место, но это уже тема отдельной статьи.
На сегодня по логам в Ubuntu у меня все. Желаю вам логов без ошибок и вечного аптайма (шутка, надо ставить обновы и перезагружаться).
Перемещение каталога данных PostgreSQL 12 в Ubuntu 18.04
Объём базы данных постоянно увеличивается и со временем дисковое пространство заканчивается. Возникает вопрос, что делать? Путей решения несколько, например расширить текущий раздел или перенести базу на более емкий и быстрый диск. При планировании новой инсталляции PostgreSQL так же желательно размещать каталог данных кластера на отдельном томе для повышения производительности.
Исходные данные: ОС Ubuntu 18.04 с PostgreSQL 12
Задача: Перенести каталог данных кластера на новый диск.
Для начала проверим где сейчас находится каталог данных кластера:
Это стандартный путь размещения каталога, в котором хранятся данные.
На сервер подключили новый дисковый массив и смонтировали его в /pgdata, именно туда нам и нужно перенести данные.
Для переноса останавливаем кластер:
Переносим данные с помощью rsync и устанавливаем владельца:
Важное примечание: Убедитесь, что в названии каталога нет конечного слеша (система может добавить его, если вы используете автодополнение). Если такой слеш есть, то уберите его.
Переименовываем текущий каталог данных
Отредактируем файл конфигурации кластера /etc/postgresql/12/main/postgresql.conf
В нем нам нужно заменить настройку
Теперь можно запустить кластер:
PostgreSQL успешно запустился и готов принимать соединения.
Проверим где сейчас находится каталог данных кластера:
Отлично. Теперь можно запустить наше приложение работающее с PostgreSQL, проверить корректность его работы. После этого можно удалить старый каталог.
Удаляем старый каталог:
На этом все, до скорых встреч. Если у Вас возникли вопросы или Вы хотите чтобы я помог Вам, то Вы всегда можете связаться со мной разными доступными способами.
Читайте также: