Oracle Cloud Infrastructureドキュメント

トラブルシューティング・ロギング

トラブルシューティング情報を使用して、ロギングの操作中に発生する可能性のある一般的な問題を特定し、対処します。

一般的な統合モニタリング・エージェントのトラブルシューティング

ハードウェア要件

ロギング要件および構成(ログの数やバッファリングのタイプなど)によっては、統合モニタリング・エージェントのハードウェア要件とパフォーマンスが大きく変化する可能性があります。運用上の負荷が存在しない場合(1分当たり1.000ログ・イベント未満)、エージェントは、200 MBを超えるRAMおよび20%を超えるCPUコアを消費することはありません。統合モニタリング・エージェント・サービスのハードコードされた制限は、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: パス・ユニット。(自動アップデータ・サービスによってダウンロードされている新しい構成のために)変更が検出された場合、統合モニタリング・エージェントによる構成のリロードをトリガーします。
ノート

ほとんどの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
   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ユニットの場合。
  • active (waiting)またはactive (running): unified-monitoring-agent_restarter.pathおよびunified-monitoring-agent_config_downloader.timerユニットの場合。
  • active (running)またはinactive (dead): unified-monitoring-agent_config_downloader.serviceユニットの場合。後者の値の場合、フィールドMain PIDに値code=exited, status=0/SUCCESS)が含まれます。

実行中プロセスのチェック

統合モニタリング・エージェントの正しい動作を確認するもう1つの方法は、システムで実行中のプロセスをチェックすることです。正しく動作している場合、統合モニタリング・エージェントは、2つのプロセス(1つのスーパーバイザ・プロセスと1つのワーカー・プロセス)を実行しています。これらの存在を確認するには、ターミナルで次のコマンドを実行します(サンプル出力が含まれます):

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つのプロセスがありますが、2番目のプロセスには–under-supervisorが追加されています。これは、ワーカー・プロセスであることを示しているため、このパラメータがないプロセスがスーパーバイザになります。

統合モニタリング・エージェントのログの場所

ノート

ほとんどのsystemctlまたはjournalctlコマンドは、スーパー・ユーザー権限を使用して(rootとして、またはsudoを介して)実行する必要があります。

統合モニタリング・エージェントのログは、/var/log/unified-monitoring-agent/unified-monitoring-agent.logにあります。このファイルには、統合モニタリング・エージェント自体のログが含まれます。

システム関連のイベント(サービス開始、サービス停止など)を含まないエージェントのログに加えて、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

統合モニタリング・エージェントがインストールされていません

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

  1. インスタンスのネットワーク接続性。
  2. コンソールでモニタリングが有効になっているかどうか。

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

統合モニタリング・エージェントが実行されていません

ステータスがロードされていないかアクティブでないか、スーパーバイザ・プロセスとワーカー・プロセスの両方が実行中である場合は、統合モニタリング・エージェントを再起動し、ログで問題がないかどうかを確認します。 

systemctl restart unified-monitoring-agent

構成が自動的にダウンロードされていません

エージェントのインストールおよびエージェント・インストールの検証のステップに従ったことを確認します。次を実行して、自動構成アップデータ・サービスのジャーナルを参照してください: 

journalctl -u unified-monitoring-agent_config_downloader.service

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

エージェントのインストールおよびエージェント・インストールの検証のステップに従ったことを確認します。すべてのユニットのジャーナルを参照してください:

  1. タイマー・ユニットは、少なくとも1回実行されている必要があります。
  2. 自動構成ダウンロード・サービスは、関連するタイマー・ユニットのトリガー後に実行されている必要があります。構成がダウンロードされ、統合モニタリング・エージェントの構成ディレクトリに抽出されたことをログから検証できます。そのディレクトリ内のファイルをリストして、これを確認することもできます: ls -lhatR /etc/unified-monitoring-agent。
  3. パス・ユニットのステータスをチェックして、それがアクティブであることを確認します: systemctl status unified-monitoring-agent_restarter.path。
  4. ジャーナルを検査して、リロード・シグナルが統合モニタリング・エージェントによって受信されたことを確認します: journalctl -u unified-monitoring-agent_config_downloader.service。このコマンドの出力に"Reloading unified-monitoring-agent"が表示されます。

解析パターンのテストとエージェントによる構成の即時ダウンロード

次のコマンドを実行します:

systemctl restart unified-monitoring-agent_config_downloader
ノート

エージェント側の構成の自動更新には、最大30分かかることがあります。

OCIを使用したデータベース・システムのアラート・ログの内容を表示するカスタム・ログの作成

統合モニタリング・エージェントはデータベース・システムをサポートしていません。

データ収集

統合モニタリング・エージェントに関する問題をエンジニアが支援できるようにチケットをオープンする場合は、次のコマンドの出力を含めます。一部の実行にはスーパー・ユーザー権限が必要な場合があります。

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

Ubuntuでは、次のようなコマンドを使用します:

apt show unified-monitoring-agent
dpkg -L unified-monitoring-agent | xargs sha512sum

また、/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/

統合モニタリング・エージェントは実行されているが、動作が不安定な場合、次のコマンドを実行してファイル/tmp/sigdump-<integer>.logをレポートに含めることで、バックトレースおよびメモリー・プロファイル情報も含めることができます(<integer>は1–6桁の整数ですが、まれにそれを超えることもあります)。

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

このコマンドの実行により、統合モニタリング・エージェント・プロセスのPIDを検出し、それらにSIGCONTシグナルを送信することで、/tmp/sigdump-<integer>.logにダンプが生成されます。

アンインストールおよび再インストール

次のコマンドを実行して、エージェントの構成を削除せずに統合モニタリング・エージェントを削除できます:

yum -y remove unified-monitoring-agent

Ubuntuの場合:

apt -y remove unified-monitoring-agent

エージェントの構成は、/etc/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 Agentによって25分以内には自動的に再インストールされます。これを実行するには、コンソールでインスタンスのモニタリングを有効にする必要があります。詳細は、Oracle Cloud Agentを参照してください。

Windows統合モニタリング・エージェント

サービス・ステータスをチェックするには

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

前述のコマンドはPowerShellでは動作しないため、かわりにWindowsコマンド・プロンプトを使用する必要があります。

Windowsサービス・エラーを検索するには

  1. 「スタート」メニューでEvent Viewerと入力し、それを選択します。
  2. 「Windowsログ」、「システム」の順に開きます。サービスが開始または停止したり、それに失敗したり、突然クラッシュしたりするたびに、ここに記録されます。
    ノート

    ほとんどのWindowsマシンでは、イベント・ビューアに含まれるイベントの数に上限があります。その結果、イベントの発生から長時間経過している場合、ログを使用できないことがあります。

Fluentdログを表示するには

  1. 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*\lib\fluent_config_updater.rb -c C:\oracle_unified_agent -b 10

Oracle Cloud Agentログの確認

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 (インストール・ログ)
  • C:\oracle_unified_agent\unified-monitoring-agent-0.log (エージェント・ワーカー・ログ。状態によっては存在しない可能性があります)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (エージェント・スーパーバイザ・ログ。状態によっては存在しない可能性があります)

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

  • 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 (インストール・ログ)
  • C:\oracle_unified_agent\unified-monitoring-agent-0.log (エージェント・ワーカー・ログ。状態によっては存在しない可能性があります)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (エージェント・スーパーバイザ・ログ。状態によっては存在しない可能性があります)

断続的に失敗するMSIインストール

断続的に失敗するMSIインストールは、次のいずれかの理由で発生する可能性があります:

  1. MSIインストールが中断され(システムの再起動、プロセスの停止など)、2回目の実行で、msiexec.exeプロセスが、作成したフォルダへのファイル・ハンドルを保持し続けています。
  2. アップグレード中に、Ruby.exeが正常に終了しないために(Fluentdの問題) MSIがメイン・エージェント・フォルダにアクセスできません。これにより、MSIは失敗し、システムはクリーンアップされ、(位置ファイルやバッファ・ファイルではなく)多くのエージェントが削除されます。

どちらの場合も、2回目のインストールで、またはOracle Cloud Agentがインストールを2回実行することで、この問題は解決します。この状態が続く場合は、次を実行してください:

  1. タスク・マネージャの「詳細」ですべてのmsiexecおよびrubyプロセスを停止します。
  2. C:\oracle_unified_agentの名前をC:\oracle_unified_agent_oldに変更します。
  3. エージェントを再インストールするか、Oracle Cloud Agentがそれをインストールするまで待機します。

エージェント構成で動作しない汎用パス

Windowsエージェント構成のパスを構成する際にスラッシュ(/)を使用します。アスタリスク(*)の付いたバックスラッシュ(\)は、内部的な制限のため Windowsでは機能しません。これを回避するには、C:\\path\\to\\*\\foo.logのようなパスを使用しないでください。かわりに次のスラッシュ方法を使用します。

path C:/path/to/*/foo.log

Windowsでサポートされる一般的な作業パスの例を次に示します。

  • C:/logs/*
  • C:/logs/t2*.txt
  • C:/logs/a*b.txt
  • C:/logs/abc*
  • C:/logs/*.txt
  • C:/logs/*/abc*
  • C:/logs/*/a.txt
  • C:/logs/*/a*b.txt
  • C:/logs*/*.txt

ただし、C:/logs/*log.txt汎用パスはWindowsでは機能しません。