User App Log Levels

From MicroFocusInternationalWiki
Jump to: navigation, search

Contents

Micro Focus International Wiki  |  Micro Focus Community  |  Knowledge Partner Program  |  KP/Geoffrey Carman  |  User App Log Levels

The NetIQ User Application is a complex product with many disparate moving parts, and a conglomeration of different technologies. Considering all the moving parts it usually works quite well.

When it does not, how do you troubleshoot it? Well, if you are an Identity Manager pro, your first thought should be, show me the trace! Of course, the engine dstrace output is not there for User Application, but it does have a log that is very useful, if you know the correct log levels to enable.

Details on the logging configuration can be found in the "User Application: Administration Guide"

https://www.netiq.com/documentation/idm402/agpro/data/b6iiw3v.html#b6ij1qt


There also is a logging section, that it is referring to the Event Logging of things that can be sent via OpenXDAS to Sentinel at this page:

https://www.netiq.com/documentation/idm402/agpro/data/b2iix14.html

Enabling trace

Log in to the User Application web interface (Often https://server:8443/IDMProv but can differ) as the User App admin account, click on the Administration tab along the top, then the Logging tab along the left side.

DEBUG is usually the best log level for troubleshooting and shows copious details, that make it hard to read.

If you wish the log setting to persist a restart, then click on the Persist settings button at the bottom each time you save the changes.

The logging is inherited, so a parent class enabled, should apply to classes below it as well. So in principle to identify an unknown issue, you could enable DEBUG level tracing at the com.novell and com.sssw levels you should see every message, which would potentially run your disk out of space. But if run for a short time, and turned off while you read the logs looking for the error might help.

Logging Configuration

The Identity Manager user application implements logging by using log4j (http://logging.apache.org/log4j/2.x/), an open-source logging package distributed by The Apache Software Foundation.

The configuration files can be found in the path "[application server]/server/IDMProv/conf" (e.g., "/opt/novell/idm/rbpm/jboss/server/IDMProv/conf") as

jboss-log4j.xml and idmuserapp_logging.xml

See http://logging.apache.org/log4j/2.x/manual/configuration.html for interpreting the configuration file syntax.

Finding the trace file

There are at least three possible web application servers and the settings are slightly different. The location is customizable through the log4j configuration file, and typically is defined there as something like "${jboss.server.log.dir}/server.log"


JBoss

This is usually in a path like: /opt/novell/idm/rbpm/jboss/server/IDMProv/log/server.log

The exact path may vary (the rbpm is there if you did an Integrated installer with 4.x but might not be via a more manual or older install) but that should give a good idea of where to find it.

Websphere

Weblogic

Tomcat

With IDM 4.5 releases and higher, the preferred Web App server platform is Apache Tomcat, and the default location for the log would be: /opt/netiq/idm/apps/tomcat/logs/catalina.out

With later IDM instances, the One SSO Provider (OSP) is added to enable SSO between the various Identity Apps (landing, dash, idmdash, sspr, rra, Access Governance, etc) and its logs are also in the same location.

What can be logged and what cannot be logged

It is important to remember that the User App is a complex product. Some parts can be logged, like actions in workflows (PRD's), and Role/Resource/Entitlement granting and management.

But some parts, execute on the client side, and do not directly happen in the context of the User Application web server and thus cannot be logged the same way. For example, most Form processing happens on the client end. That is, an onload event or onchange event happens in the context of the users browser, not in the User App web server. Thus errors in rendering the form or processing scripts cannot be directly logged. However as always, it is work noting that IDVault queries performed from a form (or the Start Activity Preactivity) can be loggged, at least the User App side of it.

Log Classes

Now we come to crux of the issue. There are at least 48 different classes listed, that could be logged at different levels. What does each log class handle? When should you turn it on? What kind of work would this class troubleshoot for you? Lets see if collectively we can figure out as many as we can.

Here is the list as I copy out of my 4.02 Patch C User Application. (If there are more, feel free to add them.)

JavaDoc

I found an interesting Javadoc for the Extend Director product that has some interesting info about some of these classes.

http://www.novell.com/documentation/extend52/Docs/help/Director/javadoc/overview-summary.html


com.novell

Parent of other Identity Manager user application logs

com.novell.afw.portal.aggregation

From JavaDoc: Provides helpers for the Portlet Aggregation (Portal) System for the Director product.

Messages related to portal page processing

com.novell.afw.portal.persist

Messages related to the persistence of portal data (including portal pages and portlet registrations)

com.novell.afw.portal.portlet

Messages from the portal core portlets and accessory portlets

com.novell.afw.portal.util

Messages from the portal import/export and navigation portlets

com.novell.afw.portlet.consumer

Messages related to portlet rendering

com.novell.afw.portlet.core

Messages related to the core portlet API

com.novell.afw.portlet.persist

Messages related to the persistence of portlet data (including portlet preferences and setting values)

com.novell.afw.portlet.producer

Messages related to the registration and configuration of portlets within the portal

com.novell.afw.portlet.util

Messages related to utility code used by portlets

com.novell.afw.theme

Messages from the theme subsystem

com.novell.afw.util

Messages related to portal utility classes

com.novell.common.auth

com.novell.idm.nrf.persist

This is useful when looking for Code Map refresh debugging to see some details of how it queries the various drivers in the driverset for the entitlementConfiguration object, parses it, and translates that into Entitlements that can be used to assign to Resources. This needs the com.novell.idm.nrf.service class as well as a companion.

com.novell.idm.nrf.service

This is useful when looking for Code Map refresh debugging to see some details of how it queries the various drivers in the driverset for the entitlementConfiguration object, parses it, and translates that into Entitlements that can be used to assign to Resources. This needs the com.novell.idm.nrf.persist class as well as a companion.

com.novell.idm.security.authorization.service

com.novell.pwdmgt.actions

com.novell.pwdmgt.service

com.novell.pwdmgt.soap

com.novell.pwdmgt.util

com.novell.roa.resources

com.novell.soa.af.impl

This is useful when working with Integration Activities to see part of the process. Needs com.novell.soa.ws.impl as a companion. SOA= Service Oriented Architecture, AF seems to be an old name for Workflows. AF=Approval Flow

Messages from the approval flow (provisioning workflow) subsystem

Workflow log activities use this package with a logging leve of "INFO", e.g.,

10:57:38,866 INFO  [STDOUT] INFO  [RBPM] [com.novell.soa.af.impl.LogEvent:logAFEvent] [Workflow_Forwarded] Initiated by System, Process ID: f6e65 ...

com.novell.soa.notification.impl

Used to display emails

com.novell.soa.script

Scripting engine

com.novell.soa.script.impl.lang.es

EcmaScript Engine

com.novell.soa.script.mozilla

Workflow ECMAscript handler

com.novell.soa.ws.impl

This is useful when working with Integration Activities to see part of the process. Needs com.novell.soa.af.impl as a companion. SOA= Service Oriented Architecture, AF seems to be an old name for Workflows, AF=Approval Flow.

com.novell.srvprv.apwa

Messages from the Requests & Approvals web application (actions and tags)

com.novell.srvprv.impl.portlet.core

Messages from the core identity portlets and password portlets

com.novell.srvprv.impl.portlet

com.novell.srvprv.impl.portlet.util

Messages from the identity-related utility portlets

com.novell.srvprv.impl.servlet

Messages from the UI control framework’s ajax servlet and ajax services

com.novell.srvprv.impl.uictrl

Messages from the UI control registry API and approval form rendering

com.novell.srvprv.impl.vdata

Messages from the directory abstraction layer

com.novell.srvprv.impl.vdata.definition

com.novell.srvprv.impl.vdata.model

com.novell.srvprv.spi

Messages from the UI control registry API

com.sssw

When logging forms, recall that most of the form processing happens on the client web browser and thus not a lot can be logged. However, the IDVault query functions are pretty much all AJAX calls and thus there is a component on the User App they talk to, which can be logged.

This parent class is a quick way to get some errors to show up. It would be nice to know exactly which more specific classes are responsible, so as to minimize the amount of logging to read.

From the JavaDoc: These classes come from the SilverStream Director Framework.

com.sssw.fw.cachemgr

com.sssw.fw.core

Messages related to the framework core subsystem

com.sssw.fw.directory

Messages related to the framework directory subsystem

com.sssw.fw.event

Messages related to the framework event subsystem

com.sssw.fw.factory

Messages related to the framework factory subsystem

com.sssw.fw.persist

Messages related to the framework persistence subsystem

com.sssw.fw.resource

From the JavaDoc: Provides an exception that is thrown when an error occurs in a resource set.

Messages related to the framework resource subsystem

com.sssw.fw.security

Messages related to the framework security subsystem

com.sssw.fw.server

Messages related to the framework server subsystem

com.sssw.fw.servlet

Messages related to the framework servlet subsystem

com.sssw.fw.session

Messages related to the framework session subsystem

com.sssw.fw.usermgr

From the JavaDoc: Provides interfaces for working with the User subsystem (user personalization and customization).

Messages related to the framework user subsystem

com.sssw.fw.util

Messages related to the framework utility subsystem

com.sssw.portal.manager

Messages related to the Portal Manager

com.sssw.portal.persist

Messages related to portal persistence