運用・監視 / 観測性

カーディナリティとは

Cardinality。メトリクスやログのラベル値の組み合わせ数です。多すぎると監視基盤の負荷や費用が急増します。

詳細な図解

ラベル設計と時系列数の増え方

メトリクス値を収集

ラベルmethod/statusなどを付与

時系列数組み合わせごとに系列化

監視基盤保存容量とクエリ負荷へ影響

カーディナリティを、定義だけで終わらせず、現場で出てくる場面、確認材料、見落としやすい点、関連語とのつながりまで順に確認できます。

カーディナリティは、メトリクスやログのラベル値の組み合わせ数です。Prometheusのような時系列監視では、ラベルの組み合わせごとに時系列が増えるため、カーディナリティが高いと保存容量、メモリ、クエリ時間、費用に直結します。

たとえばhttp_requests_totalにmethodとstatusだけなら組み合わせは少なめです。しかしuser_id、request_id、full_urlのような値をラベルに入れると、リクエストごとに時系列が増え、監視基盤が急激に重くなります。

OpenTelemetryを導入した直後、アプリチームが便利なラベルを追加した直後、ログからメトリクスを作り始めた直後に問題化しやすいです。ダッシュボードを詳しくしたつもりが、監視基盤のコスト増やクエリ遅延を招くことがあります。

障害時には、監視基盤そのものが重くなり、見たいメトリクスが見えないという二次被害も起きます。

確認では、メトリクス名ごとの系列数、ラベル一覧、値の種類、増加傾向、保存期間、クエリ頻度を見ます。Prometheusなら高カーディナリティのメトリクスを上位から洗い出し、不要なラベルを削るのが基本です。

ラベルが多いほど分析しやすい、とは限りません。検索したい情報はログへ、集計したい情報はメトリクスへ、という使い分けが必要です。

また、カーディナリティは単なる技術制約ではありません。監視費用、障害時の調査速度、保存期間、個人情報混入のリスクにも関係します。

カーディナリティを管理するには、メトリクス命名規則、許可ラベル、禁止ラベル、レビュー手順を決めます。新しいラベルを追加するときは、値の種類がどれくらい増えるかを見積もり、必要ならログやトレースで代替します。

関連語はメトリクス、Prometheus、OpenTelemetryです。観測性を高めるほどデータ量は増えるため、何を見るためのラベルなのかを常に説明できる状態にしておくことが大切です。

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。