OCI可観測性発展編Vol1｜LA/APM/Ops Insights料金と体系化

1. この記事について — Vol1の予告を回収する発展編

「OCI可観測性・運用監視実践」シリーズVol1では、Logging・Monitoring・Connector Hubの3サービスを結線し、ログ収集からアラーム通知までの運用監視E2EをAlways Freeテナンシのみで完全無料実践しました。しかし同記事の§9-2・§10-3では、Logging Analytics・APM(Application Performance Monitoring)・Ops Insightsという3つの発展サービスについて、あえて深掘りせず「将来の発展記事のテーマ」として扱いを保留しています。本記事は、この保留分を実際に回収する発展編です。

Vol1が「収集の土台をAlways Free枠内で無料構築する」ことを主眼にしていたのに対し、本記事は視点を反転させます。Logging Analytics・APM・Ops Insightsの3サービスは、いずれも「有効化すると何にいくらかかるか」という課金の実像を正確に押さえていないと、意図せず高額な請求につながりかねないサービスです。特にLogging Analyticsは、Vol1の§9-2で「本記事の実演範囲では有効化不要」と整理した張本人であり、本記事ではその「使わない」から一歩進めて「使うなら何にいくらか」を正面から扱います。

この4軸のうち、軸1と軸3は特に本記事の存在理由に直結します。軸1は、Vol1という既刊記事があるからこそ成立する軸であり、単体のLogging Analytics解説記事には持ち得ない連続性です。軸3は、Logging Analyticsの課金がWeb上の単体記事でほとんど正面から扱われていない中で、本記事が最も紙幅を割く部分です。軸2と軸4は、この2つの軸を土台に、3サービスを俯瞰する視点とAWS実務者向けの橋渡しを加えることで、記事全体の一貫性を保つ役割を担っています。

1-1. 本記事のゴール

本記事を完走すると、次の状態に到達します。第一に、Logging Analytics・APM・Ops Insightsという名前が似た3サービスを、役割・階層・課金体系の3軸で明確に区別できるようになります。第二に、Vol1で構築したLogging資産をConnector Hub経由でLogging Analyticsに取り込み、クエリとダッシュボードで実際に分析する一連の流れを、課金発生ポイントを把握した状態で実演できます。第三に、APMをAlways Free枠(1,000スパン/時間)の範囲内で、Ops InsightsをBasic($0)の範囲内で、それぞれ安全にハンズオンできます。最後に、AWSのCloudWatch Logs Insights・X-Ray・Compute Optimizer/Performance Insightsとの対応関係を整理し、AWS実務者が本記事の内容を自分の経験に引き寄せて理解できる状態を目指します。

到達状態を具体的な成果物ベースで整理すると、次の4点です。

• Logging Analytics・APM・Ops Insightsの役割・階層・課金体系を、表を見ずに自分の言葉で説明できる
• Vol1のLogging資産をLogging Analyticsに取り込み、クエリとダッシュボードで分析した実績を持てる
• APM・Ops InsightsをAlways Free/Basicの境界内で安全にハンズオンした実績を持てる
• AWS実務経験を土台に、OCI側の3サービスをそれぞれの対応サービスに引き寄せて理解できる

Vol1完走時点との違いを表で整理すると、次のようになります。

この表からも分かる通り、本記事はVol1の延長線上にありながら、扱う対象(分析・トレース・容量計画)も、意識すべき課金構造(Always Free一覧には掲載されない無料枠を含む)も、Vol1とは質的に異なります。この違いを踏まえたうえで、§2以降を読み進めてください。

1-2. 読者像

本記事は、前作「OCI可観測性・運用監視実践 Vol1」を完遂済みの読者、またはOCIのLogging/Monitoring/Connector Hubの基本操作に一通り慣れているエンジニアを主な想定読者としています。加えて、AWSでCloudWatch Logs Insights・X-Ray・Compute Optimizer(RDS Performance Insightsを含む)のいずれかを実務で運用した経験があり、OCI側での対応実装を知りたい可観測性実務者も対象に含みます。

Vol1の§9-2で「Logging Analyticsは別サービス・別課金」と整理した内容を前提知識として扱うため、両サービスの名称区別そのものは本記事では再掲せず、Vol1側の解説にリンクで委譲します。OCIのLogging/Monitoring/Connector Hubをまだ一度も操作したことがない読者は、先にVol1を完走してから本記事に進むことを推奨します。

本記事は、Vol1で「収集・可視化・通知」を扱った読者が、次の「分析・トレース・容量計画」の段階に進むための記事として設計されています。逆に、Logging Analytics・APM・Ops Insightsの本格的な有償運用(Full Features・大量ログの取り込み等)まで踏み込みたい読者にとっては、本記事は入り口までの案内に留まる点をあらかじめお伝えしておきます。

1-3. なぜ今これを書くか — Vol1予告の回収と3サービスの体系化

本記事を書く理由は、大きく3点あります。

1つ目は、Vol1自身が残した予告の回収です。Vol1の§10-3では、次のように明言されています。

本記事のLoggingで収集したログを、Logging Analyticsに取り込んでさらに分析する構成は、将来の発展記事のテーマとなります。

同じく§10-3では、APMとOps Insightsについても次のように予告されています。

APM(Application Performance Monitoring): アプリケーションレベルのトレース・パフォーマンス分析を扱う、本記事のMonitoring(インフラ/サービスレベルのメトリクス)とは異なる階層のサービスです。

Ops Insights: リソースの容量計画・キャパシティ分析に特化したサービスで、本記事のMonitoring(リアルタイムのメトリクス確認)とは目的が異なります。

本記事は、この3つの予告文が指す構成をまとめて実装する記事です。対応関係を整理すると、次のようになります。

2つ目は、3サービスを可観測性スタックとして体系化する視点です。Logging Analytics単体のハンズオン記事(ログ取り込み・クエリ・ダッシュボード等)は、Web上に複数存在します。しかし、Logging Analytics・APM・Ops Insightsの3サービスを1つの可観測性スタックとして設計論的に整理し、かつVol1で構築した資産からの連続性を持たせた記事は見当たりません。本記事は、この空白を埋めることを目指します。

3つ目は、誤課金境界の実像を扱うことです。Logging AnalyticsのStorage Unit課金は、Web上の単体記事ではほとんど正面から扱われていません。本記事は、Vol1の§9-2が「誤課金防止(使わない)」を扱ったのに対し、「使うなら何にいくらか」という利用者視点の続編として、この課金境界を公式一次情報に基づいて解説します。

→ 前作はこちら: OCI可観測性・運用監視実践 Vol1 — Logging/Monitoring/Connector Hubの完全無料E2E実践(Logging Analyticsとの区別は同記事§9-2で解説)

本記事は、次の範囲についてはあえて深掘りせず、既刊記事・今後公開予定の記事に委譲します。

• Logging と Logging Analyticsの名称区別: Vol1「OCI可観測性・運用監視実践 Vol1」§9-2で詳しく整理済みのため、本記事では再掲しません。
• Database Management(データベース固有の監視・診断サービス): Vol1§10-3で言及の通り、本記事の対象外です。
• Logging・Monitoring・Connector Hubの基本操作: 前作Vol1で実演済みのため、本記事では前提知識として扱います。
• Logging Analyticsクエリ言語(Oracle Log Analytics query language)の全コマンド網羅: §3-3では代表的な使い方に絞り、詳細は公式のQuery Language Command Referenceに委譲します。
• APM・Ops InsightsのFull Features/有償プランでの本格運用設計: 本記事はAlways Free/Basicの境界内での最小実践に絞り、本格運用は今後の発展記事のテーマとします。

これらの委譲は、本記事のスコープを「Logging Analytics・APM・Ops Insightsの体系化と課金境界の実像」に絞り込むための判断です。個々のサービスの操作手順を網羅するよりも、3サービスを可観測性スタックとして組み合わせたときに初めて見えてくる設計判断(どこまでを無料枠で完結させ、どこから課金を許容するか)に焦点を当てることを優先しています。

本記事のハンズオン(§3〜§5)へ進む前に、次の前提を整えておいてください。

• Vol1「OCI可観測性・運用監視実践 Vol1」を完走し、Logging・Monitoring・Connector Hubが動作する状態になっていること
• 対象コンパートメントに対して、Logging Analytics・APM・Ops Insightsを有効化できるIAM権限が付与されていること
• Logging Analyticsのハンズオン(§3)は、価格表上の無料枠(最初の10GB)を超えるとActive Storageの課金が発生するため、その可能性を許容できるテナンシで実施すること
• 東京(ap-tokyo-1)または大阪(ap-osaka-1)リージョンを使用していること(両リージョンとも3サービス提供済み)

いずれも、Vol1を完走したテナンシであれば大きな追加準備は不要ですが、Logging Analyticsのみ課金発生を伴う点だけは、着手前に必ず認識しておいてください。

本記事の各章は、Logging Analytics(§3)→APM(§4)→Ops Insights(§5)の順に進みます。この順序は、§2-6の料金試算節で示す通り、課金インパクトの大きいサービスから先に扱い、無料で完結できるサービスを後段に配置するという意図的な構成です。

課金額の大きいサービスを先に理解しておくことで、後段のAlways Free/Basicのハンズオンを、より安心して進められるようにするための順序でもあります。

それでは、次の§2で3サービスの料金体系を整理したうえで、§3以降で実際のハンズオンに進んでいきましょう。

2. サービス仕様と料金 — 有効化すると何にいくらかかるか

本章では、Logging Analytics・APM・Ops Insightsの3サービスについて、公式一次情報(OCI Price List・OCI Always Freeドキュメント・cetools実測)に基づき、課金体系と無料枠の境界を整理します。数値は2026-08-10時点でOracleの公式情報源から確認したものです。

料金は変更される可能性があるため、本章の数値はあくまで執筆時点のスナップショットとして扱ってください。特にLogging AnalyticsのStorage Unit単価は、有効化前に必ずOCIコンソールの見積りツールで最新の値を確認することを推奨します。

本章の構成は、まず3サービスの位置づけを俯瞰し(§2-1)、次にサービスごとの料金体系を個別に整理し(§2-2〜§2-4)、AWS対応関係(§2-5)・料金試算(§2-6)でまとめ、最後に有効化前チェックリスト(§2-7)で実務に接続するという流れです。

2-1. 3サービスの位置づけ再整理

まず、3サービスの役割と階層を表で整理します。

いずれも東京(ap-tokyo-1)・大阪(ap-osaka-1)両リージョンで提供されており、廃止・メンテナンスモードの告知はなく現役のサービスです。Ops Insightsは近年もHost Capacity Planning(OCI Computeインスタンスへの対応拡大・バーストパフォーマンスの考慮を含むベースライン推奨等)の機能強化が継続しています。APMもJavaエージェントがトレース/スパンIDをアプリケーションログへ注入できるようになるなど、Logging Analyticsとの連携を強める方向で機能拡張が進んでいます。この連携強化の流れは、本記事が軸に据える「3サービスの資産連続活用」という設計思想とも整合します。

いずれのサービスも、OCIコンソールの「Observability & Management」メニュー配下からアクセスします。§4〜§10でLogging・Monitoring・Connector Hubを個別のメニュー項目として操作したVol1に対し、本記事で扱う3サービスは同じ「Observability & Management」という括りの中に並んでいる点も、3サービスが可観測性スタックとして体系的に位置づけられていることの表れです。

fig01で示した階層関係を踏まえると、Loggingが収集層、Logging Analyticsが分析層、APMがアプリケーション層のトレース、Ops Insightsが中長期の容量計画層という4層構造として整理できます。本記事の§3〜§5は、このうち分析層・アプリケーション層・容量計画層の3層を、それぞれ最小構成で実践する構成になっています。

2-2. Logging Analyticsの料金 — Storage Unit課金の実像

Logging Analyticsの課金は、次の2つのSKUで構成されます(cetools実測・2026-08-10取得)。

ここで最も重要なのが、「Storage Unit」という課金単位の定義です。OCIの価格リスト上の定義では、Active Storage・Archival Storageのいずれも、1 Storage Unitは300GBのログデータとして定義されています(Active Storageは「300GBのログを1ヶ月間保持した状態」、Archival Storageは「300GBのログを1時間保持した状態」を1 Storage Unitとする課金単位)。つまり、Active Storageで300GB未満のログ量であっても、課金上は端数が切り上げられて最小でも1 Storage Unit分(0〜35 Storage Unit帯なら$372/月)が発生する前提で見積もる必要があります。300GB未満での按分課金の有無については、公式ドキュメント上に明記した記述が確認できなかったため、本記事では「憶測で按分ルールを記載しない」という方針に基づき、按分の有無を断定しません。実際の課金額は、有効化前に必ずOCIコンソールの見積りツールで確認してください。

Active Storageの段階割引が実際にどう積み上がるかを、Storage Unit数ベースの目安として整理すると、次のようになります。段階割引は、超過分のみ低い単価が適用される累進方式(0〜35 Storage Unit分は$372/unit、35〜103 Storage Unit分は$260.4/unit、103 Storage Unit超過分は$223.2/unit)という前提で計算しています。この前提の妥当性を含め、実際の請求額は必ずOCIコンソールの見積りで確認してください。

Archival Storageは、Active Storageに比べて大幅に安価です。$0.02/Storage Unit/時間を1ヶ月(730時間換算)で計算すると、1 Storage Unitあたり約$14.6/月となり、Active Storageの最小単価($372/月)と比べて大きな差があります。ただし、Archival Storageへの移行には条件があり、Logging Analytics側のドキュメントによれば、Active Storageのデータ量が最低1TBに達していること、かつ対象ログのActive Storage保持期間が最低30日を経過していることの両方が必要です。この条件を満たさないログは、そもそもArchival Storageへ移行できません。

ログの取り込み量が増えてきた場合は、Logging Analyticsの「Storage Activity Report」画面で、アーカイブ・リコール・リリース・パージといったストレージ管理アクティビティを一覧で確認できます。本記事の§3ハンズオンのような少量ログの検証では、Archival Storageへの移行条件(1TB以上)に到達すること自体が通常ないため、Active Storageの課金のみを意識すれば十分です。

Vol1で扱ったLoggingとの違いも、あらためて整理しておきます。

同じ「ログを扱うサービス」でありながら、いずれも無料枠自体は存在するものの、超過後の課金モデル(従量課金 vs Storage Unit単位の最小$372/月)が大きく異なります。Vol1の§9-2で「誤って有効化しないように」と注意喚起されていた理由は、この超過後の崖の高さにあります。

2-3. APMの料金とAlways Free枠

APMは、Always Free資産としてリージョンごとに1個のAPMドメインを作成できます。このドメインでは、1時間あたり1,000スパンまで無料利用できます。この上限は公式Always Freeドキュメントで確認済みです。1,000スパンを超えたリクエストはスロットリングされ、UI・API上のトレース表示・応答には反映されません。トレースデータの保持期間は31日間です。

Always Free枠を超えてスパンを処理したい場合は従量課金に移行しますが、単価は執筆時点でOracleの公式Observability and Managementプラットフォーム価格ページ(oracle.com/manageability/pricing)から都度確認することを推奨します。本記事執筆時点では該当ページへのアクセスが制限されており、正確な単価を一次情報で確認できなかったため、本記事では具体的な単価を記載しません。本記事の§4ハンズオンは、1,000スパン/時間のAlways Free枠内に収まる最小構成で実演するため、単価を把握していなくても無料で完走できます。

なお、APMのAlways Free資産には、トレーシングイベント枠(1,000スパン/時間)に加えて、Synthetic Monitor(合成監視)の実行枠(1時間あたり10回)も含まれています。本記事の§4ハンズオンではSynthetic Monitorは扱いませんが、APMのAlways Free資産がトレースとSynthetic Monitorの2種類で構成されている点は、押さえておいて損はありません。

Always Free枠(1,000スパン/時間)を維持しながらAPMを活用するうえでの考え方は、次の2点に整理できます。

• リクエスト頻度そのものを検証目的の範囲に抑える(本番相当のトラフィックをそのままトレースしない)
• 1トランザクションあたりのスパン数(呼び出し先のサービス数)が多い構成では、より少ないリクエスト数でも枠を消費しやすいことを踏まえて設計する

2-4. Ops Insightsの無料/有料境界

Ops Insightsは、対象リソースの種類ごとに課金SKUが分かれていますが、本記事で扱うAutonomous AI Databaseに関しては、次の境界があります。

ここで見落としやすいのが、有効化時のデフォルト挙動です。OCIコンソールでAutonomous DatabaseをOps Insightsの管理対象に追加する(Database fleetから「Add databases」を実行する)と、「Full feature set」列はデフォルトで「Full」が選択された状態になります。Basic($0)に留めたい場合は、対象データベースの「Actions」メニューから「Disable full feature set」を明示的に選択する必要があります。この操作をせずに有効化を進めると、意図せずFull Features側の課金対象になる可能性がある点に注意してください。

有効化そのものの操作フローを整理すると、次のようになります。

Basic対象外の画面(SQL Insights等)には、そもそもデータが表示されません。

Full Featuresで追加される機能名は表に列挙しましたが、それぞれ何をするものかを簡単に整理しておきます。

なお、本記事ではAutonomous AI Database向けのBasic/Full境界のみを扱いますが、Ops InsightsはOCI Compute・Exadataなど他のリソース種別にも対応しており、それぞれ個別の課金SKUと機能境界を持ちます。他のリソース種別のBasic/Full境界を確認したい場合は、有効化前にOCIコンソールの見積りツールで対象リソース種別の単価を個別に確認してください。

2-5. AWSサービスとの対応関係

AWS実務者向けに、3サービスの対応関係を整理すると次のようになります。

ただし、名前の対応だけを頼りに機能範囲まで同一視することは避けてください。特にOps InsightsはBasic/Full Featuresという機能段階を持つ点が、AWS側の対応サービスとは異なる構造です。この対応関係を、サービスごとにもう少し詳しく見ていきます。

Logging Analytics ↔ CloudWatch Logs Insights

CloudWatch Logs InsightsがCloudWatch Logsに蓄積されたログに対してクエリ言語で分析するのに対し、Logging Analyticsも同様にLoggingで収集したログを取り込んでクエリ(Oracle Log Analytics query language)で分析します。両者とも、収集用サービス(CloudWatch Logs / Logging)と、専用のクエリ言語を持つ分析用サービス(CloudWatch Logs Insights / Logging Analytics)を分ける「2段構えの構造」を持つ点が共通しています。

一方、CloudWatch Logs Insightsはクエリ実行時のスキャン量に応じた課金であるのに対し、Logging AnalyticsはStorage Unit単位のストレージ課金を主体とする点が、課金モデルとしての大きな違いです。

APM ↔ X-Ray

X-Rayが分散システムのリクエストフローをトレースするのに対し、APMもアプリケーションのトランザクションをトレース単位・スパン単位で可視化します。X-RayもAWSアカウントごとに月100,000トレースの無料枠を持つ点は、APMのAlways Free枠(1,000スパン/時間・APMドメイン1個/リージョン)と発想は近いものの、無料枠の計測単位(トレース数 vs スパン数/時間)が異なるため、単純な数値比較はできません。実務での置き換えを検討する場合は、単位の違いを踏まえたうえでトラフィック量を見積もる必要があります。

Ops Insights ↔ Compute Optimizer / Performance Insights

Compute OptimizerがEC2等のリソースのサイジングを推奨し、Performance InsightsがRDSのDB負荷を分析するのに対し、Ops InsightsはOCI Compute・Autonomous Database等を対象に容量計画とキャパシティ分析をします。AWSではCompute Optimizer(リソース全般のサイジング推奨)とPerformance Insights(DB特化のパフォーマンス診断)が別サービスとして提供されているのに対し、OCIではOps Insightsという1サービスの中に、Compute向けのHost Capacity PlanningとDatabase向けのCapacity Planning/SQL Insights等が包含されている点が構造上の違いです。

3つの対応関係に共通するのは、いずれもOCI側が「収集(Logging/Monitoring)」と「分析(Logging Analytics/APM/Ops Insights)」を別サービスとして明確に分離している点です。AWSでも、CloudWatch LogsとCloudwatch Logs Insights、あるいはX-Rayのようにトレース収集と可視化が一体化したサービスなど、統合の度合いはサービスによって異なります。この統合度合いの違いを意識しておくと、AWSからOCIへの設計移行時に「1つのAWSサービスが担っていた範囲が、OCI側では複数サービスに分かれていないか」を確認する習慣がつきます。

2-6. 料金試算 — モデルケース

本記事のハンズオン(§3〜§5)を実施した場合の概算費用は、次の通りです。

本記事のハンズオン規模を超えて、本格的に3サービスを使い続けた場合のコスト増加要因も、あらかじめ整理しておきます。あくまで概念的な整理であり、具体的な金額は環境ごとに異なります。

継続的にコストを把握するには、OCIコンソールのCost Analysis(コスト分析)画面で、Logging Analytics・APM・Ops Insightsそれぞれのサービス単位の実績コストを定期的に確認することを推奨します。特にLogging Analyticsは、§2-2で整理した通り10GBを超えた瞬間にStorage Unit課金へ跳ね上がるため、取り込み対象のログ・グループを増やす際は、10GB枠に対する残量と増分のStorage Unit数を事前に見積もったうえで判断してください。

2-7. 誤課金を防ぐための実務チェックリスト

§3〜§5のハンズオンへ進む前に、本章で整理した課金境界を踏まえたチェックリストとして整理します。§6の「落とし穴・まとめ」が実施後の振り返りであるのに対し、こちらは実施前の予防チェックです。

このチェックリストは、あくまで本記事のハンズオン規模を前提にした最小限の確認事項です。本格運用時には、対象リソースの数やログ量の増加を見込んだ、より詳細な見積りが必要になります。

特にLogging Analyticsは、一度取り込みを開始すると、Connector Hubの接続を停止してもすでに取り込み済みのログのActive Storage課金は継続します。検証を終えて課金を止めたい場合は、Connector Hubの接続を無効化するだけでなく、取り込み済みログの保持・削除方針についても、あわせて確認しておくことを推奨します。

APM・Ops Insightsについては、Always Free/Basicの範囲内で操作している限り、追加の停止作業をしなくても課金は発生しません。ただし、検証用に作成したAPMドメインやOps Insightsの管理対象データベース登録を放置すると、後から見返したときに構成の見通しが悪くなるため、不要になった時点で整理しておくことを推奨します。

それでは、§2で整理した課金境界を踏まえたうえで、§3からLogging Analyticsのハンズオンに進みます。§1-3で述べた通り、課金インパクトの大きいサービスから先に扱う構成としているため、まずはLogging Analyticsから着手します。

3. Logging Analyticsハンズオン — Vol1資産の取り込み・クエリ・ダッシュボード

本章は、Logging Analyticsの取り込み手順を網羅的に解説するものではありません。Vol1「OCI可観測性・運用監視実践 Vol1」§4で有効化したLogging資産を対象に、Connector Hubを使ってLogging Analyticsへ取り込みます。取り込んだログはクエリとダッシュボードで分析し、「資産の連続活用」に絞って実演します。§2-2の整理通り、Vol1の少量ログ資産(数GB規模)であれば10GBの無料枠内で完走できる可能性が高いものの、取り込み量が10GBを超えた場合はその時点からActive Storageの課金(最小$372/月)が発生します。発生ポイントと10GBに対する目安量は各ステップで明示します。

3-1. 前提 — Vol1で構築したLogging資産

Vol1では、監査ログ・サービスログ・カスタムログの3層と、VCNフローログをLoggingで収集しています。本記事では、このうちVCNフローログまたはカスタムログの一部を、Logging Analyticsへの取り込み対象とします。取り込み対象を絞る理由は、取り込むログ量が増えるほどActive Storageの課金額(Storage Unit数)も増えるためです。まずは検証目的の少量ログのみを対象にし、課金インパクトを最小化した状態で本章のハンズオンを実演します。

3-2. Connector Hub経由でLogging Analyticsへ取り込む — ★課金発生ポイント①

Logging Analyticsへログを取り込む標準的な経路は、Vol1§7で実演したConnector Hub(Service Connector Hub)です。Connector HubはSourceとして「Logging」を、Targetとして「Logging Analytics」を指定できます。OCI CLIで構成する場合、次のような形になります。

oci sch service-connector create
 --display-name LAIngestConnector
 --compartment-id <Connector_Compartment_OCID>
 --source '{ "kind": "logging", "logSources":
  [ { "compartmentId": "<Logging_LogGroup_Compartment_OCID>",
"logGroupId": "<Logging_LogGroup_OCID>" } ] }'
 --target '{ "kind": "loggingAnalytics", "logGroupId": "<LogAnalytics_LogGroup_OCID>" }'

コンソールから作成する場合は、Loggingサービスの「Service Connectors」またはConnector Hub本体の「Create Service Connector」から、Source=Logging・Target=Logging Analyticsを選択し、Configure Source Connectionでコンパートメント・ログ・グループ・ログ名を指定します。ここでのlogGroupIdは、取り込み先となるLogging Analytics側のログ・グループのOCIDです。この接続を作成し、Logging Analyticsへの累積取り込み量が10GBの無料枠を超えた時点から、§2-2で整理したActive Storageの課金が発生します。取り込みを開始する前に、対象ログの量が10GB枠に対してごく少量であることを確認してください。

3-3. Oracle Log Analytics query languageでのクエリ

取り込んだログは、Logging Analytics側のクエリ言語(公式ドキュメント上の名称は「Oracle Log Analytics query language」)で検索・分析します。このクエリ言語は、検索文字列(Search String)・コマンド(Command)・関数(Function)・演算子(Operator)から構成され、パイプ(|)でコマンドをつなぎながら、統計集計やフィールド生成などの処理を段階的に適用していく設計になっています。例えば、取り込んだVCNフローログに対して特定の送信元IPで絞り込み、時間帯ごとの件数を集計する、といった使い方が可能です。本記事では、クエリ言語の全コマンドを網羅するのではなく、Vol1で「Loggingの検索画面での確認」に留めていた分析を、Logging Analytics側でどこまで発展させられるかを体感することを目的とします。

3-4. ダッシュボード化

作成したクエリは、ウィジェットとして保存し、ダッシュボードに追加できます。Vol1のMonitoringで実演したメトリクスダッシュボードが「メトリクスの可視化」を担っていたのに対し、Logging Analyticsのダッシュボードは「ログの相関分析結果の可視化」を担う点が異なります。両者を組み合わせることで、メトリクス側の異常(Vol1§5〜§6)とログ側の相関(本記事§3)を、それぞれ適した画面で確認できる体制が整います。

4. APMハンズオン — Always Free枠内でトレースを取る

本章では、APMをAlways Free枠(1,000スパン/時間・APMドメイン1個/リージョン)の範囲内で最小構成のハンズオンとして実演します。

4-1. APMドメインの作成

APMドメインは、トレースデータを収集する単位です。Always Freeテナンシでは、リージョンごとに1個のAPMドメインをAlways Free資産として作成できます。既に他の用途でAlways Free枠のAPMドメインを使用している場合、新規に作成すると有償ドメインとして扱われる可能性があるため、既存ドメインの有無を先に確認してください。

4-2. データキーの発行

APMドメインを作成すると、トレースデータを送信するためのデータキー(Private Data KeyまたはPublic Data Key)を発行できます。このデータキーを、トレースを送信するアプリケーション側のAPMエージェントやSDKに設定することで、APMドメインへのデータ送信経路が確立します。

4-3. 最小トレースの取り込み

本記事では、1,000スパン/時間というAlways Free枠の上限を踏まえ、検証用の小規模なリクエストを数件〜数十件程度発生させる形で、最小構成のトレースを取り込みます。§2-3で整理した通り、1,000スパンを超えた分はUI・APIともに表示されずスロットリングされるため、大量のリクエストを一度に発生させる負荷試験的な使い方は、Always Free枠内では意図した結果が得られません。

4-4. Always Free枠内での設計指針

APMをAlways Free枠内で継続利用する場合、1時間あたりのスパン数が1,000を超えないよう、リクエスト頻度やサンプリング率を設計する必要があります。本番相当のトラフィックをそのままトレースする用途には向かず、あくまで検証・学習目的での利用に適した無料枠である点を踏まえて活用してください。

5. Ops Insights — Basic($0)で始める容量分析

5-1. Autonomous Database向けBasicの有効化

Ops Insightsの管理画面(Observability & Management → Ops Insights → Administration → Database fleet)から「Add databases」を実行し、Telemetryに「Cloud Infrastructure」、Database typeに「Autonomous AI Database」を選択して、対象のAutonomous Databaseを追加します。この時点で「Full feature set」列はデフォルトで「Full」が選択された状態になるため、§2-4で述べた通り、Basic($0)に留める場合は対象データベースの「Actions」メニューから「Disable full feature set」を明示的に選択してください。

5-2. 画面確認

Basicで有効化すると、Capacity Planningアプリケーションの画面で、対象Autonomous DatabaseのOCPU/ECPU使用状況の推移や、将来的なキャパシティ予測を確認できます。Vol1のMonitoringが「現在のメトリクス値」を扱っていたのに対し、Ops InsightsのCapacity Planningは「中長期のリソース使用傾向」を扱う点が異なります。

5-3. フル機能との境界

Full Featuresを有効化すると、Capacity Planningに加えてSQL Insights・SQL Explorer・Data Object Explorer・ADDM Spotlightといった、データベース内部のSQL実行状況・パフォーマンス診断機能が利用可能になります。ただし、これらは有償SKU(データベース種別により単価が異なる)の対象であり、本記事のハンズオン範囲には含めません。Full Featuresを試したい場合は、事前にOCIコンソールの見積りツールで対象データベースのOCPU/ECPU数に応じた概算費用を確認してください。

6. まとめ・落とし穴チェックリスト

本記事では、Vol1「OCI可観測性・運用監視実践 Vol1」の§9-2・§10-3で保留した3サービス——Logging Analytics・APM・Ops Insights——を、可観測性スタックとして体系的に整理し、それぞれの課金境界を公式一次情報に基づいて確認したうえでハンズオンしました。§3ではVol1のLogging資産をLogging Analyticsに取り込みクエリ・ダッシュボードで分析し、§4ではAPMをAlways Free枠内でトレース実践し、§5ではOps InsightsをBasic($0)で有効化しました。

最後に、本記事全体を通じてつまずきやすい落とし穴を整理します。

→ 前作はこちら: OCI可観測性・運用監視実践 Vol1 — Logging/Monitoring/Connector Hubの完全無料E2E実践