Our Blog
Photo by Jitze Couperus
When debugging a problem, it’s always frustrating to get sidetracked hunting down the relevant logs. PostgreSQL users can select any of several different ways to handle database logs, or even choose a combination. But especially for new users, or those getting used to an unfamiliar system, just finding the logs can be difficult. To ease that pain, here’s a key to help dig up the correct logs.
Where are log entries sent?
First, connect to PostgreSQL with psql, pgadmin, or some other client that lets you run SQL queries, and run this:
The log_destination setting tells PostgreSQL where log entries should go. In most cases it will be one of four values, though it can also be a comma-separated list of any of those four values. We’ll discuss each in turn.
Syslog
Syslog is a complex beast, and if your logs are going here, you’ll want more than this blog post to help you. Different systems have different syslog daemons, those daemons have different capabilities and require different configurations, and we simply can’t cover them all here. Your syslog may be configured to send PostgreSQL logs anywhere on the system, or even to an external server. For your purposes, though, you’ll need to know what ident and facility you’re using. These values tag each syslog message coming from PostgreSQL, and allow the syslog daemon to sort out where the message should go. You can find them like this:
Syslog is often useful, in that it allows administrators to collect logs from many applications into one place, to relieve the database server of logging I/O overhead (which may or may not actually help anything), or any number of other interesting rearrangements of log data.
Event Log
For PostgreSQL systems running on Windows, you can send log entries to the Windows event log. You’ll want to tell Windows to expect the log values, and what “event source” they’ll come from. You can find instructions for this operation in the PostgreSQL documentation discussing server setup.
stderr
This is probably the most common log destination (it’s the default, after all) and can get fairly complicated in itself. Selecting stderr instructs PostgreSQL to send log data to the “stderr” (short for “standard error”) output stream most operating systems give every new process by default. The difficulty is that PostgreSQL or the applications that launch it can then redirect this stream to all kinds of different places. If you start PostgreSQL manually with no particular redirection in place, log entries will be written to your terminal:
In these logs you’ll see the logs from me starting the database, connecting to it from some other terminal, and issuing the obviously erroneous command “select syntax error”. But there are several ways to redirect this elsewhere. The easiest is with the pg_ctl -l option, which essentially redirects stderr to a file, in which case the startup looks like this:
Finally, you can also tell PostgreSQL to redirect its stderr output internally, with the logging_collector option (which older versions of PostgreSQL named redirect_stderr ). This can be on or off, and when on, collects stderr output into a configured log directory.
So if you see a log_destination set to stderr , a good next step is to check logging_collector :
In this system, logging_collector is turned on, which means we have to find out where it’s collecting logs. First, check log_directory . In my case, below, it’s an absolute path, but by default it’s the relative path pg_log . This is relative to the PostgreSQL data directory. Log files are named according to a pattern in log_filename . Each of these settings is shown below:
Documentation for each of these options, along with settings governing log rotation, is available in the PostgreSQL Error Reporting and Logging documentation.
If logging_collector is turned off, you can still find the logs using the /proc filesystem, on operating systems equipped with one. First you’ll need to find the process ID (pid) of a PostgreSQL process, which is simple enough:
Then, check /proc/YOUR_PID_HERE/fd/2 , which is a symlink to the log destination:
CSV log
The csvlog mode creates logs in CSV format, designed to be easily machine-readable. In fact, this section of the PostgreSQL documentation even provides a handy table definition if you want to slurp the logs into your database. CSV logs are produced in a fixed format the administrator cannot change, but it includes fields for everything available in the other log formats. For these to work, you need to have logging_collector turned on; without logging_collector , the logs simply won’t show up anywhere.
But when configured correctly, PostgreSQL will create CSV format logs in the log_directory , with file names mostly following the log_filename pattern. Here’s my example database, with log_destination set to stderr, csvlog and logging_collector turned on, just after I start the database and issue one query:
Как посмотреть логи postgresql
PostgreSQL supports several methods for logging server messages, including stderr , csvlog and syslog . On Windows, eventlog is also supported. Set this parameter to a list of desired log destinations separated by commas. The default is to log to stderr only. This parameter can only be set in the postgresql.conf file or on the server command line.
If csvlog is included in log_destination , log entries are output in “ comma separated value ” (CSV ) format, which is convenient for loading logs into programs. See Section 19.8.4 for details. logging_collector must be enabled to generate CSV-format log output.
When either stderr or csvlog are included, the file current_logfiles is created to record the location of the log file(s) currently in use by the logging collector and the associated logging destination. This provides a convenient way to find the logs currently in use by the instance. Here is an example of this file’s content:
current_logfiles is recreated when a new log file is created as an effect of rotation, and when log_destination is reloaded. It is removed when neither stderr nor csvlog are included in log_destination , and when the logging collector is disabled.
On most Unix systems, you will need to alter the configuration of your system’s syslog daemon in order to make use of the syslog option for log_destination . PostgreSQL can log to syslog facilities LOCAL0 through LOCAL7 (see syslog_facility), but the default syslog configuration on most platforms will discard all such messages. You will need to add something like:
to the syslog daemon’s configuration file to make it work.
On Windows, when you use the eventlog option for log_destination , you should register an event source and its library with the operating system so that the Windows Event Viewer can display event log messages cleanly. See Section 18.11 for details.
This parameter enables the logging collector, which is a background process that captures log messages sent to stderr and redirects them into log files. This approach is often more useful than logging to syslog , since some types of messages might not appear in syslog output. (One common example is dynamic-linker failure messages; another is error messages produced by scripts such as archive_command .) This parameter can only be set at server start.
It is possible to log to stderr without using the logging collector; the log messages will just go to wherever the server’s stderr is directed. However, that method is only suitable for low log volumes, since it provides no convenient way to rotate log files. Also, on some platforms not using the logging collector can result in lost or garbled log output, because multiple processes writing concurrently to the same log file can overwrite each other’s output.
The logging collector is designed to never lose messages. This means that in case of extremely high load, server processes could be blocked while trying to send additional log messages when the collector has fallen behind. In contrast, syslog prefers to drop messages if it cannot write them, which means it may fail to log some messages in such cases but it will not block the rest of the system.
When logging_collector is enabled, this parameter determines the directory in which log files will be created. It can be specified as an absolute path, or relative to the cluster data directory. This parameter can only be set in the postgresql.conf file or on the server command line. The default is log .
When logging_collector is enabled, this parameter sets the file names of the created log files. The value is treated as a strftime pattern, so % -escapes can be used to specify time-varying file names. (Note that if there are any time-zone-dependent % -escapes, the computation is done in the zone specified by log_timezone.) The supported % -escapes are similar to those listed in the Open Group’s strftime specification. Note that the system’s strftime is not used directly, so platform-specific (nonstandard) extensions do not work. The default is postgresql-%Y-%m-%d_%H%M%S.log .
If you specify a file name without escapes, you should plan to use a log rotation utility to avoid eventually filling the entire disk. In releases prior to 8.4, if no % escapes were present, PostgreSQL would append the epoch of the new log file’s creation time, but this is no longer the case.
If CSV-format output is enabled in log_destination , .csv will be appended to the timestamped log file name to create the file name for CSV-format output. (If log_filename ends in .log , the suffix is replaced instead.)
This parameter can only be set in the postgresql.conf file or on the server command line.
On Unix systems this parameter sets the permissions for log files when logging_collector is enabled. (On Microsoft Windows this parameter is ignored.) The parameter value is expected to be a numeric mode specified in the format accepted by the chmod and umask system calls. (To use the customary octal format the number must start with a 0 (zero).)
The default permissions are 0600 , meaning only the server owner can read or write the log files. The other commonly useful setting is 0640 , allowing members of the owner’s group to read the files. Note however that to make use of such a setting, you’ll need to alter log_directory to store the files somewhere outside the cluster data directory. In any case, it’s unwise to make the log files world-readable, since they might contain sensitive data.
This parameter can only be set in the postgresql.conf file or on the server command line.
When logging_collector is enabled, this parameter determines the maximum lifetime of an individual log file. After this many minutes have elapsed, a new log file will be created. Set to zero to disable time-based creation of new log files. This parameter can only be set in the postgresql.conf file or on the server command line.
When logging_collector is enabled, this parameter determines the maximum size of an individual log file. After this many kilobytes have been emitted into a log file, a new log file will be created. Set to zero to disable size-based creation of new log files. This parameter can only be set in the postgresql.conf file or on the server command line.
When logging_collector is enabled, this parameter will cause PostgreSQL to truncate (overwrite), rather than append to, any existing log file of the same name. However, truncation will occur only when a new file is being opened due to time-based rotation, not during server startup or size-based rotation. When off, pre-existing files will be appended to in all cases. For example, using this setting in combination with a log_filename like postgresql-%H.log would result in generating twenty-four hourly log files and then cyclically overwriting them. This parameter can only be set in the postgresql.conf file or on the server command line.
Example: To keep 7 days of logs, one log file per day named server_log.Mon , server_log.Tue , etc, and automatically overwrite last week’s log with this week’s log, set log_filename to server_log.%a , log_truncate_on_rotation to on , and log_rotation_age to 1440 .
Example: To keep 24 hours of logs, one log file per hour, but also rotate sooner if the log file size exceeds 1GB, set log_filename to server_log.%H%M , log_truncate_on_rotation to on , log_rotation_age to 60 , and log_rotation_size to 1000000 . Including %M in log_filename allows any size-driven rotations that might occur to select a file name different from the hour’s initial file name.
When logging to syslog is enabled, this parameter determines the syslog “ facility ” to be used. You can choose from LOCAL0 , LOCAL1 , LOCAL2 , LOCAL3 , LOCAL4 , LOCAL5 , LOCAL6 , LOCAL7 ; the default is LOCAL0 . See also the documentation of your system’s syslog daemon. This parameter can only be set in the postgresql.conf file or on the server command line.
When logging to syslog is enabled, this parameter determines the program name used to identify PostgreSQL messages in syslog logs. The default is postgres . This parameter can only be set in the postgresql.conf file or on the server command line.
When logging to syslog and this is on (the default), then each message will be prefixed by an increasing sequence number (such as [2] ). This circumvents the “ — last message repeated N times — ” suppression that many syslog implementations perform by default. In more modern syslog implementations, repeated message suppression can be configured (for example, $RepeatedMsgReduction in rsyslog ), so this might not be necessary. Also, you could turn this off if you actually want to suppress repeated messages.
This parameter can only be set in the postgresql.conf file or on the server command line.
When logging to syslog is enabled, this parameter determines how messages are delivered to syslog. When on (the default), messages are split by lines, and long lines are split so that they will fit into 1024 bytes, which is a typical size limit for traditional syslog implementations. When off, PostgreSQL server log messages are delivered to the syslog service as is, and it is up to the syslog service to cope with the potentially bulky messages.
If syslog is ultimately logging to a text file, then the effect will be the same either way, and it is best to leave the setting on, since most syslog implementations either cannot handle large messages or would need to be specially configured to handle them. But if syslog is ultimately writing into some other medium, it might be necessary or more useful to keep messages logically together.
This parameter can only be set in the postgresql.conf file or on the server command line.
When logging to event log is enabled, this parameter determines the program name used to identify PostgreSQL messages in the log. The default is PostgreSQL . This parameter can only be set in the postgresql.conf file or on the server command line.
19.8.2. When To Log
Controls which message levels are sent to the client. Valid values are DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , LOG , NOTICE , WARNING , ERROR , FATAL , and PANIC . Each level includes all the levels that follow it. The later the level, the fewer messages are sent. The default is NOTICE . Note that LOG has a different rank here than in log_min_messages .
Controls which message levels are written to the server log. Valid values are DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , INFO , NOTICE , WARNING , ERROR , LOG , FATAL , and PANIC . Each level includes all the levels that follow it. The later the level, the fewer messages are sent to the log. The default is WARNING . Note that LOG has a different rank here than in client_min_messages . Only superusers can change this setting.
Controls which SQL statements that cause an error condition are recorded in the server log. The current SQL statement is included in the log entry for any message of the specified severity or higher. Valid values are DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , INFO , NOTICE , WARNING , ERROR , LOG , FATAL , and PANIC . The default is ERROR , which means statements causing errors, log messages, fatal errors, or panics will be logged. To effectively turn off logging of failing statements, set this parameter to PANIC . Only superusers can change this setting.
Causes the duration of each completed statement to be logged if the statement ran for at least the specified number of milliseconds. Setting this to zero prints all statement durations. Minus-one (the default) disables logging statement durations. For example, if you set it to 250ms then all SQL statements that run 250ms or longer will be logged. Enabling this parameter can be helpful in tracking down unoptimized queries in your applications. Only superusers can change this setting.
For clients using extended query protocol, durations of the Parse, Bind, and Execute steps are logged independently.
When using this option together with log_statement, the text of statements that are logged because of log_statement will not be repeated in the duration log message. If you are not using syslog , it is recommended that you log the PID or session ID using log_line_prefix so that you can link the statement message to the later duration message using the process ID or session ID.
Table 19.1 explains the message severity levels used by PostgreSQL . If logging output is sent to syslog or Windows’ eventlog , the severity levels are translated as shown in the table.
Table 19.1. Message Severity Levels
| Severity | Usage | syslog | eventlog |
|---|---|---|---|
| DEBUG1..DEBUG5 | Provides successively-more-detailed information for use by developers. | DEBUG | INFORMATION |
| INFO | Provides information implicitly requested by the user, e.g., output from VACUUM VERBOSE . | INFO | INFORMATION |
| NOTICE | Provides information that might be helpful to users, e.g., notice of truncation of long identifiers. | NOTICE | INFORMATION |
| WARNING | Provides warnings of likely problems, e.g., COMMIT outside a transaction block. | NOTICE | WARNING |
| ERROR | Reports an error that caused the current command to abort. | WARNING | ERROR |
| LOG | Reports information of interest to administrators, e.g., checkpoint activity. | INFO | INFORMATION |
| FATAL | Reports an error that caused the current session to abort. | ERR | ERROR |
| PANIC | Reports an error that caused all database sessions to abort. | CRIT | ERROR |
19.8.3. What To Log
The application_name can be any string of less than NAMEDATALEN characters (64 characters in a standard build). It is typically set by an application upon connection to the server. The name will be displayed in the pg_stat_activity view and included in CSV log entries. It can also be included in regular log entries via the log_line_prefix parameter. Only printable ASCII characters may be used in the application_name value. Other characters will be replaced with question marks ( ? ).
debug_print_parse ( boolean )
debug_print_rewritten ( boolean )
debug_print_plan ( boolean )
These parameters enable various debugging output to be emitted. When set, they print the resulting parse tree, the query rewriter output, or the execution plan for each executed query. These messages are emitted at LOG message level, so by default they will appear in the server log but will not be sent to the client. You can change that by adjusting client_min_messages and/or log_min_messages. These parameters are off by default.
When set, debug_pretty_print indents the messages produced by debug_print_parse , debug_print_rewritten , or debug_print_plan . This results in more readable but much longer output than the “ compact ” format used when it is off. It is on by default.
Causes checkpoints and restartpoints to be logged in the server log. Some statistics are included in the log messages, including the number of buffers written and the time spent writing them. This parameter can only be set in the postgresql.conf file or on the server command line. The default is off.
Causes each attempted connection to the server to be logged, as well as successful completion of client authentication. Only superusers can change this parameter at session start, and it cannot be changed at all within a session. The default is off .
Some client programs, like psql , attempt to connect twice while determining if a password is required, so duplicate “ connection received ” messages do not necessarily indicate a problem.
Causes session terminations to be logged. The log output provides information similar to log_connections , plus the duration of the session. Only superusers can change this parameter at session start, and it cannot be changed at all within a session. The default is off .
Causes the duration of every completed statement to be logged. The default is off . Only superusers can change this setting.
For clients using extended query protocol, durations of the Parse, Bind, and Execute steps are logged independently.
The difference between setting this option and setting log_min_duration_statement to zero is that exceeding log_min_duration_statement forces the text of the query to be logged, but this option doesn’t. Thus, if log_duration is on and log_min_duration_statement has a positive value, all durations are logged but the query text is included only for statements exceeding the threshold. This behavior can be useful for gathering statistics in high-load installations.
Controls the amount of detail written in the server log for each message that is logged. Valid values are TERSE , DEFAULT , and VERBOSE , each adding more fields to displayed messages. TERSE excludes the logging of DETAIL , HINT , QUERY , and CONTEXT error information. VERBOSE output includes the SQLSTATE error code (see also Appendix A) and the source code file name, function name, and line number that generated the error. Only superusers can change this setting.
By default, connection log messages only show the IP address of the connecting host. Turning this parameter on causes logging of the host name as well. Note that depending on your host name resolution setup this might impose a non-negligible performance penalty. This parameter can only be set in the postgresql.conf file or on the server command line.
This is a printf -style string that is output at the beginning of each log line. % characters begin “ escape sequences ” that are replaced with status information as outlined below. Unrecognized escapes are ignored. Other characters are copied straight to the log line. Some escapes are only recognized by session processes, and will be treated as empty by background processes such as the main server process. Status information may be aligned either left or right by specifying a numeric literal after the % and before the option. A negative value will cause the status information to be padded on the right with spaces to give it a minimum width, whereas a positive value will pad on the left. Padding can be useful to aid human readability in log files. This parameter can only be set in the postgresql.conf file or on the server command line. The default is ‘%m [%p] ‘ which logs a time stamp and the process ID.
| Escape | Effect | Session only |
|---|---|---|
| %a | Application name | yes |
| %u | User name | yes |
| %d | Database name | yes |
| %r | Remote host name or IP address, and remote port | yes |
| %h | Remote host name or IP address | yes |
| %p | Process ID | no |
| %t | Time stamp without milliseconds | no |
| %m | Time stamp with milliseconds | no |
| %n | Time stamp with milliseconds (as a Unix epoch) | no |
| %i | Command tag: type of session’s current command | yes |
| %e | SQLSTATE error code | no |
| %c | Session ID: see below | no |
| %l | Number of the log line for each session or process, starting at 1 | no |
| %s | Process start time stamp | no |
| %v | Virtual transaction ID (backendID/localXID) | no |
| %x | Transaction ID (0 if none is assigned) | no |
| %q | Produces no output, but tells non-session processes to stop at this point in the string; ignored by session processes | no |
| %% | Literal % | no |
The %c escape prints a quasi-unique session identifier, consisting of two 4-byte hexadecimal numbers (without leading zeros) separated by a dot. The numbers are the process start time and the process ID, so %c can also be used as a space saving way of printing those items. For example, to generate the session identifier from pg_stat_activity , use this query:
If you set a nonempty value for log_line_prefix , you should usually make its last character be a space, to provide visual separation from the rest of the log line. A punctuation character can be used too.
Syslog produces its own time stamp and process ID information, so you probably do not want to include those escapes if you are logging to syslog .
The %q escape is useful when including information that is only available in session (backend) context like user or database name. For example:
Controls whether a log message is produced when a session waits longer than deadlock_timeout to acquire a lock. This is useful in determining if lock waits are causing poor performance. The default is off . Only superusers can change this setting.
Controls which SQL statements are logged. Valid values are none (off), ddl , mod , and all (all statements). ddl logs all data definition statements, such as CREATE , ALTER , and DROP statements. mod logs all ddl statements, plus data-modifying statements such as INSERT , UPDATE , DELETE , TRUNCATE , and COPY FROM . PREPARE , EXECUTE , and EXPLAIN ANALYZE statements are also logged if their contained command is of an appropriate type. For clients using extended query protocol, logging occurs when an Execute message is received, and values of the Bind parameters are included (with any embedded single-quote marks doubled).
The default is none . Only superusers can change this setting.
Statements that contain simple syntax errors are not logged even by the log_statement = all setting, because the log message is emitted only after basic parsing has been done to determine the statement type. In the case of extended query protocol, this setting likewise does not log statements that fail before the Execute phase (i.e., during parse analysis or planning). Set log_min_error_statement to ERROR (or lower) to log such statements.
Causes each replication command to be logged in the server log. See Section 53.4 for more information about replication command. The default value is off . Only superusers can change this setting.
Controls logging of temporary file names and sizes. Temporary files can be created for sorts, hashes, and temporary query results. A log entry is made for each temporary file when it is deleted. A value of zero logs all temporary file information, while positive values log only files whose size is greater than or equal to the specified number of kilobytes. The default setting is -1, which disables such logging. Only superusers can change this setting.
Sets the time zone used for timestamps written in the server log. Unlike TimeZone, this value is cluster-wide, so that all sessions will report timestamps consistently. The built-in default is GMT , but that is typically overridden in postgresql.conf ; initdb will install a setting there corresponding to its system environment. See Section 8.5.3 for more information. This parameter can only be set in the postgresql.conf file or on the server command line.
19.8.4. Using CSV-Format Log Output
To import a log file into this table, use the COPY FROM command:
There are a few things you need to do to simplify importing CSV log files:
Set log_filename and log_rotation_age to provide a consistent, predictable naming scheme for your log files. This lets you predict what the file name will be and know when an individual log file is complete and therefore ready to be imported.
Set log_rotation_size to 0 to disable size-based log rotation, as it makes the log file name difficult to predict.
Set log_truncate_on_rotation to on so that old log data isn’t mixed with the new in the same file.
The table definition above includes a primary key specification. This is useful to protect against accidentally importing the same information twice. The COPY command commits all of the data it imports at one time, so any error will cause the entire import to fail. If you import a partial log file and later import the file again when it is complete, the primary key violation will cause the import to fail. Wait until the log is complete and closed before importing. This procedure will also protect against accidentally importing a partial line that hasn’t been completely written, which would also cause COPY to fail.
19.8.5. Process Title
These settings control how process titles of server processes are modified. Process titles are typically viewed using programs like ps or, on Windows, Process Explorer . See Section 28.1 for details.
Sets the cluster name that appears in the process title for all server processes in this cluster. The name can be any string of less than NAMEDATALEN characters (64 characters in a standard build). Only printable ASCII characters may be used in the cluster_name value. Other characters will be replaced with question marks ( ? ). No name is shown if this parameter is set to the empty string » (which is the default). This parameter can only be set at server start.
Enables updating of the process title every time a new SQL command is received by the server. This setting defaults to on on most platforms, but it defaults to off on Windows due to that platform’s larger overhead for updating the process title. Only superusers can change this setting.
Как посмотреть логи postgresql
PostgreSQL поддерживает несколько методов протоколирования сообщений сервера: stderr , csvlog и syslog . На Windows также поддерживается eventlog . В качестве значения log_destination указывается один или несколько методов протоколирования, разделённых запятыми. По умолчанию используется stderr . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.
Если в log_destination включено значение csvlog , то протоколирование ведётся в формате CSV (разделённые запятыми значения). Это удобно для программной обработки журнала. Подробнее об этом в Подразделе 19.8.4. Для вывода в формате CSV должен быть включён logging_collector.
Если присутствует указание stderr или csvlog , создаётся файл current_logfiles , в который записывается расположение файла(ов) журнала, в настоящее время используемого сборщиком сообщений для соответствующего назначения. Это позволяет легко определить, какие файлы журнала используются в данный момент экземпляром сервера. Например, он может иметь такое содержание:
current_logfiles переписывается когда при прокрутке создаётся новый файл журнала или когда изменяется значение log_destination . Он удаляется, когда в log_destination не задаётся ни stderr , ни csvlog , а также когда сборщик сообщений отключён.
Примечание
В большинстве систем Unix потребуется изменить конфигурацию системного демона syslog для использования варианта syslog в log_destination . Для указания типа протоколируемой программы (facility), PostgreSQL может использовать значения с LOCAL0 по LOCAL7 (см. syslog_facility). Однако на большинстве платформ конфигурация syslog по умолчанию не учитывает сообщения подобного типа. Чтобы это работало, потребуется добавить в конфигурацию демона syslog что-то подобное:
Для использования eventlog в log_destination на Windows, необходимо зарегистрировать источник событий и его библиотеку в операционной системе. Тогда Windows Event Viewer сможет отображать сообщения журнала событий. Подробнее в Разделе 18.12.
Параметр включает сборщик сообщений (logging collector). Это фоновый процесс, который собирает отправленные в stderr сообщения и перенаправляет их в журнальные файлы. Такой подход зачастую более полезен чем запись в syslog , поскольку некоторые сообщения в syslog могут не попасть. (Типичный пример с сообщениями об ошибках динамического связывания, другой пример — ошибки в скриптах типа archive_command .) Для установки параметра требуется перезапуск сервера.
Примечание
Можно обойтись без сборщика сообщений и просто писать в stderr . Сообщения будут записываться в место, куда направлен поток stderr . Такой способ подойдёт только для небольших объёмов протоколирования, потому что не предоставляет удобных средств для организации ротации журнальных файлов. Кроме того, на некоторых платформах отказ от использования сборщика сообщений может привести к потере или искажению сообщений, так как несколько процессов, одновременно пишущих в один журнальный файл, могут перезаписывать информацию друг друга.
Примечание
Сборщик спроектирован так, чтобы сообщения никогда не терялись. А это значит, что при очень высокой нагрузке, серверные процессы могут быть заблокированы при попытке отправить сообщения во время сбоя фонового процесса сборщика. В противоположность этому, syslog предпочитает удалять сообщения, при невозможности их записать. Поэтому часть сообщений может быть потеряна, но система не будет блокироваться.
При включённом logging_collector , определяет каталог, в котором создаются журнальные файлы. Можно задавать как абсолютный путь, так и относительный от каталога данных кластера. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. Значение по умолчанию — 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 этот параметр определяет максимальное время жизни отдельного журнального файла, по истечении которого создаётся новый файл. Если это значение задаётся без единиц измерения, оно считается заданным в минутах. Значение по умолчанию — 24 часа. При нулевом значении смена файлов по времени не производится. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_rotation_size ( integer )
При включённом logging_collector этот параметр определяет максимальный размер отдельного журнального файла. При достижении этого размера создаётся новый файл. Если это значение задаётся без единиц измерения, оно считается заданным в килобайтах. Значение по умолчанию — 10 мегабайт. При нулевом значении смена файлов по размеру не производится. Задать этот параметр можно только в 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 )
При включённом протоколировании в syslog , этот параметр задаёт имя программы, которое будет использоваться в syslog для идентификации сообщений относящихся к PostgreSQL . По умолчанию используется postgres . Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. syslog_sequence_numbers ( boolean )
Когда сообщения выводятся в syslog и этот параметр включён (по умолчанию), все сообщения будут предваряться последовательно увеличивающимися номерами (например, [2] ). Это позволяет обойти подавление повторов « — последнее сообщение повторилось N раз — » , которое по умолчанию осуществляется во многих реализациях syslog. В более современных реализациях syslog подавление повторных сообщений можно настроить (например, в rsyslog есть директива $RepeatedMsgReduction ), так что это может излишне. Если же вы действительно хотите, чтобы повторные сообщения подавлялись, вы можете отключить этот параметр.
Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. syslog_split_messages ( boolean )
Когда активен вывод сообщений в syslog , этот параметр определяет, как будут доставляться сообщения. Если он включён (по умолчанию), сообщения разделяются по строкам, а длинные строки разбиваются на строки не длиннее 1024 байт, что составляет типичное ограничение размера для традиционных реализаций syslog. Когда он отключён, сообщения сервера PostgreSQL передаются службе syslog как есть, и она должна сама корректно воспринять потенциально длинные сообщения.
Если syslog в итоге выводит сообщения в текстовый файл, результат будет тем же и лучше оставить этот параметр включённым, так как многие реализации syslog не способны обрабатывать большие сообщения или их нужно специально настраивать для этого. Но если syslog направляет сообщения в некоторую другую среду, может потребоваться или будет удобнее сохранять логическую целостность сообщений.
Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. event_source ( string )
При включённом протоколировании в event log , этот параметр задаёт имя программы, которое будет использоваться в журнале событий для идентификации сообщений относящихся к PostgreSQL . По умолчанию используется PostgreSQL . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.
19.8.2. Когда протоколировать
Управляет минимальным уровнем сообщений, записываемых в журнал сервера. Допустимые значения DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , INFO , NOTICE , WARNING , ERROR , LOG , FATAL и PANIC . Каждый из перечисленных уровней включает все идущие после него. Чем дальше в этом списке уровень сообщения, тем меньше сообщений будет записано в журнал сервера. По умолчанию используется WARNING . Обратите внимание, позиция LOG здесь отличается от принятой в client_min_messages. Только суперпользователи могут изменить этот параметр. log_min_error_statement ( enum )
Управляет тем, какие SQL-операторы, завершившиеся ошибкой, записываются в журнал сервера. SQL-оператор будет записан в журнал, если он завершится ошибкой с указанным уровнем важности или выше. Допустимые значения: DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , INFO , NOTICE , WARNING , ERROR , LOG , FATAL и PANIC . По умолчанию используется ERROR . Это означает, что в журнал сервера будут записаны все операторы, завершившиеся сообщением с уровнем важности ERROR , LOG , FATAL и PANIC . Чтобы фактически отключить запись операторов с ошибками, установите для этого параметра значение PANIC . Изменить этот параметр могут только суперпользователи. log_min_duration_statement ( integer )
Записывает в журнал продолжительность выполнения всех команд, время работы которых не меньше указанного. Например, при значении 250ms в журнал сервера будут записаны все команды, выполняющиеся 250 миллисекунд и дольше. С помощью этого параметра можно выявить неоптимизированные запросы в приложениях. Если значение этого параметра задаётся без единиц измерения, оно считается заданным в миллисекундах. При нулевом значении записывается продолжительность выполнения всех команд. Со значением -1 (по умолчанию) запись полностью отключается. Изменить этот параметр могут только суперпользователи.
Этот параметр переопределяет log_min_duration_sample, то есть запросы с длительностью, превышающей заданное значение, всегда фиксируются в журнале, вне зависимости от параметров извлечения выборки.
Для клиентов, использующих расширенный протокол запросов, будет записываться продолжительность фаз: разбор, связывание и выполнение.
Примечание
При использовании совместно с log_statement, текст SQL-операторов будет записываться только один раз (от использования log_statement ) и не будет задублирован в сообщении о длительности выполнения. Если не используется вывод в syslog , то рекомендуется в log_line_prefix включить идентификатор процесса или сессии. Это позволит связать текст запроса с записью о продолжительности выполнения, которая появится позже.
Позволяет сделать выборку по продолжительности команд, которые выполнялись не менее чем определённое время. При этом в журнал будут вноситься такие же записи, как и при включённом параметре log_min_duration_statement, но не для всех команд, а только для их подмножества, ограничиваемого параметром log_statement_sample_rate. Например, при значении 100ms предварительно для выборки будут отобраны все SQL-операторы, выполняющиеся 100 миллисекунд и дольше. Этот параметр может быть полезен, когда количество запросов слишком велико, чтобы записывать в журнал их все. Если значение этого параметра задаётся без единиц измерения, оно считается заданным в миллисекундах. При нулевом значении для выборки отбираются команды с любой продолжительностью. Со значением -1 (по умолчанию) формирование выборки по продолжительности полностью отключается. Изменить этот параметр могут только суперпользователи.
Этот параметр имеет меньший приоритет, чем log_min_duration_statement , то есть команды с длительностью, превышающей log_min_duration_statement , будут регистрироваться в журнале всегда, вне зависимости от того, какой будет выборка.
Другие замечания, относящиеся к log_min_duration_statement , применимы так же и к данному параметру. log_statement_sample_rate ( floating point )
Определяет, какая доля команд с длительностью, достигшей log_min_duration_sample, будет регистрироваться в журнале. Выборка формируется вероятностным образом, например, со значением 0.5 можно считать, что шанс попадания каждой отдельной команды в выборку равен один к двум. Значение по умолчанию — 1.0 , то есть выбираются и регистрируются все команды. Со значением 0 запись команд выборки, в зависимости от их длительности, отключается, так же как и при log_min_duration_sample , равном -1 . Изменить этот параметр могут только суперпользователи. log_transaction_sample_rate ( floating point )
Задаёт долю транзакций, команды из которых будут записываться в журнал дополнительно (помимо команд, записываемых по другим причинам). Этот параметр действует на все транзакции, независимо от длительности команд. Выборка осуществляется вероятностным образом, например, со значением 0.1 можно считать, что каждая транзакция может попасть в журнал с шансом один к десяти. Параметр log_transaction_sample_rate может быть полезен для анализа выборки транзакций. Значение по умолчанию — 0 , то есть команды из дополнительно выбираемых транзакций не записываются. При значении 1 записываются все команды из всех транзакций. Изменить этот параметр могут только суперпользователи.
Примечание
С этим параметром, как и со всеми остальными, управляющими журналированием команд, могут быть связаны значительные издержки.
В Таблице 19.2 поясняются уровни важности сообщений в PostgreSQL . Также в этой таблице показано, как эти уровни транслируются в системные при использовании syslog или eventlog в Windows.
Как включить журналы базы данных
PostgreSQL — это система управления реляционными базами данных с открытым исходным кодом, которая используется в непрерывной разработке и продакшне уже 30 лет. Почти все крупные технологические компании используют PostgreSQL, поскольку это одна из самых надежных, проверенных в боях систем реляционных баз данных на сегодняшний день.
PostgreSQL является критически важной точкой в вашей инфраструктуре, поскольку в ней хранятся все данные. Для этого важна наглядность, а значит, вы должны понимать, как работает протоколирование в PostgreSQL. Это достигается с помощью журналов и метрик, которые предоставляет PostgreSQL.
В этой статье я объясню все, что вам нужно знать о журналах (логах) PostgreSQL, начиная с того, как их включить и заканчивая тем, как их легко форматировать и анализировать.
Что такое журналы PostgreSQL?
Журналы PostgreSQL — текстовые файлы, в которых отображается информация о том, что в данный момент происходит в вашей системе баз данных. Это включает в себя сведения о том, кто имеет доступ и к какому компоненту, какие ошибки произошли, что изменилось в настройках, какие запросы находятся в процессе выполнения и какие транзакции выполняются.
Чтобы получить общую картину всех журналов, вы можете разместить их централизованно, а затем организовать возможность поиска среди них. Парсинг позволяет извлекать важную информацию и метрики, которые затем можно нанести на график для лучшей визуализации в виде точек.
В этой статье мы покажем вам, как изменить настройки PostgreSQL с помощью файла конфигурации и интерфейса командной строки. Рекомендуется вносить все эти изменения исключительно с помощью файла конфигурации, иначе ваши изменения могут быть потеряны при перезагрузке сервера.
Местоположение журнала PostgreSQL
Из коробки PostgreSQL будет показывать журналы в stderr, что не очень удобно, так как они будут смешиваться с другими процессами, которые также ведут логирование в stderr. Чтобы PostgreSQL мог создавать собственные логи, необходимо включить параметр logging_collector . Когда вы это сделаете, журналы начнут отправляться в стандартное местоположение, определенное вашей ОС. Ниже приведены директории журналов по умолчанию для нескольких различных операционных систем:
Система на базе Debian: e/var/log/postgresql/postgresql-x.x.main.log. X.x.
Система на базе Red Hat: /var/lib/pgsql/data/pg_log
Windows: C:\Program Files\PostgreSQL\9.3\data\pg_log
Чтобы поменять место хранения файлов журнала при включенном сборщике (коллекторе) логов, вы можете использовать параметр log_directory для указания пользовательского каталога.
Обратите внимание, что иногда ведение журнала может быть затруднительно в PostgreSQL. Коллектор логов не позволит потерять ни одного сообщения журнала, поэтому при высокой нагрузке он может блокировать процессы сервера, что приведет к проблемам. Вместо него можно использовать системный журнал (syslog), так как он позволяет отбрасывать некоторые сообщения и не блокирует систему. Чтобы отключить коллектор логов, вы можете настроить опцию на off:
В зависимости от условий использования, вам может понадобиться изменить местоположение журналов PostgreSQL. Обычно используются такие варианты, как запись в syslog, CSV, Windows Event и Docker, о которых речь пойдет ниже.
Syslog
Вы можете легко настроить PostgreSQL на ведение журнала в syslog. Вам нужно сделать это на демоне syslog с помощью следующей конфигурации:
Вы можете использовать такие параметры, как syslog_facility , syslog_indent , syslog_sequence_number в конфигурационном файле PostgreSQL для форматирования логов.
CSV лог
Если вы хотите загрузить журналы в инструмент анализа или программу, можно сохранить их в CSV-файл. CSV хорошо определен, что делает этот процесс простым. Для перевода журналов в CSV необходимо добавить следующую строку в конфигурацию PostgreSQL:
Вы также можете создать таблицу дополнительно к журналам, а затем использовать SQL для запроса по определенным условиям.
Журнал событий Windows
Для систем PostgreSQL, работающих под Windows, вы можете отправлять логи в журнал событий (event) Windows, используя следующую конфигурацию:
Обязательно зарегистрируйте систему источника событий в ОС Windows, чтобы она могла получать и показывать вам сообщения журнала событий с помощью программы просмотра событий Windows. Для этого выполните команду:
Docker
В настоящее время многие инструменты и базы данных запускаются как Docker-приложения, включая PostgreSQL. Вы также можете легко запустить Docker-версию PostgreSQL на Kubernetes или любой другой платформе оркестрации контейнеров. Однако в таких случаях не стоит вносить изменения непосредственно в поды или контейнеры, поскольку эти изменения могут быть потеряны при перезапуске подов. Вместо этого необходимо передавать конфигурации во время запуска этих контейнеров.
Чтобы включить логирование, необходимо передать конфигурации с помощью ConfigMaps в Kubernetes. Читайте этот блог, чтобы развернуть PostgreSQL на Kubernetes и включить/выключить различные настройки.
Что важно записывать в журнал?
Запись большого количества информации в журнал может привести к пустой трате времени, если вы не сможете определить, какие логи важны, а какие нет. Очень важно уменьшить шум в журналах, чтобы ускорить отладку — это также сэкономит ваше время и ресурсы для их хранения.
Журналы должны показать вам медленные запросы, уровни логов и то, как отловить критическую информацию с минимальным объемом логирования. Этого можно добиться с помощью фильтров, наиболее распространенными из которых являются пороговые значения журнала, его уровни, время выполнения оператора и семплинг. Давайте немного углубимся в каждый из них.
Пороговые значения для медленного запроса
PostgreSQL может регистрировать запросы, которые занимают больше времени, чем определенный порог. Определение медленных запросов в журнале помогает обнаружить проблемы с базой данных и причины задержек в работе вашего приложения.
Чтобы включить эту функцию, необходимо отредактировать файл postgresql.conf . Найдите строку log_min_duration_statement и настройте ее в соответствии с вашими потребностями. Например, приведенный ниже оператор будет регистрировать все запросы, которые выполняются более 1 секунды:
После этого сохраните файл и перезагрузите PostgreSQL. Ваши настройки будут применены, и вы сможете увидеть логи медленных запросов в файлах журнала PostgreSQL.
Вы также можете задать эти параметры динамически с помощью интерфейса запросов PostgreSQL, выполнив следующую команду:
Время выполнения оператора
Вы можете легко регистрировать продолжительность выполнения каждого оператора в PostgreSQL. Для этого добавьте приведенный ниже оператор в свою конфигурацию, чтобы включить протоколирование каждого оператора:
Другим вариантом решения этой задачи является запуск следующего оператора PostgreSQL:
Обратите внимание, что это включит логирование всех запрошенных операторов, что может оказаться не слишком полезным и попросту будет создавать много шума.
Вместо этого, возможно, вы захотите вести журнал по типу запроса, например, DDL или MOD. DDL состоит из операторов CREATE, ALTER и DROP, а MOD включает в себя DDL плюс другие операторы модификации.
Семплинг
При включенном семплинге вы можете записывать в журнал примеры операторов, которые переходят определенный порог. Если ваш сервер генерирует огромное количество журналов в связи с различными событиями, то вы не захотите регистрировать все, что выходит за порог. Можно делать это выборочно. Это помогает поддерживать меньший объем ввода/вывода при логировании и уменьшить шум в журналах, что облегчает определение того, какие типы операторов вызывают проблему.
Этими порогами и выборкой можно управлять с помощью таких параметров в файле postgresql.conf, как log_min_duration_sample , log_statement_sample_rate и log_transaction_sample_rate . Обратитесь к документации PostgreSQL, чтобы узнать, как правильно их использовать. У вас также есть возможность внести данные изменения через командную строку PostgreSQL.
Обратите внимание, что подобное решение может стать неожиданной ловушкой, так как в результате семплинга можно пропустить единственный оператор, создающий проблему. В таких случаях вы не сможете найти причину ошибки, и отладка займет больше времени, чем обычно.
Уровни журналов PostgreSQL
PostgreSQL предлагает несколько уровней оповещения журнала в зависимости от серьезности события. Вы можете изменить уровень журнала PostgreSQL с помощью параметра log_min_error_statement в конфигурационном файле PostgreSQL, выбрав любой из приведенных ниже:
DEBUG1, DEBUG2, DEBUG3. DEBUG5: Предоставляет разработчикам более подробную информацию.
INFO: Извлекает конкретные данные, запрошенные пользователем, подобно вербозному выводу
NOTICE: Предлагает пользователям полезную информацию, например, об усечении идентификатора.
WARNING: Выдает предупреждения о вероятных проблемах
ERROR: Регистрирует ошибки, включая те, которые вызывают прерывание любой команды.
LOG: Регистрирует данные, например, активность контрольных точек, что может быть полезно для администратора.
FATAL: Возникает при ошибках, которые привели к прерыванию текущего сеанса работы.
PANIC: Возникает при ошибках, которые приводят к прерыванию всех сеансов базы данных.
Если вы отправляете журналы в Windows eventlog (журнал событий) или syslog (системный журнал), уровень серьезности (log-severity) журнала будет изменен следующим образом:
DEBUG1. DEBUG5 будут преобразованы в DEBUG в syslog и INFORMATION в eventlog.
INFO будет INFO в syslog и INFORMATION в eventlog.
NOTICE будет NOTICE в syslog и INFORMATION в eventlog.
WARNING будет NOTICE в syslog и WARNING в eventlog.
ERROR будет WARNING в syslog и ERROR в eventlog.
LOG будет INFO в syslog и INFORMATION в eventlog.
FATAL будет ERR в syslog и ERROR в eventlog.
PANIC будет CRIT в syslog и ERROR в eventlog.
Помимо уровней, очень важно понимать, какие типы журналов генерируются PostgreSQL. Это поможет вам понять, какие именно журналы следует просматривать при возникновении определенной проблемы.
Типы журналов
Существует несколько типов журналов PostgreSQL, которые необходимо учитывать при дебаггинге Их можно разделить на два типа: журналы для администратора, и журналы для пользователя приложения.
Журналы, специфичные для администратора, помогают управлять сервером PostgreSQL. Если сервер работает неправильно, они могут указать причину этого и помочь в устранении неполадок.
Существует два типа журналов, специфичных для администратора:
Журналы запуска: Здесь отображаются все важные события и любые проблемы (например, связанные с неправильной конфигурацией) в процессе запуска вашего сервера PostgreSQL.
Журналы сервера: Они помогут вам определить, что происходит с сервером PostgreSQL во время работы с точки зрения администратора. Они располагаются в стандартном месте вашей инсталляции или в том месте, которое вы указали в конфигурационном файле PostgreSQL.
Когда речь заходит о журналах, специфичных для пользователей приложений, следует обратить внимание на такие важные журналы PostgreSQL:
Журналы запросов показывают все запросы, которые были сделаны на сервере; вы можете увидеть зарегистрированные запросы, если у вас включен log_statement.
Журналы транзакций — это записи всех событий, происходящих с базой данных; они соответствуют стандарту WAL (write ahead log), который не предназначен для чтения человеком. WAL — это способ хранения записей всех действий, выполняемых с базой данных, и может быть использован для восстановления после аварии. Плагин pg_receivexlog может отображать журналы транзакций, передаваемые вашим сервером PostgreSQL.
Журналы соединений полезны для выявления любых нежелательных подключений к серверу. Вы можете включить log_connections в файле postgresql.conf для фиксации каждой попытки подключения к серверу; log_disconnections позволит вам увидеть всех клиентов, которые отключились от сервера.
Журналы ошибок помогут вам определить, создают ли какие-либо из ваших запросов нежелательные проблемы на сервере; log_in_error_statement управляет уровнем важности регистрации сообщений об ошибках.
Журналы аудита и доступа очень важны с точки зрения администратора. Первые показывают изменения, внесенные в базу данных, а вторые определяют, кто какие запросы делал; их можно включить с помощью конфигурации log_statement или плагина PostgreSQL, например, pgAudit.
Большинство из этих типов журналов находятся в стандартных местах хранения по умолчанию или там, куда вы их определите в файле postgresql.conf. Есть также несколько проектов с открытым исходным кодом, которые я люблю использовать вместе с PostgreSQL для лучшего анализа журналов, например pgBadger.
Просто вести журнал — это еще не все случаи. Вам также нужно подумать о том, как вы будете архивировать или выполнять ротацию журналов. PostgreSQL поддерживает ротацию журналов, о которой пойдет речь в следующем разделе.
Ротация журналов PostgreSQL
PostgreSQL может выполнять ротацию журналов с помощью некоторых базовых параметров конфигурации. Благодаря таким параметрам, как log_rotation_age, log_rotation_size и log_truncate_on_rotation, вы можете легко настроить, в какой момент вы хотите произвести ротацию журналов. Например:
Вы также можете использовать CLI для настройки этой конфигурации.
Как уже говорилось, изучение журналов — необходимый шаг в выявлении проблем, а для этого нужно понимать форматирование журналов. В PostgreSQL вы можете легко определить формат журнала в соответствии с вашими потребностями.
Как форматировать журналы
В PostgreSQL есть возможность использовать формат CSV и сгенерировать CSV файл, который можно использовать для добавления логов в таблице, и в дополнение к всему использовать SQL.
Кроме того, параметр log_line_prefix позволяет форматировать начало каждой строки журнала в файле postgresql.conf или через командную строку. Настраиваемые параметры включают имя приложения, имя пользователя, имя базы данных, удаленный хост, тип бэкенда, идентификатор процесса и т.д. Весь список параметров доступен в документации PostgreSQL. Например:
Приведенный префикс log_line_prefix означает, что журналы будут начинаться со времени в миллисекундах, затем идентификатор процесса, имя пользователя, имя базы данных и имя приложения.
Форматирование журнала, пороговые значения, семплинг, уровни и типы журналов — все это поможет вам в процессе дебаггинга. Но в идеале вам нужен инструмент, который позволяет агрегировать и анализировать все эти журналы и просматривать результаты через одну панель, а не заходить на каждый сервер. Одним из таких инструментов является Sematext. Давайте рассмотрим, как вы можете получить преимущества от ведения журналов PostgreSQL с помощью Sematext.
Ведение журналов PostgreSQL с помощью Sematext
Ведение журналов PostgreSQL с помощью Sematext
Sematext Logs — это решение для управления журналами и их мониторинга, которое позволяет вам объединять журналы из различных источников данных вашей инфраструктуры в одном месте для просмотра и анализа.
Sematext обладает функцией автоматического обнаружения сервисов, поэтому вам просто нужно установить агент Sematext на свои серверы, выполнить базовую настройку, и ваши журналы PostgreSQL начнут в него стекаться. Они будут представлены на интуитивно понятной, готовой к использованию информационной панели (дашборд). Вы даже можете легко создать собственный дашборд, настроить оповещения и отправлять их по различным каналам передачи уведомлений, таким как Gmail, Slack или PagerDuty.
Sematext также предлагает такие функции, как обнаружение аномалий, что помогает вам заранее выявлять проблемы, а затем принимать меры для их предотвращения. Для более глубокого понимания вы можете сопоставить журналы PostgreSQL с метриками PostgreSQL, чтобы быстрее обнаружить узкие места. Таким образом, вы получаете вид с высоты птичьего полета на ваши установки PostgreSQL, что облегчает поиск и отладку неисправностей.
Sematext Logs (журналы) являются частью Sematext Cloud (облако), полнофункционального решения для ведения журналов и мониторинга, которое позволяет вам получить возможность обзора и интеграции всей вашей ИТ-среды. Помимо баз данных, оно поддерживает интеграцию с широким спектром инструментов, включая HAProxy, Apache Tomcat, JVM и Kubernetes. Кроме того, вы получаете поддержку деплоя Kubernetes, поэтому вам будет проще контролировать свою установку в среде Kubernetes.
Заключение
Следить за журналами PostgreSQL — важная часть работы по устранению неполадок в базе данных. Понимая, как делаются запросы и выполнятся операторы, а также трафик, соединения, ошибки и другие изменения или события на вашем сервере, вы можете легко докопаться до проблематичных процессов и обнаружить первопричину затруднений с производительностью.
Вы можете отслеживать журналы различными способами, например, используя less или tail для файлов журналов, но это будет сложно сделать, если журналы разбросаны по нескольким файлам и машинам. Вам нужны журналы в одном месте, и такое решение, как Sematext Logs, может помочь вам достичь этого.
В преддверии старта курса «Observability — мониторинг, логирование, трейсинг» хотим порекомендовать два абсолютно бесплатных вебинара от OTUS, регистрация на которые доступна по ссылкам ниже.