PingFederate Server

Log4j 2 logging service and configuration

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 servers to use the same logging configuration, manually synchronize the log4j2.xml file across multiple PingFederate servers.
Log levels and verbosity

Log messages are categorized into six log levels:

  1. FATAL

  2. ERROR

  3. WARN

  4. INFO

  5. DEBUG

  6. TRACE

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

For troubleshooting purposes, you can enable console logging or verbose messages.

When you no longer require console logging or verbose messages, turn them off. On Windows, never highlight the console output because it might slow or stop PingFederate from processing requests.

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.

PingFederate activates the changes within half a minute. You don’t need to restart PingFederate.

Fields (and attributes)

You can customize some logs, such as the audit log and the administrative API log, to log additional or less information by modifying their pattern elements. The log4j2.xml file documents available fields inline.

You can configure PingFederate to log user attributes, if they are present, in the audit log, transaction log, and server log. When you require privacy 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 used for troubleshooting and support purposes, to aggregate and analyze log entries tied to the same original request. The tracking ID, %X{trackingid}, can also be added to the configuration for the transaction log, or 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 Common Event Format (CEF). Furthermore, the audit log can also be written in a format 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 might 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. Administrators can adjust the file size and the number of files to be retained in the log4j2.xml configuration file, as needed.

For more information about Log4j 2, see the Log4j 2 open-source project.