Prometheus メトリックを使用して、IBM Blockchain Platform ネットワークをモニタリングする

概要

ブロックチェーン・ネットワークのオペレーターとして IBM Cloud 内で IBM Blockchain Platform ネットワークを実行しているとしたら、ノードをモニタリングするための Sysdig ダッシュボードを試したことがあるかもしれません。Hyperledger Fabric v1.4 で導入された Operations Service は、一連の運用メトリックPrometheus ターゲットを公開する API です。この API を使用して、ネットワーク・コンポーネントの状態をモニタリングし、追跡することができます。

IBM Blockchain Platform for IBM Cloud ネットワークでは、すでにピアと順序付けサービス・ノードの運用メトリックを公開しています。このメトリックの公開機能を Sysdig ダッシュボード内でどのように利用しますか?最初に引き出したい有用な洞察には何があるでしょうか?このチュートリアルでは、Sysdig ダッシュボードを構成して、IBM Blockchain ネットワークをモニタリングする Prometheus メトリックを組み込むために必要な手順を説明します。手順ではピアのメトリックに焦点を当てますが、同じプロセスで順序付けサービス・ノードのメトリックにも対応できます。このチュートリアルで Prometheus メトリックの使用方法を紹介するので、これを出発点に、これらのメトリックを独自のシナリオに合わせて使用する方法を探ってください。

前提条件

  • IBM Cloud アカウントと、そのアカウントを使用して作成した IBM Blockchain Platform インスタンスと IBM Cloud Monitoring with Sysdig インスタンス。

  • IBM Blockchain Platform で Sysdig を使用したことがない場合は、このチュートリアルを参考に IBM Cloud Monitoring with Sysdig をセットアップしてください。

  • このチュートリアルでは IBM Cloud CLI を使用して Sysdig 内で Prometheus メトリックを構成するため、コマンド・ラインから IBM Cloud Kubernetes クラスターにログインできる必要があります。

  • Hyperledger Fabric Operations Service と、モニタリングに使用可能な Prometheus メトリックを十分に理解している必要があります。

  • IBM Blockchain Platform 上にピアと順序付けサービス・ノードがデプロイ済みなっている必要があります。セットアップのヘルプが必要な場合は、「ネットワークの構築」チュートリアルを参照してください。

所要時間

このチュートリアルの推定所要時間は約 1 時間です。

手順

  1. Sysdig がノードにアクセスするための ID を作成する
  2. TLS シークレットを構成する
  3. Prometheus の設定を構成する
  4. Sysdig ダッシュボード内で Prometheus メトリックを表示する
  5. Sysdig ダッシュボード内で Prometheus メトリックを使用する
  6. Prometheus メトリックを使用して順序付けサービス・ノードをモニタリングする

以下の 5 つのステップを完了すると、ピアをモニタリングするための 2 つの Prometheus メトリックが構成された、実際に使える Sysdig ダッシュボードが完成します。6 番目のステップでは、ピアではなく順序付けサービス・ノードをモニタリングする場合の手順の違いについて説明します。

1

Sysdig がノードにアクセスするための ID を作成する

Sysdig がクラスター内のノードにアクセスするために使用するのは、Mutual Transport Layer Security (TLS) です。したがって、組織の TLS 認証局 (CA) を使用して秘密鍵と公開鍵を生成しなければなりません。そのためのプロセスは、ピア・ノードの ID を登録してエンロールするときに従ったプロセスと同じですが、Sysdig の場合は TLS CA を使用する必要があります。

コンソール内にピアの CA を開いたら、「Register user (ユーザーを登録)」をクリックし、Sysdig からブロックチェーン・ネットワークにアクセスするために使用する新しいユーザーを作成します。新しく作成するユーザーのエンロール ID とシークレットを指定し、タイプをクライアントに設定します。ユーザーを追加したら、ユーザーのアクション・メニューにある「Enroll identity (ID をエンロール)」をクリックし、このユーザーの証明書と秘密鍵を生成します。

図 1. Sysdig ユーザーの登録とエンロール

重要: 「Certificate Authority (認証局)」ドロップダウン・リストからは必ず「TLS Certificate Authority (TLS 認証局)」を選択してください。

図 2. TLS CA の選択方法

前のステップでユーザーを作成するときに指定したエンロール ID とシークレットを入力します。「Next (次へ)」をクリックすると表示されるパネルに、生成された証明書が表示されます。Sysdig にはこの証明書が必要です。

図 3. 証明書と秘密鍵のダウンロード

次のステップで必要になるため、証明書と秘密鍵をファイル・システムにダウンロードします。その上で、「Add identity to Wallet (ID をウォレットに追加)」をクリックして、コンソール内の鍵を保管します。

ヒント: IBM Blockchain Platform コンソールは証明書を保管しないため、証明書を管理する責任はユーザーにあります。ブラウザーを閉じると、鍵は保存されずに失われてしまいます。鍵を再度使用する必要がある場合 (例えば、別のブラウザーから使用する場合)、ID をブラウザー上のコンソール・ウォレットにインポートする必要があります。したがって、「Export identity (ID をエクスポート)」をクリックして ID をファイル・システムに保存することをお勧めします。こうしておくと、後で必要に応じて ID をインポートできます。

2

TLS シークレットを構成する

Kubernetes クラスター内に Sysdig を構成したときに、Kubernetes クラスター内に ibm-observe 名前空間が作成されています。この名前空間に関連付けられている daemonsetconfigmap を Prometheus に合わせて構成する必要がありますが、その前に、ダウンロードした TLS 証明書を Kubernetes シークレット内に保管しておく必要があります (以下のコマンドは、Sysdig を構成したときに使用したのと同じ IBM Cloud CLI から実行してください)。

  1. 以下のコマンドを実行して、ibm-observe 名前空間内に TLS シークレットを作成します。<cert-path><key-path> は、ローカル・ファイル・システムにダウンロードした証明書のパスです。使用する <secret-name> をメモしておいてください。

    kubectl create secret tls <secret-name> --cert=<cert-path> --key=<key-path> -n ibm-observe
    
  2. Sysdig がクラスターにデプロイされると、ibm-observe 名前空間内に daemonset が作成されます。以下のコマンドを実行して、この daemonset を編集します。

    kubectl edit daemonset -n ibm-observe sysdig-agent
    
  3. spec.template.spec.containers.volumeMounts までスクロールダウンして、シークレット用のボリューム・マウント・パスを追加します。

    - mountPath: /<mount-path>
      name: <volume-name>
    

    以下はその一例です。

    - mountPath: /ibp
      name: ibp-volume
    
  4. 次に、spec.template.spec.containers.volumes を見つけて、このボリュームにシークレットを追加します。<volume-name> に任意の値を指定して、先ほど ibm-observe 名前空間内に作成したシークレットの名前を入力します。

    - name: <volume-name>
      secret:
        defaultMode: 420
        secretName: <secret-name>
    

    以下はその一例です。

    - name: ibp-volume
      secret:
        defaultMode: 420
        secretName: sysdigtls
    
3

Prometheus の設定を構成する

作業の完了まで、あと一息です!以下のコマンドを実行して、ibm-observe 名前空間の configmap を編集します。

kubectl edit configmap -n ibm-observe sysdig-agent
  1. items.data.dragent.yaml.prometheus を見つけます。
  2. インデントに注意しながら、以下のように編集します。

    prometheus:
      enabled: true
      # Helpful for determining why the metrics aren't being detected
      log_errors: true
      process_filter:
      # Exclusions avoid any Prometheus metrics other than the ones included from being detected
      - exclude:
          process.name: docker-proxy
      - exclude:
          container.image: sysdig/agent
      - exclude:
          appcheck.match: prometheus
      # Includes all Kubernetes pods that match the specified label (name in this case)
      - include:
          kubernetes.pod.label.orgname: <peer-organization-msp-id>
          conf:
              use_https: true
              auth_cert_path: "<mount-path where secret is located>/tls.crt"
              auth_key_path: "<mount-path where secret is located>/tls.key"
    

    <peer-organization-msp-id> の部分はピアの組織の MSP ID で置き換えます。<mount-path where secret is located>/tls.key では、上記の daemonset 内に指定した値 (例: /ibp) を使用してください。

これで構成は完了しました。次は、Sysdig ダッシュボード内でメトリックを確認しましょう。

4

Sysdig ダッシュボード内で Prometheus メトリックを表示する

configmap を編集した後、変更が Sysdig ダッシュボードに反映されるまでに数分かかることがあります。構成に問題がないことを調べるには、ダッシュボード内で「Explore (探索)」タブをクリックします。「Hosts (ホスト)」 & 「Containers (コンテナー)」 を選択し、「Entire Infrastructure (インフラストラクチャー全体)」をクリックします。「Overview by Host (ホストごとの概要)」ツイスティーをクリックし、スクロールダウンしてすべての Prometheus メトリックを確認します。

図 4. Sysdig ダッシュボード内に表示された Prometheus メトリック

上の図のように Prometheus メトリックが表示されることを確認できたら、Sysdig と Prometheus メトリックは正常に構成されていることになります。

5

Sysdig ダッシュボード内で Prometheus メトリックを使用する

それぞれの Prometheus メトリックが取り込む内容についての詳細は、常に 「Hyperledger Fabric Metrics Reference」ガイドで確認できます。まず始めに、ピアの状態を評価するのに役立つメトリックをいくつか見ていきましょう。このチュートリアルでは、ledger_blockchain_heightcouchdb_processing_time を調べます。

ledger_blockchain_height

組織内のピアのレジャーの高さを評価するところから始めます。Prometheus メトリックのリストから、「ledger_blockchain_height」を選択します。メトリックの横にある「AVG (平均)」ドロップダウン・メニューをクリックし、メトリックの集計が「Average (平均)」ではなく「Maximum (最大)」に設定されていることを確認します。次に、「Segment (セグメント)」ドロップダウン・リストから「kubernetes.pod.label.name」を選択します。グラフ内の線をクリックすると、ピアごとのレジャーの高さの内訳が表示されます。このビューは、組織内のすべてのピアがトランザクションに遅れを取っていないことを確かめる、ピアの正常性の潜在的インジケーターとして役立ちます。このグラフを使用して、レジャーが最新の状態になっていないすべてのピアを識別できます。

図 5. メトリック: ピア別の ledger_blockchain_height

このグラフは、ledger_blockchain_height メトリックを新しい「Blockchain – Prometheus Metrics (Blockchain – Prometheus メトリック)」ダッシュボードに追加することによって作成されたものです (「前提条件」の「IBM Cloud Monitoring with Sysdig」チュートリアルの手順に従った場合、新しいダッシュボードを作成するプロセスがその手順で説明されています)。ダッシュボードはグラフに加えたカスタマイズを保存して、後で必要に応じてデータを確認するのに便利な場所です。新しい Sysdig ダッシュボードを作成して「+」記号をクリックするだけで、新しいパネルを追加し、そのパネルでメトリックとセグメンテーション・タイプを選択できます。

ヒント: グラフ上にデータが表示されない場合、ページの下部にあるグレーのタイムラインを使用して期間を調整できます。さらに、カスタムの期間を設定することもできます。

図 6. Sysdig ダッシュボードのタイムライン

couchdb_processing_time

次は、couchdb_processing_time メトリックを調べましょう。ledger_blockchain_height メトリックを追加したときと同じプロセスを繰り返します。ただし、今回は couchdb_processing_time メトリックを選択してください。この場合もデータを kubernetes.pod.label.name で分割します。生成されるグラフは、ピア全体でのレジャー・リクエストに対する CouchDB の平均応答時間 (秒数) を追跡して、平均から外れているクエリーを明らかにするのに役立ちます。

図 7. 応答時間 (秒数) の追跡

6

Prometheus メトリックを使用して順序付けサービス・ノードをモニタリングする

順序付けサービス・ノードのモニタリングに関心がある場合、モニタリングの構成プロセスは、以下の点を除き、ピア・ノードのモニタリングを構成する場合と同じです。

  • ステップ 1 でユーザーを登録してエンロールするときに、ピア・ノードの CA ではなく、順序付けサービス・ノードの CA を使用します。

  • ステップ 2 では、順序付けサービス・ノードの TLS CA 証明書の Kubernetes シークレットを作成します。

  • ステップ 3 では、説明に従い、daemonset を編集して、順序付けサービス・ノードの TLS CA 証明書と鍵を追加します。configmap を編集するときに、kubernetes.pod.label.orgname パラメーターにはピア組織の MSP ID ではなく、順序付けサービス組織の MSP ID を指定する必要があります。

上記の手順に従うと、Prometheus メトリックを使用して順序付けサービス・ノードをモニタリングできるようになります。

まとめ

このチュートリアルでは、IBM Blockchain Platform ネットワーク内のピアまたは順序付けサービス・ノードをモニタリングするためのメトリックを処理する Prometheus ダッシュボードを構成しました。構成は完了したので、他の Prometheus メトリックをいろいろと試して、洞察を引き出し、ネットワーク内の問題領域をデバッグできます。「IBM Cloud Monitoring with Sysdig tutorial」をまだ完了していない場合は、今すぐこのチュートリアルに取り組んでノード・リソース割り当て量をモニタリングできるようにしてください。

Sysdig ダッシュボードから得た洞察と Prometheus メトリック・ダッシュボードを組み合わせれば、トランザクション・リクエストに対するネットワークの応答状況をより全体的に把握できるようになります。ブロックチェーン・ネットワーク上でのノードのアクティビティーを詳細に探るダッシュボードで使用できるその他のメトリックについては、「Hyperledger Fabric Metrics Reference」ガイドを参照してください。