Large complex software systems often have logs for various information that can be useful for debugging, data mining and analysis. When an application or a system crashes often the error is found in such a log. When performance becomes an issue, the logs can often be useful to try and understand what is going on with the system so you can figure out how to react.
IBM Cognos is no different. There are many different types, targets, and levels of Cognos logging. It has the basic things like error reporting and timestamps which can help isolate performance issues, but it also contains a few other things. For instance, it can tell you when reports were run, when users logged on, when changes were made to objects and many other things. Using this data you could start collecting statistics about how your environment is used and keep track of what is happening without resorting to guessing.
The IBM Cognos Administration and Security Guide has some fairly detailed information about how to set up and use the Cognos logging facilities. This documentation is mostly aimed at administrators, but it is useful for planning how to lay out your environment as well, since you have to make more choices about where and how you store the log data.
By default there is only has one Cognos logging target for “File.” This set up has the various Cognos components logging to cogserver.log. This file log is useful for administrators since it can be used with some standard administration tools like “tail” to watch the log as events occur. It is not a very useful format for doing analysis and reporting, however.
The logging configuration in Cognos Configuration can be configured with multiple different targets of various types. In addition to the File type mentioned above, it can be configured to write to the system log, a named windows event log, or a SQL database. Using an SQL database will let you then consume the data using the Cognos tools you're already familiar with and using – Framework Manager, Datasources, and Report and Query Studio. Cognos even provides a sample package for doing reporting against this database. They provide a handful of reports which can be run to start understanding who, how, and when your Cognos environment is being used.
There is quite a wealth of information hidden in these tables. There is some Cognos documentation about what the tables and their data available for reference. Basically the types of events are split out into various tables.
This table is fairly obvious: it captures the log on and log off event for people accessing Cognos. This includes Framework Manager, Cognos Connection, and third party SDK using applications. It also includes “timeout” information for when a session is not explicitly stopped and instead is terminated after a set period of time. From my research, it seems that shutting down Cognos will result in unbalanced logins. This means sessions could have a logon, without a time out or log off.
To enable this table your Content Manager service needs to be set to at least basic logging.
The action table is often ignored by people using the audit tables. It acts as a log for operations performed on Cognos content store objects. This includes making querying for or making changes to objects in the various studios, Cognos Connection, or third party applications. It can tell you which session – which can be tied to a user using a join – performed which type of action (update, add, move, etc) on which objects.
The objects, unfortunately, are listed as a sort of display name. This makes the audit data difficult to use when tracking the history of an object, but easy to use for building simple reports. Another limitation to this table is that operations that affect multiple objects only show one row. For instance, if you select multiple objects' check boxes in Cognos Connection and click delete, you will only get an entry for the first.
Here again, to enable this table your Content Manager service needs to be set to at least basic logging.
Using these tables you can figure out who, when, and which reports are used. This is useful if you want to figure out which reports are taking the most time to run, which reports are most frequently used, or other information such as if your saved output is being used or if runs are being done each time. These pieces of information can be critical in determining how to deal with performance issues in a Cognos environment.
To enable this table your report service needs to be set to at least basic logging.
In a future article we will share with you how some of this data from audit tables can be used in creative ways.
© Envisn, Inc., All rights reserved.