ARCHIVE/xrpl-dev-portal

Fork 0

mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 11:45:50 +00:00

Files

Vova Rutskyi 9a0c010600 chore: rename deprecated i18n to l10n

2024-11-04 12:01:06 -08:00

7.2 KiB

Raw Blame History

html, parent, seo, labels

html

parent

seo

labels

health-check.html

peer-port-methods.html

description
サーバの状態を報告するための特別なAPIメソッドです。

コアサーバ

ヘルスチェック

[ソース]

ヘルスチェックは、個々のrippledサーバの状態を報告するための特別なpeer portメソッドです。このメソッドは、自動化された監視において、機能停止を認識し、サーバの再起動のような自動または手動による介入を促すために使用することを意図しています。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}新規: rippled 1.6.0{% /badge %}

このメソッドは、複数の情報をチェックして、一般に正常とみなされる範囲にあるかどうかを確認します。すべての情報が正常な範囲にある場合、このメソッドは、サーバが正常であることを報告します。いずれかの情報が正常な範囲外の場合、このメソッドは、サーバが正常でないことを報告し、正常でない情報を報告します。

情報によっては、急速に正常範囲から外れる情報もあるため、ヘルスチェックが複数回連続して失敗しない限り、アラートを発生させないようにしてください。

{% admonition type="info" name="注記" %}ヘルスチェックはpeer portメソッドであるため、[スタンドアロンモード][]でサーバをテストしているときは利用できません。{% /admonition %}

リクエストのフォーマット

ヘルスチェック情報をリクエストするには、以下のHTTPリクエストを行ってください。

プロトコル: https
HTTPメソッド: GET
ホスト: (任意のrippledサーバ(ホスト名またはIPアドレスによる))
ポート: (rippledサーバがピアプロトコルを使用するポート番号、通常は51235です。)
パス: /health
セキュリティ: ほとんどのrippledサーバはリクエストにレスポンスするために自己署名証明書を使います。デフォルトでは、(Webブラウザを含む)ほとんどのツールは、そのようなレスポンスは信頼できないとしてフラグを立てたりブロックしたりします。これらのサーバからのレスポンスを表示するには、証明書のチェックを無視しなければなりません (たとえば、cURLを使用している場合は--insecureフラグを追加します)。

レスポンスの例

{% tabs %}

{% tab label="Healthy" %}

HTTP/1.1 200 OK
Server: rippled-1.6.0-b8
Content-Type: application/json
Connection: close
Transfer-Encoding: chunked

{
  "info": {}
}

{% /tab %}

{% tab label="Warning" %}

HTTP/1.1 503 Service Unavailable
Server: rippled-1.6.0
Content-Type: application/json
Connection: close
Transfer-Encoding: chunked

{
  "info": {
    "server_state": "connected",
    "validated_ledger": -1
  }
}

{% /tab %}

{% tab label="Critical" %}

HTTP/1.1 500 Internal Server Error
Server: rippled-1.6.0
Content-Type: application/json
Connection: close
Transfer-Encoding: chunked

{
  "info": {
    "peers": 0,
    "server_state": "disconnected",
    "validated_ledger":-1
  }
}

{% /tab %}

{% /tabs %}

レスポンスのフォーマット

レスポンスのHTTPステータスコードは、サーバの状態を示します。

ステータスコード	現在の状態	説明
200 OK	Healthy	すべての指標は許容範囲内です。
503 Service Unavailable	Warning	1つ以上の指標が警告範囲にあります。手動介入が必要な場合と不要な場合があります。
500 Internal Server Error	Critical	1つ以上のメトリクスが深刻な範囲にあります。おそらく手動による修正が必要な深刻な問題があります。

レスポンスボディは JSON オブジェクトで、トップレベルに infoオブジェクトが 1 つあります。infoオブジェクトには、warningまたはcriticalの範囲にある指標ごとの値が含まれます。正常な範囲にある指標は省略されるため、完全に正常なサーバは空のオブジェクトを持ちます。

infoオブジェクトは以下のフィールドを含むことができます。

`Field`	値	説明
`amendment_blocked`	真偽値	(省略される場合があります) `true`の場合、サーバはamendmentブロック状態で、ネットワークとの同期を維持するためにアップグレードする必要があります。この状態は非常に重要です。サーバがAmendmentブロックされていない場合、このフィールドは省略されます。
`load_factor`	数値	(省略される場合があります) サーバが受けている全体的な負荷の指標。I/O、CPU、メモリの制限が反映されます。負荷率が100以上の場合はwarning、1000以上の場合はcriticalです。
`peers`	数値	(省略される場合があります) このサーバが接続しているピアサーバの数。7つ以下のピアに接続されている場合はwarning、0つのピアに接続されている場合はcriticalです。
`server_state`	文字列	(省略される場合があります) 現在のサーバの状態。サーバの状態が`tracking`、`syncing`、`connected`の場合はwarningです。サーバが`disconnected`状態の場合はcriticalです。
`validated_ledger`	数値	(省略される場合があります) レジャーが最後にコンセンサスによって検証されてから何秒経ったかを表します。検証されたレジャーがない場合(サーバ起動時の初期同期期間)、この値は`-1`となり、warningとみなされます。また、最後に検証されたレジャーが少なくとも7秒前であればwarningとなり、最後に検証されたレジャーが少なくとも20秒前であればcriticalとなります。

7.2 KiB Raw Blame History

ヘルスチェック

リクエストのフォーマット

レスポンスの例

レスポンスのフォーマット

関連項目

7.2 KiB

Raw Blame History