The log_alert_* tables store pg_log errors and warnings.
There are three log_alert tables, all having the same columns:
- log_alert_now is an external table whose data files are stored in $MASTER_DATA_DIRECTORY/gpperfmon/data. Current pg_log errors and warnings data is stored in log_alert_now during the period between data collection from the Command Center agents and automatic commitment to the log_alert_history table.
- log_alert_tail is an external table whose data files are stored in $MASTER_DATA_DIRECTORY/gpperfmon/data. This is a transitional table for query workload data that has been cleared from log_alert_now but has not yet been committed to log_alert_history. It typically only contains a few minutes worth of data.
- log_alert_history is a regular table that stores historical database-wide errors and warnings data. It is pre-partitioned into monthly partitions. Partitions are automatically added in two month increments as needed. Administrators must drop old partitions for the months that are no longer needed.
|logtime||timestamp with time zone||Timestamp for this log|
|loguser||text||User of the query|
|logdatabase||text||The accessed database|
|loghost||text||Host name or ip address|
|logsessiontime||timestamp with time zone||Session timestamp|
|logfile||text||Source code file|
|logline||text||Source code line|
Log Processing and Rotation
The Greenplum Database system logger writes alert logs in the $MASTER_DATA_DIRECTORY/gpperfmon/logs directory.
The agent process (gpmmon) performs the following steps to consolidate log files and load them into the gpperfmon database:
- Gathers all of the gpdb-alert-* files in the logs directory (except the latest, which the syslogger has open and is writing to) into a single file, alert_log_stage.
- Loads the alert_log_stage file into the log_alert_history table in the gpperfmon database.
- Truncates the alert_log_stage file.
- Removes all of the gpdb-alert-* files, except the latest.
The syslogger rotates the alert log every 24 hours or when the current log file reaches or exceeds 1MB. A rotated log file can exceed 1MB if a single error message contains a large SQL statement or a large stack trace. Also, the syslogger processes error messages in chunks, with a separate chunk for each logging process. The size of a chunk is OS-dependent; on Red Hat Enterprise Linux, for example, it is 4096 bytes. If many Greenplum Database sessions generate error messages at the same time, the log file can grow significantly before its size is checked and log rotation is triggered.