monitoring-operations

OCI Monitoring and Observability - 専門知識

🏗️ OCI Landing Zone Terraform Modules を使用する

同じものを一から作らないでください。 オブザーバビリティスタックには 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 分間は「メトリックが見つからない」問題のデバッグをしないでください

❌ データがまばらなメトリックのアラームしきい値に = を絶対に使用しないでください

# WRONG - alarm never fires if metric has gaps
MetricName[1m].mean() = 0

# RIGHT - handle missing data
MetricName[1m]{dataMissing=zero}.mean() > 0

❌ メトリックのディメンションを絶対に忘れないでください（「データなし」の原因になります）

# WRONG - missing required dimension
CPUUtilization[1m].mean()

# RIGHT - include resourceId dimension
CPUUtilization[1m]{resourceId="<instance-ocid>"}.mean()

❌ トリガーの遅延を設定せずにアラームのしきい値を絶対に設定しないでください（アラート疲れにつながります）

# BAD - fires on every CPU spike
CPUUtilization[1m].mean() > 80

# BETTER - sustained high CPU
CPUUtilization[5m].mean() > 80
Trigger delay: 5 minutes (fires after 5 consecutive breaches)

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

# WRONG - alarm fires but nobody knows
oci monitoring alarm create ... --destinations '[]'

# RIGHT - always link to notification topic
oci monitoring alarm create ... --destinations '["<notification-topic-ocid>"]'

コストへの影響：本番環境で検知されない障害は、1 時間あたり 5,000～50,000 ドルの損失につながります

❌ Cloud Guard の検出結果を絶対に無視しないでください（セキュリティ監査の失敗につながります）

• Cloud Guard は、設定ミスがインシデントになる前に検出します
• Cloud Guard → Notifications → Email/Slack/PagerDuty を統合してください
• コストへの影響：事前に修正すれば 0 ドルですが、セキュリティ侵害が発生すると 100,000 ドル以上かかります

メトリックの名前空間に関する注意点

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 と oci_computeagent を取り違える）

アラームでのデータ欠損の処理

設定	動作	使用する場面
treatMissingDataAsBreaching	データがない場合にアラームが発生します	重要なサービス（障害が侵害に相当する場合）
treatMissingDataAsNotBreaching	データがない場合、アラームは発生しません	任意のモニタリング
{dataMissing=zero}	欠損データを 0 として扱います	カウンター（リクエスト／秒）

ログ収集でよくある問題

問題：Log Analytics にログが表示されない

Logs not appearing?
├─ Is log enabled on resource?
│  └─ Compute: oci-compute-agent must be running
│  └─ Function: Logging enabled in function config
│
├─ Is Service Connector configured?
│  └─ Source: Log Group → Target: Log Analytics
│  └─ Check: Service Connector status = ACTIVE
│
├─ IAM policy for Service Connector?
│  └─ "Allow any-user to use log-content in tenancy"
│  └─ "Allow service loganalytics to READ logcontent in tenancy"
│
└─ 10-15 minute ingestion lag?
   └─ Wait before debugging

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

高コスト（低速）：

# Queries ALL instances
CPUUtilization[1m].mean()

最適化済み（ディメンションでフィルタリング）：

# Query specific instance
CPUUtilization[1m]{resourceId='<instance-ocid>'}.mean()

コスト：クエリは無料ですが、レート制限があります（1 分あたり 1000 リクエスト）

段階的に読み込むリファレンス

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

次の場合に読み込みます oci-monitoring-reference.md:

• OCI サービスのすべてのメトリクスを網羅した一覧が必要な場合
• MQL（Monitoring Query Language）を詳しく理解する場合
• 複雑なアラーム条件や複合アラームを実装する場合
• Logging と Service Connector に関する Oracle 公式のガイダンスが必要な場合
• Log Analytics と APM の統合を設定する場合

次の場合は読み込まないでください:

• 簡単なアラーム設定（このスキルの例を参照）
• 一般的なメトリクスのパターン（上の表を参照）
• トラブルシューティングの決定木（上記で説明）

---

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

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