2.7.2　トレンドデータ管理DB

インテリジェント統合管理データベースにトレンドデータ管理DBを構築すると，管理対象から収集したトレンドデータを，トレンドデータ管理DBで一元管理できます。

〈この項の構成〉

(1)　データベースの構成
(2)　インストールとセットアップ
(3)　トレンドデータの削除

(1)　データベースの構成

インテリジェント統合管理データベースの「2.7.1(1)(a)データベースの構成」を参照してください。

(2)　インストールとセットアップ

インテリジェント統合管理データベースにトレンドデータ管理DBを構築して，トレンドデータを管理します。

インテリジェント統合管理データベース（トレンドデータ管理DB）の構築については，マニュアル「JP1/Integrated Management 3 - Manager 構築ガイド」の「インテリジェント統合管理データベースの構築」を記載している個所を参照してください。

ページの先頭へ

(3)　トレンドデータの削除

(a)　機能概要

トレンドデータ（「時刻,値」の形式）の時刻を起点として，保存期間を過ぎたトレンドデータを，トレンドデータ管理DBから自動で削除する機能です。

保存期間のデフォルトは32日（46080分）です。

保存期間は，インテリジェント統合管理データベースのセットアップコマンド（jimgndbsetup）で，保存期間を変更できます。上限は1096日（3年）です。

ただし，設定変更にはトレンドデータ管理サービスの再起動が必要です。

■動作イメージ

例えば，保存期間が「32日」，削除機能の実行時刻が「2022/01/21 09:05:42.055」の場合，「2022/01/21 09:05:42.055」から過去32日分のトレンドデータ，つまり，「2021/12/20 09:05:42.055」〜「2022/01/21 09:05:42.055」の期間が保存され，この期間以外のトレンドデータは削除されます。

上記の条件の場合に，データベースに格納されている各トレンドデータが削除されるかどうかの例を，次に示します。

データベースに格納されているトレンドデータ	削除されるかどうか
：　：	削除される
2021/12/20 09:05:42.017のデータ	削除される
2021/12/20 09:06:42.017のデータ	削除されない
2021/12/20 09:07:42.017のデータ
：　：
2022/01/21 09:05:42.017のデータ

(b)　保存期間の設定および変更

トレンドデータの保存期間の設定および変更は，jimgndbsetupコマンドで行います。

■保存期間の設定

物理ホスト環境の場合

インテリジェント統合管理データベースセットアップ情報ファイル（jimgndbsetupinfo.conf）の項目「RETENTION」で，保存期間^※を指定します。
クラスタ環境の場合

クラスタ環境インテリジェント統合管理データベースセットアップ情報ファイル（jimgndbclustersetupinfo.conf）の項目「RETENTION」で，保存期間^※を指定します。

注※: 設定した保存期間を過ぎたトレンドデータは，定期的（30分間隔）に削除されます。

項目「RETENTION」の記載例を，次に示します。

# IM GNDATABASE SERVICE - Retention
RETENTION=32

インテリジェント統合管理データベースセットアップ情報ファイル，およびクラスタ環境インテリジェント統合管理データベースセットアップ情報ファイルの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」（2.　定義ファイル）の「インテリジェント統合管理データベースセットアップ情報ファイル（jimgndbsetupinfo.conf）」，および「クラスタ環境インテリジェント統合管理データベースセットアップ情報ファイル（jimgndbclustersetupinfo.conf）」を参照してください。

■jimgndbsetupコマンドの実行

jimgndbsetupコマンドの実行例を，次に示します。

jimgndbsetup -f セットアップ情報ファイル名^※

注※

物理ホスト環境の場合

インテリジェント統合管理データベースセットアップ情報ファイル名
クラスタ環境の場合

クラスタ環境インテリジェント統合管理データベースセットアップ情報ファイル名

jimgndbsetupコマンドの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「jimgndbsetup」（1.　コマンド）を参照してください。

(c)　トレンドデータの自動削除のタイミングについて

トレンドデータの削除は，jimgndbsetupコマンドによる保存期間の設定完了時を起点として，30分ごとに自動実行されます。トレンドデータの保存期間がデフォルト（32日（46080分））の場合，30分ごとに，保存期間が46080分を経過したトレンドデータを削除します。

なお，トレンドデータの自動削除を実行するタイミングで，データベースが停止していた場合は，データベースの起動時に，トレンドデータの自動削除が実行されます。この場合，自動削除処理が完了した30分後に，次の自動削除処理がスケジューリングされます。

また，トレンドデータの削除のタイミングおよび間隔は，ユーザーが変更できません。

トレンドデータの削除の実行予定日時は，jimgndbstatusコマンドで確認できます。

jimgndbstatusコマンドの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「jimgndbstatus」（1.　コマンド）を参照してください。

(d)　削除対象のトレンドデータの保存について

保存期間を過ぎたトレンドデータは，トレンドデータ管理DBから削除されます。保存期間の経過後も利用したいトレンドデータ（時系列データ）が存在する場合は，JP1/IM - Manager（インテリジェント統合管理基盤）の時系列データ取得のAPI^※を使用して，該当するデータを出力および保存します。

時系列データ取得のAPIの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「5.11.2　時系列データ取得」を参照してください。

注※: JP1/IM - Agentの製品プラグインが必要です。JP1/IM - Agentの製品プラグインで実装するトレンド情報取得の時系列データ取得メソッド（__timeSeriesDataGetメソッド）を使用します。

■ ユースケース「月次で削除対象のトレンドデータ（時系列データ）を出力・保存」

次のことを実施します。

時系列データ取得のAPIに指定する，IM管理ノードのSIDおよびメトリックを，事前にリスト化する。

●出力対象のJP1/IM - AgentのSIDの確認

IM管理ノード情報取得のAPIなどを利用して，時系列データを出力するJP1/IM - AgentのSIDを確認します。

JP1/IM - AgentのSIDは，PrometheusSID（_JP1PC-IMB_統合エージェント管理基盤のホスト名/_JP1PC-M_Pホスト名/_HOST_Pホスト名/_PROMETHEUS_）やエージェントSID（_JP1PC-IMB_統合エージェント管理基盤のホスト名/_JP1PC-M_Pホスト名/_JP1PC-AHOST_Iホスト名/_HOST_Iホスト名/_JP1PC-A_jp1_pc_nodelabel）のノードから特定します。

Pホスト名

Prometheus serverがセットアップされているホストのホスト名

Iホスト名

監視対象ホストのホスト名

jp1_pc_nodelabel

Prometheus設定ファイル（jpc_prometheus_server.yml）のscrape_configsで，jp1pc_nodelabelに設定している値

IM管理ノード情報取得のAPIの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「5.8.3　IM管理ノード情報取得」を参照してください。

Windowsのコマンドプロンプト上で，OSSのcurlコマンドを利用して，IM管理ノード情報取得のAPIを実行する場合のイメージを，次に示します。
- ログインのAPIを実行
```
curl -XPOST -H "Content-Type: application/json" -c 出力先のテキストファイルAのパス -d "{\"user\":\"JP1ユーザー名\",\"password\":\"パスワード\"}" http://ホスト名:20703/im/api/v1/login
```
- IM管理ノード情報取得のAPIを実行
```
curl -GET -H "Content-Type: application/json" -b テキストファイルAのパス http://ホスト名:20703/im/api/v1/nodes/configInfo
```
- IM管理ノード情報取得のAPIの実行結果（JSON形式）
```
{"simtData":
  [{
    "sid":"XXXX/XXXX",
    "value":{"component":"/HITACHI/JP1/XXXX","visible":"true","label":"XXXX"}
  },{
    ・・・・
  },{
    "sid":"YYYY/YYYY/YYYY",
    "value":{ ・・・・
       "methods":[・・・,"__metricListGet","__timeSeriesDataGet",・・・],
       ・・・・}
  },{
     ・・・・
  }]
}
```
●出力できるメトリックの確認

メトリック一覧取得のAPIなどを利用して，時系列データのメトリック名を確認します。

メトリック一覧取得のAPIの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「5.11.1　メトリック一覧取得」を参照してください。

Windowsのコマンドプロンプト上で，OSSのcurlコマンドを利用して，メトリック一覧取得APIを実行する場合のイメージを，次に示します。
- ログインAPIの実行例
```
curl -XPOST -H "Content-Type: application/json" -c 出力先のテキストファイルAのパス -d "{\"user\":\"JP1ユーザー名\",\"password\":\"パスワード\"}" http://ホスト名:20703/im/api/v1/login
```
- メトリック一覧取得APIの実行例
```
curl -XPOST -H "Content-Type: application/json" -b テキストファイルAのパス -d "{\"sid\":\"JP1/IM - AgentのSID\"}" http://ホスト名:20703/im/api/v1/nodes/metrics
```
- メトリック一覧取得APIの実行結果の例（JSON形式）
```
{"metrics":[
  {
    "name":メトリック名,
    "default":デフォルトの設定,
    "label":メトリック表示名,
    "description":"メトリックの説明"
  } {
  ・・・・
  }
]}
```
時系列データ取得APIに，JP1/IM - AgentノードのSID，メトリック，および出力対象期間（開始日時と終了日時）を指定して実行する

●トレンドデータの取得

時系列データ取得のAPIを利用して，トレンドデータ（時系列データ）のメトリック名を取得します。時系列データ取得のAPIは，SIDとメトリックの組み合わせで実行するため，トレンドデータを出力したいJP1/IM - AgentノードのSIDまたはメトリックが複数ある場合は，SID数×メトリック数の回数の実行が必要です。

時系列データ取得のAPIの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「5.11.2　時系列データ取得」を参照してください。

なお，時系列データ取得のAPIで取得できるデータ数の上限は，30,000個です。例えば，1インスタンス当たりのデータ数が1個の場合，毎分×1か月（31日）のデータを出力すると，データ数は44,640個となるため，出力対象期間を2回に分割して取得する必要があります。分割の要否や分割数は，データの間隔，出力対象期間，およびメトリックの内容（1インスタンス当たりのデータ数）に依存します。

また，時系列データ取得のAPIでは，JSON形式でデータを取得できるため，JSON形式のデータからトレンドデータを取り出す必要があります。

具体的には，"timeSeriesData"の"data"に，「{"time":日時のデータ,"value":その日時における（メトリックの）値},」という形式で格納されているため，「日時のデータ」と「その日時における（メトリックの）値」のデータを抽出する必要があります。

時系列データ取得APIのリクエストとレスポンスの例を，次に示します。
- 時系列データ取得APIのリクエストの例
```
POST http://ホスト名:20703/im/api/v1/nodes/timeSeries
{
"sid":"_JP1PC-IMB-IMMHOST/_JP1PC-M_IMAHOST/_HOST_IMAHOST/_PROMETHEUS_",
"metric": "cpu_used_rate",
"startTime": "2021-06-01T00:00:00Z",
"endTime": "2021-06-15T23:59:59Z",
"countPerInstance":1,
"instanceCount":30000
}
```
- 時系列データ取得APIのレスポンスの例
```
< HTTP/1.1 200 OK
< Content-Type: application/json
{    
    "metric":"cpu_used_rate",
    "timeSeriesData":[
            {
                 "unit":"%",
                 "data":[
                  {"time":"2021-06-01T00:00:00Z","value":14.04},
                               ・・・
              ]
    ],
    "exceedCountDetected": {
        "countPerInstance": false,
        "instanceCount": false
    }
}
```
Windowsのコマンドプロンプト上で，OSSのcurlコマンドを利用して，時系列データ取得APIを実行し，1か月分のデータを2回に分けて出力する場合のイメージを，次に示します。
- ログインAPIの実行例
```
curl -XPOST -H "Content-Type: application/json" -c 出力先のテキストファイルAのパス -d "{\"user\":\"JP1ユーザー名\",\"password\":\"パスワード\"}" http://ホスト名:20703/im/api/v1/login
```
- 時系列データ取得APIの実行例＜1回目＞
```
curl -XPOST -H "Content-Type: application/json" -b テキストファイルAのパス -d "{\"sid\":\"JP1/IM - AgentのSID\",
\"metric\":\"メトリック名\",
\"startTime\":\"2021-06-01T00:00:00Z\",
\"endTime\":\"2021-06-15T23:59:59Z\",
\"countPerInstance\":30000,
\"instanceCount\":1}" 
http://ホスト名:20703/im/api/v1/nodes/timeSeries
```
- 時系列データ取得APIの実行結果の例（JSON形式）＜1回目＞
```
{"metric":
  "cpu_used_rate",
  "timeSeriesData":[
    {"unit":"%",
    "data":[
      {"time":"2021-06-01T00:00:00Z","value":10.480632},
       ・・・・
    ]}
  ],
  "exceedCountDetected":{"countPerInstance":false,"instanceCount":false}
}
```
- 時系列データ取得APIの実行例＜2回目＞
```
curl -XPOST -H "Content-Type: application/json" -b テキストファイルAのパス -d "{\"sid\":\"JP1/IM - AgentのSID\",
\"metric\":\"メトリック名\",
\"startTime\":\"2021-06-16T00:00:00Z\"
\"endTime\":\"2021-06-30T23:59:59Z\",
\"countPerInstance\":30000,
\"instanceCount\":1}" 
http://ホスト名:20703/im/api/v1/nodes/timeSeries
```
- 時系列データ取得APIの実行結果の例（JSON形式）＜2回目＞
```
{"metric":
  "cpu_used_rate",
  "timeSeriesData":[
    {"unit":"%",
    "data":[
      {"time":"2021-06-16T00:00:00Z","value":9.560327},
       ・・・・
    ]}
  ],
  "exceedCountDetected":{"countPerInstance":false,"instanceCount":false}
}
```

(e)　トレンドデータの手動削除（psqlコマンド）

運用を止めずに，インテリジェント統合管理データベースのトレンドデータを削除する場合は，スーパーユーザーロール（postgres）でテーブルを直接操作してトレンドデータの削除を行います。

トレンドデータを削除する手順を，次に示します。

次のコマンドを実行して，インテリジェント統合管理データベースに，スーパーユーザーロールで接続する。
```
psql -d imgndb -U postgres -W -p インテリジェント統合管理データベースのポート番号
```
パスワードの入力を促されるため，次に示すパスワードを入力します。
```
2BXY7aVkbicj
```
次のコマンドを実行して，メトリック名の一覧を取得する。
```
select * from metric;
```
上記のコマンドを実行すると，metric_name（トレンドデータとして取得したメトリック名），およびtable_name（時系列のトレンドデータを格納しているテーブル名）の値が取得できます。
手順2で確認したメトリック名に対応するテーブルを確認する（手順3以降はメトリックの数だけ繰り返す）。

メトリック名に対応するテーブルの名前は「prom_data.メトリック名」です。

次のコマンドを実行すると，各メトリック名に対応するテーブルのレコード件数を確認できます。
```
select count(*) from prom_data.メトリック名;
```
削除対象のレコードの件数や内容を確認する。

一例として，現時刻より1か月前のレコードを削除対象とする場合（直近1か月のレコードを残す場合）は，次のコマンドを実行すると，各メトリック名に対応するテーブルのレコード件数を確認できます。
```
select count(*) from prom_data.メトリック名 where time <= cast(now() - interval^※ '1 months' as timestamp);
```
また，次のコマンドを実行すると，削除対象のレコードの内容を確認できます。
```
select * from prom_data.メトリック名 where time <= cast(now() - interval^※ '1 months' as timestamp);
```
注※

intervalで指定する値の単位には，minutes，hourなども指定できます。

また，次の例に示すように，特定日の指定もできます。
```
select * from prom_data.メトリック名 where time <= '2021-09-30';
```
トレンドデータを削除する。

トレンドデータは，チャンクと呼ばれる単位（日時の間隔別の子テーブル）で管理されているため，トレンドデータの削除はチャンク単位で行います。

一例として，1か月より前のデータを削除する場合は，次のコマンドを実行します。
```
select drop_chunks('prom_data.メトリック名', older_than => interval^※ '1 months');
```
注※

intervalで指定する値の単位には，minutes，hourなども指定できます。

また，次の例に示すように，特定日の指定もできます。
```
select drop_chunks('prom_data.メトリック名', older_than => '2021-09-30');
```
なお，トレンドデータをチャンク単位で削除すると，削除時に指定した期間のデータだけが含まれるチャンクが削除されます。そのため，指定した期間のデータであっても，指定した期間外のデータも含まれるチャンクに格納されている場合は，削除されません。

(f)　トレンドデータの自動削除（サイズキャップ）

トレンドデータ管理DBが使用しているディスク容量を監視します。使用しているディスク容量が基準値（インテリジェント統合管理データベースセットアップ情報ファイル，または，クラスタ環境インテリジェント統合管理データベースセットアップ情報ファイルのTDDBDISKMAXに指定した値の90%）を超えた場合は，古いトレンドデータを削除して，使用しているディスク容量を削減します。

インテリジェント統合管理データベースのセットアップコマンドで，次の項目を設定できます。

トレンドデータ管理DBの最大ディスク所要量

指定した値の90%を超えると，トレンドデータの自動削除が実行されます。
削除するトレンドデータの期間

トレンドデータの自動削除が実行されると，トレンドデータの最古から指定した期間分のデータが削除されます。

■ディスク所要量の監視、トレンドデータの削除タイミングについて: ディスク所要量の監視，および，（基準値を超えた場合の）トレンドデータの削除を１つのタスクとし，このタスクを1分間隔で実行します（1回のタスクが終了してから1分後に次のタスクを実行します）。
■削除するトレンドデータの期間について: インテリジェント統合管理データベースセットアップ情報ファイル，または，クラスタ環境インテリジェント統合管理データベースセットアップ情報ファイルのTDDBCUTOFFTERMで指定します。

(g)　トレンドデータの手動削除（統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名を指定して削除）

統合エージェントホストのPrometheusやFluentd，ユーザー独自のPrometheus，ユーザー独自のFluentdが，トレンドデータ管理DBに保存したトレンドデータを削除する機能です。

JP1/IM - Managerのトレンドデータ削除のREST APIを使用し，トレンドデータ管理サービス（Promscale）を経由して，トレンドデータをトレンドデータ管理DBから削除します。統合オペレーション・ビューアーの［統合エージェント一覧］画面からも削除できます。

トレンドデータを削除したあと，トレンドデータ管理サービスを自動で再起動します。なお，トレンドデータの削除に失敗した場合は，トレンドデータ管理サービスは再起動しません。ただし，複数の削除対象を指定して一部のトレンドデータの削除に成功した場合は，トレンドデータ管理サービスを再起動します。

トレンドデータの削除は，同一ホストのトレンドデータ管理DBに対して同時実行できません。また，トレンドデータを削除したあとのトレンドデータ管理サービスの再起動後から一定期間（トレンドデータ削除を実行するときのインターバル）は，同一ホストのトレンドデータ管理DBに対して連続で実行できません。同時実行した場合や連続で実行した場合は，警告メッセージ（KAJY62015-W）を表示します。連続で実行できない期間（トレンドデータ削除を実行するときのインターバル）については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「インテリジェント統合管理基盤定義ファイル（imdd.properties）」（2.　定義ファイル）の設定項目「jp1.imdd.trenddata.deleteInterval」を参照してください。

トレンドデータ削除のAPIの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「5.11.4 トレンドデータ削除」を参照してください。統合オペレーション・ビューアーの［統合エージェント一覧］画面については，マニュアル「JP1/Integrated Management 3 - Manager 画面リファレンス」の「2.2.1 ［統合エージェント一覧］画面」を参照してください。

■削除対象の範囲

トレンドデータの削除対象に指定したホストのPrometheusやFluentd（ユーザー独自のPrometheusやユーザー独自のFluentdを含む）が，トレンドデータ管理DBに保存したトレンドデータをすべて削除します。

削除対象のトレンドデータを次に示します。

Prometheusがスクレイプしたパフォーマンスデータ^※およびアラート情報
Fluentdのログ監視機能がメトリック送信機能で送信したメトリック

なお，次のようなトレンドデータ削除はできません。

特定のExporterが収集したトレンドデータだけの削除
特定の監視対象のトレンドデータだけの削除
削除対象に監視対象ホストを指定したトレンドデータ削除

注※: スクレイプするExporterは，Prometheusと同一ホストの構成，および，別ホストの構成の両方が対象です。また，Exporterの監視対象も，Exporterと同一ホストの構成，および，別ホストの構成の両方が対象です。

■トレンドデータ削除のJP1イベントについて

トレンドデータの削除を実行した場合，次に示すイベントIDのJP1イベントのどれかを発行します。JP1イベントの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「3.2.3 JP1/IM - Agentが発行するJP1イベント一覧」を参照してください。

00003F86（トレンドデータ削除成功）
00003F87（トレンドデータ削除失敗）
00003F88（トレンドデータ削除に成功したが，トレンドデータ管理サービスの再起動に失敗）

マネージャーが階層構成の場合は，トレンドデータの削除を統合マネージャーで検知するために，各下位マネージャーで上記のイベントIDのJP1イベントを転送するように設定することを推奨します。イベントを転送する設定については，マニュアル「JP1/Base 運用ガイド」のJP1イベントの転送を説明している章を参照してください。

■トレンドデータ管理サービスの再起動について

トレンドデータ管理サービスの再起動時に，次のメッセージIDのメッセージを統合トレースログに出力します。メッセージの詳細については，マニュアル「JP1/Integrated Management 3 - Manager メッセージ」の該当するメッセージの記載個所を参照してください。

メッセージID	出力契機
KAJY62016-I	トレンドデータ管理サービスの再起動の開始時
KAJY62017-I	トレンドデータ管理サービスの再起動の成功時
KAJY62018-E	トレンドデータ管理サービスの再起動の失敗時

トレンドデータの削除後に，トレンドデータ管理サービスを自動で再起動する際，インテリジェント統合管理データベースとトレンドデータ管理サービスの起動状態に応じたトレンドデータ管理サービスの再起動処理は，次の表のようになります。

サービスの状態		トレンドデータ管理サービスの再起動処理
インテリジェント統合管理データベースサービス	トレンドデータ管理サービス	トレンドデータ管理サービスの再起動処理
起動	起動	トレンドデータ管理サービスを再起動します。イベントIDが00003F86のJP1イベントを通知します。統合トレースログにKAJY62017-Iのメッセージを出力します。
停止	停止	トレンドデータ管理サービスを起動しません。イベントIDが00003F86のJP1イベントを通知します。統合トレースログにKAJY62017-Iのメッセージを出力します。
起動	停止	トレンドデータ管理サービスを起動しません。イベントIDが00003F86のJP1イベントを通知します。統合トレースログにKAJY62017-Iのメッセージを出力します。
停止	起動	トレンドデータ管理サービスを停止し，起動しません。イベントIDが00003F86のJP1イベントを通知します。統合トレースログにKAJY62017-Iのメッセージを出力します。

■トレンドデータの削除時の注意事項

1. トレンドデータを削除すると，統合エージェントホスト，ユーザー独自のPrometheus，ユーザー独自のFluentdを管理しているマネージャーホストのトレンドデータ管理サービスを自動で再起動されます。そのため，次のパラメーターを調整する必要があります。

＜指定したマネージャーホストがクラスタ環境の場合＞

トレンドデータ管理サービスの再起動によってフェールオーバーが実行されないように，クラスタソフトのパラメーターを調整します。また，トレンドデータの削除を連続で実行したときに，トレンドデータ管理サービスの再起動が連続で実行されてフェールオーバーが実行されないように，インテリジェント統合管理基盤定義ファイルのパラメーターを調整します。

クラスタソフトのパラメーター

マニュアル「JP1/Integrated Management 3 - Manager 構築ガイド」の「7.5.3 クラスタソフトのパラメーターの設定（Windowsの場合）」および「8.5.3 クラスタソフトのパラメーターの設定（Linuxの場合）」を参照してください。
インテリジェント統合管理基盤定義ファイルのパラメーター

マニュアル「JP1/Integrated Management 3 - Manager 構築ガイド」の「7.4.1 クラスタ環境を新規構築する（Windowsの場合）」および「8.4.1 クラスタ環境を新規構築する（UNIXの場合）」を参照してください。

＜指定したマネージャーホストのトレンドデータ管理サービスのプロセスまたはサービスの死活監視をしている場合＞

トレンドデータ管理サービスが再起動したときに，異常として検知されないように，次のパラメーターを調整します。

Prometheus設定ファイルのパラメーター

Prometheus設定ファイル（jpc_prometheus_server.yml）のscrape_interval（スクレイプ間隔）に15秒以上の値を設定します。Prometheus設定ファイルの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・API リファレンス」（2.　定義ファイル）の「Prometheus設定ファイル（jpc_prometheus_server.yml）」を参照してください。
アラート設定ファイルのパラメーター

アラート設定ファイル（jpc_alerting_rules.yml）の「for」で指定する期間に，Prometheus設定ファイル（jpc_prometheus_server.yml）で指定するスクレイプ間隔の2倍以上の値を設定します。アラート設定ファイルの詳細については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・API リファレンス」（2.　定義ファイル）の「アラート設定ファイル（jpc_alerting_rules.yml）」を参照してください。
インテリジェント統合管理基盤定義ファイルのパラメーター

トレンドデータ削除のインターバルに，Prometheus設定ファイル（jpc_prometheus_server.yml）で指定するスクレイプ間隔の2倍以上の値を設定します。トレンドデータ削除のインターバルについては，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・API リファレンス」（2.　定義ファイル）の「インテリジェント統合管理基盤定義ファイル（imdd.properties）」のプロパティ「jp1.imdd.trenddata.deleteInterval」を参照してください。

上記の両方に当てはまる場合は，トレンドデータ削除のインターバルに，値の大きい方を設定します。

上記で記載しているパラメーターの設定値は，トレンドデータ管理サービスの再起動時間が7秒程度であることを想定した値を基準にして，それ以上の値となるように求めた値です。そのため，トレンドデータ管理サービスの再起動時間を測定して7秒より時間がかかる場合，クラスタソフトや，プロセスまたはサービスの監視で誤検知されないように，パラメーターを調整してから，トレンドデータ削除の機能を使用する必要があります。

なお，トレンドデータ管理サービスの再起動時間は，トレンドデータ削除を実行したときに統合トレースログに出力されるKAJY62016-IとKAJY62017-Iのメッセージの時間から算出します。算出した値を元に，システムへの負荷を考慮して余裕を持った値を設定してください。

トレンドデータ管理サービスの再起動時間を7秒と想定し，各パラメーターが次の設定値の場合に，誤検知が発生するケースと対処について，次に示します。

■パラメーターの設定値の例

クラスタソフトの監視間隔：14秒
クラスタソフトが停止したと判断する回数：連続で2回
トレンドデータ削除のインターバル：28秒

＜クラスタソフトの監視処理が遅延するケース＞

クラスタソフトの監視処理が遅延して，監視間隔の設定値の2倍以上（28秒以上）の時間がかかった場合に，誤検知が発生します。

この場合，誤検知されないように，次のどちらか，または，両方を実施します。

トレンドデータ削除のインターバルに，遅延したときのクラスタソフトの監視間隔（28秒以上）の2倍以上の値（56秒以上）を設定する。
クラスタソフトが停止したと判断する回数に，連続で3回以上を設定する。

＜トレンドデータ管理サービスの再起動処理が遅延するケース＞

トレンドデータ管理サービスの再起動処理が遅延して，想定時間の2倍以上（14秒以上）の時間がかかった場合に，誤検知が発生します。

この場合，誤検知されないように，次のどちらか，または，両方を実施します。

クラスタソフトの監視間隔に，遅延したときのトレンドデータ管理サービスの再起動時間（14秒以上）の2倍以上の値（28秒以上）を設定し，その2倍以上の値（56秒以上）をトレンドデータ削除のインターバルに設定する。
クラスタソフトが停止したと判断する回数に，連続で3回以上を設定する。

2. トレンドデータの削除後，トレンドデータ管理サービスを再起動するため，再起動中はトレンドデータが参照できない状態になります。トレンドデータ管理サービスの再起動時間の目安は7秒以内です。

トレンドデータが参照できない状態の間，統合オペレーション・ビューアーの画面は次の動作になります。この場合，トレンドデータ管理サービスの再起動後に，再表示または再実行をすることで対処できます。

［詳細表示］領域−［タブ］領域−［トレンド］タブの［トレンドグラフ表示］領域に，グラフを表示すると，KAJY22006-Eのエラーが表示され，メッセージの詳細にKAJY24610-Eのエラーが表示され，メッセージにKAJY62000-Eのエラーが表示されます。
次に示すダッシュボードのメトリックの情報を表示するパネル（アラート情報パネル含む）に対して，タイトルの左側には赤色で「!」が表示され，情報の表示領域には「NO DATA」と表示されます。
［詳細表示］領域−［タブ］領域−［ダッシュボード］タブで表示するダッシュボード
［表示］メニュー−［ダッシュボード一覧］−［ダッシュボード一覧］ダイアログから表示するダッシュボード
［マネージャーの定義ファイル一覧］画面で［ツリー情報生成］ボタンをクリックして，［ツリー情報生成］ダイアログからツリー情報の生成を実行したときに，KAJY02028-Wの警告が表示され，メッセージの詳細にKAJY04704-Eのエラーが表示され，メッセージにKAJY62000-Eのエラーが表示されます。

3. 統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名を変更したあと，変更前に保存したトレンドデータを削除する場合は，変更前のホスト名を指定してください。

4. トレンドデータの削除対象に複数のマネージャーホストを指定したときに，エラーが発生して処理が中断した場合，トレンドデータの削除を実行していないマネージャーホストは、イベントIDが3F86、3F87、3F88のJP1イベントを発行しません。

5. トレンドデータの削除対象に指定した統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホストのIM管理ノードに対して，参照・操作権限がある場合に，そのホストのPrometheusとFluentdが保存したトレンドデータをすべて削除します。

6. トレンドデータ削除は連続で実行できません。トレンドデータ削除のインターバルより短い間隔で連続実行した場合，警告メッセージ（KAJY62015-W）を出力し，トレンドデータを削除できません。また，同時実行もできません。トレンドデータ削除のインターバルについては，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・API リファレンス」（2.　定義ファイル）の「インテリジェント統合管理基盤定義ファイル（imdd.properties）」のプロパティ「jp1.imdd.trend.delete.interval」を参照してください。

7. 統合エージェントホストにユーザー独自のPrometheusやユーザー独自のFluentdをインストールしている場合，それらがトレンドデータ管理DBにトレンドデータを保存しているときは，そのトレンドデータも削除されます。

8. 削除対象に存在しないホストを指定した場合でも，削除処理を実行してトレンドデータ管理サービスを再起動します。

9. トレンドデータが削除されないケースがあります。トレンドデータが削除されないケースと削除方法を下記の表に示します。

項番	トレンドデータが削除されないケース	削除方法
1	SAPシステム監視機能で，SAPシステムのシステムログ情報またはCCMSアラート情報を監視している。	トレンドデータ削除APIで，リクエストのagenthostパラメーターに，次の値を指定して実行してください。テキスト形式のログファイルの監視定義ファイルの[Metric Settings]セクションのinstanceに指定したSAPインスタンス名
2	Fluentdのログ監視機能で，テキスト形式のログファイルの監視定義ファイル，またはWindowsイベントログの監視定義ファイルの[Metric Settings]セクションのinstanceに，統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名以外を指定している（誤って設定した場合や大文字小文字が異なる場合も含みます）。	トレンドデータ削除APIで，リクエストのagenthostパラメーターに，次の値を指定して実行してください。テキスト形式のログファイルの監視定義ファイル，またはWindowsイベントログの監視定義ファイルの[Metric Settings]セクションのinstanceに指定した文字列
3	Fluentdのログ監視機能で，テキスト形式のログファイルの監視定義ファイル，またはWindowsイベントログの監視定義ファイルの[Metric Settings]セクションのinstanceを指定していない。	トレンドデータの手動削除（psqlコマンド）を実行してださい。ただし，指定したメトリックすべてが削除対象となるため，複数のログ監視の設定がある場合や，複数ホストでログ監視の設定がある場合，すべてのFluentdのログ監視のトレンドデータが削除対象となります。
4	性能監視機能で，Prometheus設定ファイルのglobal.external_labelsセクションのjp1_pc_prome_hostnameに，統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名以外を指定している（誤って設定した場合や大文字小文字が異なる場合も含みます）。	トレンドデータ削除APIで，リクエストのagenthostパラメーターに，次の値を指定して実行してください。 Prometheus設定ファイルのglobal.external_labelsセクションのjp1_pc_prome_hostnameに指定した文字列

10. 階層構成の場合，統合マネージャーと下位マネージャーのJP1/IM - Manager のバージョンは13-10以降である必要があります。そうでない場合，トレンドデータは削除できません。

(h)　トレンドデータの手動削除（管理対象から削除）

統合エージェントをインテリジェント統合管理基盤の管理対象から削除するときに，統合エージェントホストのPrometheusやFluentdが，トレンドデータ管理DBに保存したトレンドデータを削除する機能です。

JP1/IM - Managerの統合エージェント情報削除のREST APIを使用し，トレンドデータ管理サービス（Promscale）を経由して，トレンドデータをトレンドデータ管理DBから削除します。統合エージェントホストのPrometheusやFluentdが，トレンドデータ管理DBに保存したトレンドデータは，統合オペレーション・ビューアーの［統合エージェント一覧］画面からも削除できます。

削除対象のトレンドデータの削除がすべて失敗した場合は，トレンドデータ管理サービスは再起動しません。削除対象の一部のトレンドデータの削除に成功した場合は，トレンドデータ管理サービスを再起動します。

統合エージェント情報削除のAPIの詳細仕様については，マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「5.18.2 統合エージェント情報削除」を参照してください。統合オペレーション・ビューアーの［統合エージェント一覧］画面については，マニュアル「JP1/Integrated Management 3 - Manager 画面リファレンス」の「2.2.1 ［統合エージェント一覧］画面」を参照してください。

■削除対象の範囲

「2.7.2(3)(g) トレンドデータの手動削除（統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名を指定して削除）」の「削除対象の範囲」を参照してください。

ただし，トレンドデータの削除対象に統合エージェントホスト（JP1/IM - Agentをインストールしているホスト）以外は指定できません。

■トレンドデータ削除のJP1イベントについて

「2.7.2(3)(g) トレンドデータの手動削除（統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名を指定して削除）」の「トレンドデータ削除のJP1イベントについて」を参照してください。

■トレンドデータ管理サービスの再起動について

「2.7.2(3)(g) トレンドデータの手動削除（統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名を指定して削除）」の「トレンドデータ管理サービスの再起動について」を参照してください。

■トレンドデータの削除時の注意事項

1. 「2.7.2(3)(g) トレンドデータの手動削除（統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名を指定して削除）」の1，2，4〜7，9を参照してください。

2. 統合エージェントのホスト名を変更したあと，変更前に保存したトレンドデータを削除する場合は，トレンドデータ削除APIでトレンドデータを削除してください。

3. トレンドデータの削除に失敗した場合，その削除対象の統合エージェント情報は削除しません。

4. 階層構成の場合，統合マネージャーと下位マネージャーのJP1/IM - Managerのバージョンは13-10以降である必要があります。そうでない場合，トレンドデータは削除できません。統合エージェント情報については，次の動作となります。

統合マネージャーがJP1/IM - Manager 13-00または13-01で，下位マネージャーがJP1/IM - Manager 13-10以降の場合，統合マネージャーから下位マネージャーが管理している統合エージェント情報を削除できます。
統合マネージャーがJP1/IM - Manager 13-10以降で，下位マネージャーがJP1/IM - Manager 13-00または13-01の場合，統合マネージャーから下位マネージャーが管理している統合エージェント情報を削除できません。この場合，次のどちらかの方法で対処してください。

・下位マネージャーのJP1/IM - Managerを13-10以降にバージョンアップして，統合マネージャーから，下位マネージャーが管理している統合エージェント情報を削除します。

・下位マネージャーから，その下位マネージャーが管理している統合エージェント情報を削除します。

(i)　ユースケースごとのトレンドデータの削除方法の使い分けについて

ユースケースに応じたトレンドデータの削除方法を，次に示します。

ユースケース	使用する削除方法
データベースのサイジング設計のミスで，データベースの保存期間より先にデータベースのディスクサイズが上限を超過しそうであるため，使用していないメトリックのトレンドデータを削除する。	トレンドデータの手動削除（psqlコマンド）^※1
開発・検証環境を本番環境として使用するため，開発・検証環境で保存したトレンドデータを削除する。	次のどちらかの方法を使用します。インテリジェント統合管理データベースの再セットアップ^※2 トレンドデータの手動削除（統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名を指定して削除）
定義ファイルなどの設定ミスで，メトリックのラベルの値が意図しない内容となり，不要なIM管理ノードが表示されたため，意図しない値となったラベルのメトリックのトレンドデータを削除する。	次のどちらかの方法を使用します。トレンドデータの手動削除（psqlコマンド）^※1 トレンドデータの手動削除（統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名を指定して削除）^※3
定義ファイルなどの設定ミスで，メトリックのラベルの値が意図しない内容となり，トレンド表示のグラフに不要な折れ線が表示されるため，意図しない値となったラベルのメトリックのトレンドデータを削除する。
統合エージェントをインテリジェント統合管理基盤の管理対象から削除して，統合エージェントが管理しているPrometheus，Exporter，FluentdのIM管理ノードも削除したいため，統合エージェントホストのPrometheusやFluentdがトレンドデータ管理DBに保存したトレンドデータを削除する。	トレンドデータの手動削除（管理対象から削除）
ユーザー独自のPrometheusやユーザー独自のFluentdをインテリジェント統合管理基盤の管理対象から削除して，ユーザー独自のPrometheus，Exporter，FluentdのIM管理ノードも削除したいため，ユーザー独自のPrometheusやユーザー独自のFluentdがトレンドデータ管理DBに保存したトレンドデータを削除する。	トレンドデータの手動削除（統合エージェント，ユーザー独自のPrometheus，ユーザー独自のFluentdのホスト名を指定して削除）

注※1

指定したメトリックすべてが削除対象になるため，次のようなケースには対応できません。

＜対応できないケースの例＞

hostAとhostBのそれぞれで，Windows exporterのwindows_memory_cache_bytesメトリックを収集しており，hostAのwindows_memory_cache_bytesメトリックは不要だが，hostBのwindows_memory_cache_bytesメトリックは必要である。

注※2

統合エージェントホストで，初期シークレットの再設定と個別シークレットの削除が必要です。

注※3

指定したホスト（統合エージェントホスト）のPrometheusとFluentdがトレンドデータ管理DBに保存したトレンドデータを削除するため，次のようなケースには対応できません。

＜対応できないケースの例＞

hostAのWindows exporterの設定ミスで，不要なトレンドデータを削除したいが，Fluentdのトレンドデータは削除したくない。

ページの先頭へ

2.7.2 トレンドデータ管理DB

(1) データベースの構成

(2) インストールとセットアップ

(3) トレンドデータの削除

(a) 機能概要

(b) 保存期間の設定および変更

(c) トレンドデータの自動削除のタイミングについて

(d) 削除対象のトレンドデータの保存について