Chia Harvesters 監視のベストプラクティス¶

はじめに¶

Chia ユーザーは、複数のホスト上の Harvester をリアルタイムで監視し、各 Harvester の可用性、状態、収益を詳細に分析することで、Harvester に対する管理力を継続的に向上させる必要があります。Guance は、能動的・受動的監視、グローバルな異常検知モジュールを活用し、Chia ユーザーの実際のニーズに合わせた統合 Chia 業務管理プラットフォームを構築します。これにより、Chia ユーザーは Harvester の稼働状態を全体的に把握し、生産効率を向上させ、Harvester の障害や期待収益の不足を容易にトラブルシューティングできるようになります。また、Chia のパフォーマンスに関するエキスパートサービスやオンサイトサポートサービスも提供し、Chia ユーザーの収益向上を支援します。監視すべき主な領域は以下のとおりです。

• Harvester

• CPU

• メモリ
• ディスク
• ネットワーク

シナリオビュー¶

組み込みビュー¶

ディスク¶

前提条件¶

DataKit がインストールされていること（DataKit インストールドキュメント）

設定¶

ログ収集¶

ここでは Windows クライアントを例に説明します（Linux も同様です）。

Chia farm ログ収集スクリプトの作成¶

Git がインストールされていること（Git インストール参考）

chia-blockchain ディレクトリ（C:\Users\{ユーザー名}\AppData\Local\chia-blockchain\app-{Chia バージョン}\resources\app.asar.unpacked\daemon）に移動し、ログ収集スクリプト farmer.sh を作成します。このスクリプトは、Chia クライアントの farm 情報を farmer.log に保存します。

事前に C:\Users\{ユーザー名}\AppData\Local\chia-blockchain\app-{Chia バージョン}\ に data_collect フォルダを作成してください。

#!/bin/bash

while true; do
    sleep 2
    ./chia.exe farm summary  | awk '{line=line "," $0} NR%10==0{print substr(line,1); line=""}' >> ../../../data_collect/farmer.log
done

DataKit のパイプライン設定¶

DataKit インストールディレクトリの pipeline ディレクトリに移動し、farm_log.p と chai_debug_log.p を作成して、収集したログのパース（切り出し）を行います。以下に例を示します。

chia_debug_log.p¶

#chia_debug_log
#名前 説明
#strptime($timestamp, "2006-01-02T15:04:05") 
#total_plots  Plot 数
#eligible_plots    一次選別を通過した Plot 数
#proofs_found   ブロック発見数
#check_duration  クエリ時間

# ログ例：
#2021-04-24T11:01:53.390 harvester chia.harvester.harvester: INFO     1 plots were eligible for farming 940b588c2a... Found 0 proofs. Time: 0.98087 s. Total 19 plots


grok(_, "%{TIMESTAMP_ISO8601:strptime} harvester chia.harvester.harvester: INFO \\s+ %{NUMBER:eligible_plots} plots were eligible for farming \\w+\\.\\.\\. Found %{NUMBER:proofs_found} proofs\\. Time: %{NUMBER:check_duration} s\\. Total %{NUMBER:total_plots} plots.*")

# 数値型変換
cast(eligible_plots, "float")
cast(proofs_found, "float")
cast(check_duration, "float")
cast(total_plots, "float")

# 元の内容を破棄
drop_origin_data()

farm_log.p¶

#farm_log
#名前 説明
#farming_status  farmer ステータス
#xch_count  獲得した XCH
#last_farm_height  Farm の高さ
#total_plot  耕作数
#total_plots_size_GiB 耕作サイズ (GiB)
#total_plots_size_TiB 耕作サイズ (TiB)
#total_plots_size_PiB 
#network_space   ネットワーク全体の算力 (PiB)

#ログ例：
#,Farming status: Farming,Total chia farmed: 0.0,User transaction fees: 0.0,Block rewards: 0.0,Last height farmed: 0,Plot count: 137,Total size of plots: 13.561 TiB,Estimated network space: 12457.266 PiB,Expected time to win: 5 months and 4 weeks,Note: log into your key using 'chia wallet show' to see rewards for each key

grok(_, ",Farming status: %{WORD:farming_status},Total chia farmed: %{NUMBER:xch_count},User transaction fees: %{NUMBER},Block rewards: %{NUMBER},Last height farmed: %{NUMBER:last_farm_height},Plot count: %{NUMBER:total_plot},Total size of plots: %{NUMBER:total_plots_size_GiB} GiB,Estimated network space: %{NUMBER:network_space_PiB} PiB.*")
grok(_, ",Farming status: %{WORD:farming_status},Total chia farmed: %{NUMBER:xch_count},User transaction fees: %{NUMBER},Block rewards: %{NUMBER},Last height farmed: %{NUMBER:last_farm_height},Plot count: %{NUMBER:total_plot},Total size of plots: %{NUMBER:total_plots_size_TiB} TiB,Estimated network space: %{NUMBER:network_space_PiB} PiB.*")
grok(_, ",Farming status: %{WORD:farming_status},Total chia farmed: %{NUMBER:xch_count},User transaction fees: %{NUMBER},Block rewards: %{NUMBER},Last height farmed: %{NUMBER:last_farm_height},Plot count: %{NUMBER:total_plot},Total size of plots: %{NUMBER:total_plots_size_PiB} PiB,Estimated network space: %{NUMBER:network_space_PiB} PiB.*")

#数値型変換
cast(farming_status, "str")
cast(xch_count, "float")
cast(last_farm_height, "float")
cast(total_plot, "float")
cast(total_plots_size_GiB, "float")
cast(total_plots_size_TiB, "float")
cast(total_plots_size_PiB, "float")
cast(network_space_PiB, "float")

# 元の内容を破棄
drop_origin_data()

DataKit のログ収集設定¶

DataKit インストールディレクトリの conf.d/log ディレクトリに移動し、logging.conf.sample をコピーして logging.conf という名前で保存します。以下に例を示します。

2 つの logfiles のパスを、ご自身の Chia ログファイルが配置されているディレクトリに変更してください。

[[inputs.logging]]
    # required, glob logfiles
    logfiles = ['''C:\Users\Administrator\.chia\mainnet\log\debug.*''']

    # glob filteer
    ignore = [""]

    # your logging source, if it's empty, use 'default'
    source = "chia_harvester"

    # add service tag, if it's empty, use $source.
    service = ""

    # grok pipeline script path
    pipeline = "chia_debug_log.p"

    # optional status:
    #   "emerg","alert","critical","error","warning","info","debug","OK"
    ignore_status = []

    # optional encodings:
    #    "utf-8", "utf-16le", "utf-16le", "gbk", "gb18030" or ""
    character_encoding = ""

    # The pattern should be a regexp. Note the use of '''this regexp'''
    # regexp link: https://golang.org/pkg/regexp/syntax/#hdr-Syntax
    match = '''^\S'''

    [inputs.logging.tags]
    # tags1 = "value1"

[[inputs.logging]]
    # required, glob logfiles
    logfiles = ['''C:\Users\Administrator\AppData\Local\chia-blockchain\app-1.1.6\data_collect\farmer.log''']

    # glob filteer
    ignore = [""]

    # your logging source, if it's empty, use 'default'
    source = "chia_farmer"

    # add service tag, if it's empty, use $source.
    service = ""

    # grok pipeline script path
    pipeline = "farm_log.p"

    # optional status:
    #   "emerg","alert","critical","error","warning","info","debug","OK"
    ignore_status = []

    # optional encodings:
    #    "utf-8", "utf-16le", "utf-16le", "gbk", "gb18030" or ""
    character_encoding = ""

    # The pattern should be a regexp. Note the use of '''this regexp'''
    # regexp link: https://golang.org/pkg/regexp/syntax/#hdr-Syntax
    match = '''^\S'''

    [inputs.logging.tags]
    # tags1 = "value1"

DataKit を再起動して設定を反映¶

監視指標の説明¶

1 Harvester¶

複数のホスト上の Harvester をリアルタイムで監視し、各 Harvester の可用性、状態、収益を詳細に分析することで、Chia ユーザーの Harvester に対する管理力を継続的に向上させます。

1 日あたりの期待収益¶

毎日安定して Plot を増やし、算力の占有率を安定させることが重要です。そうすることで、1 日あたりの期待収益が大きく変動することはありません。期待収益が急激に変動した場合は注意が必要です。Harvester ノードがダウンしている可能性や、ネットワーク全体の算力が急増して自身の算力占有率が低下している可能性があります。常に期待収益を監視し、アラートを設定して収益の安定を確保することをお勧めします。

Harvester の一次選別通過率¶

収益の安定を確保するため、Harvester の一次選別通過数を監視してください。通常、ネットワークとディスクの状態が健全であれば、Harvester の一次選別通過率は一定の範囲で安定し、大きな変動はありません。Harvester の一次選別通過率が大きく変動した場合は、速やかにディスクとネットワークの状態を確認し、収益の安定を確保してください。

平均チャレンジクエリ時間¶

Harvester の平均チャレンジクエリ時間を常に監視し、各 Harvester のクエリ時間が 5 秒を超えないようにアラートを設定してください。5 秒を超えた場合は、速やかにネットワーク情報やディスク情報を確認し、収益の安定を確保してください。

2 CPU 監視¶

CPU 監視は、CPU 負荷のピークを分析し、過剰な CPU 使用状況を特定するのに役立ちます。CPU 監視指標を使用して、CPU 能力の向上や負荷の軽減、潜在的な問題の特定、不要なアップグレードによる過剰なコストの回避が可能です。また、CPU 監視指標は、実行中の不要なバックグラウンドプロセスを特定し、プロセスやアプリケーションのリソース使用率、およびネットワーク全体への影響を把握するのにも役立ちます。

CPU 使用率¶

CPU 使用率は、User Time（ユーザープロセス実行時間の割合）、System Time（カーネルプロセスおよび割り込みの実行時間の割合）、Idle Time（CPU がアイドル状態である時間の割合）に分類できます。CPU のパフォーマンスとしては、まず各 CPU の実行キューが 3 を超えないようにします。また、CPU がフル負荷状態の場合、User Time は 65%～70%、System Time は 30%～35%、Idle Time は 0%～5% が目安です。

3 メモリ監視¶

メモリは Linux のパフォーマンスに影響を与える主要な要素の一つであり、メモリリソースの十分さはアプリケーションシステムの使用パフォーマンスに直接影響します。

メモリ使用率¶

利用可能なメモリ容量を注意深く監視することは重要です。RAM の競合は、ページングやパフォーマンス低下を引き起こす可能性があるためです。マシンを正常に稼働させるには、ワークロードに十分な RAM があることを確認してください。メモリの可用性が低い状態が続くと、セグメンテーションフォールトやその他の深刻な問題が発生する可能性があります。発生した場合の対策としては、システム内の物理メモリ容量を増やす、可能であればメモリページのマージを有効にするなどがあります。

4 ディスク監視¶

ディスク容量¶

十分な空きディスク容量を維持することは、あらゆるオペレーティングシステムにとって必要です。通常のプロセスに加えて、コアシステムプロセスはログやその他のデータをディスクに保存します。空きディスク容量が 15% を下回った場合に通知するアラートを設定し、ビジネスの継続性を確保できます。

ディスク読み書き時間¶

このペアの指標は、ディスクの読み取り/書き込み操作にかかる平均時間を追跡します。50 ミリ秒を超える値は、比較的高いレイテンシを示します（通常は 10 ミリ秒未満が最適です）。レイテンシを減らすには、より高速なディスクにビジネスジョブを移行することが一般的に推奨されます。サーバーの役割に応じて異なるアラート値を設定できます。許容されるしきい値は役割によって異なります。

ディスク読み書き¶

サーバーで要求の厳しいアプリケーションをホストしている場合は、ディスク I/O レートを監視する必要があります。ディスク読み書き指標は、ディスクタグが付けられた読み取り（diskio.read_bytes）と書き込み（diskio.write_bytes）アクティビティの集約です。ディスクアクティビティが高い状態が続くと、特に高 RAM とページファイルを同時に使用している場合、サービスの低下やシステムの不安定性を引き起こす可能性があります。ディスクアクティビティが高い場合は、使用中のディスク数を増やす（特にキュー内の操作が多い場合）、より高速なディスクを使用する、ファイルシステムキャッシュ用に予約する RAM を増やす、可能であればワークロードをより多くのマシンに分散することをお勧めします。

ディスク温度¶

ビジネスにおいてディスクの可用性要件が非常に高い場合は、ディスクの動作温度を監視するアラートを設定できます。温度が 65℃（SSD の場合は 75℃ 以上）を超えると注意が必要です。ハードディスクに過熱保護や温度制御機構がない場合は特に注意が必要です。ハードディスクの温度がさらに上昇すると、ハードディスクが損傷し、業務データが失われる可能性があります。

5 ネットワーク監視¶

アプリケーションとインフラストラクチャコンポーネントは、ますます複雑なアーキテクチャで相互に依存しています。モノリシックアプリケーションであれマイクロサービスであれ、クラウドインフラストラクチャ、プライベートデータセンター、またはその両方にデプロイしているかどうかに関係なく、同様です。仮想化インフラストラクチャにより、開発者は任意の規模に対応でき、従来のネットワーク監視ツールではうまく対応できない動的なネットワークパターンを作り出せます。環境内のすべてのコンポーネントとそれらの間のすべての接続に対する可視性を提供するために、Guance はクラウド時代向けのネットワークパフォーマンス監視を導入しています。

ネットワークトラフィック¶

これら 2 つの指標を組み合わせることで、特定のネットワークインターフェースの総ネットワークスループットを測定できます。一般的なコンシューマ向けハードウェアの場合、NIC の転送速度は 1 Gbps 以上であり、極端なケースを除けば、ネットワークがボトルネックになる可能性は低いです。インターフェース帯域幅の 80% 以上を使用した場合に通知するアラートを設定し、ネットワークの飽和を防止できます（1 Gbps リンクの場合、毎秒 100 メガバイトに相当します）。

再送回数¶

TCP 再送は頻繁に発生しますが、エラーではありません。ただし、再送の存在は問題の兆候である可能性があります。再送は通常、ネットワーク輻輳の結果であり、高い帯域幅消費と関連していることがよくあります。過剰な再送はアプリケーションに大きなレイテンシを引き起こす可能性があるため、この指標を監視する必要があります。再送側が送信済みパケットの確認応答を受信しない場合、さらなるパケットの送信を延期し（通常約 1 秒間）、レイテンシが増加し、輻輳に関連した速度低下が発生します。

ネットワーク輻輳が原因でない場合、再送の原因はネットワークハードウェアの障害である可能性があります。ドロップされるパケット数が少なく、再送率が高い場合は、過剰なバッファリングが原因である可能性があります。原因に関係なく、この指標を追跡して、ネットワークアプリケーションの応答時間における一見ランダムな変動を理解する必要があります。

結論¶

この記事では、マイニング時に状態を把握するために監視できる、最も有用な指標のいくつかを紹介しました。マイニング作業を行っている場合は、以下のリストの指標を監視することで、ファームの稼働状態と可用性を適切に把握できます。

• ディスク読み書きレイテンシ
• ディスク温度
• ネットワークトラフィック
• 1 日あたりの期待収益
• Harvester の一次選別通過率
• プロセス

最終的には、ご自身のユースケースに特に関連するその他の指標を認識できるようになります。もちろん、Guance を通じて詳細をご確認いただくこともできます。