Hitachi

JP1 Version 13 JP1/Integrated Management 3 - Manager Administration Guide


1.3.1 Managing the IM database capacity

Organization of this subsection

(1) Managing IM database Capacity

The integrated monitoring databases used by JP1/IM are designed not to increase invalid areas, even during continued use. As long as the required capacity is secured, there is no need to check the database during operations.

Because data is written to the database created at setup, you basically do not have to consider capacity increase if the capacity is properly estimated at setup.

For details about increasing the log file size, see 1.3.2 Managing the log file size.

When the number of JP1 events exceeds the storage limit of the integrated monitoring database, JP1 events are automatically deleted. Therefore, you need to output and save JP1 event information regularly to prevent data loss.

To manage the disk capacity using the output-and-save operation:

  1. View the information related to output-and-save operations.

    Executing the jcoevtreport -showsv command displays the information related to output-and-save operations. Based on this information, estimate the output-and-save frequency and the free space required for outputting and saving information.

    The following table shows the items that are displayed.

    Table 1‒15: Displayed items

    Displayed item

    Description

    Percentage of events that have not been saved

    Shows the percentage of JP1 events within the integrated monitoring database that have not been output or saved (the ratio relative to the maximum number of entries in the integrated monitoring database).

    Size of events that are have not been saved

    Shows the data size of JP1 events within the integrated monitoring database that have not been output or saved (in megabytes).

    The size displayed is the size within the integrated monitoring database. CSV output will require 1.2 times the size of the displayed events that have not been output.

    Settings for deletion warning notification

    Shows the value set as the deletion warning notification level.

    If the deletion warning notification is set to OFF, a hyphen (-) is displayed.

  2. Output and save the events that have not been output.

    Executing the jcoevtreport -save command outputs to a CSV file all JP1 events that have not been output and saved.

For details about the jcoevtreport command, see jcoevtreport in Chapter 1. Commands in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

If too many JP1 events occurred and regular output-and-save operations were too late for them, you can issue a deletion warning notification event. A deletion warning notification event reports when the percentage of JP1 events that have not been output and saved exceeds the deletion warning notification level.

To set up a deletion warning notification:

  1. Enable the issuance of deletion warning notification events.

    Executing the jcoimdef -dbntc ON command enables the function that issues a deletion warning notification event when the percentage of JP1 events not output and saved within the integrated monitoring database exceeds the deletion warning notification level. This percentage is the ratio relative to the maximum number of entries in the integrated monitoring database. The default for the deletion warning notification event is OFF.

  2. Specify a deletion warning notification level.

    Executing the jcoimdef -dbntcpos 70 command sets the percentage of JP1 events for issuing a deletion warning notification event to 70%.

For details about the jcoimdef command, see jcoimdef in Chapter 1. Commands in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

For details about when the IM Configuration Management database is used, see 1.2.1(5) Reorganization of the IM databases.

(2) Intelligent Consolidated Management Database Capacity Management

Running out of PostgreSQL disk space as an Intelligent Integrated Management Database can cause the following problems:

#

In the Intelligent Integration Management Database (PostgreSQL), disk access when trend data is written is reduced as much as possible so that database processing can be performed at high speed, and the contents of update operations (transactions) to the database are written to a log called WAL (write-ahead log). I'm going to write it down to disk in units that are organized to some extent. Depending on when the disk is full, it may fail to write to this WAL, or the WAL file itself may be corrupted.

In order to prevent such problems, it is necessary to operate to monitor the free space of the disk.

If the number of data items is reached the upper limit of registration, only for data that is registered frequently in the database, the old data judging from registration date and time will be deleted and new data will be registered.

Monitor the free disk space in "JP1/IM - Directories monitored by Manager" shown in the following table.

Areas to be monitored

Monitored directory in JP1/IM - Manager

Database cluster area

Where to store data files in the Intelligent Integrated Management Database#1

TABLESPACE area

Temporary space in the database

WAL storage

Database log storage

Storage space for server logs

Individual logs of operational commands

Where to store individual logs of operational commands#1

Trend Data Management Service Log

Where to store trend data management service#1

Logging OS

Windows event log

System-drive:\Windows\System32\winevt\Logs

syslog

/var/log#2

System log (syslog)

/var/log#2

#1

See 2.7.1(1)(d) Where related files are stored in the JP1/Integrated Management 3 - Manager Overview and System Design Guide.

#2

For Linux 7 and later, the storage destination can be changed by "/etc/syslog.conf" or "/etc/rsyslog.conf". When the storage destination is changed, set the destination directory as the monitoring target.

Note:

Because the database is reorganized automatically, there is no need for user reorganization.

If you are using per-user disk quotas, monitor disk usage and usage limits for users who start trend data management DB. In addition to being able to cope with the lack of disk space with plenty of time, it is recommended that you use a guide in advance, for example, to deal with the available disk space when it interrupts 20% of the total.

Alevere trend data managed by the Intelligent Integrated Management Database is deleted after a certain period of time (the default retention period is 32 days), there is a risk that the disk will be depleted by inserting a large amount of trend data into the Intelligent Integrated Management Database before the trend data is deleted in the following cases:

Consider planning to deal with disk shortages in advance, such as assuming a disk full state based on the amount of disk usage before and after operation after a certain period of time (1 day, 1 week, etc.).

(a) Recovering from Disk Full State

Here are the steps to recover when the disk is full:

  1. Verify that the service is stopped.

    If the event that the disk becomes full, it is necessary to take action once the request from the monitoring agent is not accepted, so make sure that the service of the intelligent integrated management database# is stopped. Also, please stop the trend data management service.

    #

    If the service is in a disk full state, the service may have been terminated, but if the service has not stopped, stop it.

  2. Free up disk space

    Remove unnecessary files and add disk space (OS functions such as LVM) to free up enough disk space.

  3. Start the service.

    Start intelligent integrated management database services and trend data management services.

If the above steps do not recover, delete and rebuild the Intelligent Integrated Management database. When backing up regularly, you can recover from the backup and # to the status at the time of the last backup.

#

Basically, if the disk is full, the recovery of the trend data collected so much cannot be guaranteed.