OCI Logging Analytics

解決する課題

サーバーやアプリ、ネットワーク機器に散らばったログを、grep で個別に追う運用から脱却し、横断的に検索・相関・可視化できます。

• 多数のリソースにまたがるログを一箇所に集約し、横断検索したい
• 非構造のテキストログを**構造化（フィールド抽出）**して集計・分析したい
• 機械学習で異常・外れ値・傾向を自動的に浮き彫りにしたい
• 障害調査やセキュリティ調査の**根本原因分析（RCA）**を、ダッシュボードで素早く進めたい
• ログ分析基盤そのものを自前で構築・運用したくない（クラスタやインデックスの管理を避けたい）

主要概念と用語

• ログソース（Log Source）: 取り込むログの種類の定義。どのパスのどんなログを、どのパーサで解釈するかをひとまとめにしたもの。データベース監査ログ、Linux syslog、Web サーバーアクセスログなど多数の事前定義がある
• パーサ（Parser）: 生のログ行からフィールドを抽出する規則。正規表現ベースや区切り文字ベースなどがあり、抽出結果を後段のフィールドへマッピングする
• フィールド（Field）: 抽出・正規化された属性（例: ホスト名、重大度、ステータスコード、ユーザー名）。検索・集計の単位になる
• エンティティ（Entity）: ログを発生させる論理的な対象（ホスト、データベース、アプリなど）。ログをエンティティに結びつけることで、対象ごとの相関分析が可能になる
• ログ取り込み（Ingestion）: 管理エージェント、Service Connector Hub、API/CLI、Object Storage 経由のオンデマンドアップロードなど複数経路でログを取り込む
• 管理エージェント（Management Agent）: ホストにインストールし、ファイルベースのログを収集して Logging Analytics へ送るコレクタ
• ログエクスプローラ（Log Explorer）: 取り込んだログを検索・ピボット・可視化する中心的な画面
• クエリ言語: 抽出済みフィールドに対して検索・集計・統計処理を記述する独自のログ問い合わせ言語。パイプでステップをつないで絞り込む
• ラベル（Label）: 重要なイベントに付与する印。アラートや分類のトリガーに使う
• 機械学習機能: クラスタリング（似たログのグルーピング）、リンク（時系列での関連付け）、外れ値検出など、大量ログから傾向や異常を浮かび上がらせる分析

仕様・制限・クォータ

• リージョン単位のサービスで、取り込んだログはそのリージョン内に保持される。クロスリージョンの一元集約が要る場合は設計で考慮する
• 保持期間（ストレージ保持）は設定可能で、ストレージ容量と保持期間が課金・運用の主要パラメータになる。長期保管が必要なログは保持期間を延ばすか別ストレージへ退避する
• 取り込みのスループットやアップロードサイズ、テナンシ／リージョン単位の上限が存在し、上限引き上げはサービスリクエストで申請する
• 事前定義のログソース・パーサ・ダッシュボードが多数同梱されるが、独自フォーマットにはカスタムパーサ／カスタムソースを作成する
• OCI 標準の OCI Logging（サービスログ／カスタムログの収集基盤）とは別サービスであり、Logging から Service Connector Hub 経由で Logging Analytics に流し込むのが定番の連携になる

内部の仕組み

Logging Analytics は、取り込んだ生ログをログソース定義に基づいてパーサで構造化し、抽出したフィールドにインデックスを張って検索可能にします。利用者はクラスタやインデックスを直接管理せず、フルマネージドな基盤として扱えます。

• 取り込み時に、ログ行は対応するログソースに割り当てられ、パーサがタイムスタンプや各フィールドを抽出して正規化します。これにより非構造テキストが集計可能なデータに変わります
• ログはエンティティに関連付けられ、ホストやデータベース単位での相関・絞り込みができます
• 取り込み経路は複数あり、ホスト上の管理エージェント、他の OCI ログを流し込む Service Connector Hub、API/CLI による直接アップロード、Object Storage からのオンデマンド取り込みなどを使い分けます
• 蓄積されたデータに対して、クラスタリング・外れ値検出などの機械学習が、膨大なログの中から似た事象のまとまりや異常を浮かび上がらせ、根本原因分析を支援します

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

• 収集は OCI Logging、分析は Logging Analytics: OCI のサービスログ／監査ログを OCI Logging で集め、Service Connector Hub で Logging Analytics へ転送する二段構成にする
• エンティティ設計を先に: ホスト・DB・アプリをエンティティとして定義し、ログを紐づけておくと、対象ごとのドリルダウンと相関が容易になる
• カスタムパーサの整備: 主要なアプリログは早期にカスタムパーサを用意し、検索・集計に使うフィールドを確実に抽出する
• ダッシュボードとラベルの活用: 同梱ダッシュボードをベースに業務に合わせて調整し、重要イベントにはラベルを付けて検知・分類を自動化する
• 保持期間でコストと要件を両立: 調査に必要な期間だけアクティブに保持し、長期保管が要るものは Object Storage 等へアーカイブする
• 取り込み量の最適化: ノイズの多い低価値ログは取り込み前に絞り込み、分析価値の高いログにストレージとコストを集中させる

運用・監視

• ログが取り込まれない: 管理エージェントの稼働状況、対象ログパス、IAM ポリシー、ネットワーク到達性（エンドポイントへの到達）を確認する
• フィールドが抽出されない: ログソースとパーサの割り当てが正しいか、カスタムパーサの抽出規則がログ形式と一致しているかを点検する
• 検索が遅い／結果が想定外: クエリの絞り込み条件、対象期間、対象ログソースの範囲を見直す。広すぎる期間・条件は時間とコストを増やす
• ストレージ逼迫: 取り込み量と保持期間を監視し、不要ログの取り込み停止や保持短縮で容量を制御する
• 監査証跡: Logging Analytics 自体への操作（設定変更など）は OCI Audit に記録される。誰が何を変更したかはこちらで追跡する

コスト

Logging Analytics の課金は概ね取り込み・分析したログ量とストレージ保持を基準に発生します。クラスタを常時起動する固定費型ではなく、扱うログ量と保持期間が主なコストドライバです。ノイズログの抑制と適切な保持設定が最適化の中心になります。

セキュリティ

• IAM ポリシーで権限を最小化: ログの取り込み・閲覧・管理の権限を、必要なグループ／動的グループにのみ付与する
• 動的グループ + リソースプリンシパル: 管理エージェントや Functions が認証する際は、長期キーを埋め込まずインスタンスプリンシパル／リソースプリンシパルを使う（AWS の IAM ロール相当）
• コンパートメントによる分離: ログデータをコンパートメント単位で分離し、テナント／チームごとにアクセス境界を引く
• 保存時・転送時の暗号化: データは暗号化されて保持・転送される。鍵管理ポリシーは組織要件に合わせる
• 役割分担の明確化: 「性能・指標」は OCI Monitoring、「API 操作の監査証跡」は OCI Audit、「ログの分析・可視化」は Logging Analytics が担う。混同しない

Well-Architected の観点

• 運用性（Operational Excellence）: 散在するログを一元化し、機械学習による異常検知とダッシュボードで、障害調査やトラブルシュートのリードタイムを短縮する。クラスタ運用を抱えずに分析基盤を維持できる点も運用負荷の低減に直結する
• 補完的に、IAM とコンパートメントによるアクセス制御はセキュリティに、保持期間とノイズ削減による課金最適化はコストに寄与するが、本サービスの主眼はあくまで運用の可観測性向上にある

試験で問われるポイント

関連サービス・比較

ログ分析・全文検索・可視化という観点では、AWS の OpenSearch によるログ分析が最も近い相当サービスです。OCI ではログの収集土台（OCI Logging）と分析レイヤ（Logging Analytics）が分かれており、CloudWatch Logs / Logs Insights や OpenSearch との対応を押さえると理解しやすくなります。

ハンズオン / CLI例

# 前提: テナンシで Logging Analytics をオンボード済みとする
# 0) 変数を用意
COMPARTMENT_OCID="ocid1.compartment.oc1..xxxx"
NAMESPACE="my-logan-namespace"   # Logging Analytics の名前空間

# 1) 利用可能なログソース（事前定義パーサ群）を一覧する
oci log-analytics source list-sources \
  --namespace-name "$NAMESPACE" \
  --compartment-id "$COMPARTMENT_OCID" \
  --limit 20

# 2) エンティティ（ログ発生源となるホスト等）を登録する
oci log-analytics entity create \
  --namespace-name "$NAMESPACE" \
  --compartment-id "$COMPARTMENT_OCID" \
  --name "web-host-01" \
  --entity-type-name "Host (Linux)"

# 3) Object Storage 上のログをオンデマンドで取り込む
#    log-source-name は取り込むログ形式に合うものを指定
oci log-analytics storage upload-log-file \
  --namespace-name "$NAMESPACE" \
  --upload-name "import-2026-06-14" \
  --log-source-name "Linux Syslog Logs" \
  --filename "/path/to/messages.log" \
  --opc-meta-loggrpid "$COMPARTMENT_OCID"

# 4) クエリ言語で取り込んだログを検索・集計する
#    （重大度ごとの件数を集計するイメージ）
oci log-analytics query \
  --namespace-name "$NAMESPACE" \
  --compartment-id "$COMPARTMENT_OCID" \
  --query-string "* | stats count as logrecords by 'Log Source'" \
  --time-start "2026-06-14T00:00:00Z" \
  --time-end "2026-06-14T23:59:59Z"