Swarm Bee のオブザーバビリティベストプラクティス¶

概要¶

Swarm はイーサリアムプロジェクトの公式な一部であり、主に財団によって開発されています。マイニングプールがストレージ、帯域幅、計算リソースを提供し、イーサリアムネットワークベースのアプリケーションをサポートすることを可能にします。チームは、ダウンタイムがなく、ゼロ故障で、検閲耐性のあるピアツーピアのストレージおよびサービスソリューションの作成を目指しています。Swarm 内に経済的インセンティブシステムを構築することで、リソース交換価値の支払いと転送を促進し、イーサリアムブロックチェーンのさまざまなプロトコルと技術を活用します。Swarm は分散型のコンテンツストレージおよび配信サービスであり、CDN と見なすことができ、インターネットを介してコンピュータ上に配信されます。イーサリアムノードを実行するのと同様に、Swarm ノードを実行して Swarm ネットワークに接続できます。これは BitTorrent に似ており、IPFS とも類似しており、ETH を報酬として使用します。ファイルはチャンクに分割され、参加ボランティアによって割り当てられ、保存されます。チャンクを保存して提供するノードは、データの保存および取得サービスを必要とするノードから ETH を受け取ります。Swarm はマイニングモードを採用しておらず、ブロック報酬はありません。代わりに、他のノードとの対話後に報酬を獲得し、対話後にチェックを受け取ります。このチェックは BZZ と交換できます。そのため、BZZ クラスタのネットワーク環境とノード状態は特に重要です。

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

シナリオビュー¶

組み込みビュー¶

ディスク¶

前提条件¶

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

Docker がインストールされ、Docker Swarm が初期化されていること（ Docker インストール参考）

設定¶

Prom Exporter の設定¶

DataKit インストールディレクトリの conf.d/prom ディレクトリに移動し、prom.conf.sample をコピーして prom.conf という名前に変更します。例は以下の通りです。

 ## Exporter アドレス
  url = "http://127.0.0.1:1635/metrics"

  ## メトリクスタイプフィルタ、設定可能な値は counter、gauge、histogram、summary
  # デフォルトでは counter と gauge タイプのメトリクスのみを収集
  # 空の場合はフィルタリングを行わない
  metric_types = ["counter", "gauge"]

  ## メトリクス名フィルタ
  # 正規表現をサポート、複数設定可能で、いずれかに一致すればよい
  # 空の場合はフィルタリングを行わない
  # metric_name_filter = ["cpu"]

  ## メジャーメント名プレフィックス
  # これを設定すると、メジャーメント名にプレフィックスを追加
  #  measurement_prefix = "prom_"

  ## メジャーメント名
  # デフォルトでは、メトリクス名をアンダースコア"_"で分割し、分割後の最初のフィールドをメジャーメント名、残りのフィールドを現在のメトリクス名とする
  # measurement_name を設定した場合、メトリクス名の分割は行われない
  # 最終的なメジャーメント名には measurement_prefix プレフィックスが追加される
  # measurement_name = "prom"

  ## 収集間隔 "ns"、"us" (または "µs")、"ms"、"s"、"m"、"h"
  interval = "10s"

  ## TLS 設定
  tls_open = false
  # tls_ca = "/tmp/ca.crt"
  # tls_cert = "/tmp/peer.crt"
  # tls_key = "/tmp/peer.key"

  ## カスタムメジャーメント名
  # プレフィックス prefix を含むメトリクスを1つのメジャーメントにまとめることができます
  # カスタムメジャーメント名の設定は measurement_name 設定よりも優先されます
  #[[inputs.prom.measurements]]
  #  prefix = "cpu_"
  #  name = "cpu"

  # [[inputs.prom.measurements]]
  # prefix = "mem_"
  # name = "mem"

  ## カスタムタグ
  [inputs.prom.tags]
  bee_debug_port = "1635"
  # more_tag = "some_other_value"

Swarm API サービスコレクターの設定¶

Dataflux Func のインストール¶

DataKit の変更¶

datakit インストールディレクトリの conf.d ディレクトリに移動し、datakit.conf ファイルの http_listen を変更します。例は以下の通りです。

http_listen = "0.0.0.0:9529"
log = "/var/log/datakit/log"
log_level = "debug"
log_rotate = 32
gin_log = "/var/log/datakit/gin.log"
protect_mode = true
interval = "10s"
output_file = ""
default_enabled_inputs = ["cpu", "disk", "diskio", "mem", "swap", "system", "hostobject", "net", "host_processes", "docker", "container"]
install_date = 2021-05-14T05:03:35Z
enable_election = false
disable_404page = false

[dataway]
  urls = ["https://openway.dataflux.cn?token=tkn_9a49a7e9343c432eb0b99a297401c3bb"]
  timeout = "5s"
  http_proxy = ""

[http_api]
  rum_origin_ip_header = "X-Forward-For"

[global_tags]
  cluster = ""
  host = "df_solution_ecs_004"
  project = ""
  site = ""

[[black_lists]]
  hosts = []
  inputs = []

[[white_lists]]
  hosts = []
  inputs = []

保存して DataKit を再起動します

datakit --restart

Func のインストール¶

DataFlux Func の依存ファイルをダウンロードします

/bin/bash -c "$(curl -fsSL https://t.dataflux.cn/func-portable-download)"

コマンドの実行が完了すると、すべての必要なファイルが現在のディレクトリに新しく作成された dataflux-func-portable ディレクトリに保存されます。

ダウンロードした dataflux-func-portable ディレクトリで、以下のコマンドを実行すると、自動的に設定が行われ、DataFlux Func 全体が起動します。

sudo /bin/bash run-portable.sh

インストール成功

Please wait for the container to run, wait 30 seconds...
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES


Installed dir:
    /usr/local/dataflux-func
To shutdown:
    sudo docker stack remove dataflux-func
To start:
    sudo docker stack deploy dataflux-func -c /usr/local/dataflux-func/docker-stack.yaml
To uninstall:
    sudo docker stack remove dataflux-func
    sudo rm -rf /usr/local/dataflux-func
    sudo rm -f /etc/logrotate.d/dataflux-func

Now open http://<IP or Hostname>:8088/ and have fun!

http://<IP or Hostname>:8088 にアクセスすると、以下の画面が表示されます。

DataKit データソースの設定によるデータの送信¶

スクリプトを作成して peer データを収集¶

import requests


@DFF.API('peer')
def peer():
    # DataKit 操作オブジェクトを取得
    datakit = DFF.SRC('datakit')
    response = requests.get("http://172.17.0.1:1635/peers")
    response_health = requests.get("http://172.17.0.1:1635/health")
    peers = response.json()
    health = response_health.json()
    res = datakit.write_metric(measurement='bee', tags={'bee_debug_port':'1635','host':'df-solution-ecs-013'}, fields={'swap_peers':len(peers["peers"]),'version':health["version"]})
    print(res, "swap_peers: ", len(peers["peers"]), "    version: ", health["version"])

DataFlux Func は Docker Stack として実行され、ホストの docker0 にブリッジ接続されているため、ホストのローカルネットワークとは直接接続されません。そのため、DataFlux Func と DataFlux DataKit が同じサーバーにインストールされている場合でも、DataFlux DataKit のリスニングポートを単純にローカルネットワーク（127.0.0.1）にバインドすることはできません。

この場合、設定を変更して、リスニングポートを docker0（172.17.0.1）または 0.0.0.0 にバインドする必要があります。この際、swarm bee の設定を変更し、ローカルリスニングポート :1635 の前に 0.0.0.0 を追加する必要があります。

API リクエストによって取得したデータを対応するメジャーメントに挿入し、適切なタグを追加して、Studio で表示できるようにします。

管理画面で自動トリガー実行を新規作成し、関数のスケジューリングを行う¶

作成した関数を選択し、定期実行を設定します。有効期限を追加し、保存をクリックします。

定期実行の最短間隔は 1 分です。特別な要件がある場合は、while + sleep を使用してデータ収集頻度を上げることもできます。

自動トリガー設定による関数の実行状態の確認¶

「成功」と表示されたら、Studio で送信したメトリクスを確認できます。

監視指標の説明¶

1 Bee¶

複数のホストのハーベスターをリアルタイムで監視し、各ハーベスターの可用性、ステータス、収益を詳細に分析することで、Chia ユーザーがハーベスターをより適切に管理できるようにします。

指標の説明	名前	基準
受信したチェック数	`bee.swap_cheques_received`	収益指標
拒否されたチェック数	`bee.swap_cheques_rejected`	収益指標
送信したチェック数	`bee.swap_cheques_sent`	収益指標
接続されているピア数	`bee.swap_peers`	パフォーマンス指標

拒否されたチェック数¶

安定した日次収益を確保するために、この指標を常に監視してください。拒否されたチェック数が急増した場合は、すぐに Bee ノードとネットワークの状態を確認し、安定した収益を確保してください。

接続されているピア数¶

収益とネットワークの安定性を確保するために、接続されているピア数を監視してください。通常、ネットワーク状態とノード状態が正常であれば、接続ピア数は一定の範囲内で安定し、急激な変動はありません。接続ピア数に急激な変動が発生した場合は、すぐに Bee ノードとネットワークの状態を確認し、安定した収益を確保してください。

2 CPU 監視¶

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

指標の説明	名前	基準
CPU 負荷	`system.load1` `systeml.load5` `system.load15`	リソース使用率
CPU 使用率	`cpu.usage_idle` `cpu.usage_user` `cpu.usage_system`	リソース使用率

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 のパフォーマンスに影響を与える主要な要因の 1 つであり、メモリリソースの十分性はアプリケーションシステムのパフォーマンスに直接影響します。

指標の説明	名前	基準
メモリ使用率	`mem.used_percent`	リソース使用率
メモリ使用量	mem.free `mem.used`	リソース使用率
メモリキャッシュ	`mem.buffered`	リソース使用率
メモリバッファ	`mem.cached`	リソース使用率

メモリ使用率¶

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

4 ディスク監視¶

指標の説明	名前	基準
ディスクヘルスステータス	`disk.health` `disk.pre_fail`	可用性
ディスク容量	`disk.free` `disk.used`	リソース使用率
ディスク Inode	`disk.inodes_free` `disk.inodes_used`	リソース使用率
ディスク読み書き	`diskio.read_bytes` `diskio.write_bytes`	リソース使用率
ディスク温度	`disk.temperature`	可用性
ディスクモデル	`disk.device_model`	基本
ディスク読み書き時間	`diskio.read_time` `disk.io.write_time`	リソース使用率

ディスク容量¶

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

ディスク読み書き時間¶

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

ディスク読み書き¶

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

ディスク温度¶

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

5 ネットワーク監視¶

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

指標の説明	名前	基準
ネットワークトラフィック	`net.bytes_recv` `net.bytes_sent`	リソース使用率
ネットワークパケット	`net.packets_recv` `net.packets_sent`	リソース使用率
再送回数	`net.tcp_retranssegs`	可用性

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

これら 2 つの指標は、特定のネットワークインターフェースの総ネットワークスループットを測定します。ほとんどのコンシューマ向けハードウェアでは、NIC の転送速度は 1 Gbps 以上であり、極端な場合を除いて、ネットワークがボトルネックになる可能性は低いです。インターフェース帯域幅の 80％以上を使用している場合にアラートを設定し、ネットワーク飽和を防ぐことができます（1 Gbps リンクの場合、毎秒 100 MB に相当）。

再送回数¶

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

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

結論¶

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

ディスク読み書きレイテンシ
ディスク温度
ネットワークトラフィック
1日の期待収益
ハーベスター一次スクリーニング通過率
プロセス

最終的には、ご自身のユースケースに特に関連するその他の指標を認識できるようになります。もちろん、Guance でさらに詳しく知ることもできます。