カスタムメトリクスを用いた監視

本文の内容は、2023年3月1日に JAVIER MARTÍNEZが投稿したブログ（https://sysdig.com/blog/monitoring-custom-metrics）を元に日本語に翻訳・再構成した内容となっております。 カスタムメトリクスとは、Prometheusのような監視システムから直接アウトオブボックスで提供されるメトリクス（例：Kube State Metricsやnode exporter）とは異なり、アプリケーションレベルまたはビジネス関連のオーダーメイドメトリクスのことです。 Prometheusで監視プロジェクトを開始すると、Node ExporterとKube State Metricsだけでアウトオブボックスのメトリクスを初期セットで入手できることに気づくかもしれません。しかし、これではブラックボックス監視を行うだけなので、ここまでしかできません。次のレベルに進み、その先にあるものを観察するにはどうしたらよいでしょうか。ビジネスやアプリのレベルとは別の次元を提供するため、クラウドネイティブなシステムの日常的な監視には欠かせない存在となっています。

エクスポーターが提供するメトリクス
お客様が設計したテーラーメードなメトリクス
以前の既存のメトリクスを集約したもの

今回は、以下の内容をご紹介します：

カスタムメトリクスが重要な理由
カスタムメトリクスを使用するタイミング
カスタムメトリクスを作成する際の注意点
KubernetesメトリクスAPI
Prometheusのカスタムメトリクス
カスタムメトリクスを使用する際の課題

カスタムメトリクスが重要な理由

カスタムメトリクスを利用することで、お客様は以下のことが可能になります。

主要業績評価指標（KPI）を監視する
問題を迅速に検出する
リソースの利用状況を把握する
レイテンシーの測定
サービスやシステムから得られる特定の値を追跡する

カスタムメトリクスの例：

トランザクションのレイテンシー（ミリ秒単位）
データベースにおけるオープン接続
キャッシュヒット数/キャッシュミス数
eコマースサイトの注文/売上
遅いレスポンスの %
リソースを大量に消費するレスポンスの %

このように、エクスポーターから取得したメトリクスや、アドホックに作成したメトリクスは、カスタムメトリクスの定義に適合します。 ただし、カスタムメトリクスの定義は、監視スイートやベンダーによって異なる可能性があることに注意してください。

カスタムメトリクスを使用するタイミング

オートスケーリング

システムを具体的に可視化することで、ワークロードがどのように拡張されるべきかのルールを定義することができます。

水平方向のオートスケーリング：Podのレプリカを追加または削除します
垂直方向のオートスケーリング：コンテナのリミットとリクエストを変更します
クラスターオートスケーリング：クラスター内のノードを追加または削除します

さらに詳しく知りたい方は、Kubernetesのオートスケーリングについてこちらの記事をご覧ください。

レイテンシー監視

レイテンシーは、システムがリクエストに応答するのにかかる時間を測定します。この監視のゴールデンシグナルは、アプリケーションのエンドユーザーエクスペリエンスがどうなっているかを理解するために不可欠です。これらは、Kube State MetricsやNode Exporterから得られるアウトオブボックスのメトリクスセットの一部ではないため、カスタムメトリクスとみなされます。レイテンシーを測定するには、個々のシステム（データベース、API）またはエンドツーエンドのいずれかを追跡するとよいでしょう。

アプリケーションレベルの監視

Kube-state-metricsやnode-exporterは、可観測性のための良い出発点かもしれませんが、ブラックボックス監視を行うため、表面を削るに過ぎません。独自のアプリケーションやサービスをインストルメント化することで、特定のケース向けに精選され、パーソナライズされたメトリクスセットを作成します。

カスタムメトリクスを作成する際の注意点

ネーミング

既存の名前と衝突したり、混乱を招く可能性があるため、ネーミングに関する既存の規約がないか確認します。カスタムメトリクスの名前は、その目的のための最初の説明です。

ラベル

ラベルのおかげで、メトリクスにパラメータを追加することができ、追加の特性を通してフィルタリングし、絞り込むことができるようになります。カーディナリティとは、各ラベルに対して取り得る値の数であり、取り得る値の組み合わせごとに時系列の入力が必要となるため、リソースが大幅に増加する可能性があります。正しいラベルを慎重に選択することが、リソース消費急増の原因の一つであるこのカーディナリティの爆発を回避する鍵となる。

コスト

カスタム・メトリクスは、お客様が使用している監視システムによっては、コストがかかる場合があります。コストを測定するために使用される次元が何であるかを再確認してください。

タイムシリーズの数
ラベルの数
データストレージ

カスタムメトリクスのライフサイクル

カスタムメトリクスがジョブや短命のスクリプトに関連している場合、Pushgatewayの利用を検討します。

Kubernetes メトリクスAPI

Kubernetesの最も重要な機能の1つは、メトリクスの値に基づいてワークロードを自動的にスケールする機能です。メトリクスAPIは、Kubernetesの公式リポジトリで定義されています。

metrics.k8s.io
custom.metrics.k8s.io
external.metrics.k8s.io

新しいメトリクスの作成

以下のようにK8sメトリクスAPIを呼び出すことで、新しいメトリクスを設定することができます：

curl -X POST \
  -H 'Content-Type: application/json' \
  http://localhost:8001/api/v1/namespaces/custom-metrics/services/custom-metrics-apiserver:http/proxy/write-metrics/namespaces/default/services/kubernetes/test-metric \
  --data-raw '"300m"'

Prometheusのカスタムメトリクス

前述の通り、Prometheusインテグレーションに含まれる各エクスポーターは、いくつかのカスタムメトリクスを考慮しています。 Prometheusのメトリクスについては、こちらの記事で詳しく解説しています。

カスタムメトリクスを使用する際の課題

カーディナリティの爆発

メトリクスによって消費されるリソースはごくわずかかもしれませんが、それらがクエリーでラベルとともに使用できるようになった瞬間、手に負えなくなる可能性があります。カーディナリティとは、メトリクスとラベルのカーテシアン積のことを指します。その結果は、その単一のメトリクスに必要な時系列項目の量となります。また、すべてのメトリクスはスクレイピングされ、scrape_interval に基づいて時系列データベースに格納されます。この値が高ければ高いほど、時系列エントリーの量も多くなります。これら全ての要素が最終的にもたらすものは

リソース消費量の増加
ストレージ需要の増大
監視のパフォーマンス低下

さらに、ほとんどの一般的な監視ツールでは、メトリクスの現在のカーディナリティや関連するコストを可視化することはできません。

エクスポーターの使い過ぎ

エクスポーターは、関連するメトリクスをシステムに取り込むための優れた方法です。これを使えば、マイクロサービスやコンテナに関連するメトリクスを簡単にインストルメントすることができます。しかし、大きな力には大きな責任が伴います。パッケージに含まれる多くのメトリクスが、あなたのビジネスに全く関連していない可能性があります。お客様のソリューションでカスタムメトリクスとエクスポーターを有効にすることで、時系列データベースエントリーの量が爆発的に増加することになるかもしれません。

コストの上昇

現在のソリューションが予想以上にリソースを消費していたり、現在の監視ソリューションが特定のしきい値を超えていたりするため、上記で説明した要素により、監視コストが突然増加する可能性があります。

アラート疲労

メトリクスでは、ほとんどの企業や個人が、値が特定のしきい値を超えたときにアラートや通知を追加し始めたいと考えています。しかし、これは通知元の増加や注意力の低下につながる可能性があります。アラート疲労とそれを軽減する方法について、詳しくはこちらをご覧ください。

まとめ

カスタムメトリクスは、ビジネス観測性の核となるものであり、クラウドネイティブ監視の次のステップとなるものです。Prometheusをkube-state-metricsとnode exporterに沿って使用することは良い出発点ですが、最終的には企業や組織は次のステップを踏み、ニーズに合わせてカスタマイズされた的確なメトリクスを作成する必要があります。