ExamFinch.com My Study

Study guide

14.1 Configuring and Leveraging log4j

Practice this exam

SailPoint Certified IdentityIQ Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: The IdentityIQ Engineer Exam

1.1 Exam Format, Official Blueprint, and Study Strategy

2 Chapter 2: Infrastructure, Installation, and Extended Attributes

2.1 IdentityIQ Infrastructure Components 2.2 Installation Steps and Procedures 2.3 Creating Extended Attributes and the Objects That Support Them

3 Chapter 3: Build, Deployment, Patching, Access, and Email

3.1 Ongoing Build and Deployment 3.2 Installing Patches and Performing Upgrades 3.3 Configuring End-User Access 3.4 Email Server Settings and Email Redirection

4 Chapter 4: Lifecycle Manager Configuration, Provisioning Policies, and Workflows

4.1 Configuring Lifecycle Manager 4.2 Identity Provisioning Policies 4.3 Configuring LCM Workflows

5 Chapter 5: Lifecycle Events, QuickLinks, Batch Requests, and Rapid Setup

5.1 Lifecycle Events and Their Workflows 5.2 QuickLinks and QuickLink Populations 5.3 Configuring and Using Batch Requests 5.4 Rapid Setup in Lifecycle Events and Identity Operations

6 Chapter 6: Certification Campaigns and Certification Rules

6.1 Configuring and Scheduling Certification Campaigns 6.2 The Purpose of Common Certification Rules

7 Chapter 7: Policies and Policy Violations

7.1 Configuring and Leveraging Policies 7.2 Responding to Policy Violations

8 Chapter 8: Reporting, Advanced Analytics, and Auditing

8.1 Executing and Leveraging Reports 8.2 Leveraging Advanced Analytics 8.3 Configuring and Using Auditing

9 Chapter 9: Rules, Rule Libraries, and the SailPoint API

9.1 The Purpose and Use of Rule Libraries 9.2 Rule Input and Output Arguments 9.3 Common SailPoint API Objects and Methods

10 Chapter 10: Workflow Development

10.1 Workflow Variables, Transitions, and Step Conditions 10.2 Workflow Steps That Generate Work Items 10.3 The Different Workflow Step Usages 10.4 Leveraging Sub-Workflows

11 Chapter 11: Email Templates, Branding, and Localization

11.1 Customizing and Using Email Templates 11.2 Branding the SailPoint User Interface 11.3 Localizing the SailPoint UI

12 Chapter 12: Application Definitions, Connector Settings, and Rapid Setup Aggregation

12.1 Configuring Application Definitions 12.2 Configuring Common Connector Settings 12.3 Configuring Rapid Setup Aggregation Settings

13 Chapter 13: Data-Loading Tasks and Application and Connector Rules

13.1 Scheduling Tasks for Data Loading and Processing 13.2 Common Application Rule Types 13.3 Common Connector Rule Types

14 Chapter 14: Debugging with log4j, Syslog, and the IdentityIQ Console

14.1 Configuring and Leveraging log4j 14.2 Configuring and Leveraging Syslog 14.3 Leveraging the IdentityIQ Console for Debugging

15 Chapter 15: Debug Pages and the Administrator Console

15.1 Leveraging the Debug Pages for Debugging 15.2 Leveraging the Administrator Console for Debugging

16 Chapter 16: Role Model and Identity Attribute Mappings

16.1 Default Role Models and Role Types 16.2 Configuring Roles and Role Options 16.3 Configuring Identity Attribute Mappings

17 Chapter 17: Data Objects, Relationships, and Group Types

17.1 Common IdentityIQ Data Objects 17.2 Relationships Between Common Data Object Models 17.3 The Difference Between Group Types

14.1 Configuring and Leveraging log4j

Key Takeaways Explain This Topic AI

IdentityIQ logging is configured in WEB-INF/classes/log4j2.properties using Log4j 2 logger, level, and appender definitions.

A logger is declared with a pair of lines, logger.<id>.name and logger.<id>.level, and the most specific matching logger wins.

The console logConfig command reloads log4j2.properties, and the Debug pages' Logging page shows or changes the path to the properties file.

Rules should log through a named logger at debug level so logging can be turned on and off per rule without code changes.

Only WARN, ERROR, and FATAL events are also stored in the database Syslog table; debug output goes only to the log appenders.

Last updated: September 2026

Configuring and Leveraging log4j

Objective 6.1 is configure and leverage log4j . Most IdentityIQ troubleshooting starts by making the right component talk more, so you need to know where logging is configured, how to change it safely, and how to read what comes back.

Where Logging Is Configured

IdentityIQ uses Apache Log4j 2 . Its configuration file is log4j2.properties , in identityiq_home/WEB-INF/classes . SailPoint's own instructions refer to it, for example: "add these entries to the log4j2.properties file" to troubleshoot Rapid Setup.

The file has three kinds of definitions:

  • Concept Meaning
  • Logger A named category, usually a Java package or class such as sailpoint.api.Aggregator , with a level

Level TRACE, DEBUG, INFO, WARN, ERROR, FATAL. A logger emits events at its level and above.

Appender Where events go: the console or stdout (captured by the application server log, such as Tomcat's), a rolling file, or other targets

Loggers inherit from their parent package and ultimately from the root logger . The most specific logger wins, so you can set sailpoint to WARN and one class to DEBUG.

Turning On Debug Logging

The documentation's Rapid Setup example shows the Log4j 2 properties syntax, a pair of lines per logger: logger.rapidsetup.name=sailpoint.rapidsetup

  • logger.rapidsetup.level=debug
  • logger.rapidsetuplib.name=sailpoint.workflow.RapidSetupLibrary
  • logger.rapidsetuplib.level=debug

The part after logger. (for example, rapidsetup ) is just an identifier that ties the two lines together. It must be unique in the file.

Categories Worth Knowing

  • Problem Useful logger
  • Aggregation and correlation sailpoint.api.Aggregator and the connector's package
  • Identity refresh sailpoint.api.Identitizer
  • Workflow execution sailpoint.api.Workflower
  • Plan compilation and provisioning sailpoint.provisioning.PlanCompiler , sailpoint.api.Provisioner
  • Rapid Setup sailpoint.rapidsetup , sailpoint.workflow.RapidSetupLibrary
  • Your own rules Your own named logger (below)

Specific tasks sometimes need their own entries. The documentation, for example, tells you to add a logger entry to enable logging for the Application Builder task.

Appenders and Output

The appenders in log4j2.properties decide where messages go. A console (stdout) appender sends output to the application server's own log. A file appender writes to a separate IdentityIQ log file that can rotate by size or date. Each logger can point to one or more appenders, and output also flows up to the root logger's appenders unless additivity is turned off. When you cannot find your debug output, check three things: that the logger's level is low enough, that it reaches an appender , and that you are reading the log file on the host that actually ran the work.

A useful pattern is a dedicated file appender for a project's custom rules. Custom output then does not get lost among product messages, and it can be collected separately.

Reloading Without a Restart

Console: the logConfig command reloads the Log4j configuration from log4j2.properties into the running instance.

Debug pages: the Logging page shows, and can change, the path to the Log4j properties file the server uses.

Import files: an import file's ImportAction can include logConfig (section 3.1).

In a cluster , each host has its own copy of log4j2.properties and reloads independently. Change and reload it on the host that runs the work you are debugging, or on all hosts.

Logging From Rules and Workflows

Every rule gets a log variable (section 9.2). For long-lived code, use a named logger so the rule's output can be switched on or off in log4j2.properties alone: import org.apache.commons.logging.Log;

  • import org.apache.commons.logging.LogFactory;
  • Log rlog = LogFactory.getLog("acme.rules.HRCorrelation");
  • if (rlog.isDebugEnabled()) {
  • rlog.debug("Correlating account " + account.getIdentity());
  • } logger.acmehr.name=acme.rules.HRCorrelation
  • logger.acmehr.level=debug

In workflows, the Standard Workflow Handler's log method writes to Log4j with a level, and the trace variable prints step-by-step execution (section 10.3). The documentation suggests println only for temporary debugging, removed before production.

Good Practice

Debug is expensive. Verbose logging on aggregation or refresh classes can slow tasks and fill disks. Turn it on for the shortest time on the host doing the work, then set it back.

Guard expensive messages with isDebugEnabled() .

Never log secrets , such as passwords, tokens, or full ResourceObjects with sensitive attributes.

Keep log4j2.properties in the build (section 3.1). Each environment may need different levels and appenders.

Know what reaches the database. Only WARN, ERROR, and FATAL events are stored in the Syslog table (section 14.2). DEBUG and INFO go only to the appenders.

Worked Troubleshooting Example

Accounts from a new JDBC application arrive, but several correlate to the wrong identities.

Add DEBUG loggers for sailpoint.api.Aggregator and the custom correlation rule's named logger.

Run logConfig in the console on the task host.

Re-aggregate a small test set, for example by filtering the source.

Read the log: which correlation key and value did the rule return for each account?

Fix the rule, set the loggers back to WARN, and run logConfig again.