OCI可観測性運用監視実践Vol1｜Connector Hub完全無料E2E

1. この記事について — 3サービス統合の運用監視E2Eと完全0円実演を軸に

OCIのLogging・Monitoring・Connector Hubは、それぞれ単体で見ればAWSのCloudWatch Logs・CloudWatch Metrics/Alarmsに近い役割を持つサービスです。ログを集約するLogging、メトリクスを可視化しアラームを発火させるMonitoring、そしてサービス間でデータを結線するConnector Hub——個々の機能だけを追うなら、AWSでCloudWatchを使ってきたエンジニアにとって理解は難しくありません。しかし、実際の運用監視は「ログを溜めるだけ」「メトリクスを見るだけ」では成立せず、ログからアラームを発火させたり、ログをアーカイブに転送したりといった、サービス間の結線があって初めて意味を持ちます。本記事は、「OCI可観測性・運用監視実践」シリーズの第1弾として、この3サービスを実際に結線し、動く運用監視パイプラインとして構築することを通じて、OCIにおける可観測性実践の勘所を掴んでもらうことを目的としています。

ただし、上記の対応マップはあくまで「大まかな役割の近さ」を示したものであり、名前の対応だけを頼りに設計を進めると足元をすくわれます。特に、AWSでは単一のCloudWatchサービスが担っている範囲が、OCIではLogging・Monitoring・Connector Hubという3つの独立したサービスに分割されているという構造差は、名前の対応表だけでは見えてきません。この構造差の詳細は§3で改めて整理します。

「OCI入門」シリーズが基礎を固める記事群であるのに対し、前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」および本記事は、その基礎の上に実践・運用レベルの深さを積み上げる位置づけの記事群です。サーバーレス(前作)の次に可観測性・運用監視(本記事)を扱うのは、実際のシステム運用が「まずアプリケーションロジックを動かし、その上で監視・運用の仕組みを整える」という順序で進むことが多いためでもあります。

1-1. 本記事のゴール

本記事は、「OCI可観測性・運用監視実践」シリーズの第1弾として、Logging・Monitoring・Connector Hubの3サービスを結線し、実際に動く運用監視E2Eを構築することをゴールとしています。具体的には、Loggingで監査ログ・サービスログ・カスタムログを整理しVCNフローログを実演した上で、Monitoringでメトリクスを確認しAlarmを作成、さらにConnector Hubでログをアーカイブへ転送するシナリオと、ログを起点にアラームを発火させるシナリオという2つの結線を構築します。

前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」では、Functionsのログ連携やNotificationsによる通知は扱ったものの、「これらのログをMonitoringのアラームと連携させることが望ましいが、アラーム設定自体は今後公開予定の可観測性関連記事のスコープとする」という形でLogging/Monitoring/アラーム設定を本記事に委譲していました。本記事は、その委譲された「ログを起点にアラームを発火させる」という結線を、Connector Hubの実演を通じて実際に回収します。

本記事における「動いている状態」の定義は§2-3で改めて明確にしますが、大枠としては、Loggingを有効化しログが実際に流れていること、Monitoringでメトリクスが確認でき閾値超過時にAlarmが発火すること、そしてConnector Hubの2つのシナリオ(Object Storageへのアーカイブ・ログ起点のアラーム発火)がいずれも実際にデータを転送している状態を指します。特に後者のログ起点アラームは、Oracleの公式ドキュメントでも「Alarming on Log Data」という名前でシナリオ化されている構成であり、本記事はこの公式シナリオの日本語実践版としても位置づけられます。

Connector Hubのシナリオをあえて2つ用意しているのは、Connector Hubが「単一の宛先にしかログを流せない」わけではないことを実演で示すためです。1つのソース(Logging)から、アーカイブ用途(Object Storage)と監視用途(Monitoring)という性質の異なる2つの宛先に、それぞれ独立したコネクタでデータを流せることは、実務でログ基盤を設計する際の重要な選択肢になります。

本記事を読み終えると、次の状態になっていることを目指しています。

• Loggingで監査ログ・サービスログ・カスタムログの違いを説明でき、VCNフローログを自分の手で有効化できる
• Monitoringで標準メトリクスを確認し、カスタムメトリクスの投稿とAlarmの作成ができる
• Connector Hubを使い、ログをObject Storageへアーカイブする構成と、ログを起点にアラームを発火させる構成の両方を結線できる
• AWSのCloudWatch Logs/Metrics/Alarms/Kinesis Data Firehoseの実務経験を踏まえて、OCIでの対応実装における構造差(1サービスvs3サービス分割)を説明できる

1-2. 読者像

本記事は、前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」を完遂済みの読者、または前作を未読でも、AWSでCloudWatch Logs・CloudWatch Metrics/Alarms・Kinesis Data Firehoseのいずれかを実務で運用した経験があり、OCIでの対応実装を実務レベルで知りたいエンジニアを主な想定読者としています。

前作を完遂済みの読者は、Functionsのログがすでに出力されている状態からLoggingとの結線を確認できるため、本記事の§4以降をより実感を持って進められます。一方、前作を未読でもAWSでの運用監視経験があれば、本記事単体でも実践に支障はありません。なお、OCIそのものが初めての方(テナンシのサインアップすら済んでいない方)は、まず「OCI入門」シリーズVol1(テナンシ・コンパートメント・Always Free枠)から着手することをお勧めします。

逆に言えば、本記事はTerraformなどIaCツールの経験や、Kinesis Data Firehoseの深い実装知識までは前提としません。console(コンソール)操作を軸に、AWSでの経験を足がかりとしながらOCIのLogging・Monitoring・Connector Hubを理解できる構成としています。Kinesis Data Firehoseに馴染みが薄い読者向けの橋渡しは、§3のAWS対応マップで補います。

特に、次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• OCIのLoggingは、AWSのCloudWatch Logsと同じ感覚でログを収集・検索できるのか
• MonitoringのカスタムメトリクスはAWSのPutMetricData相当のAPIを持っているのか
• Connector Hub(旧Service Connector Hub)は、AWSのKinesis Data Firehose+サブスクリプションフィルタとどこまで役割が近いのか
• 純粋なAlways Freeテナンシだけで、この記事の内容を最後まで実践できるのか
• Logging と Logging Analyticsは何が違い、どちらを使えば誤課金を避けられるのか
• Connector Hubの「コネクタ」は、AWSのサブスクリプションフィルタやEventBridgeルールと比べて、どこまで柔軟にフィルタ・変換できるのか

こうした読者は、多くの場合「まずAWSで動かしてきた監視構成をそのままOCIに置き換えられるか試したい」という動機で本記事にたどり着きます。その際、最初につまずきやすいのが、CloudWatchという1サービスに慣れた感覚のまま、OCI側でも同様に1サービスを探してしまうことです。本記事は、この構造差を早い段階で明示し、名前の類似に惑わされず実際の役割と挙動を基準にサービスを理解し直すことを狙いとしています。

1-3. なぜ今これを書くか

本記事を今このタイミングで書く理由は、大きく2点あります。

1つ目は、「名称の罠」です。本記事で扱うConnector Hubは、もともと「Service Connector Hub」という名称でしたが、現在は「Connector Hub」に改名されています。公式ドキュメントの一部URLパス(/service-connector-hub/)や、過去に書かれた技術記事・フォーラムの投稿には旧称のまま残っているものも多く、読者が旧称「Service Connector Hub」で検索してたどり着くケースが今後も一定数見込まれます。本記事は、この名称変更を明示した上で、新旧どちらの名称で検索してきた読者にも本記事にたどり着いてもらえるよう、旧称にも言及しながら新称「Connector Hub」に統一して解説します。

2つ目——そして本記事の差別化の核となるのが、料金構造です。Logging・Monitoring・Connector Hubの3サービスは、いずれもAlways Free枠内で完結します(Monitoring: ingestion 5億+retrieval 10億datapoints/月無料、Logging: 10GB/月無料、Connector Hub: 2コネクタ無料)。これは、前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」がFunctions・API Gatewayのいずれも Always Free対象外で、実演にPay As You Go環境への移行が前提だったのとは対照的です。本記事は、純粋なAlways Freeテナンシのみで、ログ収集からアラーム通知までの運用監視E2Eを最後まで完全無料で実践できる点を、本記事の題材価値の中核として位置づけています。

この2点に加え、3サービスを1本の記事の中でE2Eとして結線し、かつAlways Free枠の正確な数値まで踏み込んで解説する記事が、現時点のWeb検索では見当たらないことも執筆理由の一つです。個々のサービスの単体チュートリアルは存在しても、Logging→Monitoring→Connector Hubという結線を、AWS実務者向けの対応マップと料金の正確性の両面から一気通貫で扱う記事は稀であり、本記事はこの空白を埋めることを目指します。

→ 前作はこちら: OCI Functions & API Gatewayサーバーレス実践 Vol1 — Logging/Monitoring/アラーム設定への委譲ポイントを本記事で回収します

本記事は、次の範囲についてはあえて深掘りせず、既存記事・今後公開予定の記事に委譲します。いずれも本記事の§4以降(同一記事内)で扱う範囲ではなく、別記事に委譲する範囲である点をご留意ください。

• Notificationsトピック/サブスクリプションの基礎: 前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」を参照してください。本記事では、既存の仕組みとしての利用のみを扱います。
• Logging Analytics・APM・Ops Insights・Database Management: いずれもLoggingやMonitoringと隣接するサービスですが、本記事では言及にとどめ、詳細は将来の発展記事に委譲します。
• IAMポリシーの基礎: 「OCI入門」シリーズVol2を参照してください。VCNの基礎: 「OCI入門」シリーズVol3を参照してください。
• OKEクラスター監視の深掘り: 将来の接続テーマとして扱います。
• Notifications自体のメッセージサイズ上限・配信レート上限などの詳細仕様: 前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」§2で整理済みのため、本記事では再掲しません。

これらの委譲は、本記事のスコープを「Logging・Monitoring・Connector Hubの3サービスによる運用監視E2E」に絞り込むための判断です。個々の隣接サービスの説明に紙幅を割くよりも、3サービスを組み合わせたときに初めて見えてくる設計判断(ログの起点をどこに置くか・アラームの閾値設計・料金構造の組み合わせ)に焦点を当てることを優先しています。

それでは、次の§2で本記事の前提環境と使用技術スタックを整理したうえで、§3で全体アーキテクチャを俯瞰し、実際の構築に進んでいきましょう。

2. 前提・環境・準備

2-1. 前提環境

本記事の実践には、次の前提が必要です。

• 有効なOCIテナンシと、Logging・Monitoring・Connector Hub・Notificationsの各サービスを操作できるIAMポリシーが設定されたユーザーまたはグループ
• テナンシ・コンパートメントの基本的な操作に慣れていること(「OCI入門」シリーズVol1完了が前提)
• VCNフローログの実演に使用する、既存のVCN・サブネット(「OCI入門」シリーズVol3で作成したものを流用可能)
• OCI CLI(バージョン3.x系。本記事の執筆時点の最新安定版で動作確認済み)。カスタムメトリクスの投稿にはOCI CLIまたはSDKのいずれかを使用します
• §7のConnector Hubシナリオで使用するObject Storageバケットを作成できる権限(bucketsリソースタイプへのmanage権限)

これらの前提を、チェックリストの形で整理すると次の通りです。

IAMポリシー: Logging/Monitoring/Connector Hub/Notificationsの操作権限

本記事の実演には、次の4つのリソースタイプに対する権限が必要です。テナンシ全体で管理者権限を持つユーザーであれば追加設定は不要ですが、権限を絞ったグループで作業する場合は、次のようなポリシーを用意します。

Allow group <グループ名> to manage logging-family in compartment <対象コンパートメント名>
Allow group <グループ名> to manage alarms in compartment <対象コンパートメント名>
Allow group <グループ名> to manage metrics in compartment <対象コンパートメント名>
Allow group <グループ名> to manage serviceconnectors in compartment <対象コンパートメント名>
Allow group <グループ名> to manage ons-topics in compartment <対象コンパートメント名>
Allow group <グループ名> to manage buckets in compartment <対象コンパートメント名>
Allow group <グループ名> to manage objects in compartment <対象コンパートメント名>

serviceconnectorsは、Connector Hubが改名される前の「Service Connector Hub」時代からのリソースタイプ名がそのまま使われている点に注意してください。ポリシー文法上のリソースタイプ名は改名の影響を受けておらず、コンソール上の表示名(Connector Hub)とポリシー文中の識別子(serviceconnectors)が一致しないという、名称の罠の一例でもあります。

なお、OCIのポリシー検証レベルは、権限の弱い順にinspect・read・use・manageの4段階です。本記事では実演の簡潔さを優先してmanageレベルで統一していますが、閲覧のみを目的とするユーザーにはreadレベルで十分な場面もあります。本番運用でグループごとに権限を分ける場合は、この4段階を使い分けることで、必要最小限の権限設計が可能です。

Notificationsトピックの再利用可否

前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」を完遂済みの読者は、そこで作成したNotificationsトピック(oci-functions-apigw-vol1-topic)がすでに存在している状態です。本記事のAlarm通知先には、このトピックを再利用しても、新規に専用トピック(oci-observability-vol1-topic)を作成しても、どちらでも構いません。ただし、複数の用途で1つのトピックを共有すると、後から「どのAlarmがどの通知に対応するか」が追いにくくなるため、本記事では新規トピックの作成を基本の手順として扱い、既存トピックを再利用する場合の注意点は§6で補足します。

コンパートメント設計の考え方

本記事では、前作と同様、監視対象リソースと監視用リソース(ログ・アラーム・コネクタ)を同一のコンパートメントにまとめる構成を前提とします。本番運用では、監視系リソースを専用のコンパートメントに分離し、IAMポリシーで権限を最小化する構成が一般的ですが、本記事はVol1として構成をシンプルに保ち、コンパートメント分離の設計は今後公開予定のOCIセキュリティ関連記事に委譲します。

本記事で使用するリソース命名規則

本記事の§4以降で作成するリソースは、次の命名規則に統一します。読者が実際に手を動かす際、どのリソースがどの役割を持つか把握しやすくするための工夫です。

VCNフローログの有効化要件

VCNフローログは、サブネットレベルまたはVNICレベルのいずれかで有効化できます。サブネットレベルで有効化すると、そのサブネット上の既存および将来作成されるすべてのVNICのトラフィックが記録対象になり、VNICレベルで有効化すると、特定のVNIC(特定のインスタンスやネットワークロードバランサーなど)のみが対象になります。本記事では、まずサブネットレベルでの有効化を扱い、対象を絞り込みたい場合の選択肢としてVNICレベルにも触れます。

フローログの記録先には、Loggingのログ グループが必要です。1つのTCPコネクションに対して、インバウンド(ingress)とアウトバウンド(egress)それぞれ1件ずつ、合計2件のログレコードが生成される点は、実際のログを確認する際に押さえておくべきポイントです。各レコードは、1つのVNICについて、1方向の通信を表します。

カスタムログの取り込み方法

カスタムログは、API経由での直接投稿と、Unified Monitoring Agent(エージェントベースの収集)の2つの方法で取り込めます。本記事では、実演のしやすさを優先し、API経由での直接投稿を扱います。エージェントベースの収集は、オンプレミスサーバーや複数インスタンスからの継続的なログ収集に向いた方式で、詳細は将来のOCI運用エージェント関連記事に委譲します。

本記事は、次の範囲についてはあえて深掘りせず、既存記事に委譲します。

• VCN・サブネット・ゲートウェイの基礎: 「OCI入門」シリーズVol3を参照してください。本記事ではVCNフローログの有効化要件のみを扱います。
• IAMポリシーの基礎: 「OCI入門」シリーズVol2を参照してください。本記事では、Logging/Monitoring/Connector Hub/Notifications操作に必要な実例のみを扱います。
• コンパートメント分離設計: 今後公開予定のOCIセキュリティ関連記事に委譲します。
• Object Storageバケットのライフサイクル管理(自動削除・階層化ストレージへの移行等): 「OCI入門」シリーズVol5を参照してください。本記事ではアーカイブ先としての基本的なバケット作成のみを扱います。

なお、シナリオAのアーカイブ先となるObject Storageバケット自体は、本記事の準備段階では作成せず、§7でConnector Hub実践の一部として作成します。これは、バケットを先に作っておくと、読者が「なぜこのタイミングでこのリソースが必要なのか」という文脈を見失いやすいためで、前作でも同様に「利用する直前に作成する」という方針を採用しています。

2-2. 使用技術スタック

本記事で使用する3サービスは、いずれもOCIのマネージド型サービスであり、インフラの管理・パッチ適用・スケーリングをOracle側が担う点で共通しています。一方で、各サービスが担う役割(ログの集約・メトリクスの可視化とアラーム・サービス間のデータ転送)は明確に異なります。基盤と東京リージョン対応状況、Always Free枠数値は、次の通りです(2026年8月時点の公式ドキュメント準拠)。

【重要】上記の通り、Logging・Monitoring・Connector Hubの3サービスはいずれもAlways Free対象であり、本記事のVol1として構築する規模(Logグループ1つ・カスタムメトリクス数個・Alarm1つ・コネクタ2つ)であれば、無料枠を超過する可能性は極めて低いと考えられます。ただし、Connector Hub自体が無料でも、転送先がObject StorageやMonitoringである場合はそれぞれの消費分が課金対象になる点には注意してください。本記事で使用する範囲では、Object Storageのストレージ使用量・Monitoringのingestion/retrievalいずれも、Always Free枠内に収まります。

Logging: 監査ログ・サービスログ・カスタムログの3層構造

Loggingは、テナンシ内のすべてのログを集約する単一の窓口です。ログは、発生源に応じて監査ログ(Audit Log)・サービスログ(Service Log)・カスタムログ(Custom Log)の3層に分類されます。監査ログはOCI Audit serviceが自動的に発行するログで、既定で有効です。サービスログは、API Gateway・Object Storage・VCN(フローログ)などOCIネイティブサービスが発行するログで、リソースごとに有効化が必要です。カスタムログは、自社アプリケーションやオンプレミス環境からUnified Monitoring AgentまたはAPI経由で取り込むログです。VCNフローログはサービスログの一種として位置づけられ、本記事の§4で実際に有効化します。

Monitoring: メトリクス名前空間とAlarmの関係

Monitoringは、「名前空間(namespace)」ごとにメトリクスを整理します。OCIネイティブサービスは、それぞれ専用の名前空間(例: oci_computeagent)に標準メトリクスを自動投稿しますが、本記事ではこれに加えて、独自の名前空間にカスタムメトリクスを投稿する手順も扱います。Alarmは、特定の名前空間・メトリクス・統計(平均/最大/合計など)に対して閾値条件を設定し、条件を満たした際にNotificationsトピックへ通知を発行する仕組みです。

ログの保持期間とメトリクスの解像度

Loggingのログ保持期間は、30日刻みで最大180日まで設定できます。監査ログのみ既定の保持期間が90日である点は、他のログ種別と異なるため注意してください。Monitoringのメトリクス解像度(resolution)は既定で1分(1m)であり、クエリ時には1分〜60分・1時間〜24時間・1日の範囲で解像度を指定できます。本記事のカスタムメトリクス投稿・Alarm設定は、いずれも既定の1分解像度で実演します。

Connector Hub: コネクタの構成要素

Connector Hubの「コネクタ」は、ソース(データの取得元)・オプションのタスク(Functionsタスク・ログフィルタタスク)・ターゲット(データの配信先)という3要素で構成されます。ソースにはLogging・Monitoring・Queue・Streamingが指定でき、ターゲットにはFunctions・Log Analytics・Monitoring・Notifications・Object Storage・Streamingが指定できます。本記事では、ソースをLoggingに固定し、ターゲットをObject Storage(シナリオA)・Monitoring(シナリオB)とする2つのコネクタを構築します。コネクタ内のデータ移動は「少なくとも1回(at least once)」の配信保証で行われる点も、AWSのKinesis Data Firehoseの配信保証モデルと比較する上で押さえておくべきポイントです。

本記事の§4以降で使用するOCI CLIコマンドグループ

本記事の各章で実際に使用するOCI CLIのコマンドグループを、あらかじめ一覧化しておきます。個別のコマンドオプションは各章で扱うため、ここでは「どの章でどのコマンドグループを使うか」の見取り図として押さえてください。

schというコマンドグループ名にも、旧称「Service Connector Hub」の名残が見られます。コンソールの表示名(Connector Hub)・IAMポリシーのリソースタイプ名(serviceconnectors)・CLIのコマンドグループ名(sch)の3箇所で、新旧の名称が混在している状態は、本記事が「名称の罠」として繰り返し注意を促す理由の一つです。

2-3. ゴール状態の定義

本記事における「動作している状態」とは、次の4つの要素がいずれも実際にデータを伴って動作し、期待した結果を得られる状態を指します。

• Logging: 監査ログ・サービスログ(VCNフローログ含む)・カスタムログがLogグループに収集され、Logging上で検索・確認できる
• Monitoring: 標準メトリクスがダッシュボードで確認でき、カスタムメトリクスの投稿が成功し、投稿した値がMonitoring上で確認できる
• Alarm: 閾値を超えた際にAlarmが発火し、Notificationsトピック経由で通知が届く
• Connector Hub: シナリオA(Logging→Object Storage)でログがアーカイブされ、シナリオB(Logging→Monitoring)でログを起点にアラームが発火する

この4つの状態を、それぞれ次の観点から確認できることをもって「動作している」と判定します。

この4つの状態を、本記事の§4以降で実際に構築しながら確認していきます。§4〜§7ではそれぞれの要素の構築手順とあわせて、上記の確認項目をどのように検証するかも扱います。

AWS実務者向けに、この「動作している状態」をCloudWatch中心の構成と対比すると、次のようになります。

この対比が示す通り、「確認する対象」自体はAWSとOCIで大きくは変わりません。異なるのは、CloudWatchという1つのコンソールで完結する感覚に対し、OCIではLogging・Monitoring・Connector Hubという3つのコンソール画面を横断して確認が必要になる点です。この構造差を踏まえた画面遷移の勘所は、§4以降の各章で実際の操作とあわせて解説します。

前提環境の整理はここまでです。IAMポリシー・使用技術スタック・ゴール状態の定義という3つの観点を押さえたことで、§4以降で実際にリソースを作成していく準備が整いました。

次の§3では、ここまで整理した3サービスが、AWSのCloudWatchとどう対応するのかを構造的に俯瞰します。

3. AWS対応マップ全体像 — CloudWatchの3分割構造

AWSでは、ログ収集・メトリクス可視化・アラーム発火・他サービスへの転送といった運用監視の機能が、CloudWatchという1つのサービス名の下にまとまっています(転送についてはKinesis Data Firehoseと組み合わせる形が一般的です)。一方OCIでは、この範囲がLogging・Monitoring・Connector Hubという3つの独立したサービスに分割されています。本章では、fig03の対応関係図に沿って、この「1サービスvs3サービス」という構造差を、機能単位で整理します。

CloudWatch Logs ↔ Logging

CloudWatch Logsがロググループ・ログストリームという階層でログを整理するのに対し、Loggingはログ グループの配下に、監査ログ・サービスログ・カスタムログという発生源ベースの分類でログを整理します(詳細は§2-2・§4)。AWSでLambdaやAPI Gatewayの実行ログをCloudWatch Logsで確認してきた読者にとって、「ロググループを作り、そこにログを流し込む」という基本の使用感自体は共通していますが、OCIでは発生源による3分類が前面に出てくる点が異なります。

CloudWatch Metrics/Alarms ↔ Monitoring/Alarms

CloudWatchでは、Metrics(収集・可視化)とAlarms(閾値判定・通知)が同一サービス内の機能として統合されていますが、OCIでもMonitoringサービスの中にMetricsとAlarmsの両方が含まれており、この点はCloudWatchと近い構造です。カスタムメトリクスの投稿は、AWSのPutMetricData APIに相当する機能がMonitoringにも用意されており、名前空間ベースでメトリクスを整理する点も共通しています(§2-2で述べた通り、既定の解像度はAWSの1分間隔と同様、OCIも1分です)。

Kinesis Data Firehose(+サブスクリプションフィルタ) ↔ Connector Hub

AWSでログやメトリクスを他サービスへ転送する場合、CloudWatch Logsのサブスクリプションフィルタでログストリームをフィルタし、Kinesis Data Firehose経由でS3やOpenSearch Serviceなどへ配信する構成が一般的です。OCIでは、この役割をConnector Hubが単独で担います。ソース(Logging/Monitoring等)・タスク(フィルタ・変換)・ターゲット(Object Storage/Monitoring等)という3要素を1つのコネクタ定義の中で完結できる点は、AWS側で「サブスクリプションフィルタ」と「Kinesis Data Firehose配信ストリーム」という2つの異なるリソースを組み合わせる構成と比べて、設定箇所がシンプルにまとまっているという特徴があります。

「1サービスvs3サービス」という構造差が意味すること

この構造差は、単なる名前の違いではなく、画面遷移と設計判断の両方に影響します。AWSでは、CloudWatchコンソールの中でログ・メトリクス・アラームを横断的に確認できますが、OCIでは、Logging・Monitoringという2つのコンソール画面を行き来しながら状況を把握する必要があります。また、ログを他サービスへ転送する設計を検討する際も、AWSでは「サブスクリプションフィルタをどう書くか」が主な検討対象になるのに対し、OCIでは「どのソースからどのターゲットへ、どのタスクを挟んで転送するか」というConnector Hubのコネクタ設計が検討の中心になります。この構造差を踏まえた上で、次の§4からは、実際にLoggingの3層構造を有効化するところから、運用監視E2Eの構築を始めていきます。

4. Logging実践 — 監査/サービス/カスタムログの3層整理 + VCNフローログ実演

本章では、§2-2で整理したLoggingの3層構造(監査ログ・サービスログ・カスタムログ)を実際にコンソール・CLIで確認・操作し、その一環としてVCNフローログを有効化します。

4-1. Logグループの作成

Logging配下のリソースは、まずLogグループという入れ物にひもづけて整理します。§2-1の命名規則に従い、本記事専用のLogグループを作成します。

oci logging log-group create \
  --compartment-id <対象コンパートメントOCID> \
  --display-name oci-observability-vol1-loggroup

作成後、レスポンスに含まれるid(Logグループの OCID)を控えておきます。以降の§4-2・§4-3で、このLogグループ配下にサービスログ(VCNフローログ)とカスタムログを作成していきます。

4-2. 監査ログの確認 — 既定で有効な自動収集ログ

Loggingの3層のうち、監査ログ(Audit Log)はテナンシ作成時から既定で有効になっており、ユーザーが個別に有効化する操作は不要です。コンソールでLogging > Log Groupsを開くと、テナンシのルートコンパートメントに_Auditという名前のシステムLogグループが存在し、コンソール操作・API呼び出しの記録が自動的に蓄積されています。

コンソールのLogging検索画面で、対象コンパートメントを_Audit、Logグループを_Auditに切り替えると、直近の操作履歴が確認できます。§2-2で述べた通り、監査ログの既定保持期間は90日で、他のログ種別(既定30日)より長く設定されている点に注意してください。監査ログ自体は今回作成したoci-observability-vol1-loggroupとは別枠で自動収集される点も、後述する§4-5・§9の「Logging と Logging Analyticsの区別」とあわせて意識しておくべきポイントです。

4-3. VCNフローログの有効化 — サブネットレベル

続いて、サービスログの実演として、VCNフローログをサブネットレベルで有効化します。前提の対象VCN・サブネットは、§2-1で述べた通り「OCI入門」シリーズVol3で作成したものを流用します。

コンソールでは、Networking > Virtual Cloud Networks > 対象VCN > 対象サブネットの詳細画面を開き、「Logs」タブから「Enable Log」を選択します。Log Categoryに「Flow Logs」を選び、ログの格納先として§4-1で作成したoci-observability-vol1-loggroupを指定し、ログの表示名(例: oci-observability-vol1-vcn-flowlog)を入力すると有効化されます。

CLIで同等の操作をする場合は、対象がサブネットのフローログであることをconfigurationのsourceに指定してからログを作成します。

oci logging log create \
  --log-group-id <Logグループ OCID> \
  --display-name oci-observability-vol1-vcn-flowlog \
  --log-type SERVICE \
  --is-enabled true \
  --configuration '{
 "source": {
"sourceType": "OCISERVICE",
"service": "flowlogs",
"category": "all",
"resource": "<対象サブネット OCID>"
 },
 "compartmentId": "<対象コンパートメントOCID>"
  }'

有効化後、対象サブネット上のインスタンスに対してSSH接続やアウトバウンド通信を発生させると、数分以内にLoggingの検索画面でフローログのエントリが確認できるようになります。§2-2で整理した通り、1つのTCPコネクションに対してインバウンド(ingress)・アウトバウンド(egress)それぞれ1件、合計2件のログレコードが生成される点を確認しながら進めてください。

4-4. カスタムログの投稿 — API経由での直接投稿

最後に、カスタムログの実演として、API経由でログエントリを直接投稿します。まず、カスタムログ用のログを作成します。

oci logging log create \
  --log-group-id <Logグループ OCID> \
  --display-name oci-observability-vol1-customlog \
  --log-type CUSTOM \
  --is-enabled true

作成したログのOCIDを控えたら、Logging IngestionサービスのPutLogs APIをCLI経由(oci logging-ingestion put-logs)で呼び出し、ログエントリを投稿します。投稿するJSONのひな形は、--generate-param-json-inputオプションで生成できます。

oci logging-ingestion put-logs --generate-param-json-input log-entry-batches > log-entry-batches.json

生成されたひな形を編集し、source(発生源を表す任意の文字列。例: oci-observability-vol1-customlog-source)・type(ログの種類を表す文字列)・subject・投稿する各エントリのdata(ログ本文)・id・timeを設定した上で、次のコマンドで投稿します。

oci logging-ingestion put-logs \
  --log-id <カスタムログ OCID> \
  --specversion "1.0" \
  --log-entry-batches file://log-entry-batches.json

投稿後、Loggingの検索画面でLogグループをoci-observability-vol1-loggroup、ログをoci-observability-vol1-customlogに絞り込むと、投稿したエントリが確認できます。

4-5. Logging と Logging Analyticsの区別(誤課金防止のさわり)

ここまで扱ってきたLoggingは、ログの収集・保存・検索を担うサービスです。一方、コンソールのメニューには「Logging Analytics」という類似名称の別サービスが存在し、ログの高度な分析(相関分析・機械学習ベースの異常検知など)を担いますが、これはLoggingとは別課金・別サービスです。本記事の実演範囲(§4〜§7)では、Logging Analyticsを有効化する操作は一切登場しません。両者の違いの詳細と、誤って有効化してしまった場合の注意点は、§9で改めて整理します。

5. Monitoring実践 — メトリクス確認 + カスタムメトリクス投稿

5-1. 標準メトリクスの確認 — メトリクスエクスプローラ

コンソールでObservability & Management > Monitoring > Metrics Explorerを開くと、名前空間ごとにメトリクスを選択して可視化できます。前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」や「OCI入門」シリーズVol4を完了済みで、コンピュートインスタンスが稼働中の読者は、名前空間oci_computeagentのCpuUtilizationメトリクスを選択すると、標準メトリクスが自動的に収集されている様子を確認できます。稼働中のインスタンスがない場合でも、名前空間の切り替えとメトリクスの選択という操作自体は、Metrics Explorer上でいつでも体験できます。

メトリクスの選択画面では、統計(統計関数)として平均(Mean)・最大(Max)・合計(Sum)などを切り替えられ、§2-2で整理した通り、解像度(resolution)は既定で1分です。クエリ時には、1分〜60分・1時間〜24時間・1日の範囲で解像度を変更でき、長期間のトレンドを確認したい場合は粗い解像度に切り替えます。

5-2. カスタムメトリクスの投稿 — PutMetricData相当

続いて、独自の名前空間にカスタムメトリクスを投稿します。まず、投稿するJSONのひな形を生成します。

oci monitoring metric-data post --generate-param-json-input metric-data > metric-data.json

生成されたひな形を編集し、名前空間・メトリクス名・データポイントを設定します。名前空間には、OCIネイティブサービスが使うoci_・oracle_という予約プレフィックスを使えない点に注意してください。

[
  {
 "namespace": "observability_vol1_custom",
 "compartmentId": "<対象コンパートメントOCID>",
 "name": "sample_requests",
 "dimensions": {
"resource": "handson"
 },
 "datapoints": [
{
  "timestamp": "2026-08-03T00:00:00.000Z",
  "value": 1
}
 ]
  }
]

投稿は、標準のtelemetryエンドポイントではなく、telemetry-ingestionエンドポイントに対して行います。

oci monitoring metric-data post \
  --metric-data file://metric-data.json \
  --endpoint https://telemetry-ingestion.ap-tokyo-1.oraclecloud.com

投稿するデータポイントのtimestampは、現在時刻から過去2時間以内・未来10分以内でなければ受け付けられません。あらかじめ用意しておいたJSONファイルをそのまま使い回すと、この時間窓を外れて投稿が失敗するため、実行の都度タイムスタンプを更新してください。

投稿後、§5-1のMetrics Explorerで、名前空間observability_vol1_custom・メトリクス名sample_requestsを選択すると、投稿した値がグラフ上に表示されます。

5-3. メトリクスとAlarmの関係 — 次章への橋渡し

§2-2で述べた通り、Alarmは特定の名前空間・メトリクス・統計に対して閾値条件を設定し、条件を満たした際にNotificationsへ通知を発行する仕組みです。本章で確認した標準メトリクス(§5-1)と投稿したカスタムメトリクス(§5-2)は、いずれも次章のAlarm作成の対象にできます。次の§6では、§5-2で投稿したカスタムメトリクスを題材に、実際にAlarmを作成し、閾値超過時にNotificationsへ通知が届くところまで実演します。

6. Alarm作成 — 閾値設定 + Notifications通知

本章では、§5で投稿したカスタムメトリクスを題材に、閾値ベースのAlarmを作成し、Notifications経由で通知を届けるところまでを実演します。Notificationsのトピック・サブスクリプションといった基礎概念そのものは、前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」§5-1・§7-4ですでに扱っているため、本章ではその基礎説明を前作に委譲し、既存の仕組みとしての利用のみを扱います。

6-1. Notificationsトピックの準備

§2-1で述べた通り、Alarmの通知先には、前作で作成したトピック(oci-functions-apigw-vol1-topic)を再利用しても、新規に専用トピックを作成しても構いません。本記事では、Alarmの発火元(本記事で新規作成したリソース)と通知先の対応を追いやすくするため、新規トピックの作成を基本の手順とします。

oci ons topic create \
  --compartment-id <対象コンパートメントOCID> \
  --name oci-observability-vol1-topic

作成したトピックに対して、通知の受け取り先を登録します。

oci ons subscription create \
  --topic-id <トピック OCID> \
  --protocol EMAIL \
  --subscription-endpoint <通知先メールアドレス>

前作§5-1で扱った通り、emailサブスクリプションは作成直後PENDING状態であり、登録したメールアドレス宛ての確認メール内のリンクをクリックしてACTIVE状態に変更する操作を忘れると、後続の動作確認で通知が届きません。既存トピックを再利用する場合は、サブスクリプションがすでにACTIVE状態であることを確認した上で次に進めます。

6-2. Alarmの作成 — 閾値設定

Alarmの通知先(--destinations)は、宛先となるNotificationsトピックのOCIDをJSON配列として指定します。

oci monitoring alarm create --generate-param-json-input destinations > destinations.json

生成されたひな形を編集し、§6-1で作成したトピックのOCIDを設定します。

["<Notificationsトピック OCID>"]

続いて、§5-2で投稿したカスタムメトリクス(名前空間observability_vol1_custom・メトリクス名sample_requests)を対象に、Alarmを作成します。

oci monitoring alarm create \
  --compartment-id <対象コンパートメントOCID> \
  --metric-compartment-id <対象コンパートメントOCID> \
  --display-name oci-observability-vol1-alarm \
  --namespace observability_vol1_custom \
  --query-text 'sample_requests[1m].count() > 0' \
  --severity CRITICAL \
  --destinations file://destinations.json \
  --is-enabled true \
  --pending-duration PT1M

--query-textのMQL(Monitoring Query Language)式は、対象メトリクス・評価間隔([1m])・統計関数(count())・トリガー条件(> 0)の4要素で構成されます。§2-2で述べた既定の解像度(1分)と一致する間隔を指定している点も確認しておいてください。--pending-durationは、条件を満たした状態がどれだけ継続したら実際にFIRING状態へ遷移するかを指定するパラメータで、ここでは1分(PT1M)としています。

6-3. 動作確認 — Alarmの発火とNotificationsへの通知

§5-2の手順で、対象メトリクスに新しいデータポイントを投稿すると、数分以内にAlarmのステータスがコンソール(Monitoring > Alarms)でFIRINGに変化します。あわせて、§6-1で登録したサブスクリプション先(email)に、Notifications経由で通知メールが届いていることを確認してください。

【重要】Alarmが一度FIRINGになった後、条件を満たさなくなる(この例では、評価間隔内に新しいデータポイントが投稿されなくなる)と、ステータスは自動的にOKに戻ります。継続的に通知を受け取りたい場合は、--repeat-notification-duration(例: PT2H)を指定することで、FIRING状態が継続している間、一定間隔で通知を再送させることもできます。本記事では動作確認のしやすさを優先し、このオプションは既定値のままとしています。

7. Connector Hub実践 — 2シナリオ結線

本章では、§2-2で整理したConnector Hub(旧称:Service Connector Hub)の「ソース・タスク・ターゲット」という構成要素を使い、実際に2つのシナリオを結線します。§7-1ではLoggingのログをObject Storageへアーカイブし、§7-2では公式ドキュメントが「Alarming on Log Data」として紹介するシナリオの日本語実践版として、ログを起点にアラームを発火させます。

まず、Connector Hubの名称について改めて触れておきます。本サービスは、かつて「Service Connector Hub」という名称でしたが、現在は「Connector Hub」に改名されています。§2-2で見た通り、IAMポリシーのリソースタイプ名(serviceconnectors)やCLIのコマンドグループ名(sch)には旧称の名残がそのまま残っており、コンソールの表示名だけを新称に統一しても、ポリシー文やCLIコマンドを書く際には旧称ベースの識別子を使い続ける必要がある点は、実際に手を動かすと強く実感できます。

7-1. シナリオA: Logging → Object Storageアーカイブ

まず、アーカイブ先となるObject Storageバケットを作成します(§2-1で述べた通り、バケットは利用直前のこのタイミングで作成します)。

oci os bucket create \
  --compartment-id <対象コンパートメントOCID> \
  --name oci-observability-vol1-bucket

続いて、コネクタのsource・targetのJSONひな形を生成します。

oci sch service-connector create --generate-param-json-input source > source-archive.json
oci sch service-connector create --generate-param-json-input target > target-archive.json

source-archive.jsonには、§4で有効化したVCNフローログ(Logグループoci-observability-vol1-loggroup配下のログoci-observability-vol1-vcn-flowlog)を指定します。

{
  "kind": "logging",
  "logSources": [
 {
"compartmentId": "<対象コンパートメントOCID>",
"logGroupId": "<Logグループ OCID>",
"logId": "<VCNフローログ OCID>"
 }
  ]
}

target-archive.jsonには、作成したバケットを指定します。

{
  "kind": "objectStorage",
  "bucketName": "oci-observability-vol1-bucket",
  "objectNamePrefix": "vcn-flowlog-archive/"
}

これらのJSONを使い、コネクタを作成します。

oci sch service-connector create \
  --compartment-id <対象コンパートメントOCID> \
  --display-name oci-observability-vol1-connector-archive \
  --source file://source-archive.json \
  --target file://target-archive.json

コネクタの状態は、作成直後は一時的にCREATINGとなり、その後ACTIVEに遷移するとデータ転送が始まります。コンソールでも作成が可能で、初回作成時にObject Storageへの書き込み権限を許可するポリシーの自動生成を提案されるので、許可して進めます。ACTIVE状態に遷移した後、対象サブネットへの通信を発生させてしばらく待つと、oci-observability-vol1-bucketバケットのvcn-flowlog-archive/プレフィックス配下に、フローログのアーカイブオブジェクトが作成されます。

7-2. シナリオB: Logging → Monitoring(ログ起点アラーム)

続いて、公式ドキュメントの「Alarming on Log Data」シナリオの実践版として、VCNフローログのうち拒否された通信(REJECTされたトラフィック)を起点に、Monitoringのカスタムメトリクスへ変換し、アラームを発火させる結線を構築します。

まず、コネクタのsourceには§7-1と同じVCNフローログを指定しますが、今回はログの内容でフィルタし、拒否された通信のみを対象にします。フィルタは、ログのペイロード中のdata.actionフィールドがREJECTであることを条件にします。

{
  "kind": "logging",
  "logSources": [
 {
"compartmentId": "<対象コンパートメントOCID>",
"logGroupId": "<Logグループ OCID>",
"logId": "<VCNフローログ OCID>"
 }
  ],
  "logRuleTasks": [
 {
"condition": "data.action = 'REJECT'"
 }
  ]
}

ターゲットには、Object Storageではなく、Monitoringのカスタムメトリクスを指定します。ターゲットのkindはmetricsで、変換先のメトリクス名前空間・メトリクス名を指定します。

{
  "kind": "metrics",
  "compartmentId": "<対象コンパートメントOCID>",
  "metricNamespace": "observability_vol1_vcnlogs",
  "metric": "rejectedtraffic"
}

oci sch service-connector create \
  --compartment-id <対象コンパートメントOCID> \
  --display-name oci-observability-vol1-connector-alarm \
  --source file://source-alarm.json \
  --target file://target-alarm.json

このコネクタがACTIVEになると、拒否された通信が発生するたびに、Monitoringの名前空間observability_vol1_vcnlogs・メトリクスrejectedtrafficにデータポイントが投稿されるようになります。最後に、このメトリクスを起点にアラームを作成します。手順は§6で扱ったAlarm作成の応用で、クエリの対象メトリクスを変更するだけです。

oci monitoring alarm create \
  --compartment-id <対象コンパートメントOCID> \
  --metric-compartment-id <対象コンパートメントOCID> \
  --display-name oci-observability-vol1-alarm-logdata \
  --namespace observability_vol1_vcnlogs \
  --query-text 'rejectedtraffic[1m].count() > 0' \
  --severity CRITICAL \
  --destinations file://destinations.json \
  --is-enabled true \
  --pending-duration PT1M

destinations.jsonは§6で作成したものと同じNotificationsトピック(oci-observability-vol1-topic)のOCIDを指しているため、既存のファイルを再利用できます。動作確認には、対象サブネットに向けて意図的に拒否される通信(セキュリティリストで許可していないポートへの接続など)を発生させ、数分後にAlarmのステータスがFIRINGに変化し、Notifications経由で通知が届くことを確認します。

8. 完全0円実演のまとめ — 前作(課金必須)との対照

本章では、§4〜§7で実際に構築した運用監視E2Eが、Always Freeテナンシのみで完全に0円で完結することを、サービスごとに整理します。

§2-2で整理した通り、Logging・Monitoring・Connector Hubの3サービスは、いずれもAlways Free対象です。本記事のVol1規模(Logグループ1つ・カスタムログ1つ・カスタムメトリクス1種類・Alarm2つ・コネクタ2つ)であれば、無料枠を大きく下回る使用量にとどまります。§7-1で使用したObject Storageも、Always Free対象のStandardティア10GB枠の範囲に収まります。

この点は、前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」とは対照的です。同作品の§7で整理された通り、前作が扱ったFunctions・API GatewayのいずれもAlways Free対象リソースではなく、実演にはPay As You Goへの移行(または一定額の課金発生の許容)が前提でした。本記事は、それとは逆に、可観測性・運用監視という「地味だが実務では欠かせない」領域を、追加コストなしで最後まで実践できる点を、本記事の題材価値の中核として位置づけています。

【重要】ただし、Always Free枠内に収まるかどうかは、あくまで本記事が示した規模(Vol1のハンズオン規模)を前提とした目安です。本番運用でログ量・メトリクス量・コネクタ数が増える場合は、§2-2の表で示した各サービスの無料枠の数値を基準に、事前に見積もっておくことを推奨します。特にLoggingの10GB/月は、監査ログや複数のサービスログを本格運用で有効化すると比較的早く消費される枠であるため、注意が必要です。

9. 名称の罠 — Connector Hub改称 / Logging と Logging Analyticsの区別

本章では、本記事のタイトルにも掲げた「名称の罠」を、2つの観点から整理します。1つはConnector Hubの改称、もう1つはLoggingとLogging Analyticsの区別です。

9-1. Connector Hub改称 — 新旧名称の使い分け

§1-3で述べた通り、Connector Hubはもともと「Service Connector Hub」という名称でした。§2-2・§7で実際に手を動かした通り、この改称の影響は次の3箇所で異なる形跡を残しています。

このように、コンソールの表示名だけを見て「Connector Hub」という名称に慣れても、実際にIAMポリシーを書いたりCLIを操作したりする段階でserviceconnectorsやschという旧称ベースの識別子に遭遇し、戸惑うケースが起こり得ます。SEOの観点でも、旧称「Service Connector Hub」で検索して本記事にたどり着く読者が一定数見込まれるため、本記事では新称「Connector Hub」を主体としつつ、随所で旧称にも言及する形を取っています。

9-2. Logging と Logging Analyticsの区別 — 誤課金誘導の防止

§4-5で触れた通り、Loggingと類似名称の「Logging Analytics」は、まったく別のサービスです。両者の違いを整理すると、次のようになります。

【重要・誤課金防止】コンソールのメニューで「Logging」の近くに「Logging Analytics」という項目が並んでいるため、操作に不慣れなうちは誤って後者を有効化してしまうケースがあります。Logging Analyticsは、専用のログソース登録を伴う別課金体系のサービスであり、本記事の§4〜§7で構築した内容には一切関与しません。本記事の実演範囲でLoggingの検索・確認ができれば十分であり、Logging Analyticsを有効化する必要はない点を、改めて強調しておきます。

10. 落とし穴・まとめ・次のステップ

10-1. 本記事全体の落とし穴

本記事を通じて実際につまずきやすいポイントを、章をまたいで整理します。

10-2. まとめ

本記事では、OCIのLogging・Monitoring・Connector Hubという3サービスを結線し、ログ収集からアラーム通知までの運用監視E2Eを、Always Freeテナンシのみで完全無料で構築しました。§4でLoggingの3層構造とVCNフローログを、§5でMonitoringのメトリクス確認とカスタムメトリクス投稿を、§6でAlarm作成とNotifications通知を、§7でConnector Hubによる2シナリオ(アーカイブ・ログ起点アラーム)の結線を、それぞれ実演しました。§7-2では、前作「OCI Functions & API Gatewayサーバーレス実践 Vol1」§8-5で保留していた「ログを起点にアラームを発火させる」という結線を、Connector Hubの公式シナリオ「Alarming on Log Data」の実践を通じて回収しています。

AWS実務者向けには、§3で整理した通り、CloudWatchという1サービスに集約されている機能が、OCIではLogging・Monitoring・Connector Hubという3つの独立したサービスに分割されているという構造差が、本記事全体を通じて繰り返し確認できたはずです。この構造差を意識できれば、CloudWatchで培った運用監視の勘所を、OCI側でもスムーズに読み替えられるようになります。

10-3. 次のステップ — 将来の発展記事へ

本記事は、次の範囲についてはあえて深掘りせず、既存記事・今後公開予定の記事に委譲してきました(§1-3・§2-1参照)。今後、次のような発展テーマの記事を通じて、本記事で扱いきれなかった領域を掘り下げていく予定です。

• Logging Analytics: §9で「別サービス・別課金」と整理した通り、収集済みログの相関分析・機械学習ベースの異常検知を担う上位サービスです。本記事のLoggingで収集したログを、Logging Analyticsに取り込んでさらに分析する構成は、将来の発展記事のテーマとなります。
• APM(Application Performance Monitoring): アプリケーションレベルのトレース・パフォーマンス分析を扱う、本記事のMonitoring(インフラ/サービスレベルのメトリクス)とは異なる階層のサービスです。
• Ops Insights: リソースの容量計画・キャパシティ分析に特化したサービスで、本記事のMonitoring(リアルタイムのメトリクス確認)とは目的が異なります。
• Database Management: データベース固有の監視・診断を担うサービスで、本記事の汎用的な運用監視(Logging/Monitoring/Connector Hub)とは別軸の専門領域です。
• OKEクラスター監視の深掘り: §2-1で「将来の接続テーマ」として言及した通り、Kubernetesクラスター特有のメトリクス・ログの扱いは、本記事の枠組みを応用しつつも専用の解説が必要な領域です。

これらはいずれも、本記事で構築した「Logging・Monitoring・Connector Hubによる基本的な運用監視E2E」を土台として、より専門的な観測性の領域へ踏み込んでいくテーマです。本記事の内容を実践し終えた読者であれば、これらの発展テーマに進むための基礎は十分に身についているはずです。