【OCI】オブジェクト・ストレージに保存したログを Log Analytics で分析する方法

目的

こんにちは。OCI使ってますか？
OCI を使っていると、「必要なときにだけログを分析したい」
料金をできるだけ抑えたい。といった悩みはありませんか？
そういった場面のためのバケット保存したログをLog Analyticsで分析する構成を紹介します。

今回やること

オブジェクト・ストレージ上に読み取ったログをLog Analytics に取り込む
Log Analytics の「ログソース」を利用して解析可能な状態にする
実際にログを検索・可視化できることを確認する

前提条件

以下の構成がすでに完了していることを前提とします。

監査ログ（Audit）が Object Storage に保存されていること

まだ設定していない場合は、以下の記事を先にご確認ください。
[OCI] 監査ログ（Audit）をオブジェクト・ストレージに長期保存する構成

Log Analytics とは？

Log Analytics は OCI が提供するログ分析サービスで、以下のような用途に利用できます。

大量ログの検索・集計
フィルタ・可視化
監査・障害調査用途

主な特徴は以下の通りです。

OCI のマネージドサービス
オブジェクト・ストレージ上のログを取り込み可能
SQL ライクなクエリで検索可能

全体構成イメージ

OCI Audit Log
↓
Service Connector Hub
↓
Object Storage（長期保存）
↓
Log Analytics（必要なときに読み込み）

オブジェクト・ストレージ上に読み取ったログをLog Analytics に取り込む

Log Analytics の有効化

OCI コンソールから以下を実施します。

1.[Observability & Management]を選択
2.[Log Analytics]を選択
3.[ログ・アナリティクスを有効化]を押下
※ 初回のみ実施が必要です。

⚠ 注意点

このタイミングでOCI側で

「監査ログを Log Analytics に自動で取り込みますか？」

という確認が表示されます。
⚠ ここでは有効化しません。

この設定を有効にすると、
監査ログが常時 Log Analytics に取り込まれ続け、
ログ量に応じて継続的に課金されてしまいます。

本記事では 必要なときだけログを取り込む構成 を採用するため、
ここでは無効のまま進めます。

こちらの画面が表示されていたら有効化できています。

オブジェクトストレージからのログ収集を許可する権限の準備

動的グループ

[アイデンティティとセキュリティ]より[ドメイン]を選択し、[動的グループ]より[動的グループの作成]を押下

下記、[一致ルール]で[動的グループ]を作成

一致ルール：ALL {resource.type='loganalyticsobjectcollectionrule'}
- これは[Log Analytics] の [Object Collection Rule に対する操作のみを許可する条件]を意味します。

ポリシー

[アイデンティティとセキュリティ]より[ポリシー]を選択し、[ポリシーの作成]を押下

[ポリシー・ビルダー]を[手動エディタ]に変更
下記ポリシーを設定
- [compartment XXX]の部分は分析したいバケットの存在するコンパートメントを指定

Allow dynamic-group Logging-analytics to read buckets in compartment XXX
Allow dynamic-group Logging-analytics to read objects in compartment XXX
Allow dynamic-group Logging-analytics to manage cloudevents-rules in compartment XXX
Allow dynamic-group Logging-analytics to inspect compartments in compartment XXX
allow service loganalytics to read objectstorage-namespaces in tenancy
allow service loganalytics to read buckets in compartment XXX
allow service loganalytics to read objects in compartment XXX
allow service loganalytics to manage loganalytics-resources-family in compartment XXX

この設定により、

Object Storage からログを読み取り
Log Analytics がログを解析
オブジェクト収集ルールを操作可能

となります。

ソース

[ログ・アナリティクス]より[管理]を選択し、[ソース]より[ソースの作成]を押下

[ソース・タイプ]より[File]を選択
[エンティティ・タイプ]より[OCI Object Storage Bucket]を選択
[パーサー：特定のパーサー]より[OCI Audit Log Formata]を選択
[含まれているパターン]よりバケットに吐き出されているログのパスを可能な範囲で明確に指定
- [ファイル名パターン]は[*.log.gz]だけでもログ取得自体はできますがパーサーがうまく適用されず正常にクエリできなくなります

ログ・グループ

[ログ・アナリティクス]より[管理]を選択し、[ログ・グループ]より[ログ・グループの作成]を押下

任意のロググループ名を指定

ObjectCollectionRule

CLI でObjectCollectionRuleの作成を実施
ObjectCollectionRuleは2026/1時点ではコンソール上で作成する項目はありません

Cloudshell作業

画面右上の[開発者ツール]より、[Cloud Shell]を押下

create.jsonを作成
- name : 任意の名前を指定
- osNamespace : ログ取得元のバケットのネームスペースを指定
- osBucketName : ログ取得元のバケット名を指定
- logGroupId : 作成したロググループのIDを指定
- logSourceName : 作成したログソース名を指定
- collectionType : HISTORICを指定
- pollSince/pollTill : UTCにてバケットより取得したいログ期間を指定

HISTORIC を使う理由

ここで指定する collectionType には HISTORIC を使用します。
HISTORIC は、[Object Storage 上のログを指定した期間（pollSince ～ pollTill）だけ取り込む方式]となります。

Log Analytics は取り込んだログ量・保存量に応じて課金されるため、

常時取り込み → コスト増
必要な期間だけ取得 → コスト最小化

という違いが生まれます。
本構成では後者を採用します。

ma_watanab@cloudshell:~ (ap-tokyo-1)$ vi create.json
{
  "compartmentId": "ocid1.compartment.oc1..XXXXXXX",
  "name": "AuditObjectCollectionRule",
  "description": "Rule to collect audit logs from Object Storage",
  "osNamespace": "XXXXXXX",
  "osBucketName": "Audit-console-log",
  "logGroupId": "ocid1.loganalyticsloggroup.oc1.ap-tokyo-1.XXXXXXX",
  "logSourceName": "Audit_Log_Source",
  "collectionType": "HISTORIC",
  "pollSince": "2025-12-16T07:50:00.000Z",
  "pollTill": "2025-12-16T09:10:00.000Z",
  "charEncoding": "UTF-8"
}

作成したjsonよりルールを作成

oci log-analytics object-collection-rule create --namespace-name XXXXX --from-json file://create.json

{
  "data": {
    "char-encoding": "UTF-8",
    "collection-type": "HISTORIC",
    "compartment-id": "ocid1.compartment.oc1..XXXXX",
    "defined-tags": {
      "Oracle-Tags": {
        "CreatedBy": "default/ma-watanabe@iret.co.jp",
        "CreatedOn": "2026-01-02T06:18:53.149Z"
      }
    },
    "description": "Rule to collect audit logs from Object Storage",
    "entity-id": null,
    "freeform-tags": {},
    "id": "ocid1.loganalyticsobjectcollectionrule.oc1.ap-tokyo-1.XXXX",
    "is-enabled": true,
    "is-force-historic-collection": null,
    "last-collected-object": null,
    "lifecycle-details": null,
    "lifecycle-state": "ACTIVE",
    "log-group-id": "ocid1.loganalyticsloggroup.oc1.ap-tokyo-1.XXXX",
    "log-set": null,
    "log-set-ext-regex": null,
    "log-set-key": null,
    "log-source-name": "Audit_Log_Source",
    "log-type": "LOG",
    "name": "AuditObjectCollectionRule",
    "object-name-filters": null,
    "os-bucket-name": "Audit-console-log",
    "os-namespace": "XXXXX",
    "overrides": null,
    "poll-since": "2025-12-16T07:50:00.000Z",
    "poll-till": "2025-12-16T09:10:00.000Z",
    "stream-cursor-time": null,
    "stream-cursor-type": null,
    "stream-id": null,
    "time-created": "2026-01-02T06:18:53.219000+00:00",
    "time-updated": "2026-01-02T06:18:53.219000+00:00",
    "timezone": null
  },
  "etag": "XXXX--gzip"
}

ログ・エクスプローラ確認

対象のソースを選択し、[アクション]より[ログ・エクスプローラで表示]を押下

CLIでルールを作成した時間帯で絞る
ログが取得できていることを確認

より見やすくしたい！

ここまでで、指定した時間帯のログを Log Analytics に取り込むこと自体はできています。
ただし、この時点ではログがほぼ生データのまま表示されており、

「誰が」
「いつ」
「何をしたのか」

といった監査で本当に確認したい情報が、非常に見づらい状態です。

実際にはログはほぼ1つの文字列として扱われており、
このままでは監査や調査には使いづらい状態です。

そのため、次にパーサーを作成してログを構造化していきます。

パーサーの作成

サンプルログの取得

ログ取得対象のバケットからなんでも良いのでログを一つ取得しておく

[パーサー]より[パーサーの作成]を押下

[サンプルログ・コンテンツ]に取得したログを貼り付け
- ログの内容に合わせて[ログ・エントリ]のJSONパスを指定
[既存のフィールドのマップ]を押下
- OCIにて自動でサンプルログに合わせてフィールドを指定してくれます
- すべてのフィールドが自動で抽出されるわけではないため、実際のログ内容を確認しながら必要に応じて調整します。

[パーサー・テスト]より[テストの実行]を押下し、ログからどのようにフィールド名/フィールド値が取れているか確認しつつ調整
パーサーの作成を選択

ログ・ソースへのパーサー紐付け

対象のログ・ソースより[編集]を押下し、作成したパーサーを指定

ログ・アナリティクスのログ削除

パーサーを適用するために一度先ほど取得してログエクスプローラに取り込んだログを削除します

[ストレージ]より[ログのパージ]を押下してログ削除
- [アクティブな使用量]は10GB以上から課金されます。そのため[パージ・ポリシー]で定期的に削除するのも大切です

ObjectCollectionRuleの再適用

ObjectCollectionRuleの確認

作成したルールの確認
- id : [ocid1.loganalyticsobjectcollectionrule.oc1.ap-tokyo-1.XXXXXX]を取得
- lifecycle-state : ACTIVEであることを確認

oci log-analytics object-collection-rule list --compartment-id ocid1.compartment.oc1..XXXX --namespace-name XXX

{
  "data": {
    "items": [
      {
        "collection-type": "HISTORIC",
        "compartment-id": "ocid1.compartment.oc1..XXXXX",
        "defined-tags": {
          "Oracle-Tags": {
            "CreatedBy": "default/ma-watanabe@iret.co.jp",
            "CreatedOn": "2026-01-02T06:18:53.149Z"
          }
        },
        "description": "Rule to collect audit logs from Object Storage",
        "freeform-tags": {},
        "id": "ocid1.loganalyticsobjectcollectionrule.oc1.ap-tokyo-1.XXXXXXX",
        "is-enabled": true,
        "lifecycle-details": null,
        "lifecycle-state": "ACTIVE",
        "log-type": "LOG",
        "name": "AuditObjectCollectionRule",
        "object-name-filters": null,
        "os-bucket-name": "Audit-console-log",
        "os-namespace": "XXXXX",
        "stream-id": null,
        "time-created": "2026-01-02T06:18:53.219000+00:00",
        "time-updated": "2026-01-02T06:18:53.219000+00:00"
      }
    ]
  }
}

ObjectCollectionRuleの削除

取得した[id]を指定してルールの削除を実施

oci log-analytics object-collection-rule delete --namespace-name XXXX --object-collection-rule-id ocid1.loganalyticsobjectcollectionrule.oc1.ap-tokyo-1.XXXX

Are you sure you want to delete this resource? [y/N]: y

ObjectCollectionRuleの作成

新しいパーサーでログを取得し直す

oci log-analytics object-collection-rule create --namespace-name XXXXX --from-json file://create.json

パーサー適用後のログ・エクスプローラ確認

対象のソースを選択し、[アクション]より[ログ・エクスプローラで表示]を押下
- パーサーが適用されてフィールドが増えていることを確認
クエリを調整することで、ログを柔軟に絞り込めます。
- [fields]：表示したいフィールドの指定・除外
- [search]：文字列による簡易検索

これにより

特定ユーザーの操作特定
API の実行履歴
エラーのみ抽出

といった確認が容易になります。

※ クエリの詳細な書き方については本記事では割愛します。

[アクション]より[結果のダウンロード]からCSV形式でフィールドを絞った状態でログファイルを取得することも可能です。

まとめ

本記事では、Object Storage に保存したログを Log Analytics で分析する構成について解説しました。

Audit ログは Object Storage に長期保存
必要な期間だけ Log Analytics に取り込み
パーサーで構造化して検索・分析
不要になったログは削除してコストを抑制

この構成により、

✅ ログは低コストで安全に保存
✅ 調査が必要なときだけ分析
✅ Log Analytics の課金を最小限に抑制

といった、実運用を意識したログ管理構成を実現できます。

運用していく上で、ログの監査と料金はどうしても切り離せないポイントになります。

すべてのログを常に分析対象とするとコストが膨らみがちですが、
今回のように 「保管は Object Storage」「分析は必要なときだけ」 という構成を取ることで、
監査要件を満たしつつ、無駄なコストを抑えた運用が可能になります。
本記事の構成が、実運用を考える際の参考になれば幸いです。