Logs in Azure Database for PostgreSQL - Single Server

APPLIES TO: Azure Database for PostgreSQL - Single Server


Azure Database for PostgreSQL - Single Server is on the retirement path. We strongly recommend that you upgrade to Azure Database for PostgreSQL - Flexible Server. For more information about migrating to Azure Database for PostgreSQL - Flexible Server, see What's happening to Azure Database for PostgreSQL Single Server?.

Azure Database for PostgreSQL allows you to configure and access Postgres's standard logs. The logs can be used to identify, troubleshoot, and repair configuration errors and suboptimal performance. Logging information you can configure and access includes errors, query information, autovacuum records, connections, and checkpoints. (Access to transaction logs is not available).

Audit logging is made available through a PostgreSQL extension, pgaudit. To learn more, visit the auditing concepts article.

Configure logging

You can configure Postgres standard logging on your server using the logging server parameters. On each Azure Database for PostgreSQL server, log_checkpoints and log_connections are on by default. There are additional parameters you can adjust to suit your logging needs:

Azure Database for PostgreSQL - Logging parameters

To learn more about Postgres log parameters, visit the When To Log and What To Log sections of the Postgres documentation. Most, but not all, Postgres logging parameters are available to configure in Azure Database for PostgreSQL.

To learn how to configure parameters in Azure Database for PostgreSQL, see the portal documentation or the CLI documentation.


Configuring a high volume of logs, for example statement logging, can add significant performance overhead.

Access .log files

The default log format in Azure Database for PostgreSQL is .log. A sample line from this log looks like:

2019-10-14 17:00:03 UTC-5d773cc3.3c-LOG: connection received: host= port=34331 pid=16216

Azure Database for PostgreSQL provides a short-term storage location for the .log files. A new file begins every 1 hour or 100 MB, whichever comes first. Logs are appended to the current file as they are emitted from Postgres.

You can set the retention period for this short-term log storage using the log_retention_period parameter. The default value is 3 days; the maximum value is 7 days. The short-term storage location can hold up to 1 GB of log files. After 1 GB, the oldest files, regardless of retention period, will be deleted to make room for new logs.

For longer-term retention of logs and log analysis, you can download the .log files and move them to a third-party service. You can download the files using the Azure portal, Azure CLI. Alternatively, you can configure Azure Monitor diagnostic settings which automatically emits your logs (in JSON format) to longer-term locations. Learn more about this option in the section below.

You can stop generating .log files by setting the parameter logging_collector to OFF. Turning off .log file generation is recommended if you are using Azure Monitor diagnostic settings. This configuration will reduce the performance impact of additional logging.


Restart the server to apply this change.

Resource logs

Azure Database for PostgreSQL is integrated with Azure Monitor diagnostic settings. Diagnostic settings allows you to send your Postgres logs in JSON format to Azure Monitor Logs for analytics and alerting, Event Hubs for streaming, and Azure Storage for archiving.


This diagnostic feature for server logs is only available in the General Purpose and Memory Optimized pricing tiers.

Configure diagnostic settings

You can enable diagnostic settings for your Postgres server using the Azure portal, CLI, REST API, and PowerShell. The log category to select is PostgreSQLLogs. (There are other logs you can configure if you are using Query Store.)

To enable resource logs using the Azure portal:

  1. In the portal, go to Diagnostic Settings in the navigation menu of your Postgres server.
  2. Select Add Diagnostic Setting.
  3. Name this setting.
  4. Select your preferred endpoint (storage account, event hub, log analytics).
  5. Select the log type PostgreSQL Server Logs.
  6. Save your setting.

To enable resource logs using PowerShell, CLI, or REST API, visit the diagnostic settings article.

Access resource logs

The way you access the logs depends on which endpoint you choose. For Azure Storage, see the logs storage account article. For Event Hubs, see the stream Azure logs article.

For Azure Monitor Logs, logs are sent to the workspace you selected. The Postgres logs use the AzureDiagnostics collection mode, so they can be queried from the AzureDiagnostics table. The fields in the table are described below. Learn more about querying and alerting in the Azure Monitor Logs query overview.

The following are queries you can try to get started. You can configure alerts based on queries.

Search for all Postgres logs for a particular server in the last day

| where LogicalServerName_s == "myservername"
| where Category == "PostgreSQLLogs"
| where TimeGenerated > ago(1d) 

Search for all non-localhost connection attempts

| where Message contains "connection received" and Message !contains "host="
| where Category == "PostgreSQLLogs" and TimeGenerated > ago(6h)

The query above will show results over the last 6 hours for any Postgres server logging in this workspace.

Log format

The following table describes the fields for the PostgreSQLLogs type. Depending on the output endpoint you choose, the fields included and the order in which they appear may vary.

Field Description
TenantId Your tenant ID
SourceSystem Azure
TimeGenerated [UTC] Time stamp when the log was recorded in UTC
Type Type of the log. Always AzureDiagnostics
SubscriptionId GUID for the subscription that the server belongs to
ResourceGroup Name of the resource group the server belongs to
ResourceProvider Name of the resource provider. Always MICROSOFT.DBFORPOSTGRESQL
ResourceType Servers
ResourceId Resource URI
Resource Name of the server
Category PostgreSQLLogs
OperationName LogEvent
errorLevel Logging level, example: LOG, ERROR, NOTICE
Message Primary log message
Domain Server version, example: postgres-10
Detail Secondary log message (if applicable)
ColumnName Name of the column (if applicable)
SchemaName Name of the schema (if applicable)
DatatypeName Name of the datatype (if applicable)
LogicalServerName Name of the server
_ResourceId Resource URI
Prefix Log line's prefix

Next steps