mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-06 17:27:57 +00:00

Files

mDuo13 7645140477 Re-levelization: move non-docs content, rename content→docs

For better URLs, the content folder has been renamed 'docs' and all
other files have been moved up a level. Also, non-docs images have been
moved to the static folder at the top level where they belong.

Many relative paths had to be fixed to make this work.

2024-01-31 17:53:52 -08:00

11 KiB

Raw Blame History

html, parent, seo, labels

html

parent

seo

labels

diagnosing-problems.html

troubleshoot-the-rippled-server.html

description
情報を収集して問題の原因を特定します。

コアサーバー

rippledの問題の診断

rippledで問題が発生した場合はまず、問題の特徴を正確に明らかにするため、詳細な情報を収集します。これにより、根本原因を洗い出して修正策を編み出すことが容易になります。

サーバーが起動しない場合（クラッシュが発生した場合や自動的にシャットダウンした場合など）は、rippledサーバーが起動しないで考えられる原因と修正策のリストを確認してください。

このドキュメントでは、サーバーが稼働している場合（プロセスがアクティブだがネットワークと同期できない場合を含む）に発生する可能性がある問題の診断手順を説明します。

server_infoの取得

コマンドラインを使用して、ローカルrippledインスタンスからサーバーステータス情報を取得できます。例:

rippled server_info

このコマンドに対するレスポンスには大量の情報が含まれています。これについては、[server_infoメソッド][]で説明します。トラブルシューティングで最も重要なフィールドは以下のとおりです（最も一般的に使われるものから順に説明します）。

server_state - ほとんどの場合、このフィールドにはproposing（バリデータとして設定されているサーバーの場合）またはfull（バリデータではないサーバーの場合）が表示されます。値がconnectedの場合は、サーバーはピアツーピアネットワークの他の部分と通信できますが、共有レジャーの状態を追跡するのに十分なデータがありません。通常、レジャーの残りの部分の状態を同期するには起動後約5～15分かかります。
- サーバーが数時間にわたりconnected状態である場合、またはfullあるいはproposing状態になってからconnected状態に戻る場合は通常、サーバーがネットワークの他の部分よりも遅れています。最も一般的なボトルネックはディスクI/O、ネットワーク帯域幅、RAMです。
- 例えば、以下のサーバー状態情報は、正常なサーバーで同期が3分以内に完了しており（disconnected、connected、syncingの状態に分かれている）、現在は完全に同期されたproposing状態が約90分間続いていることを示しています。
```
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2020-Jan-03 22:49:32.834134358 HTTPClient:NFO Connecting to 127.0.0.1:5005

{
  "result" : {
      "info" : {
      ...（省略）...
        "server_state" : "proposing",
        "server_state_duration_us" : "5183282365",
        "state_accounting" : {
          "connected" : {
            "duration_us" : "126164786",
            "transitions" : 1
          },
          "disconnected" : {
            "duration_us" : "2111321",
            "transitions" : 1
          },
          "full" : {
            "duration_us" : "5183282365",
            "transitions" : 1
          },
          "syncing" : {
            "duration_us" : "5545604",
            "transitions" : 1
          },
          "tracking" : {
            "duration_us" : "0",
            "transitions" : 1
          }
        },
      ...（省略）...
   }
  }
}
```
  サーバーが同じ状態間で複数のtransitionsを示している場合、サーバーが同期状態を維持できなかったことを示します。fullまたはproposing状態でない場合、サーバーはまだネットワークに同期されていません。長期の間には、インターネット接続が不安定になってサーバーの同期が時々失われる場合があります。そのためこれが問題になるのは、同期されていない時間がアップタイムのかなりの部分を占める場合のみです。アップタイムが約24時間経過した後に、fullまたはproposing状態だった時間がサーバーの合計実行時間の99%に満たない場合、不安定になっている原因を調査することをお勧めします。
- 同期の問題をデバッグする際の参考として、サーバーが同期しないを参照してください。
complete_ledgers - このフィールドは、サーバーに完全なレジャーデータが保管されているレジャーインデックスを示します。通常、正常なサーバーには連続した最新のレジャーのセット（"12133424-12133858"など）があります。
- 連続していない完全なレジャーのセット（"11845721-12133420,12133424-12133858"など）がある場合、サーバーで断続的な障害が発生したか、またはネットワークの他の部分との同期が一時的にできなかった可能性があります。このようなケースの最も一般的な原因は、ディスクI/Oまたはネットワーク帯域幅の不足です。
- 通常、rippledサーバーはピアから最新のレジャー履歴をダウンロードします。レジャー履歴のギャップが数時間以上続く場合は、欠落データを所有しているピアに接続されていない可能性があります。この状況が発生した場合は、構成ファイルに次のスタンザを追加して再起動すれば、完全な履歴が保管されているRippleのパブリックサーバーの1つにサーバーを強制的にピア接続できます。
```
[ips_fixed]
s2.ripple.com 51235
```
amendment_blocked - このフィールドは通常server_infoレスポンスでは省略されます。このフィールドの値がtrueの場合は、ネットワークにより承認されたAmendmentがサーバーに導入されていません。ほとんどの場合は、最新バージョンにrippledを更新することで修正できます。また[featureメソッド][]を使用して、現在有効なAmendment ID、サーバーでサポートされているAmendment ID、サーバーでサポートされていないAmendment IDを確認することもできます。
peers - このフィールドは、サーバーが接続しているXRP Ledgerピアツーピアネットワーク内のその他のサーバーの数を示します。特定のピアのみに接続するように明示的に構成されているサーバーを除き、正常なサーバーでは通常5～50ピアと表示されます。
- ピアの数が0の場合、サーバーがネットワークに接続できないか、またはシステムクロックが正しくない可能性があります。（サーバーのクロックを同期するため、すべてのサーバーでNTPデーモンを実行することが推奨されます。）
- ピアの数が10の場合、rippledがNATを使用したルーター経由での着信接続を受信できていない可能性があります。接続を改善するには、ルーターのファイアウォールがピアツーピア接続に使用するポート（デフォルトではポート51235）を転送するように設定します。

サーバーからレスポンスがない場合

rippled実行可能ファイルがクライアントとしてrippledサーバーに接続できなかった場合、以下のメッセージが返されます。

{
   "error" : "internal",
   "error_code" : 71,
   "error_message" : "Internal error.",
   "error_what" : "no response from server"
}

通常これはさまざまな問題の1つを示します。

rippledサーバーが起動したばかりであるか、または完全に稼働していません。サービスのステータスを確認してください。稼働している場合は数秒間待ってから再試行してください。
サーバーに接続するために異なるパラメーターをrippledコマンドラインクライアントに渡す必要があります。
rippledサーバーがJSON-RPC接続を受け入れるように構成されていない可能性があります。

サーバーログの確認

デフォルトではrippledはサーバーのデバッグログを/var/log/rippled/debug.logファイルに書き込みます。このデバッグログの位置は、サーバーの構成ファイルにより異なる可能性があります。rippledサービスを（systemctlまたはserviceを使用して開始するのではなく）直接開始した場合、デフォルトではログメッセージはコンソールにも出力されます。

デフォルトの構成ファイルでは、起動時に[log_levelメソッド][]を内部で使用して、すべてのログメッセージカテゴリーでログレベルの重大度は「警告」に設定されています。デバッグログの詳細レベルを制御するには、起動時に--silentコマンドラインオプションを使用し、サーバーの稼働中に[log_levelメソッド][]を使用します。（設定については構成ファイルの[rpc_startup]スタンザを参照してください。）

rippledサーバーが起動中に多数の警告レベルの（WRN）メッセージを出力し、その後はときどきいくつかの警告レベルメッセージを出力することは正常です。サーバー起動時の最初の5～15分間に出力されるほとんどの警告は、安全に無視できます。

さまざまな種類のログメッセージに関する詳しい説明については、ログメッセージについてを参照してください。

11 KiB Raw Blame History Unescape Escape

rippledの問題の診断

server_infoの取得

サーバーからレスポンスがない場合

サーバーログの確認

関連項目

11 KiB

Raw Blame History