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:
-
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.
-
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:
-
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.
-
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:
-
Cannot write, browse, or delete trend data
-
Forcibly terminate database
-
Corruption of trend data#
- #
-
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:
-
Set a longer retention period for trend data
-
Extremely large number of monitored or samples
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:
-
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.
-
Free up disk space
Remove unnecessary files and add disk space (OS functions such as LVM) to free up enough disk space.
-
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.