Monitor distributed accelrator for cloud storage (preview)

クラウドストレージ用分散アクセラレータ(DACS)は、各キャッシュサーバーからPrometheus形式のメトリクスを公開します。 これらの指標を使って、接続、キャッシュ容量、リクエスト遅延とボリューム、リクエストサイズ、オペレーティングシステムのネットワーク負荷を監視します。

メトリクス エンドポイント

始める前にDACSをインストールし、キャッシュサーバーポッドが準備完了するのを待ちましょう。 コマンドと設定内の <cache-namespace> を、それらのポッドを含む名前空間に置き換えてください。

各キャッシュサーバーポッドは、ポート/metricsの9096パスでメトリクスを公開します。 すべてのキャッシュサーバーポッドをスクレイピングして、監視システムがサーバーごとの状態やカウンターをキャプチャできるようにします。

キャッシュサーバーポッドをリストアップし、メトリクスポートを確認してください:

kubectl get pods \
  --namespace <cache-namespace> \
  --selector app=cacheserver \
  --output wide

kubectl get pods \
  --namespace <cache-namespace> \
  --selector app=cacheserver \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .spec.containers[*].ports[*]}{.containerPort}{" "}{end}{"\n"}{end}'

1つのエンドポイントをローカルで検証する:

CACHE_POD=$(kubectl get pods \
  --namespace <cache-namespace> \
  --selector app=cacheserver \
  -o jsonpath='{.items[0].metadata.name}')

kubectl port-forward \
  --namespace <cache-namespace> \
  pod/$CACHE_POD \
  9096:9096

別の端末で以下の指標を取得します:

curl --fail --silent --show-error http://localhost:9096/metrics

エンドポイントのチェックが終わったらポートフォワードコマンドを停止してください。

指標パイプラインの設定

Prometheus互換コレクタを設定し、DACS名前空間内のキャッシュサーバーポッドを発見し、ポート/metricsを9096でスクレイプします。 コレクターはポート 9096 のポッドIPアドレスへのネットワークアクセスと、Kubernetes APIへの認証されたアクセスが必要です。 DACS 名前空間内のポッドに対して、その ID に権限（get、list、watch）を付与します。 クラスタ内のコレクタの場合は、これらの権限を持つロールをそのサービスアカウントにバインドします。

以下のPrometheus設定は、クラスタ内コレクタの例です。 これにより、Kubernetesの検出はDACS名前空間に限定されます。 <cache-namespace>をお使いのネームスペースに置き換えてください。

scrape_configs:
  - job_name: dacs-cache-server
    scrape_interval: 30s
    metrics_path: /metrics
    kubernetes_sd_configs:
      - role: pod
        namespaces:
          names:
            - <cache-namespace>
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace]
        action: keep
        regex: <cache-namespace>
      - source_labels: [__meta_kubernetes_pod_label_app]
        action: keep
        regex: cacheserver
      - source_labels: [__meta_kubernetes_pod_phase]
        action: keep
        regex: Running
      - source_labels: [__meta_kubernetes_pod_container_port_number]
        action: keep
        regex: "9096"
      - source_labels: [__meta_kubernetes_pod_name]
        target_label: pod
      - source_labels: [__meta_kubernetes_namespace]
        target_label: namespace

パイプラインがPrometheusオペレーターを使用している場合は、PodMonitor、DACS名前空間、メトリクスポートを選択するapp=cacheserverまたは同等のリソースを作成しましょう。 インストール済みプレビューリリースのラベルとポート名を使ってください。

スクレイピングの設定後、メトリックシステムに各キャッシュサーバーポッドごとにアクティブターゲットが1つあるか確認してください。 pod、instance、namespaceラベルを保持して、単一の不健康または飽和したキャッシュサーバーを特定しましょう。

メトリックリファレンス

キャッシュサーバーは以下のメトリクスファミリーを公開します:

ヒストグラム メトリクス ファミリーは標準的な _bucket、_sum、_count 時系列を公開します。 キャッシュサーバープロセスが再起動されるとカウンター値はリセットされます。 リスタートごとに生のカウンター値を比較するのではなく、まず rate() や increase() を使いましょう。

インストール済みプレビュービルドで公開されている指標名（cache_server_request_counter と _ms レイテンシユニットを含む）を使いましょう。 Prometheusの命名規則のlintツールは、Prometheusがそれらをスクレイプしてクエリできても、これらの名前について警告を出すことができます。

PromQLクエリの例

以下の例は、あなたの指標パイプラインが namespace ラベルと pod ラベルを保持することを前提としています。 共有メトリクス ワークスペースでは、各クラスターのサンプルにも一意の cluster ラベルを付与してください。 アグリゲーションは3つのラベルすべてを保持するため、同じ名前のポッドが名前空間やクラスタ間で結合されることはありません。 もしコレクターが別のクラスターラベルを使っているなら、その名前に置き換えてください。 クラスターラベルがない場合は、1 つのクラスターに限定されたデータソースを使用します。

少なくとも2回スクレイプしてから、rate()やincrease()を評価してください。 アイドル状態のサーバーでは、クエリ期間内にリクエストが観測されなかったため、レイテンシの分位数と平均リクエスト サイズが NaN を返すことがあります。 この状態自体は、スクレープ失敗を示すものではありません。 ターゲットの up メトリックを別途確認してください。

キャッシュサーバーごとのアクティブ接続

cache_server_active_connections

キャッシュサーバーごとのリクエスト率

sum by (cluster, namespace, pod) (rate(cache_server_request_counter[5m]))

リリース0.1.0では、cache_server_request_counterにはrequest_typeラベルとstatusラベルが含まれています。 これらのラベルを集計に含めて、アップロード、ダウンロード、失敗を分類してください。 インストールしたリリースで表示されるラベルを確認してください。

キャッシュ全体でのダウンロードの成功例

繰り返し読み取り中のキャッシュサーバーのダウンロードアクティビティを確認するには、成功した Download リクエストをフィルタリングし、選択した Cache リソースが所有するすべてのサーバー Pod 全体で集計します:

sum by (cluster, namespace) (
  increase(cache_server_request_counter{
    cluster="<cluster>",
    namespace="<cache-namespace>",
    pod=~"<cache-server-pod-regex>",
    request_type="Download",
    status="Success"
  }[5m])
)

クラスタ、名前空間、ポッド正則表現のプレースホルダーを置き換えます。 共有名前空間内の他のキャッシュは照合せず、キャッシュリソースが所有するサーバーポッドのみをマッチングしてください。 clusterラベルのない単一クラスタのデータソースの場合は、そのセレクタを省略してください。 DownloadラベルとSuccessラベルの値は大文字と小文字を区別します。

読み取り前に基準を記録し、少なくとも2回スクレープしてください。 increase() ウィンドウ内の活動を推定し、カウンターリセットも考慮します。これは正確な生のカウンター差ではありません。 シリーズが欠けているからといって、活動がゼロの証拠にはなりません。 結果を解釈する前に、スクレイプの状態や公開されているラベルを確認してください。

増加をクライアントのキャッシュヒット指標と相関させ、検証時に無関係なトラフィックを分離します。 このカウンターはキャッシュヒット率ではなく、アプリケーションによる読み取りが成功したり高速になっただけではキャッシュ使用を証明できません。 データの投入は非同期なので、即時の繰り返し読み取りでも依然として見つからない可能性があります。 詳細は 「DACSリクエストパスの検証」を参照してください。

P95 成功リクエスト レイテンシ（ミリ秒）

histogram_quantile(
  0.95,
  sum by (le, cluster, namespace, pod) (
    rate(cache_server_successful_request_latency_ms_bucket[5m])
  )
)

平均ダウンロードリクエストサイズ

sum by (cluster, namespace, pod) (rate(cache_server_download_request_size_bytes_sum[5m]))
/
sum by (cluster, namespace, pod) (rate(cache_server_download_request_size_bytes_count[5m]))

キューのオーバーフロー

sum by (cluster, namespace, pod) (increase(cache_server_accept_queue_overflows_total[5m]))

Listen と SYN キューのドロップ

sum by (cluster, namespace, pod) (
  increase(cache_server_listen_drops_total[5m])
  + increase(cache_server_syn_queue_full_drops_total[5m])
)

推奨アラート

ワークロードのベースラインやキャッシュサーバーのVMサイズを反映したアラートを作成しましょう。 少なくとも、以下のアラートを検討してください:

• ダウンしているか存在しないDACSスクレイピングターゲット。
• cache_server_accept_queue_overflows_totalの持続的な0を超える増加。
• cache_server_listen_drops_totalやcache_server_syn_queue_full_drops_totalの持続的なゼロでない増加。
• errnoごとにグループ化されたcache_server_accept_errors_totalの増加
• P95またはP99の成功リクエストのレイテンシがワークロード目標を上回っている。
• アクティブ接続は、キャッシュサーバーのVMサイズの検証済みの容量に近づいています。
• キャッシュサイズの予期しない変化やキャッシュサーバーポッド間のバランスの崩れ。
• システム全体で割り当てられたファイルハンドル数が異常に高いこと。 cache_server_open_fdsはプロセスごとのファイルディスクリプタ数ではないことを覚えておいてください。

固定の閾値を設定する前に、期待される同時実行性の下で基準を確立しましょう。 ネットワークプレッシャーの指標をリクエストレート、リクエストサイズ、レイテンシ、ノードCPU、ノードメモリ、Azure Blobリクエストおよびバイトメトリクスと相関させます。

次のステップ

• クラウドストレージ用の分散アクセラレータを管理します。
• クラウドストレージ用の分散アクセラレータのトラブルシューティング。