Back to the IdentityIQ 8.0 overview: What’s new in IdentityIQ 8.0
Version 8.0 of IdentityIQ uses version 2.11.1 of Log4j: Log4j2 This change adds new logging capabilities (specifically, change listening), and also means that there are changes to the the logging configuration file name, and to logging syntax.
Previously, the log4j configuration file was WEB-INF/classes/log4j.properties. This log4j.properties file is no longer shipped, and will not be referenced if present.
In IdentityIQ 8.0, the log4j2 configuration file is WEB-INF/classes/log4j2.properties. (Note the digit 2 in the filename.)
Log4j2's syntax is different from log4j's. Previously in v1 in log4j.properties, the syntax was:
log4j.logger.com.acme.example=debug
In version 2 in log4j2.properties, you now declare using this syntax:
logger.acmeExample.name=com.acme.example
logger.acmeExample.level=debug
Notice the differences:
In IdentityIQ 8.0, the previous log4j.properties have been fully converted into the new syntax in the log4j2.properties file. You can refer to Apache's Log4j – Configuring Log4j 2 - Apache Log4j 2 document for a full description of log4j2 configuration.
The log4j2.properties file that is shipped with IdentityIQ version 8.0 includes statements for SailPoint loggers.Some are enabled by default and others provide commented-out statements; in these cases you can simply un-comment the statements that provides the logging you want. Here are some examples:
Hibernate Example
logger.orgHibernate.name=org.hibernate
logger.orgHibernate.level=trace
Aggregator Example
logger.aggregator.name=sailpoint.api.Aggregator
logger.aggregator.level=trace
Sailpoint Connector Example
logger.sp_connectorName.name=sailpoint.connector.ConnectorName
logger.sp_connectorName.level=debug
OpenConnector Example for Okta
logger.okta.name=openconnector.connector.Okta
logger.okta.level=trace
As with previous releases, with version 8.0 it is recommended that classes which perform simple logging use org.apache.commons.logging. For example:
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
…
private static Log log = LogFactory.getLog(MyClass.class);
…
log.info("printing message 1");
Listening for, and automatically enforcing, changes to the logging configuration is a new feature of log4j2. IdentityIQ's default log4j2.properties declares a monitorInterval of 20 seconds, so changes will be enforced within 20 seconds of saving changes to log4j2.properties.
You can turn off change listening by setting the property monitorInterval to 0 in log4j2.properties.
As part of your upgrade to IdentityIQ version 8.0, you must edit the new log4j2.properties file to reflect any customizations you may have made to your prior version of IdentityIQ. The sample logging statements in the log4j2.properties file can help you with the log4j2 logging syntax.
Also, any rules that that use log4j logging may require updating, and verification that they are importing correctly. If there are tools, plugins, or other custom code written that used log4j v1 APIs (typically to modify logging configurations), those will need to be rewritten to use the new log4j v2 APIs in order to work for IdentityIQ 8.0. For more information, refer to the section on Converting to the Log4j 2 API in Migrating from Log4j 1.x
NOTE: There is some support for backward-compatibility with basic log4j v1 APIs, due to the inclusion of the log4j-1.2-api-2.11.2.jar. But, as mentioned earlier, the apache commons-logging should be used for the basic logging calls.
For more information on Log4j2, refer to these Apache documents:
For more information on logging in IdentityIQ, see . Although this document is written for the earlier version of log4j, it includes general guidance about logging that is useful regardless of the version of log4j you are using.
Are there any plans to enhance the SSB to include identifying where log4j v1 calls exist when upgrading to IdentityIQ 8.0?
I have added a small note to the doc, Chris:
NOTE: There is some support for backward-compatibility with basic log4j v1 APIs, due to the inclusion of the log4j-1.2-api-2.11.2.jar. But, as mentioned earlier, the apache commons-logging should be used for the basic logging calls.
But that will only help for cases when just very simple logging calls were being done with log4j v1.
I appreciate the update. However, converting from the old log4j v1 to v2 would be ideal in many engagements where log4j Loggers were used. The asynchronous file I/O in log4j v2 is really nice. As such, would it be possible to update the SSB to have some kind of check for the v1 imports and method calls that exist in Rules, Workflows, etc.? That way we can provide customers with a list of items that can be updated to take advantage of the features afforded by log4j v2.
According to https://logging.apache.org/log4j/2.x/manual/migration.html , we can look for the v1 package "org.apache.log4j" as opposed to the v2 package "org.apache.logging.log4j". I'm probably just going to write a custom Ant task (see https://ant.apache.org/manual/develop.html) to scan all configurations for the v1 package and fail the build if it finds any.
Thanks for that really helpful article.
We recently upgrade to 8.0p1 and it seems the that UI setting "Level at which syslog events are stored" is not honored anymore.
We suspect that this is now solely adjustable via log4j2.properties and the UI setting is obsolete in 8.0+.
Can you please confirm or advice how to set the log level for syslog events via UI in 8.0+?
Thanks,
Daniel
There is an excellent overview of log4j here: https://community.sailpoint.com/t5/Working-With-Support/log4j-Support-Guide/ta-p/137421
Is there a plan to deliver a similar document with the same amount of detail for log4j2? The information about how to configure log4j2 seems to be very sparse here, more help on how to correctly configure logging for version 8.0+ of SailPoint IIQ would be appreciated, rather than having to rely on trial and error to see if we have set the configuration up correctly or not.
Agree the same. Not sure how to convert log4j.properties of 7.3p2 to log4j2.properties
Fully agreed!
There is also another excellent article as part of the BSDG series which is not updated yet:
https://community.sailpoint.com/t5/Technical-White-Papers/BSDG-2-Using-Apache-Log4J-in-Bean-Shell/ta...
Even though an update version is promised since a very long time.
Please kindly provide some more details regarding log4j2 in the same manner this was done related to log4j.
Thank you very much.
We upgrade from IIQ 7.3 to 8.1. Now we are not getting any logging info being written in the sailpoint.log file.
The last entry was.
WARN ServerThread sailpoint.server.FileChangeMonitor:114 - Monitored file D:/apache-tomcat-9.0/webapps/identityiq/WEB-INF/classes/log4j.properties no longer exists