Monitor distributed accelrator for cloud storage (preview)

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

Important

DACSは現在、Prometheus用のAzure Monitorマネージドサービスと連携していません。 Azureコンテナストレージは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 名前空間内のキャッシュサーバー ポッドを発見し、ポート 9096 を /metrics でスクレイプします。 コレクターはポート 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ラベルを保持して、単一の不健康または飽和したキャッシュサーバーを特定しましょう。

メトリックリファレンス

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

メトリック ファミリ	タイプ	Meaning
cache_server_active_connections	計器	アクティブな接続数。 TCPの場合、この指標はリクエストを処理する際に接続を追跡しており、すべての確立されたアイドルソケットを追跡するわけではありません。
cache_server_cache_size_bytes	計器	キャッシュされたデータサイズはバイト単位で、設定されたキャッシュ容量ではありません。
cache_server_listen_backlog_max	計器	設定済みのリスニング バックログが listen() に渡されました。
cache_server_accept_queue_overflows_total	Counter	TcpExt.ListenOverflows から合計受け入れキューのオーバーフロー。
cache_server_listen_drops_total	Counter	総再生数が TcpExt.ListenDrops から減少
cache_server_syn_queue_full_drops_total	Counter	SYN リクエスト キューの総ドロップ数 (TcpExt.TCPReqQFullDropから)。
cache_server_syn_cookies_sent_total	Counter	TcpExt.TCPReqQFullDoCookiesから送信された合計SYNクッキー数。
cache_server_passive_opens_total	Counter	nstat年からPassiveOpens年までの合計Tcp.PassiveOpens。
cache_server_open_fds	計器	/proc/sys/fs/file-nr のシステム全体で割り当てられたファイルハンドルであり、プロセスごとのオープンファイルディスクリプタではありません。
cache_server_accept_errors_total	Counter	合計 accept() 件のエラーを errno 値で分類します。 エラーが発生するとシリーズが作成されます。正常なサーバーではそのシリーズが存在しない場合もあります。
cache_server_successful_request_latency_ms	ヒストグラム	成功したリクエストのレイテンシ（単位: ミリ秒）
cache_server_request_counter	Counter	要求の数。
cache_server_download_request_size_bytes	ヒストグラム	ダウンロード リクエストのサイズ。
cache_server_upload_request_size_bytes	ヒストグラム	アップロードリクエストのサイズ。

ヒストグラム メトリクス ファミリーは標準的な _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リクエストおよびバイトメトリクスと相関させます。

次のステップ

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