The Shibboleth software uses logging facilities derived from the log4j Java package and a library called log4cpp that is modeled after log4j and can be configured in the same way. By default logging is generally done to rolling files, but other approaches can be configured.
see http://logging.apache.org/log4j

ServiceProvider Logging

There are three log files produced by the software itself, plus whatever additional logging your web server or operating system may do. By default, the logging level is INFO and the amount of information is moderate. Experienced users could use the WARN level, while DEBUG is useful during initial installation and testing.
note: on each startup of a new process a (debugging) message is sent to stderror before the logging system has been loaded. You will notice this line in the log that catches stderror for that process (eg Apache error.log for the module). A multi-threaded or hybrid webserver will significantly decrease the output of these messages. (see https://mail.internet2.edu/wws/arc/shibboleth-users/2005-11/msg00244.html about this)

SHIBD Log

The is the main log file that traces the software. Most of the real work is done by shibd and ends up in this file.

The location (usually var/log/shibboleth) and the logging level are usually set by the etc/shibboleth/shibd.logger file. Touching or opening/saving ShibbolethXml is sufficient to reset the logging level or method.

Native Log

This log file is typically only useful if you have problems configuring ShibbolethXml to recognize and protect the content you want or apply the right rules to it. The information in it is produced by the web server module/filter and generally only contains information about how requests are being mapped/treated and low level details about the interactions with shibd.

The location (usually var/log/httpd) and the logging level are usually set by the etc/shibboleth/native.logger file. Touching or opening/saving ShibbolethXml is sufficient to reset the logging level or method.

You probably will need to change the permissions on the var/log/httpd folder so that your web server can write to this directory. If there is no file created when you start the web server, this is probably the reason.

Transaction Log

The transaction log is a special log file created to track information that may be useful if you need to audit who is accessing you site or look up information to cross reference in the other logs. It tracks all sessions as they are created or deleted, and the attribute query operations that succeed or fail.

IdentityProvider Logging

The logging for the Identity Provider can be configured easily in idpXml. It allows to specify a level and a location (file). This configuration will create daily rolling logfiles. Identity Provider logging can also be configured using log4j.
Note that when the IdP webapp fails to load in the servlet container, there will be NO output to the logfiles of the IdP. In that case, you need to take a look in the logfile of the servlet container (see CreateUsefulContainerLogs).

Error Log

The error log's default name is shib-error.log . This is the main logging file of the Identity Provider. The information is produced by the JAVA webapp. This means that this file will not be used until the servlet container actually runs the webapp (the webapp, and its configuration, is loaded on the first access attempt).

Access Log

The error log's default name is shib-access.log . This file tracks all authentication assertions and attribute assertions that succeed or fail. It shows the provider and the principal associated with the assertion. It is comparable to the Transaction log on the Service Provider.

LogLevels

Here's a quick summary of available logLevels, borrowed from the API.
remember: logLevels are inherited, if none is specified the parent's level applies. (and that's also true for the rootLogger!)

level	description
OFF	highest possible rank and is intended to turn off logging
FATAL	very severe error events that will presumably lead the application to abort
ERROR	error events that might still allow the application to continue running
WARN	potentially harmful situations
INFO	informational messages that highlight the progress of the application at coarse-grained level
DEBUG	fine-grained informational events that are most useful to debug an application
(TRACE)	(recently added in log4j v1.2.12)
ALL	lowest possible rank and is intended to turn on all logging

Browser not supported