OCI Stack Monitoring

解決する課題

OCI Monitoring が「クラウドリソースの組み込み指標」を集めるのに対し、Stack Monitoring は「アプリケーションスタックを構成するソフトウェア層そのもの」を監視対象にします。1 つの業務アプリは Web サーバー、アプリケーションサーバー、データベース、ホスト OS といった層が積み重なって動いており、これらを横断して状態を把握しないと、ユーザー影響の原因がどの層にあるのかを切り分けられません。

• データベースやミドルウェアのプロセス／インスタンスレベルの健全性を、ホスト指標とは別に把握したい
• 多数のサーバーに散らばる監視対象を、**手作業ではなく自動探索（ディスカバリ）**でまとめて登録したい
• アプリ・DB・ホストの**依存関係（トポロジ）**を踏まえて、障害の影響範囲と根本原因を切り分けたい
• リソース種別ごとに推奨される監視指標とアラームを、ゼロから設計せず使いたい
• オンプレミスやサードパーティクラウド上のスタックも、同じ監視基盤で扱いたい

主要概念と用語

• 監視対象リソース（Monitored Resource）: Stack Monitoring が監視する論理エンティティ。データベース 1 インスタンス、アプリケーションサーバー 1 つ、ホスト 1 台などがそれぞれリソースになる
• リソース種別（Resource Type）: 監視対象の種類。Oracle Database、各種アプリケーションサーバー、ホスト、外部 HTTP エンドポイントなど、種別ごとに収集指標やプロパティが定義される
• ディスカバリ（Discovery）: エージェントを通じて対象環境をスキャンし、稼働中のスタック構成要素を自動で見つけてリソースとして登録する処理
• 管理エージェント（Management Agent）: 監視対象ホストや近傍に導入する OCI の収集エージェント。Stack Monitoring プラグインを有効化して指標を収集・送信する
• アソシエーション（Association／関連）: リソース間の依存・包含関係。DB がどのホスト上で動くか、アプリがどの DB に依存するかといったトポロジを表現する
• メトリクス（Metric）: 各リソースから収集される時系列指標。種別ごとに推奨指標が用意され、しきい値監視に使える
• アラームルール（Alarm Rule）: 指標がしきい値条件を満たしたときに通知・状態遷移を起こす設定。OCI Monitoring のアラームと連携し、Notifications 経由で配信する
• メンテナンスウィンドウ（Maintenance Window）: 計画停止中の誤検知を避けるため、特定リソースのアラームを一時的に抑止する期間
• OCI Observability and Management: Stack Monitoring が属する、Monitoring・Logging・APM・Database Management などを束ねる運用管理スイートの総称

仕様・制限・クォータ

• 指標収集は管理エージェント前提: クラウドの組み込み指標と異なり、Stack Monitoring は基本的に管理エージェントの Stack Monitoring プラグインが対象に到達して収集する。エージェントの到達性とポリシーが前提条件になる
• リソース種別ごとに収集できる指標が決まる: データベースやアプリケーションサーバーなど、サポートされる種別とその推奨指標はサービス側で定義される。任意のソフトウェアを無制限に監視できるわけではない
• 対象のクレデンシャル管理が必要: DB など認証を要する対象は、収集用アカウントの資格情報を安全に登録して使う。OCI Vault と連携してシークレットを保護するのが基本
• メトリクスの保持・集計はリージョン単位: 監視データはリージョン内で扱われ、長期トレンドが必要なら別途エクスポートやレポート化を設計する
• テナンシ／リージョン単位のサービス上限: 登録できるリソース数や API レートには上限があり、大規模環境では上限引き上げをサービスリクエストで申請する
• 具体的な保持日数・上限値・対応バージョンは更新されうるため、最新の公式ドキュメントで確認する

内部の仕組み

Stack Monitoring は「対象ソフトウェアの近くに置いたエージェントが指標を吸い上げ、OCI 側でリソースとして時系列管理する」構造です。流れは概ね次のとおりです。

• エージェント導入: 監視対象ホスト（または到達可能な近傍）に管理エージェントを入れ、Stack Monitoring プラグインを有効化する
• ディスカバリ: エージェントが環境をスキャンし、稼働中の DB・アプリケーションサーバー・ホストなどを検出して監視対象リソースとして登録する。検出時に依存関係（アソシエーション）も把握され、トポロジが形成される
• 収集: 各リソース種別に定義された推奨指標を、エージェントが定期的に収集して OCI へ送信する。認証が要る対象には登録済みクレデンシャルを使う
• 評価と可視化: 収集指標はリソース単位で時系列として保持され、トポロジ表示や種別別ダッシュボードで可視化される。アラームルールが条件成立を検知すると OCI Monitoring／Notifications を通じて通知される

設計パターン / ベストプラクティス

• エージェントの自動探索を起点にする: 手動登録ではなくディスカバリで対象を洗い出し、登録漏れと属人的な構成管理を避ける
• トポロジで根本原因を辿る: アプリ遅延が DB 起因かホスト起因かを、アソシエーションをたどって切り分ける。アラームは依存元と依存先の両方に設計する
• 種別ごとの推奨指標を採用する: 各リソース種別の推奨指標とアラームテンプレートをまず採用し、必要に応じて固有のしきい値へ調整する
• メンテナンスウィンドウで誤検知を抑える: 計画パッチ・再起動の時間帯はアラームを抑止し、通知疲れと無駄なオンコールを防ぐ
• 通知は OCI Monitoring／Notifications に集約: Stack Monitoring 由来のアラームも同じトピックに集約し、Email／PagerDuty／Slack／Functions へ一元配信する
• APM・Database Management と併用: リクエスト経路の遅延は APM、DB の詳細チューニングは Database Management、層の健全性は Stack Monitoring、と観測スイート内で補完させる

運用・監視

• 指標が出ない: 対象ホストの管理エージェントと Stack Monitoring プラグインが有効か、エージェントが OCI エンドポイントへ到達できるネットワーク／プロキシ／ポリシーかを確認する
• ディスカバリで対象が見つからない: 収集用クレデンシャルの権限不足、対象プロセスの稼働状態、エージェントから対象への到達性（ポート・認証）を点検する
• アラームが鳴らない／鳴りすぎる: しきい値と評価条件、対象リソースの選択範囲、メンテナンスウィンドウの設定有無を確認する
• 通知が届かない: 連携先 Notifications トピックのサブスクリプションが確認済みか、IAM ポリシーで publish が許可されているかを確認する
• クレデンシャルの失効: DB 等の収集用パスワードをローテーションしたら、Vault のシークレットと登録情報を更新する。失効すると収集が静かに止まる点に注意

コスト

Stack Monitoring の課金は概ね監視対象リソースの数や監視時間に応じて発生し、エージェント自体の利用やディスカバリ機能は管理エージェントの枠組みで提供されます。監視対象を増やすほど費用が増えるため、本番クリティカル層を優先し、検証環境は監視を絞る／停止するなどメリハリを付けるのがコスト最適化の基本です。具体的な単価は変動するため、最新の料金ページで確認してください。

セキュリティ

• 収集クレデンシャルは Vault で保護: DB 等への収集用アカウントのパスワードはコードや設定ファイルに直書きせず、OCI Vault のシークレットとして管理しローテーションする
• IAM ポリシーで最小権限: リソースの登録・閲覧、エージェント管理、アラーム管理を、必要なグループ／動的グループにのみ付与する
• 動的グループ＋インスタンスプリンシパル: エージェントを動かすインスタンスは長期キーを埋め込まず、インスタンスプリンシパルで OCI へ認証させる
• 収集用アカウントは読み取り中心の最小権限: 監視のための DB／ミドルウェアアカウントは、必要な性能ビューの参照に絞り、書き込み権限を与えない
• 監査との役割分担: 「スタックがどんな状態か」は Stack Monitoring、「誰が何を操作したか」は OCI Audit が担う。混同しない

関連サービス・比較

最も近いのは OCI Monitoring です。Monitoring が「クラウドリソースの組み込みメトリクスとアラームの土台」であるのに対し、Stack Monitoring は「その上で動く DB・ミドルウェアなどソフトウェア層を、自動探索とトポロジ付きで監視する」レイヤーを担います。両者は同じ Observability and Management スイート内で補完し合います。

ハンズオン / CLI例

# 1) 監視対象リソースの一覧を取得（コンパートメント内）
oci stack-monitoring monitored-resource list \
  --compartment-id "$COMPARTMENT_OCID"

# 2) 特定の監視対象リソースの詳細を確認
#    指標やプロパティ、関連（アソシエーション）を把握する
oci stack-monitoring monitored-resource get \
  --monitored-resource-id "$RESOURCE_OCID"

# 3) ホストなどの監視対象リソースを手動登録する例
#    認証が要る対象は Vault のシークレットを参照する設計にする
oci stack-monitoring monitored-resource create \
  --compartment-id "$COMPARTMENT_OCID" \
  --name "app-host-01" \
  --type "host" \
  --management-agent-id "$MGMT_AGENT_OCID"

# 4) リソース間の関連（依存関係）を作成し、トポロジを表現
oci stack-monitoring monitored-resource-association create \
  --compartment-id "$COMPARTMENT_OCID" \
  --association-type "depends_on" \
  --source-resource-id "$APP_RESOURCE_OCID" \
  --destination-resource-id "$DB_RESOURCE_OCID"