OCIのモニタリングのメトリック・データは最大90日の保存期間に設定されています。長期的にそのメトリック値を保存するためには、Service Connector Hubを使用して、そのメトリック値をObject Storageに格納することができます。オブジェクト・ストレージに格納されたメトリック値は、JSON形式でzipファイルとして保存され、最小間隔1分ごとに出力されます。
JSONファイルのため、そのままでは可読性がよろしくありません。そのためLogging AnalyticsでそのOject Storageに格納されたメトリックのzipファイルを直接アクセスし、ログを取り込み、モニタリングのようにグラフでビジュアライズすることが可能です。
今回は、前回の続きということで、Autonomousのメトリック値を対象に設定してみます
Service Connector Hubの設定
Service Connector HubでADBのメトリック値をObject Storageに出力させる設定をする
- ソース:モニタリング -> ターゲット:オブジェクトストレージ、ネームスペース: oci_autonomous_database、バケット:出力するバケットを指定
拡張オプションでは、バッチ時間で出力頻度(最小60000ミリ秒)が指定できる
Object Storageの確認
設定が正しく動作していれば、下記のようにログが出力されいく
パーサーの作成
ADBのJSONファイルからフィールドを正しく読み込むためのパーサーを作成する
-
管理->パーサーの作成、JSONタイプを指定し、サンプル・ログコンテンツの部分にObject Storageに格納されているJSON形式のログの1,2レコードをコピーして貼り付ける
-
JSONファイルを解析して読み込まれたフィールドに対して、Logging Analyticsのフィールドをマッピングしていく。timestampはTimeフィールドを割り当てること。それ以外は既存または新規で作成したフィールドをマッピングしていく。必要なフィールドのみで、すべてマッピングしなくてもOK
また、パーサーテストを使って正常に取り込めるかどうか確認して、パーサー作成を完了する
ソースの作成
作成したパーサーを用いるソースを作成する。これは、LAが直接Object Storageにアクセスし、ログ解析に使用するパーサーを指定する定義。ソース内ではパターン(ファイルの存在する位置)は特に指定せずに、次のステップのコマンドで指定する
- 管理->ソース->ソースの作成、エンティティタイプ: Host(Linux)、特定のパーサー:上記で作成したパーサーを指定
LA->Object Storageの読み取りの開始
-
Object Storageの位置を記述したJSONを準備。ここでは、adb_monitoring.jsonのファイル名で作成
{
"name": "名前",
"compartmentId": "コンパートメントID",
"osNamespace": "Object Storageのネームスペース",
"osBucketName": "バケット名",
"logGroupId": "ロググループ ID",
"logSourceName": "上記で作成したログソース名"
} -
OCI CLIが実行可能なインスタンスで以下のコマンドを実行。パラメータ HISTORIC_LIVEは、バケットにある古いログから順に収集し、継続的に最新のログを取得することを意味する
oci log-analytics object-collection-rule create --from-json file://db_monitoring.json --namespace-name namespace --collection-type HISTORIC_LIVE --poll-since BEGINNING -
正しく設定できていれば下記のようにログ・エクスプローラーに表示される
-
メトリックのCPUとストレージの使用率をLogging Analyticsのグラフで描写した例
Logging Analyticsは、今回のようにObject Storageに直接アクセスしログを収集することが可能です。この場合は、管理エージェントは必要ありません。また、最大で1000までのobject collection rulesを作成することができるので、例えば、Object Storageを各VMでマウントして様々なログを集め、LAのobject collection rulesで数百種類のログを直接取り込む、というような管理エージェントレスな構成も可能です。