Within the directory structure described in Data Collector Log File Organization, log files have the following naming convention:

For example, an EMC Isilon probe from checkinstall would result in a file name similar to:

Some collectors may have a period of time when they are not processing a specific subsystem. For those periods, logging will occur in an aggregate log file similar to:

Examples of vendor.product folder names within this directory structure include:

Additionally, each Java Virtual Machine (JVM) creates its own logging file(s) when starting up. This is necessary because multiple processes logging to the same file could overwrite each other’s log messages. These log files can be found in the framework sub-directory, as described in Data Collector Log File Organization. See also, Checkinstall Log.

Throughout the Hitachi Storage Viewer life cycle, some collectors have been upgraded to include new functionality and new Data Collectors have been designed with an improved architecture. The log file naming convention depends on the generation of the Data Collector that you are using. You do not need to know the generation of the Data Collector to find relevant log files.

When running a scheduled Data Collector the following log files are created, depending on the generation of the Data Collector. For technical reasons, older-generation collectors use framework/#META or EVENT_ID and newer-generation collectors share a single file named with the main collector ID, for example, framework/#<policyID>.

Several log file names include a specific ID. This ID can be found in a System Administration report, Data Collection Schedule Summary. See also, Find the Event/Meta Collector ID.

The checkinstall process produces its own log file, but in most cases, there is very little to report in this log.

For example, the checkinstall creates: