Administrators are concerned about system availability, stability, speed, security, and troubleshooting. In this chapter, some core administrative tasks will be discussed that help in troubleshooting a problem and enabling Cognos content backups. The following topics will be discussed in this chapter:
IBM Cognos BI uses log messages to help administrators diagnose and troubleshoot problems that are faced in the Cognos environment. In other words, it can be used to investigate and diagnose the behavior of the Cognos BI system. Events, errors, warnings, and informative messages are sent to the logging service that redirects the log message data to either a flat file or a remote log server. IBM Cognos BI supports logging to a flat file as well as to a database. Database logging is not just information in the form of log messages, but it includes the mechanism for recording events related to jobs, reports, queries, e-mails, or user logins.
Administrators may determine the logging configuration that is suitable for the environment.
By default, the IBM Cognos BI server is configured to send log messages to a flat file called cogserver.log
. It is stored in the logs
folder in the Cognos installation path. There are many other files in this path. Every file present in this path stores messages and logs for different functionalities of applications.
Log messages can provide information about the Cognos configuration, start and stop activities, completion of processing requests, and also act as an indicator of warnings. Audit logs provide information about a user and report activities.
To prepare for logging, there are three major steps involved: the Planning phase, the Configuration phase, and the Setting up Logging Level phase. Each step is briefly discussed as follows:
cogserver.log
), database, event log
(Windows), syslog
(Unix, Linux), and remote log servers. The targets for logging must be secure in order to avoid tempering. The following screenshot shows the configuration window and the option where we can add new logging resources. The destination of the new resources can be a file, database, event log, or Linux log.The preceding screenshot is from the IBM Cognos Configuration window. The File option is highlighted, and on the right-hand side, all the available options possible for File can be seen.
Here's another example of message logging for the purpose of configuring Cognos BI audit logging. The configuration of a database logging in terms of the connection properties is shown in the following screenshot, where the administrator has configured Oracle database logging:
cogserver.log
file. The logging level must be carefully selected as it also lowers the system's performance. A basic or report level is recommended. The setting of the logging level is inversely proportional to the system's performance. The lower the logging level, the higher the system performance and vice versa.The procedure to alter logging levels is as follows:
Audit reports may be used for capacity planning, licensing conformance, performance monitoring, and to identify unused Cognos BI contents. The following procedure will help to configure Cognos Audit Reports:
The audit model is provided by IBM Cognos BI and is saved in Audit.cpf
upon navigating through c10_location/webcontent/samples/models/Audit/
. The sample audit reports are saved in IBM_Cognos_Audit.zip
upon navigating through c10_location /webcontent/samples/content/
. A data source connection to the logging database is also required prior to running any of the reports extracted from the samples. The preceding ZIP file needs to be placed in <install_path>/deployment
, and then may be imported to Cognos. A Sample
folder containing many reports will be created on successful import. A bundle of reports will be available that may be run as and when required.
Cognos BI takes care of the sensitive information of the user's data model while displaying Cognos error messages on the Cognos Connection. This is done by assigning a unique reference to each error that arises. A sequential number is assigned to an error each day. A very basic error code and a message are displayed to users. However a complete secure error message ID is also displayed along with the timestamp. Cognos administrators may trace down this error to the cogserver.log
file. For example, the error number in the following message is secureErrorID:2013-9-20-10:31:15.343-#2
:
An error has occurred. Please contact your administrator. The complete error has been logged by CAF with SecureErrorID: 2013-9-20-10:31:15.343-#2
The Cognos administrator will have to open the cogserver.log
file using any text editor and search for the error code ID to find the complete error message. Cognos BI also supports user-specific logging.
The procedure is given just after the upcoming table. The following table shows the levels at which various types of information are captured:
Details |
Minimal |
Basic |
Request |
Trace |
Full |
---|---|---|---|---|---|
Logging system and services startup, and shutdown and runtime errors |
✔ |
✔ |
✔ |
✔ |
✔ |
User account logging, runtime usage |
✔ |
✔ |
✔ |
✔ | |
User requests |
✔ |
✔ |
✔ |
✔ | |
Service requests and responses |
✔ |
✔ | |||
Every request to all components including parameter values |
✔ |
✔ | |||
Native queries (queries to Cognos components) |
✔ |
✔ |
Table 1