PingFederate uses the Log4j 2 logging service to generate its log files. Configurations are maintained in the log4j2.xml file, located in the <pf_install>/pingfederate/server/default/conf directory.


The log4j2.xml configuration file is individually managed per PingFederate server. This flexibility allows multiple PingFederate nodes to write different level of messages to different destinations.

If you want all PingFederate server to use the same logging configuration, manually synchronize the log4j2.xml file across multiple PingFederate server.

Log levels and verbosity
Log messages are categorized into six log levels:
  1. FATAL
  2. ERROR
  3. WARN
  4. INFO
  5. DEBUG
  6. TRACE

Starting with version 8.2, PingFederate only records messages that are tagged with log level INFO, WARN, ERROR, and FATAL to the server log (and the provisioner log). Messages that are tagged DEBUG (or TRACE) are not recorded to optimize performance. Console logging is also disabled for the same reason.

For troubleshooting purpose, you may adjust the log level to DEBUG in the log4j2.xml file and optionally re-enable console logging.

When debug messages and console logging are no longer required, ensure they are turned off.

For the audit log, the provisioner audit log, and the transaction log, any setting lower than INFO (WARN, ERROR, or FATAL) turns logging off.

For more information, see Enabling debug messages and console logging.

Changes, such as adding a Logger or adjusting log levels, are activated within half a minute. No restart of PingFederate is required.

Fields (and attributes)
Some logs, such as the audit log and the administrative API log, can be customized to log additional (or less) information by modifying their pattern elements. Available fields are documented inline in the log4j2.xml file.

PingFederate can be configured to log user attributes (if they are present) in the audit log, transaction log, and server log. When privacy is required for sensitive user attributes, select the corresponding check boxes under Mask Log Values to mask their values in these logs.

In addition, messages in the audit log and the server log are recorded with a tracking ID, which can be used to identify subsequent, related transactions. The tracking ID can be useful for troubleshooting and support purposes to aggregate and analyze log entries tied to the same original request. The tracking ID (%X{trackingid}) may also be added to the configuration for the transaction log, or be removed from the audit log and the server log by modifying the pattern element for the logs in the log4j2.xml configuration file.
Log formats
The audit log and the provisioner audit log can be written in CEF format. Furthermore, the audit log may also be written in a format that can be used in conjunction with Splunk and the Splunk App for PingFederate. The log4j2.xml file comes preset with configuration samples to ease the setup.
Log destinations
The audit log, the provisioner audit log, the provisioner log, and the server log can be written to databases. PingFederate installation includes setup scripts for various tables (located in the <pf_install>/pingfederate/server/default/conf/log4j/sql-scripts directory) and configuration samples in the log4j2.xml file.
Log rotation
Most PingFederate-generated log files roll over at midnight each day. The system keeps all of the resulting historical log files. Some log files, such as the audit.log file, the audit-event-detail.log file (if enabled), the provisioner-audit.log file (when applicable), and the transaction.log, can become quite large, depending on your production load and settings; you may want to back up or remove older files on a routine basis.
The server.log file is rolled over when it reaches 10 MB. Five old log files are kept before the oldest file is removed. As needed, administrators may adjust the file size and the number of files to be retained in the log4j2.xml configuration file.

For more information about Log4j 2, please refer to the Log4j 2 open-source project (