OCI Log Analytics for Oracle Database@AWSフリート・ログ管理 (2026/10/15)
OCI Log Analytics for Oracle Database@AWSフリート・ログ管理 (2026/10/15)
https://www.ateam-oracle.com/oci-log-analytics-for-oracle-databaseaws-fleet-log-management
投稿者：Royce Fu | Master Principal Cloud Architect
Oracle Exadata Database Serviceは、パブリッククラウドおよびCloud@Customer環境において、専用に構築され最適化されたOracle Exadataインフラストラクチャ上で、実績のあるOracle Databaseの機能を提供します。組み込みのクラウド自動化、柔軟なリソーススケーリング、セキュリティ、そしてあらゆるOracle Databaseワークロードに対応する高速パフォーマンスにより、管理の簡素化とコスト削減を実現します。データベースのパフォーマンスと効率性を最適化したい企業にとって、不可欠なコンポーネントです。
Exadata システムの管理は複雑であるため、運用準備を整えるには、可観測性と監視が不可欠です。包括的な可観測性により、管理者はシステムのパフォーマンスに関する詳細な情報を取得し、異常を検出し、潜在的な問題が重大な問題に発展する前に対処できます。Exadata システムの包括的な可観測性と管理を実現するには、管理エージェント クラウド サービス、データベース管理サービス、Ops Insights、ログ分析などの OCI 可観測性および管理 (O&M) サービスのご利用をお勧めします。これらのサービスにより、OCI、Cloud@Customer、オンプレミス環境など、さまざまな環境にわたる Exadata システムのメトリックとログ データの収集と取り込みが可能になります。
この記事では、Oracle Database@AWS Exadata Database Service on Dedicated Infrastructure (ExaDB-D) 向けの OCI Log Analytics に焦点を当てます。同じ ZIP ベースの管理エージェントとログ収集モデルは、Exadata Database Service on Cloud@Customer (ExaC@C) にも適用されます。このチュートリアルでは、管理エージェントのインストール、データベースと Grid Infrastructure (GI) のログへのアクセス、エンティティとソースの関連付け、ログエクスプローラの検証、ダッシュボード、および調査クエリについて説明します。この記事は、「可視性の最大化: OCI Logging Analytics を使用した Oracle Database からのログの収集と分析」に基づいています。
Oracleのマルチクラウドデータベース監視戦略
Oracleのマルチクラウドデータベース監視戦略は、3つの補完的なOCIオブザーバビリティおよび管理サービスを組み合わせたものです。データベース管理は、フリート監視、データベースおよびインフラストラクチャのメトリクス、パフォーマンス管理、および管理機能を提供します。Ops Insightsは、キャパシティプランニング、SQLインサイト、機械学習による診断、およびフリートレベルのトレンドを追加します。ログ分析は、クラウド環境とオンプレミス環境からのログを一元化し、Oracle対応の解析、インタラクティブな分析、ダッシュボード、およびAI支援による調査を適用します。これらのサービスを組み合わせることで、運用チームは、単一のシグナルを完全な解決策とみなすことなく、フリートの症状からデータベースのパフォーマンス、キャパシティ、およびログの証拠へと移行できます。
データベースとGIログがフリート全体で使いにくくなる理由
Oracle Database@AWS は、Amazon CloudWatch のネームスペースに、有用なパフォーマンスおよびインフラストラクチャ メトリックを公開しますAWS/ODB。サービス ビューでは、リソースと有効化された監視に応じて、CPU 使用率、負荷、メモリ、ASM ディスク グループ使用率、ノード ステータス、割り当て済み OCPU、ファイルシステム使用率、アクティブ セッション、および I/O パフォーマンスを表示できます。これらのメトリックは、オペレーターが Exadata VM クラスタ全体のリソース負荷と可用性の変化を把握するのに役立ちます。
参考資料： Oracle Database@AWS CloudWatchモニタリング、AWSモニタリングの概要
このチュートリアルでキャプチャした CloudWatch Logs ビューは、主に /aws/events/odba_eventsログ グループを表示します。以下の例では、FetchProtectedDatabaseConfiguration操作を監査スタイルのサービス イベントとして記録しています。AWS は、Oracle Database@AWS イベントを、Exadata インフラストラクチャ、VM クラスタ、CDB、PDB イベントなど、リソース ライフサイクルの変更に関する構造化メッセージとして記録します。CloudTrail は、Oracle Database@AWS コントロール プレーン API 呼び出しを別途記録します。これらのストリームは、プロビジョニング、構成変更、および管理アクティビティを追跡するのに役立ちますが、データベース サーバー内で生成される診断ファイルとは異なります。
参照： Oracle Database@AWS イベント、Oracle Database@AWS CloudTrail ログ
/aws/events/odba_eventsExadataデータベースVM上では、データベースアラートログ、リスナーログ、ASMログ、およびクラスタウェアログが生成されます。集中収集が行われていない場合、DBAはORA-07445、ORA-00600アラート、リスナー障害、またはクラスタウェアイベントを調査する際に、関連するデータベースノードに接続し、データベースおよびGrid Infrastructureの診断ディレクトリ構造をたどり、適切なインスタンスと時間範囲を特定し、ノード間でレコードを関連付ける必要があります。VMクラスタの数が増えるにつれて、このプロセスは遅くなり、一貫性も低下します。
Exadataの診断情報は、コンポーネント間およびVMローカルディレクトリに分散して存在します。RACデータベースにはインスタンス固有の診断情報があり、リスナー、ASM、およびクラスタウェアはそれぞれ独自のファイルと所有権を持っています。そのため、トラブルシューティングには、適切なファイルへのアクセスと、各レコードをどのコンポーネントが生成したかを把握するための十分なコンテキストの両方が必要となります。
フリートが拡大するにつれて、いくつかの実務上の問題が蓄積されます。ノードごとにデータベースのホームやADRパスが異なる場合があります。データベース所有者、GI所有者、および収集アカウント間でファイルへのアクセス権限が異なります。ローテーションによって、誰かがインシデントの証拠を取得する前に削除される可能性があります。クラスターの他の部分が正常に収集されている場合でも、新しく追加されたVMにはソース関連付けが欠落している可能性があります。
小規模なコレクションインベントリを使用して、これらの問題を明示的な構成に変換します。
| 診断領域 | 最初の運用上の疑問 | 収集優先順位 |
|---|---|---|
| データベースアラート | ORAエラー、再起動、またはその他の重大なイベントを報告したインスタンスはどれですか？ | ベースライン |
| リスナー | このインシデント発生時に、接続関連のメッセージはどのようなものでしたか？ | ベースライン |
| クラスターウェア | 資源、会員資格、またはサービスに関するイベントは、症状の発現と同時期に発生しましたか？ | 基本アラート範囲 |
| ASM | ゲストクラスタから見えるストレージ管理イベントは何でしたか？ | 基本アラート範囲 |
| データベース/GIトレースおよびインシデントダンプ | この診断には、どのようなより詳細な証拠が必要ですか？ | 対象を絞った収集 |
| 監査記録 | どの監査対象行為について、調査または記録の保管が必要ですか？ | 個別のセキュリティ使用事例 |
この記事では、 Oracle Database@AWSおよびExaC@Cの顧客がアクセス可能なExadataデータベースVMから収集したデータを使用します。Oracleが管理する物理ホストとExadataストレージセルは、それぞれ異なる運用責任を負っています。カタログにExadataパーサーが存在しても、顧客がそれらのログを生成するインフラストラクチャにアクセスできるわけではありません。
マルチクラウドデータベースにおけるOCI Log Analyticsの価値
クラウドネイティブな運用モデルでは、ローカルログの監視が必要なすべてのExadata Database VMに、Log Analyticsプラグインを搭載したOCI管理エージェントをデプロイします。各エージェントは、承認されたデータベースファイルとGIファイルを読み取り、そのレコードをOCI Log Analyticsに送信します。運用チームは、OCI Log Analytics上で、これらのレコードをまとめて検索、解析、相関分析、可視化、レポート作成できます。これにより、各ノードにサインインして個別の診断ツリーを手動で検索するという、調査開始時の手間が省けます。
ExaDB-DまたはExaC@C VMクラスタ群の場合、有用なログサービスは単にファイルを保持するだけでは不十分です。オペレーターは、インスタンス間で同じエラーを検索し、繰り返し発生するメッセージと新しいパターンを区別し、データベースの症状からリスナー、GI、ゲストホストの証拠に至るまで、インシデントを追跡する必要があります。
OCI Log Analyticsは、ログの収集、解析、エンリッチメント、検索、および視覚化を1つのサービスで提供します。そのカタログには、Oracleおよびその他のテクノロジーに対応した250以上の事前構築済みパーサーが含まれています。これにより、データベース運用チームはOracleで定義されたコンテンツから始め、診断フォーマットのカスタム処理が必要な場合にそれを拡張することができます。
参考資料： OCI Log Analytics の機能、Oracle Database@AWS 向け OCI Log Analytics
運用価値は、具体的な疑問に答えるための一般的な場である。
- 範囲：エラーは特定のインスタンスに限定されていますか、両方のRACノードで繰り返し発生しますか、それとも複数のVMクラスタで発生していますか？
- 発生順序：リスナーの障害はデータベースイベントの後に発生したのか、それとも両方ともGIイベントと同時に発生したのか？
- 変更点：今回の事件発生時に出現したメッセージパターンで、以前の比較期間には見られなかったものはどれか？
- 証拠：作業説明と次の運用チームへの引き継ぎを裏付ける具体的な記録はどれですか？
OCI Log Analyticsを中心とした運用モデルを構築する
VMで収集し、艦隊全体を調査する
ローカルログが必要な各ゲストVMに、Log Analyticsプラグインを搭載したスタンドアロンの管理エージェントをデプロイします。ログを出力しているコンポーネントをLog Analyticsエンティティで表現し、そのソースを関連付け、レコードを目的のロググループに送信します。これにより、フリート分析に必要なインスタンスとノードのコンテキストが維持されます。
参考資料： 継続的収集ワークフロー
構成に関する3つの概念を明確に区別してください。ソースはレコードの収集方法と処理方法を定義し、パーサーはフィールドを抽出し、エンティティはレコードを生成したコンポーネントを識別します。ロググループは収集されたレコードの保存先であり、OCI IAMとコンパートメントによって管理されます。
インスタンスエンティティなどの命名規則を作成しaws-prod-cluster01-vm01-db01、ホストおよびVMクラスタとの関係を記録します。VM、インスタンス、およびソース関連付けの想定されるインベントリを維持します。オペレーターがクエリ可能なAWSアカウントまたはクラスタディメンションを必要とする場合は、関連するエンリッチメントを設定および検証します。OCIリソースタグがすべてのログレコードのフィールドとして自動的に表示されるとは想定しないでください。
AWSからOCIへの収集パスを確立する
AWS のドキュメントによると、ODB ネットワークはリンクされた OCI テナント内の VCN に対応します。Oracle の Database@AWS セキュリティの前提条件では、Service Gateway から OCI Vault への経路が示されています。一方、OCI サービス マトリックスでは、Service Gateway を介してサポートされるサービスとして、Management Agent、LogAnalytics、Monitoring、Monitoring Ingestion が挙げられています。これらは、図 4 に示す提案されたプライベート サービス パスの基礎となります。ただし、これらは、ターゲット ゲスト VM からの Log Analytics 収集のエンドツーエンド チェックに取って代わるものではありません。
インストール前に、ネットワーク所有者にリンクされたOCIリージョン、既存のゲートウェイとルート構成、DNS解決、および許可されたHTTPS送信を確認してもらってください。関連するエンドポイントパターンは次のとおりです。
| 目的 | HTTPS宛先 |
|---|---|
| 管理代行サービス | management-agent.<region>.oci.oraclecloud.com |
| ログ記録と収集に関する警告 | loganalytics.<region>.oci.oraclecloud.com |
| 収集メトリクス | telemetry-ingestion.<region>.oraclecloud.com |
デプロイメントには、現在のすべての前提条件を使用してください。この表は、すべての許可リストを網羅したものではありません。証明書検証を有効にしてTLSを検証してください。接続テストが成功すれば到達可能性が確立され、エージェントの登録と新規レコードの取り込みによって収集ワークフローが正常に機能することが確認されます。
参考資料： AWS ODB ネットワーク、Oracle Database@AWS ネットワークの前提条件、Service Gateway サポート マトリックス、エージェント接続診断、Log Analytics エージェント エンドポイント
記録を説明と再現可能な調査に変換する
Log Explorerは、対話型の調査と保存済みクエリの両方をサポートしています。クラスタ分析では、繰り返し発生するメッセージパターンをグループ化し、リンク機能では、関連するレコードを分析できます。これらの機能を利用して、詳細なメッセージを読む前に、インシデントの範囲を絞り込んでください。
LoganAIは、選択したログと視覚化に対して、生成された説明、要約、および状況に応じたフォローアップ質問を追加します。たとえば、オペレーターは指定した時間枠内のデータベースエラーの要約を要求し、提案された次の質問をGIとホストの証拠と照らし合わせて調査できます。これはRCAを支援しますが、オペレーターはレコードに基づいて結論を検証する必要があります。LoganAIを有効にするには、ドキュメントに記載されている生成AI領域、IAM、およびサービスの前提条件が必要です。
アプリケーションからデータベースまでのより広範なビューを実現するために、OCI Log Analyticsは、UploadOtlpLogsOTLP JSONを使用したドキュメント化されたAPIを介してOpenTelemetryログも受け入れます。これはアプリケーションコンテキストのオプションの取り込みパスであり、ここで構成されたゲストVMファイルコレクションとは別個のものです。
参考資料： LoganAI、有効化の前提条件、OpenTelemetryログの取り込み
管理エージェントをインストールし、ExaDB-DとExaC@Cのログ収集を設定します。
以下の手順は、Oracle の公開 Exadata ZIP インストール ガイダンスに従います。/u02このガイダンスでは、Exadata への RPM インストールは明示的に禁止されており、OCI および Cloud@Customer の Exadata Cloud について規定されています。この手順は、OCI および ExaC@C の ExaDB-D に直接適用されます。この記事では、Oracle Database@AWS ExaDB-D ゲスト VM を作業例として使用します。AWS への適応を適用する前に、必要に応じて Oracle サポートに問い合わせて、 MOS 3015115.1「OCI: Exadata Cloud の可観測性と管理サポート」に記載されている適用可能なイメージとライフサイクル要件を確認してください。公開ガイドでは、AWS を明示的に指定しておらず/u02、AWS、OCI、および顧客データセンター間で接続方法が異なります。
ステップ1：OCI宛先とアクセス許可を設定する
選択した OCI リージョンで Log Analytics を有効にし、宛先ロググループを作成します。リージョン、エージェントコンパートメント、ロググループコンパートメント、およびロググループの OCID を記録します。実行中のコレクターが使用する ID と、人間の管理情報を分離してください。
例えば、エージェントの管理をOCIグループに委任するには、IDドメイン名とコンパートメント名を置き換えてください。
Allow group <domain>/LogAnalyticsAdmins to manage management-agents in compartment <agent_compartment>
Allow group <domain>/LogAnalyticsAdmins to manage management-agent-install-keys in compartment <agent_compartment>
Allow group <domain>/LogAnalyticsAdmins to read metrics in compartment <agent_compartment>これらの説明はエージェントの管理に関するものです。Log Analyticsの設定については、既存の承認済みロールを使用するか、次のサービス権限を追加して、エンティティまたはロググループを含む各コンパートメントにリソースアクセスを適用してください。
Allow group <domain>/LogAnalyticsAdmins to use loganalytics-features-family in tenancy
Allow group <domain>/LogAnalyticsAdmins to use loganalytics-resources-family in compartment <log_configuration_compartment>
Allow group <domain>/LogAnalyticsAdmins to manage management-dashboard-family in compartment <dashboard_compartment>
Allow group <domain>/LogAnalyticsAdmins to read compartments in tenancy
Allow service loganalytics to read loganalytics-features-family in tenancyサービスの初期有効化には、文書化された管理者アクセス権限が必要です。オンボーディングワークフローによって、サービスポリシーが既に作成されている場合があります。機能ファミリーの権限はテナント全体に適用されますが、リソースファミリーの権限はコンパートメント単位で設定できます。
権限のあるIAM管理者に、エージェントコンパートメント内のコレクター用のポリシーと動的グループを作成してもらう。
ALL {resource.type='managementagent', resource.compartment.id='<agent_compartment_ocid>'}このグループに、ログのアップロード、収集メトリックの出力、およびテナントユーザー情報の読み取りの権限を付与します。Oracleのポリシーテンプレートは、最初の2つの権限付与の宛先コンパートメントの選択をサポートしています。READ USERSテナントスコープです。
Allow dynamic-group <domain>/LogAnalyticsAgents to {LOG_ANALYTICS_LOG_GROUP_UPLOAD_LOGS} in compartment <log_group_compartment>
Allow dynamic-group <domain>/LogAnalyticsAgents to use metrics in compartment <collection_metrics_compartment>
Allow dynamic-group <domain>/LogAnalyticsAgents to read users in tenancy動的グループのコンパートメントをインストールキーのコンパートメントに一致させてください。コレクター構成で実際に使用されるメトリックコンパートメントを選択してください。IAMはエージェントのOCI操作を承認し、ファイルシステムのアクセス許可によって、エージェントが読み取れるローカルログが個別に決定されます。
参考資料： 継続的収集IAMポリシー、コンパートメントスコープのテンプレート、自動取り込みポリシーの例
ステップ2：ホストの前提条件を確認する
各仮想マシンに進む前に、セクション3のネットワーク検証を完了してください。
sudo アクセス、時刻同期、 の十分な空き容量/u02、およびホストに があることを確認してくださいunzip。監視260729.1846インストーラーはJAVA_HOME最初に をチェックし、次に をチェックします。/usr/bin/java検証済みのゲストでは Java が見つかりました1.8.0_491。インストール前に、root がサポートされている Java ランタイムを読み取り、実行できることを確認してください。JAVA_HOME必要な Java がデフォルト パスから利用できない場合にのみ を設定し、root シェルからそれを検証します。正確なエージェント リリースの前提条件に従ってください。
例ではホストのunzipユーティリティを使用しています。インストールウィンドウが表示される前に、そのユーティリティが利用可能であることを確認してください。
ステップ3：ZIPインストールの準備
管理エージェントの管理画面から、 Linux ZIPファイルとその公開されているSHA-256チェックサムをダウンロードしてください。計画しているノード数に応じた期間限定のインストールキーを作成し、その応答ファイルテンプレートをダウンロードしてください。これらのファイルを承認済みの管理チャネルを通じて転送してください。
新規インストールの場合、/opt/oracle既に存在することを確認してから、ドキュメントに記載されているZIPの手順に従って、外部ボリュームのターゲットとシンボリックリンクを作成します。
sudo mkdir -p /u02/app/oracle/mgmt_agent
sudo ln -s /u02/app/oracle/mgmt_agent /opt/oracle/mgmt_agent既存のエージェント ディレクトリまたはシンボリック リンクに対してこれらのコマンドを実行しないでください。変更する前に、既存のデプロイメントを確認してください。インストーラーは、デフォルトのmgmt_agentオペレーティングシステム ユーザーを作成し、所有します。この手順のためだけに、グループ、ユーザー、またはカスタム ホームを事前に作成しないでください。この要件は、エージェントのインストール ディレクトリ/u02に適用され、アカウント ホームには適用されません。
ステップ4：抽出、設定、インストール
以前のA-Team手順で使用したExadataレイアウトを使用します。install_dir外部/u02エージェントパスの下にディレクトリを作成し、そこにLinux ZIPを展開します。このディレクトリはで作成されsudo、この時点では通常rootが所有しているため、この例ではsudo展開にもを使用します。これにより、ステージングユーザーが新しいディレクトリに書き込みできるかどうかに依存する必要がなくなります。
sudo mkdir -p /u02/app/oracle/mgmt_agent/install_dir
sudo unzip /home/opc/oracle.mgmt_agent.260729.1846.Linux-x86_64.zip \
-d /u02/app/oracle/mgmt_agent/install_dir
cd /u02/app/oracle/mgmt_agent/install_dir/mgmt_agent観測されたZIPファイルは、ネストされたmgmt_agentディレクトリを作成しますinstaller.sh。インストーラーをinstall_dir自身から実行すると、が返されますNo such file or directory。ZIPファイル名と/home/opcソースパスは、観測された環境を反映しています。Oracleの推奨に従い、展開する前に、ZIPファイルのsha256sum出力をManagement Agent管理画面のチェックサムと比較してください。
ルートシェルを開く前、またはインストーラーを実行する前に、ファイルを編集して安全に保存してくださいmgmt_agent_exadbd.rsp。ダウンロードしたインストールキーはローカルファイルで使用しますが、スクリーンショット、チケット、ソース管理には絶対に保存しないでください。以下はスクリーンショットに安全なレンダリングです。表示名とプラグインオプションはそのままに、機密情報を伏せています。
# Do not replace this marker with the actual key in screenshots or published material.
ManagementAgentInstallKey = <REDACTED-INSTALL-KEY>
AgentDisplayName = odb-aws-host-vak331
#FreeFormTags = [{"<key1>":"<value1>"}, {"<key2>":"<value2>"}]
#DefinedTags = [{"namespace1":{"<key1>":"<value1>"}}, {"namespace2":{"<key2>":"<value2>"}}]
#CredentialWalletPassword =
#Service.plugin.jm-container.download=true
#Service.plugin.appmgmt.download=true
#Service.plugin.jms.download=true
#Service.plugin.dbaas.download=true
Service.plugin.logan.download=true
#Service.plugin.mds.download=true
#Service.plugin.osmh.download=true
#Service.plugin.opsiHost.download=true
#Service.plugin.jm.download=true
#Service.plugin..startup.jersey.hotpath.1.2f97483d-2052-4ce7-b18e-59a835d599c4.plugin.download=trueこの応答ファイルでは、のみがService.plugin.logan.download=true有効になっています。表示されているその他のプラグインオプションはコメントアウトされています。環境から必要な定義済みタグと承認済みのゲートウェイ設定を追加してください。キーをシェル履歴に貼り付けないでください。応答ファイルにはインストールキーが含まれているため、承認済みの保護された転送場所に保管し、登録が成功したら削除または安全に保管してください。Oracleでは、応答ファイルとすべての親ディレクトリがmgmt_agentOSユーザーからアクセス可能である必要があります。
mgmt_agent_exadbd.rsp/tmp重要 — を実行する前に、応答ファイルを に配置してくださいinstaller.sh。インストーラーはmgmt_agent、そのユーザーとしてエージェントを作成し、構成します。 の応答ファイルは、/home/opc親ディレクトリのアクセス許可が原因で読み取れない場合があります。完成した応答ファイルを にコピーし/tmp、ブートストラップ中に必要な一時的な読み取りアクセスのみを付与してください。
sudo cp /home/opc/mgmt_agent_exadbd.rsp /tmp/mgmt_agent_exadbd.rsp
sudo chmod 0644 /tmp/mgmt_agent_exadbd.rsp検証済みのトラブルシューティングセッションではモードが使用され777、権限が障害の原因であることが証明されました。公開されている手順ではを使用しない777でください。応答ファイルにはインストールキーが含まれており、モードでは777すべてのローカルユーザーがそれを読み取り、変更、実行できます。モードは、0644インストーラーがを作成する前の最小限の実用的なブートストラップ権限ですmgmt_agent。構成が正常に完了したら、ファイルをすぐに削除してください。
応答ファイルが保存され、エージェントユーザーがアクセス可能になったら、明示的にネストされたディレクトリに移動しinstaller.sh、ルートシェルを開きます。
cd /u02/app/oracle/mgmt_agent/install_dir/mgmt_agent
sudo /bin/bashルートシェルプロンプトで、インストールを開始します。
export OPT_ORACLE_SYMLINK=true
./installer.sh /tmp/mgmt_agent_exadbd.rspインストールは成功したが、エージェントの設定が失敗した場合
監視されたインストールでは、ソフトウェアのコピーとサービスの作成は完了しましたが、新しいmgmt_agentユーザーがファイルを読み取れなかったため、構成が失敗しました/home/opc/mgmt_agent_exadbd.rsp。これは部分的な成功です。ZIPファイルを再インストールしないでください。まず構成ログを確認してください。
以下のホスト出力は、/tmp修正前に、指定されたinstaller.sh場所に応答ファイルを受信した際に取得されたものです/home/opc。これは、ソフトウェアのインストールが成功した場合と、エージェントの設定が失敗した場合の違いを示しています。
Checking pre-requisites
Checking if any previous agent service exists
Checking if OS has systemd or initd
Checking available disk space for agent install
Checking if /opt/oracle/mgmt_agent directory exists
Checking if 'mgmt_agent' user exists
'mgmt_agent' user does not exist. Proceeding to create the user...
User home directory is valid and writable. Proceeding with user creation...
Creating user on Linux-based OS...
Checking Java version
JAVA_HOME is not set or not readable to root
Trying default path /usr/bin/java
Java version: 1.8.0_491 found at /usr/bin/java
Checking agent version
Executing install
Unpacking software zip
Copying files to destination dir (/opt/oracle/mgmt_agent)
Initializing software from template
Checking if JavaScript engine is available to use
Creating mgmt_agent daemon
Agent Install Logs: /opt/oracle/mgmt_agent/installer-logs/installer.log.0
Agent install successful
/home/opc/mgmt_agent_exadbd.rsp file is either not present or not readable to mgmt_agent user
Please make sure that the directory and parent directories also have the read permissions to make this file readable.
You may execute the following commands to make sure mgmt_agent user can read input.rsp:
cd /tmp
sudo -u mgmt_agent cat <FULL_PATH>/input.rsp
Missing mandatory properties opts
Usage: setup.sh opts=<FULL-PATH>
Please make sure there is no space in between opts=<FULL-PATH>
Executing configure
Prerequisite check failed
Pass opts=<> to application at the startup
Additional details are available in the configure logs at /u02/app/oracle/mgmt_agent/configure-logs
Agent configure failed.
Additional logs can be found at /opt/oracle/mgmt_agent/configure-logs/configure.log.0sudo tail -n 200 /opt/oracle/mgmt_agent/configure-logs/configure.log.0
sudo -u mgmt_agent cat /home/opc/mgmt_agent_exadbd.rsp >/dev/null2 番目のコマンドが を報告した場合Permission denied、応答ファイルを にコピーします/tmp。mgmt_agentが存在するため、 モードでそのファイルをそのユーザーに直接割り当て0600、インストール キーを表示せずにアクセスを確認します。
sudo cp /home/opc/mgmt_agent_exadbd.rsp /tmp/mgmt_agent_exadbd.rsp
sudo chown mgmt_agent:mgmt_agent /tmp/mgmt_agent_exadbd.rsp
sudo chmod 0600 /tmp/mgmt_agent_exadbd.rsp
sudo -u mgmt_agent cat /tmp/mgmt_agent_exadbd.rsp >/dev/null設定手順のみを再実行してください。opts=引数は必須であり、等号の前後にスペースを含めてはいけません。
sudo /opt/oracle/mgmt_agent/agent_inst/bin/setup.sh \
opts=/tmp/mgmt_agent_exadbd.rsp修正後の再試行により、以下の正常な構成出力が得られました。
Executing configure
Parsing input response file
Validating install key
Generating communication wallet
Generating security artifacts
Registering Management Agent
Found service plugin(s): [logan]
Starting agent...
Agent started successfully
Starting plugin deployment for: [logan]
Deploying service plugin(s)...Done.
logan : Successfully deployed service plugin
Agent setup completed and the agent is running.
In the future agent can be started by directly running: sudo systemctl start mgmt_agent
Please use OCI CLI or OCI Management Agent console to validate the successful activation of your agent.
Please make sure that you delete /tmp/mgmt_agent_exadbd.rsp or store it in secure location.検証済みのゲストでは、この再試行により、インストールキーの検証、ウォレットの生成、登録、エージェントの起動、およびloganプラグインの展開が完了しました。構成が再び失敗した場合は、/opt/oracle/mgmt_agent/configure-logs/configure.log.0報告された正確な原因を保存して確認してください。次に確認すべき一般的な項目は、インストールキーの有効期限切れまたは使用済み、ゲートウェイ/プロキシパラメータの誤り、および構成済みのOCIリージョンエンドポイントへのDNS、TLS、またはTCP 443接続です。応答ファイルまたは接続の問題を修正し、再度読み取り可能性を確認してからmgmt_agent、同じsetup.sh opts=...コマンドを再実行してください。
セットアップが成功し、OCIでエージェントがアクティブになったと表示されたら、一時応答ファイルを削除します。
sudo rm -f /tmp/mgmt_agent_exadbd.rspステップ5：エージェントとプラグインを検証する
プロセスと場所を確認してください。
systemctl status mgmt_agent --no-pager
readlink -f /opt/oracle/mgmt_agent
grep -F 'packageType=ZIP' \
/opt/oracle/mgmt_agent/agent_inst/config/security/resource/agent.package
rpm -qa | grep -i mgmt_agent || true
stat -c '%U %n' /opt/oracle/mgmt_agent
stat -c '%U %n' /opt/oracle/mgmt_agent/agent_instsystemctlサービスの状態を確認します。インストールターゲットに解決されるreadlinkことを確認します。を報告する必要があります。 RPM クエリは管理エージェント パッケージを生成してはなりません。所有権チェックの両方が を報告する必要があります。/opt/oracle/mgmt_agent/u02agent.packagepackageType=ZIPmgmt_agent
次に、管理エージェントクラウドサービスにおける登録と通信を検証します。
- OCIコンソールで、管理エージェントのリソースが作成されたリージョンを選択します。
- 「可観測性と管理」→「管理エージェント」→「エージェント」を開き、エージェントコンパートメントを選択します。
- ノード固有の
AgentDisplayName、例えばodb-aws-host-vak331や を検索しますodb-aws-host-vak332。 - 可用性がアクティブであること、オペレーティングシステムがLINUXであること、およびバージョンがインストールされているZIPビルドと一致していることを確認してください。必要なアップデートがないか、アップグレードを確認してください。
- サービスプラグインにログ分析がリストされていることを確認してください。エージェントの詳細を開き、ログ分析プラグインのステータスが「実行中」になっていることを確認してください。
- すべてのデータベースノードに対してこのチェックを繰り返し、コンソールリストと計画されたVMクラスタのインベントリを照合します。
アクティブエージェントは、クラウド登録と最近の管理エージェントとの通信を確立しますが、それ自体ではデータベースまたはGIログが取り込まれていることを証明するものではありません。目的のホスト、データベース、クラスタエンティティおよびソースを関連付け、ログエクスプローラで各ノードからの最近のイベントを確認します。収集警告とメトリックを確認し、ローテーションされたファイルや新しく作成されたファイル、および既存のファイルをテストします。選択したログパスには、適切なデフォルトACLを含め、ディレクトリトラバーサルとファイル読み取りアクセスを許可するACLを使用します。
このログ分析に特化した記事では、Service.plugin.logan.download=true必要なプラグインは のみです。データベース管理または Ops Insights は、それらのサービスがデプロイメントに含まれている場合にのみ有効にしてください。これらは、OCI ログ分析でデータベースまたは GI ログを収集するための前提条件ではありません。応答ファイルでログ分析プラグインが有効になっていない場合は、OCI コンソールの管理エージェントページからデプロイできます。
ステップ6：各データベースノードにエージェントをインストールして構成します。
最初のデータベースノードで構成が完了し、ステップ5のチェックに合格したら、同じ管理エージェントZIPファイルと保護された応答ファイルテンプレートのコピーを、残りのすべてのExadataデータベースノードにコピーします。データベースファイルまたはGIファイルを収集する必要がある各ノードに、個別の管理エージェントをローカルにインストールします。インストール済み/u02/app/oracle/mgmt_agentディレクトリをあるノードから別のノードにコピーしないでください。
応答ファイルを再利用する前に、[監視と管理] → [管理エージェント] → [管理] → [キーのインストール]を開きます。キーが有効であり、残りのインストール数が残りのすべてのノードに対応できることを確認してください。既存のキーの有効期限が切れた場合、キーが使い果たされた場合、または最大インストール数の設定が計画されているノード数をカバーしていない場合は、新しいインストールキーを作成またはダウンロードしてください。
環境に適した暗号化転送方法を使用してください。例えば、現在2つのファイルを保持しているノードまたはステージングホストから転送する場合：
target_dbnode=host-vak332
scp /home/opc/oracle.mgmt_agent.260729.1846.Linux-x86_64.zip \
/home/opc/mgmt_agent_exadbd.rsp \
opc@"$target_dbnode":/home/opc/
ssh opc@"$target_dbnode" \
'chmod 0600 /home/opc/mgmt_agent_exadbd.rsp'コピーした応答ファイルをテンプレートとして扱います。ターゲットノードで、AgentDisplayNameファイルをステージングする前に、ノード固有の値に変更します/tmp。これにより、管理エージェントとログ分析コンソールで各データベースノードを簡単に識別できるようになります。例:
AgentDisplayName = odb-aws-host-vak332検証済みのインストール キーとService.plugin.logan.download=true、そのノードに適用される承認済みのタグやゲートウェイ設定を保持します。次に、ターゲット ノードで手順 2～5 を繰り返します。事前チェックを完了し、/u02ターゲットと/opt/oracle/mgmt_agentシンボリック リンクを作成し、ZIP を解凍し、応答ファイルをステージングし、を実行しinstaller.sh、を検証しpackageType=ZIP、エージェントとloganプラグインがアクティブであることを確認します。emd.properties以下の と 2 GB のヒープ ベースラインを適用し、エージェントを再起動して、そのノードからのログ収集を検証します。
各VMクラスタ内のすべてのデータベースノードに対して、この手順を繰り返します。OCI Log Analyticsで、各ノードのアクティブなエージェントと最新のログレコードがそれぞれ異なることを確認します。ノードが正常に登録されたら、手順4で説明したように、そのノードの一時的な応答ファイルのコピーを削除します。保持するマスターコピーは、承認されたシークレット管理場所にのみ保存してください。
ベストプラクティス：Exadata Management Agentのベースラインを確立する
データベースログとGIログを収集するExaDB-DまたはExaC@Cフリートの場合、まず以下の管理エージェントプロパティから始めます。バックアップを作成しemd.properties、元のファイルを編集して、additional-propertiesセクションに設定を追加します。
sudo cp -p \
/opt/oracle/mgmt_agent/agent_inst/config/emd.properties \
/opt/oracle/mgmt_agent/agent_inst/config/emd.properties.pre-exadbd-baseline
sudo vi /opt/oracle/mgmt_agent/agent_inst/config/emd.propertiesloganalytics.enable_large_dir=true
# Sender properties
senderManagerMaxDiskUsedTotal=1000
_senderManagerPoolSize=10
# Connection pooling properties
clientConnectionPool.SERVICE_INVOKING.defaultMaxConnectionsPerRoute=50
clientConnectionPool.SERVICE_INVOKING.maxTotalConnections=100これらの値は、この Exadata ユースケースの開始ベースラインとして扱ってください。VM クラスタ、データベース、PDB、有効なログソース、1 時間あたりに作成されるファイル数、および観測された収集バックログの数に応じて調整してください。変更をフリート全体に適用する前に、まず代表的な VM クラスタで変更を検証し、エージェントの CPU、メモリ、ディスク使用量、収集レイテンシ、およびエラーを監視してください。以前の A-Team サイジング表のより大きな例は、普遍的な認定プロファイルではなく、計画の参考値です。
Oracleでは、10,000を超えるファイルを含むディレクトリを大規模ログディレクトリと定義しています。loganalytics.enable_large_dir=trueこれにより、エージェントはこのようなディレクトリを監視できますが、ヒープ、ディスク、inode、およびオープンファイルの負荷が増加する可能性があります。収集が不要になったファイルをクリーンアップし、大容量ソースを有効にする前にホストの容量を確認してください。参照：大規模ディレクトリ構成
このスタンドアロン管理エージェントのデプロイメントでは、Exadataフリートのベースラインとして最大2GBのJavaヒープを設定します。Oracleのドキュメントでは、スタンドアロン管理エージェントの標準最大ヒープは512MBとされていますが、2GBはこの記事で使用される運用ベースラインであり、製品のデフォルトではありません。バックアップを作成しjava.options、現在アクティブな-Xmxエントリを確認して、次のエントリに置き換えてください-Xmx2048m。
sudo cp -p \
/opt/oracle/mgmt_agent/agent_inst/config/java.options \
/opt/oracle/mgmt_agent/agent_inst/config/java.options.pre-2gb-heap
sudo grep -n '^-Xmx' \
/opt/oracle/mgmt_agent/agent_inst/config/java.options
sudo vi /opt/oracle/mgmt_agent/agent_inst/config/java.options-Xmx2048m両方のファイルを更新した後、エージェントを一度再起動し、サービス、ヒープエントリ、および管理エージェントのプロパティを確認してください。
sudo systemctl restart mgmt_agent
sudo systemctl status mgmt_agent --no-pager
sudo grep -n '^-Xmx' \
/opt/oracle/mgmt_agent/agent_inst/config/java.options
sudo grep -E \
'^(loganalytics\.enable_large_dir|senderManagerMaxDiskUsedTotal|_senderManagerPoolSize|clientConnectionPool\.SERVICE_INVOKING\.(defaultMaxConnectionsPerRoute|maxTotalConnections))=' \
/opt/oracle/mgmt_agent/agent_inst/config/emd.properties以下の出力は、host-vak331物理/u02構成パスと構成された2GBのヒープサイズを確認するものです。この-XX:+HeapDumpOnOutOfMemoryErrorオプションはインストールされたファイルにも含まれていました。
[root@host-vak331 config]# pwd
/u02/app/oracle/mgmt_agent/agent_inst/config
[root@host-vak331 config]# cat java.options
#encoding=UTF-8
#These java.options contain user supplied extensions to the options set in wrapper.conf.
#If you modify this file, please make sure that you restart the mgmt_agent service.
#Note: Please do not delete this file. Deleting this file will cause agent failures.
#Add each additional parameter on new line
#------------------------------------------------------------------------------------------------
-Dpolyglot.engine.AllowExperimentalOptions=true
-Dpolyglot.js.nashorn-compat=true
-Djdk.tls.client.protocols=TLSv1.3,TLSv1.2
-Djdk.tls.server.protocols=TLSv1.3,TLSv1.2
-Doracle.polaris.fips.approved_only=false
-XX:+HeapDumpOnOutOfMemoryError
-Dio.netty.native.workdir=/u02/app/oracle/mgmt_agent/agent_inst/tmpdir
-Dio.netty.tmpdir=/u02/app/oracle/mgmt_agent/agent_inst/tmpdir
-Dorg.newsclub.net.unix.library.tmpdir=/u02/app/oracle/mgmt_agent/agent_inst/tmpdir
-Dorg.bouncycastle.native.cpu_variant=java
-Xmx2048m同じホストは、最後に要求された Log Analytics 送信者と接続プールのベースラインを表示しましたemd.properties。
[root@host-vak331 config]# tail -10 emd.properties
################################
loganalytics.enable_large_dir=true
#Sender properties
senderManagerMaxDiskUsedTotal=1000
_senderManagerPoolSize=10
# Connection pooling properties
clientConnectionPool.SERVICE_INVOKING.defaultMaxConnectionsPerRoute=50
clientConnectionPool.SERVICE_INVOKING.maxTotalConnections=100
[root@host-vak331 config]#上記のファイル出力は、保存された構成を検証しています。再起動後、以下のsystemctl出力により、サービスが有効かつアクティブであることが確認されました。また、物理インストール環境から実行されているラッパーとJavaプロセスも表示されました/u02/app/oracle/mgmt_agent。キャプチャされたターミナルでは、長いプロセス引数は切り捨てられていますsystemctl。
[root@host-vak331 config]# sudo systemctl status mgmt_agent --no-pager
● mgmt_agent.service - mgmt_agent
Loaded: loaded (/etc/systemd/system/mgmt_agent.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2026-09-17 20:08:40 UTC; 3s ago
Process: 348607 ExecStop=/u02/app/oracle/mgmt_agent/agent_inst/bin/agentcore stop sysd (code=exited, status=0/SUCCESS)
Process: 350167 ExecStart=/u02/app/oracle/mgmt_agent/agent_inst/bin/agentcore start sysd (code=exited, status=0/SUCCESS)
Main PID: 350257 (wrapper)
Tasks: 73 (limit: 319999)
Memory: 562.9M
CGroup: /system.slice/mgmt_agent.service
├─350257 /u02/app/oracle/mgmt_agent/agent_inst/bin/./wrapper /u02/app/oracle/mgmt_agent/agent_inst/bin/../config/wrapper.conf wrapper.syslog.ident=mgmt_agent wrapper.pidfile=/u02/app/oracle/mgm…
└─350326 /usr/lib/jvm/jdk-1.8.0_491-oracle-x64/bin/java -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.maxStartMainWait=5 -Djava.security.egd=file:///dev/./urandom -Dpolyglot.engine.AllowExperim…
Sep 17 20:08:28 host-vak331 systemd[1]: Starting mgmt_agent...
Sep 17 20:08:28 host-vak331 agentcore[350167]: Starting mgmt_agent...
Sep 17 20:08:35 host-vak331 agentcore[350167]: Waiting for mgmt_agent.........
Sep 17 20:08:40 host-vak331 agentcore[350167]: .....running: PID:350257
Sep 17 20:08:40 host-vak331 systemd[1]: Started mgmt_agent.保存されたファイルの出力と再起動後のサービスステータスを合わせて確認することで、2 GB のヒープと管理エージェントのプロパティ変更が検証されますhost-vak331。ワークロードが追加されるにつれて、メモリ、エージェントログ、および収集バックログの監視を継続してください。
トラブルシューティング: エージェントが報告しますOutOfMemoryException
エージェントに割り当てられた収集負荷が設定された最大値を超えると、ヒープが不足する可能性があります。-Xmxまず、アクティブ値と最近のサービスメッセージを確認してください。
sudo grep -n '^-Xmx' \
/opt/oracle/mgmt_agent/agent_inst/config/java.options
sudo journalctl -u mgmt_agent -n 100 --no-pagerスタンドアロンエージェントがまだデフォルトの 512 MB を使用している場合は、上記の手順で 2 GB に増やし、サービスを再起動して、サービスがアクティブな状態を維持していることを確認してください。2 GB にしても例外が続く場合は、VM に十分な空きメモリがあることを確認し、ファイル数、ログ生成レート、有効なソース、収集バックログ、その他のプラグインワークロードを確認してから、ヒープを再度増やしてください。サポートされている構成でも障害が続く場合は、エージェントログを保存し、Oracle サポートにお問い合わせください。
参考資料： 管理エージェントのOutOfMemoryExceptionトラブルシューティング
登録が正常に完了したら、応答ファイルとダウンロードしたインストール成果物を転送場所から削除するか、承認済みの秘密の場所に保存してください。ノード、エージェントOCID、ソース関連付け、および検証時間を記録してから、プロセスを再度実行してください。ExaC@Cの場合は、ZIPファイルと/u02アプローチを維持し、接続を顧客が承認したOCI出力パスまたは管理ゲートウェイに合わせて調整してから、同じ収集チェックを適用してください。
OCI ExaDB-DおよびExaC@Cのデプロイメント前提条件を調整する
ソース/エンティティの設定および検証手順は、フリート全体で再利用可能です。コマンドを再利用する前に、各環境のネットワークおよびサポート要件を適用してください。
| デプロイメント | インストールと接続の調整 |
|---|---|
| Oracle Database@AWS ExaDB-D | このZIP手順と、リンクされたOCIネットワークを介したリージョン収集パスにおけるAWSゲストイメージのサポートを検証します。 |
| OCI の ExaDB-D | ドキュメントに記載されている Exadata ZIP と/u02手順を使用し、ゲストサブネットから必要なリージョンサービスへの経路と出力を確認します。 |
| ExaC@C | 文書化されたZIPファイルと/u02手順を使用し、承認済みの出口、プロキシ、または管理ゲートウェイパスを経由して、顧客ゲストネットワークからの接続を設定してください。インフラストラクチャ管理接続がこのパスを提供すると想定しないでください。 |
各デプロイメントにおいて、VMごとのエージェント、ログアクセス、ソース関連付け、および最新レコードのチェックを同じものを使用してください。最新のインストール手順とホスト/ネットワークの前提条件に従ってください。
データベースとGIログを適切なエンティティに関連付ける
エージェントとプラグインが利用可能になったら、各仮想マシン（VM）のコレクションモデルを構築します。テナント内の実際のソース定義（必要なエンティティプロパティとファイルパターンを含む）を使用してください。以下のOracle定義のソースは、便利な出発点となります。
| ソース | エンティティタイプ |
|---|---|
Database Alert Logs | Oracleデータベースインスタンス |
Database Listener Alert Logs | Oracleデータベースリスナー |
Automatic Storage Management Alert Logs | 自動ストレージ管理インスタンス |
Clusterware Ready Services Alert Logs | Oracle Cluster ノード |
Clusterware Ready Services Daemon Logs | Oracle Cluster ノード |
Clusterware Disk Monitor Logs | Oracle Cluster ノード |
データベース診断を行うには、承認済みのDBAセッション経由で接続し、アクティブなADRパスを確認してください。
SELECT name, value
FROM v$diag_info
ORDER BY name;特定のインスタンスの ADR ホームとトレース ディレクトリを記録します。最初のノードのパスをコピーする代わりに、他のインスタンスに対して検出を繰り返します。リスナー診断は、適切なローカル リスナー エンティティまたは SCAN リスナー エンティティにマッピングする必要があります。Clusterware のドキュメントに記載されている ADR ホームは で<GRID_ORACLE_BASE>/diag/crs/<hostname>/crs、テキスト アラートは にtrace/alert.logあります。VM 上の実際の Grid ベースとホスト名を検出します。
mgmt_agentデータベースとリスナーログへのアクセスを許可する
スタンドアロン管理エージェントは として実行されますmgmt_agent。このアカウントには、ログファイルへの読み取りアクセスと、各ログパス内のすべてのディレクトリへの読み取り/実行アクセスが必要です。Oracle では、このアクセスを付与する最初の方法としてファイルシステム ACL の使用を推奨しています。既存の ACL を変更する前に確認し、パッケージaclが存在することを確認してから、既存のエントリを置き換えずに権限を追加してください。コマンドは です。setfacl類似のスペルsetfactlは無効です。参照: エージェントユーザーに読み取りアクセスを付与する
以下のデータベースアラートの例では、監視対象の/u02/app/oracle/diag/rdbms/oradbrac/ORADBRAC2/traceディレクトリを使用します。データベースの一意の名前、インスタンス名、およびパスを、ターゲットデータベースノードで検出された値に置き換えてください。rootログインシェルを開きます。
sudo su -ルートプロンプトで、親ディレクトリへのトラバーサルを許可し、既存のADRコンテンツへの再帰的アクセスを許可し、将来のファイルのためにトレースディレクトリにデフォルトのACLを設定します。
rpm -q acl
getfacl -p /u02/app/oracle/diag
setfacl -m u:mgmt_agent:rx /u02
setfacl -m u:mgmt_agent:rx /u02/app
setfacl -m u:mgmt_agent:rx /u02/app/oracle
setfacl -m u:mgmt_agent:rx /u02/app/oracle/diag
setfacl -R -m u:mgmt_agent:rx /u02/app/oracle/diag
setfacl -d -m u:mgmt_agent:rx \
/u02/app/oracle/diag/rdbms/oradbrac/ORADBRAC2/trace
getfacl -p \
/u02/app/oracle/diag/rdbms/oradbrac/ORADBRAC2/trace
exit以下のリスナー例は 用ですhost-vak332。ホスト名を置き換え、対象ノードに存在するリスナーディレクトリのみを残してください。
sudo su -ルートプロンプトで、以下を実行します。
rpm -q acl
getfacl -p /u01/app/grid/diag
setfacl -m u:mgmt_agent:rx /u01
setfacl -m u:mgmt_agent:rx /u01/app
setfacl -m u:mgmt_agent:rx /u01/app/grid
setfacl -m u:mgmt_agent:rx /u01/app/grid/diag
setfacl -R -m u:mgmt_agent:rx /u01/app/grid/diag
setfacl -d -m u:mgmt_agent:rx \
/u01/app/grid/diag/tnslsnr/host-vak332/listener/trace
setfacl -d -m u:mgmt_agent:rx \
/u01/app/grid/diag/tnslsnr/host-vak332/listener_scan1/trace
setfacl -d -m u:mgmt_agent:rx \
/u01/app/grid/diag/tnslsnr/host-vak332/listener_scan2/trace
setfacl -d -m u:mgmt_agent:rx \
/u01/app/grid/diag/tnslsnr/host-vak332/listener_scan3/trace
setfacl -d -m u:mgmt_agent:rx \
/u01/app/grid/diag/tnslsnr/host-vak332/asmnet1lsnr_asm/trace
getfacl -p \
/u01/app/grid/diag/tnslsnr/host-vak332/listener/trace
exitソースを関連付ける前に、エージェントアカウントとしての有効なアクセス許可を検証してください。以下のループは、ログの内容を表示せずに、サンプルディレクトリへの読み取りアクセスとトラバーサルアクセスをチェックします。
for log_dir in \
/u02/app/oracle/diag/rdbms/oradbrac/ORADBRAC2/trace \
/u01/app/grid/diag/tnslsnr/host-vak332/listener/trace \
/u01/app/grid/diag/tnslsnr/host-vak332/listener_scan1/trace \
/u01/app/grid/diag/tnslsnr/host-vak332/listener_scan2/trace \
/u01/app/grid/diag/tnslsnr/host-vak332/listener_scan3/trace \
/u01/app/grid/diag/tnslsnr/host-vak332/asmnet1lsnr_asm/trace
do
sudo -u mgmt_agent test -r "$log_dir"
sudo -u mgmt_agent test -x "$log_dir"
done実際のファイル名を確認した後、代表的なデータベースアラートログとリスナーログから1行を読み取りますmgmt_agent。出力が成功すれば、root権限に頼らずにファイルレベルの読み取りアクセスが可能であることがわかります。
database_alert_log=/u02/app/oracle/diag/rdbms/oradbrac/ORADBRAC2/trace/alert_ORADBRAC2.log
listener_log=/u01/app/grid/diag/tnslsnr/host-vak332/listener/trace/listener.log
sudo -u mgmt_agent tail -n 1 "$database_alert_log"
sudo -u mgmt_agent tail -n 1 "$listener_log"すべてのデータベースノードで、そのノードで検出されたパスを使用して、ACLと検証の手順を繰り返します。データベースまたはグリッドホームの変更後、およびログローテーション後に、アクセス権限を再確認してください。デフォルトACLは、将来のファイルがアクセス権限を継承するのに役立ちますが、再帰ACLは既に存在するファイルとディレクトリを対象とします。
ORADBRAC1Oracleデータベースインスタンスエンティティを作成します。
注:
ORADBRAC1、、および関連するすべてのコンポーネントを手動で作成することORADBRAC2は、チュートリアルには実用的ですが、大規模な Exadata フリート全体にはうまく拡張できません。OCI Log Analytics はOCI Stack Monitoringと統合され、エージェント駆動のエンティティ検出を提供します。Log Analyticsエンティティページから、[新しいリソースの検出] をクリックすると、Stack Monitoring 検出ワークフローが開きます。オペレーターがジョブを開始すると、管理エージェントが選択された Oracle Database 環境を検査し、検出されたリソース モデルを OCI に送信します。Linux 上の外部 Oracle Database または RAC デプロイメントの場合、Stack Monitoring はデータベース システムとその依存リソースを検出できます。Oracle は、リスナーや ASM などのコンポーネントのデータベース システム検出について具体的に文書化しています。検出結果は、Stack Monitoring と Log Analytics の両方に送信できます。参照: エンティティとログ コレクションの自動検出、Stack Monitoring リソース検出
Oracle で定義されたアラートログソースが正しいパスを解決し、それらのファイルを所有するノード上の管理エージェントを使用できるように、データベースインスタンスごとに個別のエンティティを作成します。この例でORADBRAC1は に作成しますhost-vak331。以前のORADBRAC2ACL パスは、ノード固有の別の例です。
- オブザーバビリティと管理 → ログ分析 → 管理 → エンティティを開き、エンティティ コンパートメントを選択して、[作成]をクリックします。
- 名前
ORADBRAC1に入力し、エンティティタイプとしてOracleデータベースインスタンスを選択します。 - 管理エージェントのコンパートメントを選択し、それを管理エージェント
odb-aws-host-vak331として選択します。 - そのデータベースノードで検出された値を入力してください。取得された構成では、以下のプロパティが使用されます。
| エンティティプロパティ | 例の値 |
|---|---|
DIAGNOSTIC_DEST | /u02/app/oracle/diag |
adr_home | /u02/app/oracle/diag |
host_name | host-vak331 |
oracle_home | /u02/app/oracle/product/19.0.0.0/dbhome_2 |
port | 1521 |
- 「変更を保存」をクリックし、エンティティを再度開いて、そのタイプ、エージェント、およびプロパティがターゲットインスタンスと一致していることを確認します。Oracleで定義されたファイルソースは、インクルードパターンでエンティティプロパティを使用するため、プロパティ値が欠落しているか間違っていると、ソースの関連付けやファイルのマッチングが失敗する可能性があります。
ORADBRAC2Oracleデータベースインスタンスエンティティを作成します。
管理エージェントとOracleホームを使用して、2番目のデータベースインスタンスのエンティティ作成を繰り返しますhost-vak332。
| エンティティ設定 | 例の値 |
|---|---|
| 名前 | ORADBRAC2 |
| エンティティタイプ | Oracle Database Instance |
| 管理会社 | odb-aws-host-vak332 |
DIAGNOSTIC_DEST | /u02/app/oracle/diag |
adr_home | /u02/app/oracle/diag |
host_name | host-vak332 |
oracle_home | /u02/app/oracle/product/19.0.0.0/dbhome_1 |
port | 1521 |
で検出されたパスと照らし合わせて値を確認しhost-vak332、「エンティティの作成」をクリックします。作成後、再度開きORADBRAC2、選択したエージェントとプロパティが保存されていることを確認してから、ソースを関連付けます。
ORADBRAC2図 8.アラートログ収集用のエンティティの作成host-vak332。「データの追加」でデータベースインスタンスとログソースを関連付けます。
データ追加ウィザードを使用して、両方のRACインスタンスのソースエンティティ関連付けを1つのワークフローで作成します。Oracleでは、このウィザードを、エンティティの選択、ソースの選択、ロググループの割り当て、および関連付けの検証を行うための継続的収集の手順として説明しています。
Database Alert Logs、Database Attention LogsおよびDatabase Incident Dump Filesが選択されます。
Multicloud_OracleDB_LogGroup目的地を選択する
検証が失敗した場合は、同じ構成を繰り返し送信しないでください。エージェント コレクションの警告を確認し、エンティティ プロパティが意図したアラート ログ パスに解決されることを確認し、ファイル アクセスをテストしmgmt_agent、Log Analytics プラグインが実行されていることを確認し、以下の動的グループと IAM ポリシーを確認してください。
管理エージェントの動的グループを確認し、ポリシーをアップロードします。
セットアップ取り込みワークフローでは、一部のIAMリソースを自動的に作成できますが、意図したスコープが選択されたと想定するのではなく、結果を検証してください。IDとセキュリティ → 動的グループを開き、exadb-mgmtagent-dg一致ルールが管理エージェントコンパートメント内の管理エージェントリソースをカバーしていることを確認します。
ALL {resource.type='managementagent', resource.compartment.id='<management-agent-compartment-OCID>'}テナント内のすべての管理エージェントが意図的にコレクションIDの一部である場合を除き、より広範なALL {resource.type='managementagent'}ルールは適用しないでください。動的グループがIDドメインに属している場合は、Oracleドキュメントとしてポリシーのサブジェクトにドメイン名を含めてください。
Oracleの「管理エージェントの動的グループを使用した継続的なログ収集を許可する」テンプレートには、メトリックとアップロード権限が含まれています。この記事のポリシーコレクションには、READ USERSOracleの自動エージェント取り込みポリシーの例にも含まれるテナンシーレベルの権限も含まれています。コンパートメントスコープの権限については、対象のLog Analyticsリソースを含むコンパートメントを選択してください。
ALLOW DYNAMIC-GROUP <identity-domain>/exadb-mgmtagent-dg TO USE METRICS IN COMPARTMENT <log-analytics-compartment>
ALLOW DYNAMIC-GROUP <identity-domain>/exadb-mgmtagent-dg TO {LOG_ANALYTICS_LOG_GROUP_UPLOAD_LOGS} IN COMPARTMENT <log-analytics-compartment>
ALLOW DYNAMIC-GROUP <identity-domain>/exadb-mgmtagent-dg TO READ USERS IN TENANCY<identity-domain>/テナントの主題構文で必要ない場合は省略します。キャプチャされた環境でIN TENANCYは、図 15 に示す有効だがより広範な形式が使用されます。メトリックとアップロード操作をカバーする最も狭いコンパートメント スコープを優先します。READ USERSテナント スコープのままです。
exadb-mgmtagent-dgメトリクスを出力し、ログをLog Analyticsロググループにアップロードする権限が付与されます。Log Analyticsで関連付けチェックを完了してください。
- 再度開き
ORADBRAC1、[管理] → [エンティティ]ORADBRAC2で、[関連ソース]の下に[データベース アラート ログ]が表示されていることを確認します。 - ソースの解決済みインクルードパターンと除外を調べます。それらが
ORADBRAC1のアラートログの場所host-vak331と のORADBRAC2アラートログの場所に解決されることを確認しますhost-vak332。 - 続行する前に、エージェント収集に関する警告を確認し、エンティティプロパティ、ファイルマッチング、IAM、または
mgmt_agentアクセスに関する問題を修正してください。 - ログエクスプローラーを開き、[データベースアラートログ] を選択して
Multicloud_OracleDB_LogGroup、[ログ] と[データベースアラートログ]ORADBRAC1の両方から最近のレコードを検証しますORADBRAC2。各レコードのタイムスタンプ、メッセージ、および抽出されたフィールドも確認してください。
ORADBRAC1ファイル収集ワークフローでは、ソースパターンとエンティティの関連付けについて説明します。まずはアラート表現を1つだけ収集します。テキストとXMLの両方のコピーを収集すると、下流のカウントでイベントが重複する可能性があります。診断上の価値がデータ量に見合う場合は、トレースやインシデントダンプに拡張します。
展開承認のためには、想定されるVM/エンティティ/ソースのリスト、エージェントの状態、収集に関する警告、および有効化された各ソースからの最新のレコードを取得してください。最新のレコードがないソースは、単に動作していない可能性があります。コレクションの状態とファイルのアクティビティを比較してから、正常か異常かを判断してください。
オプション拡張機能：ExaWatcher診断
ExaWatcher は、データベース調査にゲスト オペレーティング システム コンテキストを追加できますが、その収集および解析ワークフローは、この記事のデータベースおよび GI の焦点範囲外です。具体的な実装例については、Jerry Russell 氏の「Oracle Log Analytics で ExaWatcher VMStat 出力用の高度なログ パーサーを作成する」を参照してください。このドキュメントでは、パーサー機能、ソース データ フィルタ、管理エージェントの関連付け、オンデマンド テスト、および ExaWatcher VMStat レコードの視覚化について説明しています。
そのパターンを適用する前に、対象のゲストイメージ上で、ExaWatcherファイルの場所、エージェントのアクセス許可、タイムスタンプの処理、ローテーション動作、およびVMStatのセマンティクスを検証してください。OracleのExaWatcherドキュメントには、ユーティリティの背景情報と操作手順が記載されています。
フリートダッシュボードと調査クエリを作成する
まず、データベースアラートの傾向とエラーを表示するOracleデータベースアラートダッシュボードから始めます。Oracleが定義したダッシュボードを複製してカスタマイズし、ゲストホストとGIのビューを追加します。共通の時間フィルタと範囲フィルタを設定して、各パネルが同じインシデント期間を表示するようにします。
Oracle Database Alertダッシュボードを開く
Log Analytics → Dashboardsを開き、目的のコンパートメントを選択して、 を検索しますoracle database。[作成者]列は、Oracle が定義したダッシュボードを示します。Oracle Database Alert を開きます。
Oracleで定義されたダッシュボードは直接編集できません。フリート固有のウィジェットを追加したり、フィルタを変更したり、保存済みの検索を置き換えたりする前に、 Oracle Database Alertを複製してください。ExaDB-Dフリートに属するロググループコンパートメント、リージョン、エンティティコンパートメント、データベースエンティティ、および時間範囲を適用してください。
Oracle Database Alert Error Summary 保存済み検索を作成する
ログエクスプローラーでエラー概要ウィジェットを開くか、次のクエリを使用して保存済み検索を作成します。
'Log Source' = 'Database Alert Logs'
| link 'Error ID', Entity
| lookup table = 'ORA Error Messages' select errmsg as 'Error Message'
using 'Error ID' = errid
| stats unique('Problem Priority') as Severity
| eventstats ifnull(sum(Count), 0) as 'Total Errors',
unique(Entity) as 'Database(s) with issues',
ifnull(distinctcount(Entity), 0) as 'Number of database(s) with issues'
| fields target = ui -'Total Errors', -'Number of database(s) with issues'このlinkコマンドは、エラー ID とデータベース エンティティごとにレコードをグループ化します。ルックアップは、一致するエラー ID をORA Error Messagesテーブルで補強し、eventstats結果全体に合計を追加します。最後のfields target = ui句は、バックエンド フィールドを破棄せずに、リンク グループ テーブルから 2 つの補助合計を削除します。エラー メッセージが空白の場合は、ルックアップに解析済みのエラー メッセージが含まれerrid、解析済みのエラー ID と元のレコードを主要な証拠として保持してください。
ウィジェットを最新の状態に保つ相対的な時間範囲を指定して検索を保存し、複製したダッシュボードに追加します。固定の時間範囲を指定すると、代わりに1つの調査ウィンドウが保持されます。Oracleは、保存された検索を再利用可能なダッシュボードウィジェットとして文書化し、カスタマイズ前にOracle定義の検索を複製することをサポートしています。
ORA-7445 レコードを詳しく調べる
図18で、2該当するORA-7445行のリンクされたカウントをクリックします。Log Analyticsは、リンクコレクション内の2つのレコードを開き、時間範囲をそれらの間隔に絞り込みます。
Quickly discover ORA-7445 across the database fleetこのドリルダウン機能を使用すると、アラートエントリ、トレースファイルまたはインシデント参照、関連するデータベースメッセージ、およびGI、ASM、リスナーソースからのレコードを同じウィンドウで確認できます。リンクされた2つのレコードは時間的なコンテキストを確立しますが、それ自体ではORA-7445の根本原因を特定することはできません。データベース診断またはOracleサポートのワークフローのために、元のアラートとトレースの証拠を保存してください。
LoganAIでAIを活用した支援を追加しましょう
LoganAIは、Log Analyticsにおける生成型AI機能です。個々のレコード、グループ、クラスタ、グラフを要約し、複雑な結果を説明し、Log Analyticsワークフロー内で状況に応じたフォローアップ質問を提案できます。テナンシー内のOCI生成型AIを使用します。Oracleは、AIが生成する応答は不完全または不正確な場合があるため、運用上の決定を下す前に、すべての説明を元のレコードと照合して検証するよう注意を促しています。
リージョンで有効にするには、[管理] → [サービスの詳細] → [LoganAI 設定の構成] を開きます。OCI 生成 AI リージョンとコンパートメントを選択し、モデルの動作を選択し、必要なモデル ライセンスを確認して承認し、ユーザー ライセンス承認ポリシーを選択して、表示される IAM 権限を構成します。[設定の検証]でテストを実行してから、 [LoganAI 設定の更新]をクリックします。LoganAI の利用可否はリージョンによって異なり、選択した OCI 生成 AI サービスでは使用料が加算され、ログは Log Analytics リージョンから選択した生成 AI リージョンに送信できます。
アクティベーション後、選択したORA-7445グループまたはその周辺のチャートに対してExplainコマンドを使用し、簡潔な要約と調査に関する質問を要求してください。インシデントのタイムラインまたはRCAに追加する前に、すべての主張を記録、データベーストレースファイル、および裏付けとなる情報源と照合してください。
統合データベースアラートビューを使用する
Oracleが定義したダッシュボードは、アラートの概要、新規問題と異常値、ログの傾向、ORAおよびTNSの分布、破損ブロックの結果、データベースの分布、重大度、エラーの傾向を1つの画面にまとめて表示します。合計値を解釈する前に、時間と範囲のフィルタを設定してください。
マルチクラウド運用ビューでは、複製されたビューに収集範囲、リスナー障害、GIおよびASMイベントを追加します。ウィジェット間で時間、ロググループ、エンティティのスコープを統一することで、オペレーターはフリートレベルの症状から、原因となっているデータベースやインフラストラクチャのレコードへとスムーズに移行できます。
ダッシュボードを操作ルーチンに変換する
接続障害が発生した場合は、データベースパネルとリスナーパネルを使用して影響を受けるインスタンスを特定し、同じウィンドウでGIレコードとASMレコードを調べます。LoganAIに選択した証拠を要約させ、次の調査手順を提案させます。RCAの結論を記録する前に、その応答を元のレコードと照合して検証します。
便利な検索条件をダッシュボードウィジェットとして保存し、フィルターが意図したすべてのソースに適用されることを確認し、各カウントの意味を文書化します。クエリとしきい値のテストが完了したら、選択した検索条件をスケジュールされた検出およびアラートワークフローに供給できます。
収集パイプラインの追跡も、同じルーチンの一部として行います。エージェントの状態、警告、新規VMのオンボーディング、ログ量などを確認します。頻繁に使用される診断情報は、必要な調査期間の間保持し、使用例が明確な大量トレースを追加します。これらの決定により、環境の変化に応じてフリートダッシュボードの有用性を維持できます。
まとめ
OCI Log Analyticsは、Oracle Database@AWS ExaDB-DおよびExaC@Cの運用において、分散診断エビデンスを扱うための共通の方法を提供します。その価値は、Oracle対応のソース構成と再現可能な調査を連携させることにあります。具体的には、影響を受けるインスタンスを特定し、関連するデータベースおよびGIメッセージを追跡し、ゲストホストのエビデンスを検査し、他のオペレーターが再現できるクエリを共有できます。
まず、1つのVMクラスタから始めます。ZIPのインストール、環境固有のネットワークパス、ソース関連付け、ファイルローテーション、タイムスタンプ、および抽出されたフィールドを検証し、検証済みのデータベースとGIコレクションパターンをOracle Database@AWSまたはExaC@Cの環境全体に展開します。
コメント
コメントを投稿