【Oracle Cloud】スタック・モニタリングでリソースの確認

こんにちは。h.serizawaです。

OCI(Oracle Cloud Infrastructure)の監視サービス「スタック・モニタリング」を使い、コンピュート・インスタンスのリソース確認を行った際の手順やポイント、注意点を記事にしました。

💡 この記事で解決できること
・OCIスタック・モニタリングの有効化手順（UI作業編）がわかる
・OCI CLIを使ったプロセス監視の設定方法（CLI作業編）がわかる

　

スタック・モニタリングとは？

スタック・モニタリングとは、ITシステム全体の各層(スタック)を包括的に監視できるOCIのサービスです。これは、高層ビルの各階を同時に見張る警備システムのようなもので、OSからアプリケーションまで、システム全体の健全性を俯瞰的に把握できます。

　

• 今回確認するリソース: Computeインスタンス (Oracle Linux 9.5)

　

　

【UI作業編】事前準備 (動的グループとポリシー)

まず、スタック・モニタリングがコンピュート・インスタンスの情報にアクセスできるようにするための「許可証」として、IAMの動的グループとポリシーを設定します。

　

動的グループの作成

特定のルールに合致するインスタンスを自動的にまとめる「動的グループ」を作成します。

• 画面遷移: OCIコンソールメニュー → 「アイデンティティとセキュリティ」 → 「ドメイン」 → 「Default」→ 「動的グループ」 → 「動的グループの作成」
• パラメータ:
  • 名前: 任意の分かりやすい名前 (例: stackmonitoring_test)
  • ルール1: ALL {resource.type='managementagent', resource.compartment.id= 'ここにコンパートメントのOCIDを記載'}

ポリシーの作成

作成した動的グループに対して、スタック・モニタリングのサービスを操作する権限を付与する「ポリシー」を作成します。

• 画面遷移: OCIコンソールメニュー → 「アイデンティティとセキュリティ」 → 「ポリシー」 → 「ポリシーの作成」
• パラメータ:
  • 名前: 任意の分かりやすい名前 (例: StackMonitoring-Policy)
  • ポリシーステートメント (手動エディタ):
    Allow dynamic-group <動的グループ名> to use metrics in compartment id 'ここにコンパートメントのOCIDを記載' where target.metrics.namespace = 'oracle_appmgmt'
Allow dynamic-group <動的グループ名> to read management-agents in compartment id 'ここにコンパートメントのOCIDを記載'

💡 ポイント: OCIDの指定について
ポリシー設定で場所をパスで指定するとエラーになることがあったため、今回はコンパートメントのOCID (Oracle Cloud Identifier) を直接指定して設定しました。OCIDは、OCIリソースの一意の識別子です。詳細は公式ドキュメントを参照してください。

---

【UI作業編】プロモーションの有効化

コンパートメント内に存在するホストをスタック・モニタリングの「監視候補」として認識させるため、プロモーションを有効化します。これは、監視したいリソースをリストアップするイメージです。

• 画面遷移: OCIコンソールメニュー → 「監視および管理」 → 「スタック・モニタリング」 → 「完全モニタリングにプロモート」 → 「ホストの自動プロモーションを有効化」

---

【UI作業編】ポリシーマネージャーの設定

エンタープライズ・ヘルスおよびアラーム画面からポリシーマネージャーを選択し、監視の自動化やライセンスに関する設定を行います。

• 画面遷移: OCIコンソールメニュー → 「監視および管理」 → 「スタック・モニタリング」 → 「ポリシーマネージャー」
• パラメータ:
  • 手動オンボード: チェック
  • リソース・ライセンスの自動割当て: Enterprise
  • Enterpriseの拡張性: 有効化
  • コンパートメントの機能構成: 有効化

---

【UI作業編】リソースのプロモート

「監視候補」として検出されたリソースの中から、実際に監視を開始したいものを選択し、「プロモート(昇格)」させます。これにより、正式な監視対象として登録されます。

• 画面遷移: OCIコンソールメニュー → 「監視および管理」 → 「スタック・モニタリング」 → 「完全モニタリングにプロモート」 → 「プロモート」
• 操作: 検出場所、ライセンスにチェックを入れ、「リソースのプロモート」ボタンを押下

⚠️ 注意: 権限の反映タイミング
UI上でプロモートした後、管理エージェントに新しい権限が適用されるまでには、2つのパターンがあります。
1. 自然適用: 最大2時間程度待つ。
2. 手動適用: コマンドを実行して即時反映させる。

すぐに設定を確認したい場合は、「sudo systemctl restart oracle-cloud-agent.service」での手動適用が有効です。

　

　

【UI作業編】機能確認

状態確認

プロモート後、しばらくするとリソース詳細画面でCPU使用率などのグラフが描画され始めます。グラフにデータが表示されていれば、モニタリングは正常に開始されています。

• 画面遷移: OCIコンソールメニュー → 「監視および管理」 → 「スタック・モニタリング」 → 「すべてのリソース」 → プロモートしたホストを選択

アラーム定義

アラームを定義することで、リソースのメトリック(CPU使用率など)が設定したしきい値を超えた場合に通知を受け取ることができます。 これにより、障害の予兆を早期に検知し、プロアクティブな対応が可能になります。

• 画面遷移: OCIコンソールメニュー → 「監視および管理」 → 「アラーム定義」 → 「Create Alarm」

---

【CLI作業編】プロセス監視の設定

ここからは、監視対象のインスタンスにログインし、コマンドライン(CLI)で作業します。プロセス監視の設定にはOCI CLIの利用が必須であるためです。 特定のプロセス(例: Java)を監視対象に追加することで、より詳細な監視と、障害発生時の迅速な原因切り分けが可能になります。

プロセス監視は、以下の手順で設定します。

　

1. OCI CLIのインストールと設定
2. プロセスセットの作成 (監視ルールの定義)
3. ホストとプロセスセットの紐付け

　

1. OCI CLIのインストールと設定

手順1: OCI CLIのインストール

# 開発者リポジトリを有効化
sudo dnf -v install oraclelinux-developer-release-el9

手順2: OCI CLIの初期設定
対話形式で設定を進めます。ユーザーOCIDやテナンシOCIDなどを入力します。

oci setup config

• Enter a location for your config...: 設定ファイルの場所 (通常はデフォルトのままEnter)
• Enter a user OCID: OCIコンソールからユーザーのOCIDをコピー＆ペースト
• Enter a tenancy OCID: OCIコンソールからテナンシのOCIDをコピー＆ペースト
• Enter a region...: リージョン名を入力 (例: ap-tokyo-1)
• Do you want to generate a new API Signing RSA key pair?: Y を選択して新しいAPI署名キーを生成

※この後、生成された公開鍵 (~/.oci/oci_api_key_public.pem) の内容をコピーし、OCIコンソールのユーザー詳細画面からAPIキーとして登録する作業が必要です。

　

2. プロセスセットの作成

手順1: プロセス定義用のJSONファイル作成
監視したいプロセスの条件を定義したJSONファイルを作成します。ここでは例として、「コマンドラインに 'java' という文字列を含むプロセス」を監視する設定ファイルを作成します。

# java.json という名前でファイルを作成
vim java.json

【java.json の中身】

{
  "compartmentId": "<コンパートメントのOCID>",
  "displayName": "java processes",
  "specification": {
    "items": [
      {
        "processCommand": "java"
      }
    ]
  }
}

手順2: プロセスセットの作成実行
作成したJSONファイルを使い、以下のコマンドでプロセスセットをOCI上に作成します。

oci stack-monitoring process-set create 
--from-json file://java.json

⚠️ 注意点: API署名キーの権限エラー
このコマンド実行時にPermissions for the key file are too openというエラーが出ることがあります。
・エラーの理由: セキュリティのため、OCI CLIは秘密鍵ファイル(~/.oci/oci_api_key.pem)のパーミッションが自分以外のユーザーにも読み取れる状態になっていると、操作を拒否します。
・解決策: 以下のコマンドで、ファイルの所有者のみが読み書きできるように権限を変更してください。
chmod 600 ~/.oci/oci_api_key.pem

成功すると、作成されたプロセスセットの情報(OCIDなど)がJSON形式で返ってきます。この中の "id" の値を後で使うので控えておきましょう。

　

3. ホストとプロセスセットの紐付け

最後に、「どのホスト」で「どのプロセスセット」を監視するかを関連付けます。

手順1: 紐付け用のJSONファイル作成
先ほどと同様に、紐付け情報を記述したJSONファイル(例: host.json)を作成します。

# host.json という名前でファイルを作成
vim host.json

【host.json の中身】

{
    "discoveryType": "ADD",
    "discoveryClient": "APPMGMT",
    "compartmentId": "",
    "discoveryDetails": {
        "agentId": "",
        "resourceType": "CUSTOM_RESOURCE",
        "resourceName": "",
        "properties": {
            "propertiesMap": {
                 "host_ocid": "",
                 "process_set_id": "プロセスセット作成時のOCID"
            }
        }
    },
    "license": "ENTERPRISE_EDITION",
    "freeformTags": [],
    "definedTags": []
}

💡 OCIDの確認場所
JSONファイルに必要な各種OCIDは、OCIコンソールの スタック・モニタリング → 対象ホストの詳細画面 → 構成タブ → プロパティ から確認できます。

手順2: 紐付けの実行
作成したJSONファイルを使い、以下のコマンドを実行します。

oci stack-monitoring discovery-job create \
--compartment-id <コンパートメントのOCID> \
--from-json file://host.json

機能確認

OCIコンソールの スタック・モニタリング → すべてのリソース を確認します。一覧に先ほど作成したプロセスセットが表示され、ホストと関連付けられていれば成功です。

---

最後に

OCIスタック・モニタリングは、システム全体を包括的に監視できるサービスです。特に今回解説したプロセス監視機能を活用することで、障害発生時の原因特定や切り分け作業の助けとなります。

今回の検証では、動的グループとポリシーの設定から始まり、UIでの有効化、そしてCLIでの詳細なプロセス監視設定まで、実際の運用に必要な手順を一通り確認しました。特にOCI CLI実行時のAPIキーのパーミッション設定など、実際に遭遇しやすいトラブルとその対処法も交えて紹介しました。

本記事が、OCIでの監視システム構築を検討されている方の参考になれば幸いです。最後までお読みいただき、ありがとうございました。

　

参考記事

• Stack Monitoringでプロセス監視の設定をしてみた (Qiita)
• コンピュートインスタンスでOCI CLIの初期設定 (Qiita)