OCI Monitoring and Observability - Expert Knowledge

🏗️ OCI Landing Zone Terraform モジュールを使用する

車輪の再発明はしないでください。 可観測性スタックには oracle-terraform-modules/landing-zone を使用してください。

Landing Zone が解決するもの:

• ❌ ベストプラクティス違反 #10: ロギング、監視、通知なし (Landing Zone は完全な可観測性をデプロイします)
• ❌ ベストプラクティス違反 #7: セキュリティサービスの限定 (Landing Zone は Cloud Guard、VSS、OSMS を統合します)

このスキルで提供するもの: Landing Zone 内にデプロイされた監視のためのメトリクス、アラーム、およびトラブルシューティング。

---

⚠️ OCI CLI/API ナレッジギャップ

OCI CLI コマンドまたは OCI API 構造について知識がありません。

トレーニングデータには以下の知識が限定的かつ古い状態で含まれています:

• OCI CLI 構文とパラメータ (毎月更新)
• OCI API エンドポイントおよびリクエスト/レスポンス形式
• Monitoring サービス CLI 操作 (oci monitoring alarm, oci monitoring metric)
• メトリクス名前空間と MQL (Monitoring Query Language)
• 最新の Logging および Service Connector 機能

OCI 操作が必要な場合:

1. このスキルのリファレンスから正確な CLI コマンドを使用してください
2. メトリクス名前空間名を推測しないでください
3. AWS CloudWatch パターンが OCI で機能すると仮定しないでください
4. 詳細な MQL ドキュメントのためにリファレンスファイルをロードしてください

あなたが知っていること:

• 一般的な可観測性の概念
• アラートと閾値設計の原則
• ログ集約パターン

このスキルは、現在の OCI 固有の監視パターンと落とし穴を提供することでギャップを埋めます。

---

絶対にこれをしないでください

❌ メトリクスが即座に利用可能だと仮定しないでください (10～15 分の遅延)

• メトリクスは 1～5 分ごとに公開されます
• 処理遅延: 5～10 分
• 総遅延: イベントから可視化されたメトリクスまで 10～15 分
• リソース作成後最初の 15 分以内に「欠落したメトリクス」をデバッグしないでください

❌ スパースなメトリクスにはアラーム閾値に = を使用しないでください

# 間違い - メトリクスにギャップがある場合、アラームは発火しません
MetricName[1m].mean() = 0

# 正しい - 欠落したデータを処理する
MetricName[1m]{dataMissing=zero}.mean() > 0

❌ メトリクスディメンションを忘れないでください (「データなし」の原因)

# 間違い - 必須ディメンションが不足している
CPUUtilization[1m].mean()

# 正しい - resourceId ディメンションを含める
CPUUtilization[1m]{resourceId="<instance-ocid>"}.mean()

❌ トリガー遅延なしでアラーム閾値を設定しないでください (アラート疲労)

# 悪い - CPU スパイクのたびに発火します
CPUUtilization[1m].mean() > 80

# より良い - 継続的な高 CPU
CPUUtilization[5m].mean() > 80
トリガー遅延: 5 分 (5 回の連続した違反後に発火)

❌ 通知チャネルなしでアラームを作成しないでください

# 間違い - アラームは発火しますが、誰も気づきません
oci monitoring alarm create ... --destinations '[]'

# 正しい - 常に通知トピックにリンクします
oci monitoring alarm create ... --destinations '["<notification-topic-ocid>"]'

コストへの影響: 検出されない障害は本番環境で時間あたり $5,000～50,000 のコスト

❌ Cloud Guard 検出を無視しないでください (セキュリティ監査の失敗)

• Cloud Guard は インシデントになる前に構成ミスを検出します
• Cloud Guard → 通知 → Email/Slack/PagerDuty を統合します
• コストへの影響: セキュリティ侵害ごとに $100,000 以上対 プロアクティブな修復で $0

メトリクス名前空間の落とし穴

OCI メトリクスはサービス固有の名前空間を使用します:

サービス	名前空間	メトリクス例
Compute	oci_computeagent	CPUUtilization, MemoryUtilization
Autonomous DB	oci_autonomous_database	CpuUtilization, StorageUtilization
Load Balancer	oci_lbaas	HttpRequests, UnHealthyBackendServers
Object Storage	oci_objectstorage	ObjectCount, BytesUploaded

一般的なミス: 間違った名前空間の使用 (oci_compute vs oci_computeagent)

アラームの欠落データ処理

設定	動作	使用する場合
treatMissingDataAsBreaching	データがない場合、アラームが発火します	クリティカルなサービス (障害 = 違反)
treatMissingDataAsNotBreaching	データがない場合、アラームはサイレントです	オプション監視
{dataMissing=zero}	欠落を 0 として処理します	カウンター (リクエスト/秒)

ログ収集の一般的なギャップ

問題: ログが Log Analytics に表示されません

ログが表示されない場合?
├─ リソースでログが有効になっていますか?
│  └─ Compute: oci-compute-agent が実行中である必要があります
│  └─ Function: 関数設定でロギングが有効になっています
│
├─ Service Connector が構成されていますか?
│  └─ ソース: Log Group → ターゲット: Log Analytics
│  └─ 確認: Service Connector ステータス = ACTIVE
│
├─ Service Connector の IAM ポリシーですか?
│  └─ "Allow any-user to use log-content in tenancy"
│  └─ "Allow service loganalytics to READ logcontent in tenancy"
│
└─ 10～15 分の取り込み遅延ですか?
   └─ デバッグする前に待機します

メトリクスクエリの最適化

高コスト (遅い):

# すべてのインスタンスをクエリします
CPUUtilization[1m].mean()

最適化 (ディメンションでフィルタリング):

# 特定インスタンスをクエリします
CPUUtilization[1m]{resourceId='<instance-ocid>'}.mean()

コスト: クエリは無料ですが、レート制限あり (1000 req/min)

段階的なロードリファレンス

OCI Monitoring リファレンス (Oracle 公式ドキュメント)

ロードするタイミング oci-monitoring-reference.md:

• すべての OCI サービスメトリクスの包括的なリストが必要
• MQL (Monitoring Query Language) を深く理解したい
• 複雑なアラーム条件と複合条件を実装している
• Logging および Service Connector に関する Oracle 公式ガイダンスが必要
• Log Analytics および APM 統合をセットアップしている

ロードしないでください (以下の場合):

• クイックアラームセットアップ (このスキルの例)
• 一般的なメトリクスパターン (上記の表)
• トラブルシューティング判定木 (上記でカバー)

---

このスキルを使用する場合

• アラーム: 閾値構成、欠落データ処理、トリガー遅延
• トラブルシューティング: メトリクスが表示されない、アラームが発火しない、名前空間エラー
• ログ収集: Service Connector、IAM ポリシー、欠落したログ
• パフォーマンス: クエリ最適化、ディメンションフィルタリング