ラベルを消せば本当に集計される？
一言でいうと
ラベルの削除は合算ではなく、up=1は、必要な情報がすべて保存されたことの証明ではありません。元データの意味とクエリの結果を突き合わせる必要があります。
なぜ必要なのか
メトリクスが多すぎるので、ユーザーラベルだけを消せば解決しそうです。12個のカウンターが1つに見えれば、保存コストも減って、作業も終わったように見えます。ところが、合計が78になるはずの実験で、結果が1になりました。ターゲットの状態は相変わらずupで、直近のエラー文字列も空です。画面を緑にすることと、運用者が問う質問を維持することは、別の目標です。この違いは、実際のコレクターを通す前には見落としやすいものです。
どう動くのか
metric_relabel_configsは、収集したサンプルのラベルを書き換えたり、一部のサンプルを除外したりします。labeldropは、指定したラベル名を取り除く動作です。異なるuser_idが区別していたサンプルからそのラベルを消すと、同じ名前で残りのラベルも同じアドレスが衝突します。この作業は、複数のcounterの値を足し合わせる集計演算ではありません。公式ドキュメントも、ラベルを取り除いたあとで時系列の一意性が保たれるかに注意するよう述べています。
今回の固定入力は、ユーザーごとの値が1から12までで、合計は78です。実際のPrometheus 3.14.0のプローブでは、user_idを消したあとの現在の時系列数が1、クエリの合計も1になりました。upは1で、lastErrorは空でした。この結果を「衝突すると常に最初の値が保存される」というAPIの契約に一般化することはしません。バージョンと入力・時刻を固定した今回の観測の核心は、labeldropが78を合算してくれなかったことです。別の入力やバージョンでは、別のエラーや拒否の形が出る可能性があるので、元のレスポンスと実際の結果を直接確認する必要があります。
今回の実験の最初の判定ツールは、衝突すれば必ずup=0になると仮定して、失敗しました。実際の結果が予想と違うからといって、サーバーを強制的にdownにしたりはしませんでした。当時のコードと読み取り専用の観測を残し、新しいVMで入力と結果をあらためて突き合わせました。良い検証とは、自分が期待した状態を作ることではなく、実際に起きたことを説明することです。テストが間違っていたときは、テストの仮定も修正の対象です。
次の修正は、問題のリクエストのメトリクスをまるごとdropすることです。元のレスポンスは相変わらず13サンプルですが、収集後には業務のgaugeが1つだけ残り、上限に収まります。upも再び正常です。しかし、リクエストカウンターのクエリは空のベクトルになります。これをリクエスト0件と報告してはいけません。観測すべき情報がないことと、値が0のサンプルがあることは、違います。フィルターが意図した除外なのか、障害による欠損なのかは、クエリだけでは区別しにくいことがあります。
| 変更 | 画面で良く見える点 | 必ず確認する損失 |
|---|---|---|
| sample_limitを上げる | 収集がまた成功する | ラベルの組み合わせ数が高いまま残る |
| 区別するラベルを削除する | 現在の時系列数が減る | 異なる値の合算と意味の保存が保証されない |
| メトリクスfamilyをすべて除外する | 上限以内で、upも正常である | 必要な業務の質問に答えるメトリクスが消えるかもしれない |
| ソースでディメンションを設計して集計する | 必要な合計を、少ない時系列で公開する | 削除した詳細なディメンションの質問には、もう答えられない |
最後には、エクスポーターの計装モデルを変えます。合成ユーザーごとの詳細な値の代わりに、routeのレベルで集計したカウンター78を公開し、user_idラベルを最初から出力しません。リクエストのcounterが1つと業務のgaugeが1つなので、元のレスポンスの時点から2サンプルです。一時的なフィルターを外し、sample_limitを8に戻しても収集は成功し、リクエストの合計は78のまま維持されます。フィルターの陰で黙って捨てることと、源泉で必要なディメンションを設計することを区別するステップです。
現場での姿
ダッシュボードのsumは、クエリの結果を合算します。そのクエリを保存したからといって、すでに収集したユーザーごとの時系列がTSDBから消えるわけではありません。ラボでは、現在の時系列数と、過去の評価時点のクエリを並べて見ます。改善後の現在は時系列が1つですが、制限を上げて12個を収集した時刻を指定すれば、当時の12個と合計78をもう一度確認できます。series APIのラベル一覧だけで、その時間に実際のサンプルがあったと断定せず、評価時刻を明示した実際のPromQLの結果も一緒に残します。メタデータの一覧と、時系列のサンプルは、同じ証拠ではありません。
このラボでは、TSDBの削除APIを有効にしたり、データを削除したりしません。ソースの計装の修正が、過去の機微な情報を自動で消すと主張しないためです。本番で保持ポリシーや削除を扱うときは、別途、権限・バックアップ・監査・影響範囲を検討する必要があります。ここでは、ユーザーIDがすべて合成値であり、現在の計装の修正と、過去のデータの保存という、異なる問題を安全に区別することに集中します。
現在の情報が正しく保存されているかも、単一の数字で終わらせません。エクスポーターの元のレスポンス、現在適用されている設定、直近のスクレイプの時刻、現在のcounterの合計、独立した対照群を、あわせて読みます。サービスプロセスの実行識別子が維持されているかを確認し、再起動で状態を初期化していないことを記録します。短期のサンプルで正常であることと、長期間のパフォーマンス・損失率を検証したことは違い、この小さな実験は、大規模な負荷テストの代わりにはなりません。
次のラボですること
上限を上げる、衝突するラベルを削除する、メトリクスを除外する、ソースで集計する、を順に比較します。最終レポートには、upだけでは情報の保存を保証できない理由、維持した業務の質問、意図的に捨てた詳細なディメンション、現在の修正では過去が消えないという点を書きます。「収集の成功」と「意味が合っている観測」を別々に検証する習慣が、このラボの成果物です。
公式ドキュメント
- Relabel設定: labeldropのあとの一意性に関する注意を読んでください。
- Prometheus HTTP API: 評価時刻と、ラベルのメタデータAPIを区別してください。
- PromQL集計演算子: クエリの集計が行うことを確認してください。