Hitachi

JP1 Version 12 JP1/Base User's Guide


2.4.4 Types of log files that can be monitored

Log files in a variety of formats can be monitored by log file trapping. Check which file formats are supported, and specify the appropriate log file format in the action definition file for log file trapping.

The log file formats supported for monitoring are described below. For the general procedure for checking the log file format, see 11.1.1 Checking the format of application program log files.

Log files in the following format can be monitored:

You can also monitor files with symbolic links by using log file trapping in UNIX. However, you can change the file destination only for log files in SEQ2 format.

Organization of this subsection

(1) Type of log files that can be monitored (SEQ)

Sequential file (SEQ)

A log file that is written to continuously or, when it reaches a certain size, is replaced with a new log file with a different file name.

In the action definition file for log file trapping, specify SEQ.

Log files of any size can be monitored.

The following figure illustrates the behavior of a sequential file (SEQ).

Figure 2‒14: Behavior of a sequential file (SEQ)

[Figure]

(2) Type of log files that can be monitored (SEQ2)

Sequential file (SEQ2)
  • In Windows:

    A log file that is renamed, and then replaced by a new log file created with the same name as the original file.

  • In UNIX:

    A log file that is renamed or deleted, and then replaced by a new log file created with the same name as the original file.

In the action definition file for log file trapping, specify SEQ2.

Log files of any size can be monitored.

The following figure illustrates the behavior of a sequential file (SEQ2).

Figure 2‒15: Behavior of a sequential file (SEQ2)

[Figure]

(3) Type of log files that can be monitored (SEQ3)

Sequential file (SEQ3)
  • Windows only

    Upon reaching a certain size, the file is deleted and log data is written to a new file with the same name as the deleted file.

    To monitor this type of log file in Windows, specify SEQ3 in the action definition file for log file trapping. You cannot monitor this type of sequential file by specifying SEQ2 in the action definition file for log file trapping in Windows.

    Log files of any size can be monitored.

The following figure illustrates the behavior of a sequential file (SEQ3).

Figure 2‒16: Behavior of a sequential file (SEQ3)

[Figure]

(4) Type of log files that can be monitored (WRAP1)

Wrap-around file (WRAP1)

When the file reaches a certain size, data is wrapped around from the end, overwriting the existing data from the top of the file.

In the action definition file for log file trapping, specify WRAP1.

Log files that are smaller than 2 gigabytes can be monitored.

Free disk space that is at least as large as the file to be monitored is required.

The following figure illustrates the behavior of a wrap-around file (WRAP1).

Figure 2‒17: Behavior of a wrap-around file (WRAP1)

[Figure]

(5) Type of log files that can be monitored (WRAP2)

Wrap-around file (WRAP2)

When the file reaches a certain size, data is wrapped around from the end, all the data is deleted and the new log data is again written from the top of the file.

In the action definition file for log file trapping, specify WRAP2.

Log files of any size can be monitored.

The following figure illustrates the behavior of a wrap-around file (WRAP2).

Figure 2‒18: Behavior of a wrap-around file (WRAP2)

[Figure]

(6) Type of log files that can be monitored (HTRACE)

Multi-process trace file (HTRACE)

Hitachi middleware-products, such as Cosminexus, use this log file format. The log file format is a group of fixed-size trace files that are shared by multiple processes as memory-mapped files.

In the action definition file for log file trapping, specify HTRACE.

Log data is written to a multi-process trace file in the same way as for a wrap-around file (WRAP1). For a multi-process trace file (HTRACE), when the file size reaches a certain upper limit (the maximum limit is 16 megabytes), data is wrapped around and written from the beginning of the file. The file modification time is not updated when data is written to the file. To determine whether the log file to be monitored is a multi-process trace file, see the relevant program manual.

The following figure illustrates the behavior of a multi-process trace file (HTRACE).

Figure 2‒19: Behavior of a multi-process trace file (HTRACE)

[Figure]

(7) Type of log files that can be monitored (UPD)

UPD type log files (UPD)

Use this approach to monitor log files whose file name contains values (such as dates) that change from time to time. You can account for the unknown value by using wildcards.

When the log file trap starts, the log-file trap management service (or daemon) monitors the most recently updated log file of those that match the wildcard pattern. While the trap is active, the service (or daemon) keeps switching its monitoring target to the file matching the wildcard pattern that has the most recent update time of those created during the monitoring process. For this process to work, the update time must be updated each time data is written to the file.

The log-file trap management service (or daemon) can monitor files that are written to continuously, and files that are replaced with a new log file with a different name when they reach a certain size (sequential files).

In the action definition file for log file trapping, specify UPD.

Log files of any size can be monitored.

The following figure illustrates the behavior of a UPD type log file.

Figure 2‒20: Behavior of a UPD type log file

[Figure]

  1. When executing the start command (jevlogstart), include wildcards in the name of the monitoring target file.

  2. Files whose file name matches the wildcard pattern become potential monitoring targets for the log-file trap management service (or daemon), to a maximum of 1,000 files.

    If more than 1,000 files match the wildcard pattern, the log file trap fails to start. If the number of files surpasses this limit while monitoring is in progress, JP1/Base outputs an error message and stops the log file trap.

  3. At startup, the log file trap identifies the log file with the most recent update time from among the potential monitoring targets, and starts monitoring the file.

  4. The log file trap reviews the monitoring target file in each monitoring interval (1 second), checking whether a new file has been created.

  5. If a new file has been created, the service (or daemon) finishes processing any backlog before switching its monitoring target to the new log file.

    The monitoring target will only switch if a new log file is created, not if an existing file is updated. If there are several new files, the service (or daemon) determines which file was updated most recently and designates that file as the monitoring target.