カスタム・ログ

カスタム・ログは、カスタム・アプリケーション、他のクラウド・プロバイダまたはオンプレミス環境からの診断情報を含むログです。カスタム・ログは、次の2つの方法で収集できます。
  1. PutLogsを使用してカスタム・ログを直接取り込みます。詳細は、ロギング収集APIおよびREST APIも参照してください。
  2. Unified Monitoring Agentを設定します。手順については、Installing the Agentを参照してください。

カスタム・ログは、Oracle Cloud Infrastructure Computeインスタンス・ページで表示でき、ログ・リソースが関連付けられています。これらは、ロギング検索ページ、ログ・ページまたは関連するログ・グループ詳細ページでも表示できます。カスタム・ログはベア・メタル・インスタンスでもサポートされます。

エージェントは多くのマシンにインストールでき、アプリケーションまたはシステムがログを発行するローカル・ディレクトリからログを取得します。エージェントはログを解析することもできます。これらはすべてエージェント構成で構成されます。エージェント構成を個別に作成してカスタム・ログを関連付けることも、カスタム・ログを作成してからそのエージェント構成を作成することもできます。

エージェント構成は、次を定義するための中心的なメカニズムです。
  • ログの元となるホスト。
  • ホストから必要な特定のログ。
  • 追加パーサー。
  • カスタム・ログの保存先。

カスタム・ログの作成は2ステップのプロセスで、最初にカスタム・ログ・オブジェクトを作成し、次に関連するエージェント構成を作成します。カスタム・ログおよびエージェント構成の作成の詳細は「カスタム・ログの作成」を、エージェントの設定および管理の詳細は「エージェント管理」を参照してください。

カスタム・ログの作成

カスタムログを作成するには
  1. ナビゲーション・メニューを開きます。「ソリューションおよびプラットフォーム」で、「ロギング」に移動し、「ログ」をクリックします。
  2. リスト・スコープ」の「コンパートメント」で、作業権限のあるコンパートメントを選択します。
  3. Custom Log Name」にカスタム・ログの名前を入力します。
  4. コンパートメント」から、操作する権限があるコンパートメントを選択します。
  5. ログ・グループ」から、カスタム・ログインを配置するログ・グループを選択します。
  6. 必要に応じて、「ログ保持」からログ保持値を選択し、「タグの追加」で適用可能なタグを追加します。
  7. ログ・オブジェクトの作成」をクリックします。「エージェント構成の作成」パネルが表示され、次に新しい構成を作成したり、関連付けられたログ・データのパラメータ(デフォルト)を定義したり、後で追加できます。
  8. 「名前とコンパートメント」で、対応するフィールドに構成名を入力し、作業権限を持つコンパートメントを選択します。
  9. この構成に適用するVMを定義できる「Choose Host Groups」で、「Dynamic Group」または「User Group」のいずれかのグループ・タイプをドロップダウン・リストから選択します。

    動的グループの場合、動的グループは、コンソールのIAM機能で作成できるインスタンスのグループを参照します。詳細は、動的グループについてを参照してください。これらの動的グループは、動的グループ設定の設定時に「グループ」フィールドから選択できます。

    ユーザー・グループ」の場合は、「グループ」フィールドからグループを選択します。ユーザー・グループは、コンソールのIAMグループ機能も参照します。詳細は、グループの管理を参照してください。

    ホスト・グループの追加」をクリックして、グループを追加します。エージェント構成にグループ・タイプの組合せを追加できます。つまり、動的グループユーザー・グループの両方を構成に設定できます。

    注意:構成ごとに最大5つ

    のグループが許可され、ホストは最大5つの異なるグループにすることができます。
  10. 次に、構成で、「ログ入力の構成」でログの形式(監視するログ)を定義する必要があります。ドロップダウン・リストから、「Windowsイベント・ログ」または「ログ・ディレクトリ」のいずれかの入力タイプを選択します。
    • Windowsイベント・ログ」で、入力を入力し、ドロップダウン・リストから「イベント・チャネル」オプションを選択します。
    • ログ・ディレクトリ」で、対応するフィールドに「入力」および「パス」を入力します。たとえば、/<log_path>/<log_name>です。複数のパスを入力できます。
    拡張パーサー・オプション」をクリックして、「拡張パーサー・オプション」パネルを開きます。これにより、次のパーサーに従って、ログの解析方法を指定できます。一部のパーサーには、選択したタイプに応じて追加の入力が必要で、追加のオプションがあります。
    • AUDITD
    • JSON
    • TSV
    • CSV
    • NONE (デフォルト)
    • SYSLOG
    • APACHE2
    • APACHE_ERROR
    • MSGPACK
    • REGEXP
    • マルチライン
    たとえば、JSONの場合、ドロップダウンから「時間タイプ」値を選択する必要がありますが、オプションで、追加のイベント時間およびNULLフィールド設定を指定できます。一方、REGEXPの場合は、一致するログの正規表現を時間書式とともに指定します。詳細は、ログ入力およびパーサーを参照してください。
  11. ログ入力およびパーサーを構成した後、オプションでタグ設定を指定できます。「送信」をクリックして変更を保存し、カスタム・ログとそれに関連付けられたエージェント構成を作成します。

要約すると、エージェント構成では、構成が適用されるインスタンス(ホスト・グループの選択)、取得されるログ・ファイル、使用されるパーサー(ログ入力の構成)、およびレコードがプッシュされるOracle Cloud Infrastructureシステム内のログ・オブジェクト(ログ宛先の選択)が定義されます。後者は、カスタム・ログ作成ステップで設定されたため、すでに設定されています。

カスタム・ログ・オブジェクトと、インスタンスからデータを取得してカスタム・ログ・オブジェクトにプッシュするエージェント構成が作成されます。

エージェント管理

アプリケーションからカスタム・ログにイベントを収集するには、Oracleのフラッシュベース・エージェントをインストールします。このエージェントを使用すると、収集するログやその解析方法などを正確に制御できます。

Oracle Cloud Infrastructureロギングは、サポートされている一連のオペレーティング・システムのエージェントを有効化および管理するための簡単なメカニズム(エージェント構成)を提供します。エージェント構成を使用すると、ホストのフリート全体で収集するカスタム・ログを簡単に構成できます。エージェント構成でサポートされているオペレーティング・システムは次のとおりです。

  • OEL 7、8
  • CentOS 7
  • Windows Server 2012 R2、Windows Server 2016、Windows Server 2019

サポートされているオペレーティングシステムのこのリストは常に更新されています。

エージェントのインストール

新規Oracle Cloud Infrastructureインスタンス

サポートされているオペレーティング・システムでは、作成時にエージェントを直接有効にできます。これを行うには、コンピュート・インスタンスの監視の有効化を参照してください。

既存のOracle Cloud Infrastructureインスタンス

サポートされているオペレーティング・システムがある既存のインスタンスの場合、監視を有効にする必要があります。コンピュート・インスタンスの監視の有効化を参照してください。

モニタリング・プラグインがすでに有効になっている場合は、18th. 9月までにエージェントをインストールするためにインスタンスに自動的にパッチが適用されます。それ以外の場合は、次の手動インストール手順に従います。

  1. (Linux)次のオペレーティングシステムのエージェントをダウンロードします。
  2. (Linux)次のコマンドを実行してRPMをインストールします。
    yum install -y <rpm-name>
  1. (Windows) https://objectstorage.us-phoenix-1.oraclecloud.com/n/axmjwnk4dzjv/b/unified-monitoring-agent-windows-repo/o/unified-monitoring-agent-0.0.5.msiからエージェントをダウンロードします
  2. (Windows)昇格されたコマンド・プロンプト(管理者として実行)を開き、MSIコマンドを実行します(インストールが完了するまでに最大5分かかる場合があります)。
    C:\path\to\file\unified-monitoring-agent-0.0.2.msi
  3. (Windows)前述のコマンドのより高度なバージョン(MSIインストールの問題をデバッグする)を実行するには、次のコマンドを実行します。
    msiexec /i "C:\path\to\file\unified-monitoring-agent-0.0.2.msi" /l*v "C:\unified-monitoring-agent_msi.log"

Oracle Cloud Infrastructure以外のインスタンス

  1. 既存のOracle Cloud Infrastructureインスタンス」と同じステップに従って、エージェントをインストールします。
  2. 実行しているインスタンスのユーザーAPIキーを構成します。「API署名キーの生成方法」で説明されている手順に従って、ユーザーAPIキーを生成します。
    • (Linux)ステップ2 a..ociディレクトリとその内容を/etc/unified-monitoring-agentの下に配置します。
    • (Windows)ステップ2 a.ウィンドウではいくつかのステップが異なるため、適切なステップに従ってください。.ociフォルダとその内容をC:\oracle_unified_agentディレクトリに作成します。
  3. 2で説明されている手順に従います。Oracle Cloud Infrastructure CLI構成ファイルでプロファイルを作成し、次のステップで変更した構成ファイルを作成します。
  4. 2のステップに従います。Oracle Cloud Infrastructure CLI構成ファイルでプロファイルを作成し、このセクションのプロファイル(<profile-name>)に「UNIFIED_MONITORING_AGENT」という名前を付けてください。次に、統合モニタリング・エージェントがサービスでの認証に使用する構成の例を示します。
    [UNIFIED_MONITORING_AGENT]
    user=ocid1.user.region..aaa...
    fingerprint=<cert fingerprint>
    key_file=/path/to/ocifolder/.oci/private.pem
    tenancy=ocid1.tenancy.region..aaa...
    region=<instances region>
    pass_phrase="pashphrase1234"

エージェントのインストールの検証

Windows:

  1. Services.mscを開きます(「スタート」メニューにservices.mscと入力します)。「Oracle Unified Monitoring Agent」が表示され、「Running」状態になるまでスクロールします。
  2. タスク・スケジューラ・ライブラリの下のタスク・スケジューラで、UnifiedAgentConfigUpdaterが存在し、正常に実行されていることを確認します。初期インストール後、最初の実行には最大20分かかることがあります。必要に応じて、これを手動で実行できます。
  3. UnifiedAgentConfigUpdaterタスクの実行後、C:\oracle_unified_agentにunified-monitoring-agent.confファイルがあることを確認します。
  4. 数分後、スーパーバイザ(unified - monitoring - agent -supervisor-0.log)ログおよびワーカー(unified - monitoring -agent-0.log)ログがC:\oracle_unified_agentディレクトリに存在する必要があります。
  5. 前述のログには、fluentdパーサーおよびプラグイン出力が含まれています。

Oracle Linux 7、Oracle Linux 8およびCentOS 7の場合:

  1. sshを使用してホストに接続します。
  2. 次のコマンドを実行して、エージェントが実行されていることを確認します。
    systemctl status unified-monitoring-agent
  3. ステータスは次のようになります。
    Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent.service; enabled; vendor preset: disabled)
    Active: active (running) since Thu 2020-09-10 18:11:45 GMT; 2h 14min ago
    Docs: https://docs.cloud.oracle.com/

エージェント構成の管理

エージェント構成を使用するには、サポートされているオペレーティング・システムでOracle Cloud Infrastructureインスタンスを実行している必要があります(「エージェント管理」を参照)。エージェント構成を使用すると、ホストのフリート全体で収集するカスタム・ログを簡単に構成できます。構成では次のものを選択できます。構成では次のものを選択できます。
  • ログの収集元となるホスト。
  • これらのホストから収集するログを正確に指定します。
  • ログ・グループ/ログの保存先。
構成は、コンソールおよびロギングAPIを介して管理されます。また、カスタム・ログの作成後にエージェント構成を作成することを選択できるため、エージェント構成ページを使用してエージェント構成を設定し、カスタム・ログを指すことができます。

エージェント構成ページは、次の観点から構成されます。

  • 名前
  • OCIDの構成
  • ステータス
  • 作成済
新しいエージェント構成を作成するには:
  1. ナビゲーション・メニューを開きます。「ソリューションとプラットフォーム」で、「ロギング」に移動し、「エージェント構成」をクリックします。エージェント構成ページが表示されます。
  2. リスト・スコープ」の「コンパートメント」で、作業権限のあるコンパートメントを選択します。
  3. 「エージェント構成の作成」をクリックします。「Agent Configurations」パネルが表示されます。
  4. 「名前とコンパートメント」で、対応するフィールドに構成名を入力し、作業権限を持つコンパートメントを選択します。
  5. 「ホスト・グループの選択」で、ドロップダウン・リストから、「動的グループ」または「ユーザー・グループ」のいずれかのグループ・タイプを選択します。「ホスト・グループの追加」をクリックして、グループを追加します。
  6. ログ入力の構成」で、ドロップダウン・リストから入力タイプ(「Windowsイベント・ログ」または「ログ・ディレクトリ」)を選択します。
    • Windowsイベント・ログ」で、入力を入力し、ドロップダウン・リストから「イベント・チャネル」オプションを選択します。
    • ログ・ディレクトリ」で、対応するフィールドに「入力」および「パス」を入力します。
  7. Select log destination」で、「Compartment」で選択した構成の「User Group」または「Dynamic Group」には、コンパートメントで作業する権限が必要です。ログ・グループ、および対応するドロップダウン・リストからログ名を選択します。ログ名はカスタム・ログのみを指すことができ、構成が機能するためには、選択したログ・グループにカスタム・ログが存在する必要があります。
  8. 必要に応じて、「追加オプションの表示」をクリックした後、必要なタグ設定を指定します。
  9. 作成」をクリックします。エージェント構成が作成され、エージェント構成ページに表示されます。
エージェント構成を表示するには
  1. ナビゲーション・メニューを開きます。「ソリューションとプラットフォーム」で、「ロギング」に移動し、「エージェント構成」をクリックします。エージェント構成ページが表示されます。
  2. リスト・スコープ」の「コンパートメント」で、作業権限のあるコンパートメントを選択します。
  3. 表の「名前」の下のリンクされたエージェント構成名をクリックします。エージェント構成の詳細ページが表示されます。このページの「ログ情報」タブには次の情報が表示されます。
    • OCID
    • コンパートメント
    • UTC形式で作成日時
    • ステータス(作成中、アクティブ、更新中、非アクティブ、削除中、削除済)
    • タグ」タブには、このログに関連付けられているタグが表示されます。
    • ログの詳細」には、区分、リンクされたログ・グループおよびログ名が表示されます。

      構成リソースでは、ホスト・グループおよびログ入力の構成設定が対応する表にリストされます。「ホスト・グループ」で、「グループ・タイプ」、「グループ名」およびOCIDを表示できます。リンクされたグループ・タイプ(ユーザー・グループまたは動的グループ)をクリックして、コンソールのIAMグループまたは動的グループ・セクションをそれぞれ開きます。詳細は、グループの管理および動的グループについてを参照してください。

      ログ入力」で、「入力タイプ」、「入力名」、「ファイル・パス」、「パーサー」および「パーサー・パラメータ」を表示できます(選択したパーサーに該当する場合)。

      ログの参照リソースでは、ログ・データは検索ページのログ・データとほぼ同じ方法で表示されます。「ソート」フィールドから最新または最も古いものでソートしたり、対応する「時間でフィルタ」フィールドから時間でフィルタしたりするなど、いくつかの単純なフィルタを適用できます。

      ログ検索で検索」をクリックすると、このログを「検索」ページに直接表示できます。このリンクをクリックすると、検索ページが開き、「検索するログの選択」フィールドにフィルタ設定のログが移入されます。この時点で、このログに関連する詳細な分析および調査を検索ページで直接実行できます。詳細は、ログの検索を参照してください。

エージェント構成を編集するには
  1. ナビゲーション・メニューを開きます。「ソリューションとプラットフォーム」で、「ロギング」に移動し、「エージェント構成」をクリックします。エージェント構成ページが表示されます。
  2. リスト・スコープ」の「コンパートメント」で、作業権限のあるコンパートメントを選択します。
  3. 表の「名前」の下のリンクされたエージェント構成名をクリックします。エージェント構成の詳細ページが表示されます。
  4. 編集」をクリックします。「Agent Configurations」パネルが表示されます。

    エージェント構成のメイン・ページで、編集するエージェント構成の「アクション」アイコン(3つの点)をクリックし、「編集」をクリックして「エージェント構成」パネルにアクセスすることもできます。

  5. 必要な変更を行い、「更新」をクリックします。
既存のエージェント構成を有効または無効にするには
  1. ナビゲーション・メニューを開きます。「ソリューションとプラットフォーム」で、「ロギング」に移動し、「エージェント構成」をクリックします。エージェント構成ページが表示されます。
  2. リスト・スコープ」の「コンパートメント」で、作業権限のあるコンパートメントを選択します。
  3. 表の「名前」の下のリンクされたエージェント構成名をクリックします。エージェント構成の詳細ページが表示されます。
  4. 無効化/有効化」をクリックします。エージェント構成の無効化または有効化に関する確認ダイアログが表示されます。
  5. 無効化/有効化」をクリックして確定します。エージェント構成の詳細ページでは、ステータスが変更され、エージェント構成の詳細ページとエージェント構成ページの両方で、「ステータス」フィールドに「非アクティブ」(無効な構成の場合)または「アクティブ」(有効な構成の場合)が表示されます。

    エージェント構成のメイン・ページで、無効化/有効化するエージェント構成の「アクション」アイコン(3つのドット)をクリックして、「無効化/有効化」をクリックすることもできます。

エージェント構成を削除するには
  1. ナビゲーション・メニューを開きます。「ソリューションとプラットフォーム」で、「ロギング」に移動し、「エージェント構成」をクリックします。エージェント構成ページが表示されます。
  2. リスト・スコープ」の「コンパートメント」で、作業権限のあるコンパートメントを選択します。
  3. 表の「名前」の下のリンクされたエージェント構成名をクリックします。エージェント構成の詳細ページが表示されます。
  4. 削除」をクリックします。削除操作に関する確認ダイアログが表示されます。
  5. 削除」をクリックして確定します。エージェント構成がエージェント構成ページから削除されます。

    エージェント構成のメイン・ページから、削除するエージェント構成の「アクション」アイコン(3つの点)をクリックし、「削除」をクリックすることもできます。

エージェント構成を別のコンパートメントに移動するには
  1. ナビゲーション・メニューを開きます。「ソリューションとプラットフォーム」で、「ロギング」に移動し、「エージェント構成」をクリックします。エージェント構成ページが表示されます。
  2. リスト・スコープ」の「コンパートメント」で、作業権限のあるコンパートメントを選択します。
  3. 表の「名前」の下のリンクされたエージェント構成名をクリックします。エージェント構成の詳細ページが表示されます。
  4. リソースの移動」をクリックします。別のコンパートメントへのリソースの移動ダイアログが表示されます。
  5. 新しいコンパートメントを選択し、「リソースの移動」をクリックします。

    エージェント構成のメイン・ページで、新しいコンパートメントに移動するエージェント構成の「アクション」アイコン(3つの点)をクリックし、「リソースの移動」をクリックすることもできます。

動的グループを含むターゲット・ホストの選択

複数のホストの構成を設定するには、IAM動的グループ機能を利用できます。全体的なプロセスでは、最初にコンパートメントを作成してから、ログの収集元のコンパートメントにすべてのインスタンスを配置します。次に、動的グループを作成できます。動的グループ・ポリシー文は、インスタンスを含むコンパートメントを指します。最後に、ログ・グループ、カスタム・ログおよびその関連エージェント構成を作成します。

次のポリシー文を設定します。
allow dynamic-group <dynamic_group_name> to use log-content in tenancy

これにより、エージェント構成はロギング・サービス・バックエンドにログをプッシュできます。これは、後でロギング・サービスの検索ページで確認できます。

動的グループ構成で、ログをロギング・サービスに送信するために使用するすべてのエージェントを含むルールを含むように動的グループを設定します。たとえば、動的グループ内のルールでは、次のように記述できます。

ANY {instance.id = 'ocid1.instance.<region>.<location>.<unique_ID>', 
instance.compartment.id = 'ocid1.compartment.<region>..<unique_ID>'}
instance.id = 'ocid1.instance.<region>.<location>.<unique_ID>'を削除し、次のもののみがある場合:
ANY {instance.compartment.id = 'ocid1.compartment.<region>..<unique_ID>'}
これは、このコンパートメントのすべてのインスタンスを使用してログを送信することを意味します。動的グループの詳細は、動的グループについてを参照してください。

次に、ログ・グループを作成します(「ログ・グループを作成するには」を参照)。ログ・グループが作成されると、カスタム・ログおよびエージェント構成を作成できます(カスタム・ログおよびエージェント構成を作成するステップは、「カスタム・ログの作成」を参照)。エージェントの構成中に、以前に作成した動的グループを使用し、「エージェント構成」パネルの「ホスト・グループの選択」セクションで選択できます。これにより、ログ構成が、ログの送信先のインスタンスにリンクされます。エージェント構成がアクティブになると、表示されるログは、前に設定した動的グループ内のインスタンスによって送信されます。エージェント構成で「ログ検索を使用した検索」を後でクリックすると、「検索」ページでログを表示できます(「ログの検索」を参照)。

ログ入力およびパーサー

エージェント構成を使用すると、収集するログのタイプとその解析方法を簡単に選択できます。エージェント構成でサポートされるログ入力は次のとおりです。

  • Windowsイベント・ログ
  • ログ・ディレクトリ(テール)

ログ・ディレクトリの入力では、ログを構造化するための追加パーサーを指定できます。次に、サポートされているパーサーのリストを示します。

ログの宛先

ログ・イベントを索引付けする正確なログ・グループおよびログ・オブジェクトを選択できます。ホストからのすべての受信ログ・イベントが収集され、選択したログ・オブジェクトに索引付けされます。収集されたログ・イベントは、検索ページで表示および検索できます(ログの検索を参照)。ログ・グループとコンパートメントの両方の既存Oracle Cloud Infrastructure Identity and Access Managementポリシーは、収集時検索時の両方に適用されます。したがって、認可されたユーザーのみがテナンシのログを表示および収集できます。

コンピュート・インスタンスのカスタム・ログの表示

コンピュートインスタンス・ページの「ログ」リソースでは、選択したコンパートメントのインスタンスのロギング詳細を表示できます。ロギング検索APIがコールされ、使用可能なログが特定のインスタンスに対してプルされます。インスタンスではカスタマ・アプリケーション(たとえば、ゲーム・サーバー)を実行でき、Oracle Cloud Infrastructureエージェントによって収集され、ロギング・サービスにプッシュされてそこに索引付けされるように、ゲーム・サーバーからのログを構成できます。ログがプルされ、ログ・リソースに表示されます。そのため、顧客がコンピュート・インスタンスを表示すると、アプリケーションがロギング・サービスにログをプッシュしていることがわかります。ただし、このインタフェースからログを有効にしたり作成したりすることはできません。

ログの参照」で、ログ・エントリ(「最新」、「デフォルト」または「最も古い」)をソートするか、時間(デフォルトの「過去5分間」、「過去15分間」、「過去15時間」、「過去24時間」、「本日」、「カスタム」)でフィルタできます。それ以外の場合、この機能は、中央ロギングの「検索」ページの「ログ・データ」でログを表示する場合と同じです(コンソールの使用を参照)。

ログ検索を使用した検索」をクリックして、中央ロギング検索ページを開きます。このページでは、フィルタの追加や削除などを行うことができます。「検索」ページがロードされ、「フィルタ」の下にフィルタとしてすでに設定されている特定のインスタンスのinstanceidが表示されます。

カスタム・ログの作成」をクリックして中央の「ログ」ページを開きます。このページでは、特定のインスタンスのカスタム・ログを作成できます。カスタム・ログは、Oracle Cloud Infrastructure Compute VMインスタンスから送信されます。

このようなインスタンスでLogsリソースを使用できるようにするには、次の2つの前提条件があります。

  1. インスタンスの監視が有効になっている必要があります。詳細は、コンピュート・インスタンスの監視の有効化を参照してください。
  2. インスタンスには、サポートされているオペレーティング・システムのいずれかが必要です。
    • Oracle Linux 7/8
    • CentOS 7 (ただし、8のイメージはまだリリースされていませんが、サポートされています)
オペレーティング・システムがサポートされていない場合、このログ・リソースは表示されません。オペレーティング・システムOracle Cloudエージェントでサポートされていない場合は、ログを作成するためにエージェントを有効にする必要があるという警告が表示されます。

エージェントのトラブルシューティング

次のトピックでは、LinuxとWindowsの両方で、Unified Monitoring Agentに関連するトラブルシューティングのヒントについて説明します。

ハードウェア要件

ロギング要件および構成(ログの数、バッファリングのタイプなど)に応じて、Unified Monitoring Agentのハードウェア要件およびパフォーマンスが大きく異なる場合があります。動作圧力が存在しない場合(1分あたり1.000未満のログ・イベント)、エージェントは200 MBを超えるRAMおよびCPUコアの20%を消費しないでください。Unified Monitoring Agentサービスのハードコードされた制限は、5 GBのRAMと40%のコアです。1 GBのRAMも推奨されます。

監視の有効化

モニタリングはトラブルシューティングに役立ちます。Oracle Cloud Infrastructure Computeインスタンスで監視(メトリックおよびロギング)を有効にする方法の詳細は、コンピュート・インスタンスの監視の有効化を参照してください。

Linux

systemdユニット

統合エージェントはsystemdユニットに基づいており、次のコンポーネントで構成されています。

  1. unified - monitoring - agent.service:メインの統合モニタリング・エージェント・サービス。
  2. unified-monitoring-agent_config_downloader.service:構成自動更新サービス。
  3. unified-monitoring-agent_config_downloader.timer:指定されたランダム化された間隔で自動ダウンローダ・サービスをトリガーするタイマー・ユニット。
  4. unified-monitoring-agent_restarter.path: (自動アップデータ・サービスによって新しい構成がダウンロードされているために)変更が検出された場合に、Unified Monitoring Agentによって構成のリロードをトリガーするパス・ユニット。
注意

: systemctlまたはjournalctlコマンドのほとんどは、スーパー・ユーザー権限(rootとして、またはsudoを介して)で実行する必要があることに注意してください。

これらのsystemdユニットの正しい動作を確認するには、次のようにsystemctlコマンドを使用できます。

systemctl status <unit_name>

<unit_name>は、次のいずれかの値に置き換える必要があります。

  1. unified-monitoring-agent.service
  2. unified-monitoring-agent_config_downloader.service
  3. unified-monitoring-agent_config_downloader.timer
  4. unified-monitoring-agent_restarter.path

通常、これらのsystemctlコマンドでは、次のような出力が表示されます。

systemctl status unified-monitoring-agent.service
● unified-monitoring-agent.service - unified-monitoring-agent: Fluentd based data collector for Oracle Cloud Infrastructure SIEM
   Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-09-29 13:54:03 UTC; 1min 37s ago
     Docs: https://docs.cloud.oracle.com/
  Process: 2337 ExecReload=/bin/kill -USR2 ${MAINPID} (code=exited, status=0/SUCCESS)
  Process: 2321 ExecStart=/opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10 $EXTRA_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 2327 (fluentd)
   Memory: 66.3M (limit: 5.0G)
   CGroup: /system.slice/unified-monitoring-agent.service
           ├─2327 /opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unif...
           └─2330 /opt/unified-monitoring-agent/embedded/bin/ruby -Eascii-8bit:ascii-8bit /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.lo...
systemctl status unified-monitoring-agent_config_downloader.service
● unified-monitoring-agent_config_downloader.service - unified-monitoring-agent Fluentd configuration downloader.
  Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_config_downloader.service; enabled; vendor preset: disabled)
  Active: inactive (dead) since Tue 2020-09-29 13:54:38 UTC; 1min 30s ago
 Process: 2333 ExecStart=/opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluent_config_updater.rb -c /etc/unified-monitoring-agent/conf.d/ -b 10 (code=exited, status=0/SUCCESS)
Main PID: 2333 (code=exited, status=0/SUCCESS) 
systemctl status  unified-monitoring-agent_config_downloader.timer
● unified-monitoring-agent_config_downloader.timer - Run unified-monitoring-agent configuration automatic updater.
   Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_config_downloader.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Tue 2020-09-29 13:54:03 UTC; 3min 57s ago 
systemctl status  unified-monitoring-agent_restarter.path
● unified-monitoring-agent_restarter.path - "Monitor the /etc/unified-monitoring-agent/conf.d/ directory for changes"
   Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_restarter.path; enabled; vendor preset: disabled)
   Active: active (waiting) since Tue 2020-09-29 13:54:03 UTC; 4min 9s ago 

Systemctlコマンド出力の最も重要な部分は、LoadedおよびActiveフィールドです。すべてのシステム・ユニットについて、Loadedフィールドの値はloadedである必要があります。Activeフィールドには、次の値が必要です。

  • active (running): unified - monitoring - agent.serviceユニットの場合。
  • unified-monitoring-agent_restarter.pathおよびunified-monitoring-agent_config_downloader.timerユニットのactive (waiting)またはactive (running)
  • unified-monitoring-agent_config_downloader.serviceユニットのactive (running)またはinactive (dead)。後者の値の場合、フィールドMain PIDに値code=exited, status=0/SUCCESS)が含まれている必要があります。

プロセス

Unified Monitoring Agentの正しい動作をさらに確認する別の方法は、システムの実行中のプロセスを確認することです。Unified Monitoring Agentは、正常に動作すると、スーパーバイザプロセスとワーカープロセスの2つのプロセスを実行します。ターミナルで次のコマンドを実行すると、それらの存在を検証できます(出力例も示します)。

ps aux | grep unified-monitoring-agen[t]
root      2327  0.0  2.3 307704 40864 ?        Sl   13:54   0:00 /opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10
root      2330  0.2  2.1 297456 38192 ?        S    13:54   0:03 /opt/unified-monitoring-agent/embedded/bin/ruby -Eascii-8bit:ascii-8bit /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10 --under-supervisor

前述のように、2番目のプロセスに追加された–under-supervisorを除いて、まったく同じ引数を持つ2つのプロセスが実行されています。これはワーカー・プロセスを示しているため、このパラメータのないプロセスが監督者になります。

ログ

注意

: systemctlまたはjournalctlコマンドのほとんどは、スーパー・ユーザー権限(rootとして、またはsudoを介して)で実行する必要があることに注意してください。

Unified Monitoring Agentのログは、/var/log/unified-monitoring-agent/unified-monitoring-agent.logにあります。このファイルには、Unified Monitoring Agent自体のログが含まれています。

システム関連のイベント(サービスの開始、サービスの停止など)を含まないエージェントのログ以外に、journald、systemdのシステム・ロギング・サービスからログを表示することもできます。ユニットに固有のシステム・ログを表示するには、次のようなjournalctlコマンドを使用できます。

journalctl -u <unit_name>

<unit_name>は、次のいずれかの値に置き換える必要があります。

  1. unified-monitoring-agent.service
  2. unified-monitoring-agent_config_downloader.service
  3. unified-monitoring-agent_config_downloader.timer
  4. unified-monitoring-agent_restarter.path
Journalctlを介してjournaldログを問い合せる場合、特定の時間範囲を定義することもできます。
journalctl --since "2020-12-30 00:00:01" --until "2020-12-31 23:59:59"
使用される日付書式はYYYY - MM - DD HH: MM: SSです。
- fパラメータを追加して、ジャーナル・ログの末尾を表示することもできます。
journalctl -f

トラブルシューティングのシナリオ

問題: Unified Monitoring Agentがインストールされていません。

解決策:新しく作成したインスタンスの場合、エージェントの自動インストールには最大25分かかることがあります。この期間を過ぎるとインストールされない場合は、次の点を確認してください。

  1. インスタンスのネットワーク接続性。
  2. コンソールで監視を有効にするかどうか。

ログ・ファイル/var/log/oracle-cloud-agent/plugins/unifiedmonitoring/unifiedmonitoring.logで、Oracleクラウド・エージェントによる統合モニタリング・エージェントのインストールに関する情報を確認することもできます。

問題: Unified Monitoring Agentが実行されていないか、そのステータスがロード/アクティブでないか、スーパーバイザプロセスとワーカープロセスの両方が実行されていません。

解決策: Unified Monitoring Agentを再起動します。

systemctl restart unified-monitoring-agent

ログで問題を確認してください。

問題:構成が自動的にダウンロードされません。

解決策:「エージェントのインストールエージェントのインストールの検証」のステップに従っていることを確認します。次のコマンドを実行して、自動構成アップデータ・サービスのジャーナルを参照します。

journalctl -u unified-monitoring-agent_config_downloader.service

問題:構成が自動的にリロードされません。

解決策:「エージェントのインストールエージェントのインストールの検証」のステップに従っていることを確認します。すべてのユニットのジャーナルを調べます。

  1. タイマーユニットは少なくとも1回実行されている必要があります。
  2. 自動構成ダウンロード・サービスは、関連する時間単位によってトリガーされた後に実行する必要があります。ログから、構成がダウンロードされ、Unified Monitoring Agentの構成ディレクトリに抽出されていることを確認できます。このことは、ls -lhatR/etc/unified-monitoring-agentディレクトリ内のファイルをリストすることで確認することもできます。
  3. Systemctl status unified-monitoring-agent_restarter.pathのステータスをチェックして、パス・ユニットがアクティブであることを確認してください。
  4. Unified Monitoring Agentのジャーナルjournalctl - u unified-monitoring-agent_config_downloader.serviceを調べて、リロード・シグナルが受信されたことを確認します。このコマンドの出力は、「unified - monitoring - agentのリロード」を参照してください。

データ収集

Unified Monitoring Agentに関する問題をエンジニアが解決できるようにチケットを開く場合は、次のコマンドの出力を含めます。スーパーユーザー権限が必要になる場合があります。

yum info unified-monitoring-agent
rpm -ql unified-monitoring-agent |  xargs sha512sum
systemctl status --full unified-monitoring-agent.service
systemctl status --full unified-monitoring-agent_config_downloader.service
systemctl status --full unified-monitoring-agent_config_downloader.timer
systemctl status --full unified-monitoring-agent_restarter.path
journalctl -a --no-pager -u unified-monitoring-agent.service
journalctl -a --no-pager -u unified-monitoring-agent_config_downloader.service
journalctl -a --no-pager -u unified-monitoring-agent_config_downloader.timer
journalctl -a --no-pager -u unified-monitoring-agent_restarter.path

また、/var/log/unified-monitoring-agent/および/var/log/oracle-cloud-agent/の下にファイルのアーカイブを含めます。次のコマンドを使用して、これらのディレクトリのgzip圧縮tarアーカイブを作成できます。

tar cvzf agent_logs_$(date +%s).tar.gz /var/log/unified-monitoring-agent/ /var/log/oracle-cloud-agent/

If the Unified Monitoring Agent is running but it is showing erratic behavior, you can also include backtrace and memory profile information, by running the following command and including the files /tmp/sigdump-<integer>.log in your report (where <integer> is an integer with 1 to 6 digits, even though in rare cases it might have more than that).

ps aux | grep unified-monitoring-agen[t] | grep ruby | awk '{print $2}' | xargs kill -SIGCONT

このコマンドの動作は、Unified Monitoring AgentプロセスPIDを検出し、SIGCONTシグナルを送信することです。これにより、ダンプが/tmp/sigdump-<integer>.logに生成されます。

アンインストールと再インストール

次のコマンドを実行すると、エージェントの構成を削除せずにUnified Monitoring Agentを削除できます。

yum -y remove unified-monitoring-agent

エージェントの構成は/etc/unified-monitoring-agent/ディレクトリの下に残ります。Unified Monitoring Agentパッケージの今後の(再)インストールのために構成を保持しない場合は、手動で削除する必要があります。

# use the following command to print the contents of the agent's configuration directory
find /etc/unified-monitoring-agent/
# use the following command to remove the directory and all of its contents (this step cannot be undone)
rm -rf /etc/unified-monitoring-agent/

エージェントは、Oracle Cloudエージェントによって最大25分で自動的に再インストールされます。これを行うには、コンソールでインスタンスの監視を有効にする必要があることに注意してください。詳細は、コンピュート・インスタンスの監視の有効化を参照してください。

ウィンドウ

統合モニタリングエージェントのトラブルシューティングステップ

  1. サービス・ステータスを確認します。エージェントはWindowsサービスの一部として実行され、そのステータスを確認するには、スタート・メニューを開き、Services.mscと入力して開きます。Oracle Cloud Unified Monitoring Serviceサービスに移動してステータスを確認します。
  2. 詳細は、サービスを右クリックして「プロパティ」を選択します。起動/停止/再起動はここで使用できます。
  3. スタート」メニューからcmdと入力し、コマンド・プロンプトを右クリックして「管理者として実行」を選択します。次のコマンドを実行します。
  • Unified Monitoring Agentサービスのステータスを表示するには、次の手順に従います。
    sc query unified-monitoring-agent
  • Unified Monitoring Agentサービスを再起動します。
    sc stop unified-monitoring-agent
    sc start unified-monitoring-agent
注意前述のコマンド

はPowerShellでは機能しないため、かわりにWindowsコマンド・プロンプトを使用する必要があります。
  1. Windowsサービスのエラーを検索します。「スタート」メニューから、「イベントビューア」と入力して選択します。
  2. Windowsログ」、「システム」の順に開きます。サービスが起動または停止したり、いずれかが失敗したり、突然クラッシュしたりするたびに、ここに記録されます。
    注意ほとんどのWindowsマシン

    では、イベント・ビューアに表示されるイベントの数に上限があるため、イベントが長時間前に発生した場合、ログは使用できないことがあります。
  1. Fluentdログ。Explorer.exeを開きます(タスク・バーのファイル・アイコン)
  2. C:\oracle_unified_agentに移動します。
  3. ファイルが1つしかない場合、マシンに有効な構成ファイルがないことを意味します。
  4. 2つのファイルがある場合、すべての設定/起動ログを含むスーパーバイザ・ログと、すべての解析/出力ログを含むワーカー・ログが存在します。unified-monitoring-agent.confは、正しくダウンロードされている場合は構成ファイルの名前になります。
  5. Fluentdを手動で実行します。前述のステップを実行して問題を特定しますが、必要に応じて、fluentdを手動で実行して問題をデバッグできます。
    注意: fluentdを手動で

    実行すると、Windowsサービスで実行されます。これにより、サービスの通常どおりの実行が停止されますが、これはLinuxとは動作が異なります。
  6. 次のコマンドを使用して、fluentdを手動で実行します。これはPowerShellまたはコマンド・プロンプトで実行できますが、管理者として実行する必要があります。
    C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\fluentd -c C:\oracle_unified_agent\unified-monitoring-agent.conf -vv

自動構成更新のトラブルシューティング・ステップ

  1. タスク・スケジューラが予想どおりに実行されていることを確認します。
  2. スタート」メニューから、Task Schedulerと入力します。
  3. タスク・スケジューラ(ローカル)」、「タスク・スケジューラ・ライブラリ」の順に移動します。UnifiedAgentConfigUpdaterという名前のタスクが必要です。
  4. 最終実行時間を確認します。無効な日付であるか、実行されていない場合、次の実行時間は、最初に実行する必要がある時間になります。デバッグの場合は、タスクを選択し、すぐに実行する必要がある場合は「実行」を選択します。
  5. 最終実行結果」は、コントロール・プレーンから構成をダウンロードした結果を指定します。エラーの結果が発生した場合は、それを手動で実行して何が発生したかを確認する必要があります。タスク・スケジューラは出力ログを保持しません。
  6. 構成アップデータを手動で実行します。これを管理者としてPowerShellで実行すると、最高のエクスペリエンスを得ることができます。
    C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\ruby.exe C:\oracle_unified_agent\unified-monitoring-agent\embedded\lib\ruby\gems\2.6.0\gems\fluent-public-config-updater-0.0.1\lib\fluent_config_updater.rb -c C:\oracle_unified_agent -b 10

Oracle Cloudエージェントのトラブルシューティング・ステップ

Oracle Cloudエージェントのログを確認します。Windows Server 2012r2または2016の場合、ログ・ファイルの場所は次のとおりです。

  • C:\Users\OCA\AppData\Local\Local\OracleCloudAgent\agent.log
  • C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log (ランタイム・ログ)
  • C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log (インストール・ログ)

Windows Server 2019のログ・ファイルの場所:

  • C:\Windows\ServiceProfiles\OCA\AppData\Local\OracleCloudAgent\agent.log
  • C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log (ランタイム・ログ)
  • C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log (インストール・ログ)

断続的にMSIインストールに失敗しました

このエラーは、次のいずれかの原因で発生した可能性があります。
  1. MSIのインストールが中断され(システムのリブート、プロセスの強制終了など)、2回目の実行でmsiexec.exeプロセスは、作成したフォルダへのファイルハンドルを保持したままになります。
  2. Ruby.exeが予期したとおりに終了しないため、MSIがメイン・エージェント・フォルダへのアクセスに失敗するアップグレード中(問題が急増)。これによりMSIが失敗し、システムがクリーンアップされ、エージェントの大部分が削除されます(ただし、位置やバッファ・ファイルは削除されません)。

どちらのインスタンスでも、2回目のインストールまたはインストールを介したOracle Cloudエージェントの実行により、この問題は解決されます。それでもこの状態でスタックしている場合は、次の手順を実行します。

  1. タスクマネージャの[詳細]で、msiexecおよびrubyプロセスをすべて強制終了します。
  2. C:\oracle_unified_agent to C:\oracle_unified_agent_oldの名前を変更します。
  3. エージェントを再度インストールするか、Oracle Cloudエージェントがインストールされるのを待ちます。