OCI Logging

解決する課題

各リソースに個別にログインして散在するログファイルを追いかける運用から脱却し、クラウド全体のログを一か所で扱えるようにします。

• 多数のサービスやインスタンスのログがバラバラの場所に散らばっているのを一元的に集めたい
• 障害調査やセキュリティ調査で、横断的にログを検索・フィルタしたい（誰が何をしたか、いつエラーが出たか）
• アプリケーション自身が出す**独自ログ（カスタムログ）**を、インフラ系ログと同じ基盤で扱いたい
• ログを SIEM や長期保管先（Object Storage）へ継続的に転送し、監査要件や分析に備えたい

主要概念と用語

• ログ（Log）: ログイベントの集まりを格納する論理的な入れ物。1つのログは1つのロググループに属する。種類は監査ログ・サービスログ・カスタムログに大別される
• ロググループ（Log Group）: 複数のログをまとめる論理コンテナ。IAM ポリシーの適用単位であり、コンパートメント内に作成してアクセス制御や整理に使う
• 監査ログ（Audit Log）: テナンシ内の API 呼び出しの記録。自動で有効で、誰がいつどのリソースを操作したかを残す。OCI Audit が出力源
• サービスログ（Service Log）: OCI の各サービス（Object Storage、Load Balancer、VCN フローログ、API Gateway、Functions など）が出力するログ。サービスごとにログを有効化して収集する
• カスタムログ（Custom Log）: アプリケーションや OS が出す独自ログ。Unified Monitoring Agent（インスタンスのエージェント）や API 経由で取り込む
• ログオブジェクト（Log Object）と取り込み: 個々のログイベントは JSON 形式で取り込まれ、検索可能なフィールドを持つ
• Connector Hub（Service Connector）: ログを別サービス（Object Storage、Streaming、Functions、Monitoring など）へ継続的に転送するパイプライン。Logging 自体とは別サービス
• エージェント設定（Agent Configuration）: どのファイルパスのログを、どのカスタムログへ送るかを定義する設定

仕様・制限・クォータ

• ログはリージョン単位のサービス。各リージョンで個別に集約され、クロスリージョン集約はコンソール標準では行わない
• **ログ保持期間（Retention）**はログ単位で設定でき、保持期間を過ぎたイベントは自動的に削除される。長期保管は別途エクスポートを前提にする
• 取り込めるログイベントの1イベントあたりのサイズや、テナンシ／リージョン単位の取り込みレートには上限があり、超過分はスロットルされうる。上限引き上げはサービスリクエストで申請する
• サービスログはサービスごとに有効化が必要で、有効化していないサービスのログは収集されない（自動では集まらない）
• コンソールの検索は保管中のログに対して行う。より高度な解析やフィールド抽出・ダッシュボードが必要な場合は Logging Analytics という別サービスを使う
• 取り込み・検索の権限はロググループ単位の IAM ポリシーで制御する

内部の仕組み

OCI Logging は、出どころの異なる3系統のログを共通のログ基盤に集約します。監査ログは OCI Audit から自動で流入し、サービスログは各 OCI サービスが有効化に応じて発行し、カスタムログはインスタンス上の Unified Monitoring Agent や API 経由で取り込まれます。

• 取り込まれたログイベントは構造化された JSONとして保管され、タイムスタンプ・ソース・本文などのフィールドで検索できます
• カスタムログでは、エージェント設定で「監視対象のファイルパス」と「送信先のカスタムログ」を紐づけます。エージェントが対象ファイルの追記を検知して継続的に送信します
• 集約したログを継続的に他サービスへ流す場合は Connector Hub を使い、Object Storage への長期保管、Streaming 経由での外部連携、Functions による加工などへつなぎます

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

• ロググループでアクセス境界を切る: チームや用途、機密度ごとにロググループを分け、ロググループ単位の IAM ポリシーで読み取り権限を最小化する
• 重要サービスのログは漏れなく有効化: Load Balancer のアクセスログ、VCN フローログ、Object Storage の操作ログなど、調査・監査で要るものは初期構築時に有効化しておく
• カスタムログはエージェントで一元化: アプリの出力先をファイルに固定し、Unified Monitoring Agent 経由で取り込むと、インスタンスを跨いで横断検索できる
• 長期保管・分析は転送前提: ログ保持期間は有限なので、監査・トレンド分析が要るログは Connector Hub で Object Storage や外部 SIEM へ流す
• 異常検知はメトリクス側と連携: ログから派生する指標（エラー件数など）でアラートを出したい場合は、Connector Hub で Monitoring へ渡すか、Functions で評価する
• 機密情報のマスキング: ログ本文に認証情報や個人情報を出さない。出力前にアプリ側でマスクし、転送先での露出範囲も意識する

運用・監視

• ログが集まらない: 対象サービスでサービスログを有効化したか、カスタムログではエージェント設定が正しいパスを指しているか、エージェントが Logging エンドポイントへ到達できるネットワーク／ポリシーかを確認する
• 検索でヒットしない: 検索対象の時間範囲とロググループ／ログの選択を確認する。保持期間を過ぎたログは削除済みで遡れない
• 権限不足: 取り込み・読み取りにはロググループに対する IAM ポリシーが要る。読めない場合はポリシーとコンパートメントを確認
• 転送が止まる: Connector Hub のソース・ターゲット設定と転送先サービスへの権限（allow service ... 形式）を点検する
• 取りこぼし: 取り込みレート上限に当たってスロットルされていないか、エージェントのバッファ・再送設定を確認する

コスト

OCI Logging の課金は概ね取り込んだログのデータ量に対して発生します。サービスログを無闇に全有効化したり、デバッグ用の冗長ログを本番で出し続けたりすると取り込み量が膨らむため、必要なログだけを適切なレベルで取り込むのがコスト最適化の基本です。長期保管は Logging に貯め込むより、安価な Object Storage へ転送するほうが経済的です。

セキュリティ

• ロググループ単位の IAM で最小権限化: ログの読み取り・取り込み・管理を、必要なグループ／動的グループにのみ付与する。機密ログのロググループは閲覧者を絞る
• 動的グループ + リソースプリンシパル: インスタンスや Functions がカスタムログを送る際は、長期キーを埋め込まずインスタンスプリンシパル／リソースプリンシパルで認証する（AWS の IAM ロール相当）
• 機密情報を残さない: パスワード・トークン・個人情報をログ本文へ出さない。出力前にマスクし、転送先（Object Storage や外部 SIEM）での露出範囲も管理する
• 役割分担を混同しない: 「誰が何を操作したか」の API 監査証跡は OCI Audit（その出力先が Logging の監査ログ）、性能・メトリクスは OCI Monitoring、ログの集約・検索・転送が OCI Logging の役割

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: ログの一元集約と横断検索により、障害調査・原因究明の時間を短縮できる。サービスログの有効化を構築の標準手順に組み込み、観測可能性を担保する
• セキュリティ: 監査ログを軸に操作証跡を保全し、ロググループ単位の権限分離で閲覧範囲を制御する。長期保管したログは改ざん耐性のある保管先で保持する
• 信頼性: ログから障害の予兆や再発条件を把握し、Connector Hub 経由で Monitoring と連携してアラートにつなげる
• コスト最適化: 取り込み量を必要十分に抑え、長期保管は安価な Object Storage へ寄せる

試験で問われるポイント

関連サービス・比較

OCI では CloudWatch 系の機能が複数サービスに分割されており、ログ収集・検索・転送が Logging、メトリクス／アラームが Monitoring、API 監査証跡の生成元が Audit、継続転送が Connector Hub という分担です。

ハンズオン / CLI例

# 1) ロググループを作成（IAM とアクセス制御の単位）
oci logging log-group create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "app-logs" \
  --description "Application and service logs"

# 2) カスタムログを作成（アプリ独自ログの受け皿）
#    retention-duration で保持期間（月数）を指定
oci logging log create \
  --log-group-id "$LOG_GROUP_OCID" \
  --display-name "checkout-app-log" \
  --log-type CUSTOM \
  --retention-duration 30

# 3) コンパートメント内のロググループを一覧
oci logging log-group list \
  --compartment-id "$COMPARTMENT_OCID" \
  --query "data[].{name:\"display-name\", id:id}" --output table

# 4) 取り込み済みログを検索（時間範囲とログ/ロググループを指定）
#    search-query は Logging の検索構文。直近のエラーを抽出する例
oci logging-search search-logs \
  --search-query "search \"$COMPARTMENT_OCID/$LOG_GROUP_OCID/$LOG_OCID\" | where data.level = 'ERROR'" \
  --time-start "2026-06-14T00:00:00Z" \
  --time-end "2026-06-14T23:59:59Z"