feat(monitoring): cut over Grafana to Thanos Querier and shrink Prometheus retention

[outductor]

Summary

#5037 で Thanos Querier / Store / Compactor を立ち上げてから 3 日経過し、smoke test 通過を確認したので 本来のゴール 3 件をまとめて反映 する PR。

変更	内容
(1) Grafana datasource 切替え	Prometheus 直結 (prometheus-kube-prometheus-prometheus:9090) → Thanos Querier 経由 (thanos-query.monitoring:9090)。ダッシュボード側の編集は不要 (UID PBFA97CFB590B2093 のまま、URL だけ変える)
(2) Prometheus retention 縮退	180d / 270GB → 75d / 240GB。当初の目的だった PVC 容量逼迫の根本解消
(3) thanos Application の ignoreDifferences	volumeClaimTemplates[].spec.volumeMode のサーバ側 default 補完による永続 OutOfSync ノイズを抑制

(2) の retention 値の根拠

Garage 側の Thanos object store のカバー開始は 2026-03-01 (Thanos sidecar が prometheus-operator.yaml に追加された日)。それ以前のデータは Garage には存在しない (sidecar 自体が無かったため)。したがって:

• ローカル retention の終端 < 2026-03-01 になると、Querier 経由でも sidecar/store どちらからも取れない欠損期間が発生
• 今日 (2026-05-08) 起点で today - 2026-03-01 ≒ 68 日
• ギャップを避けつつ縮退する下限 = 68 日 + 数日マージン → 75d
• size はピーク約 3.4GB/日 × 75 日 ≒ 255GB を少し下回る 240GB

将来 (1ヶ月後など) に再評価して、Garage カバー期間が伸びていれば retention をさらに縮められる (例えば 2026-06 時点で 45d 程度まで)。

(1) の効果と影響

• 追加で見えるようになるもの: Garage 上に蓄積した過去 ~70 日分のメトリクス (Querier が store gateway を fan-out するため、retention で消えた範囲も透過的に見える)
• HA 化への布石: 将来 Prometheus を冗長化したとき、Querier 側で --query.replica-label=prometheus_replica で dedup する仕組みが既に動く
• 影響範囲: Grafana のすべてのダッシュボードと recording rule 評価。datasource UID は変えていないので、ダッシュボード側の edit 不要

(3) の背景

/api/v1/stores で StoreAPI 接続は確認済みだが、ArgoCD が StatefulSet を OutOfSync と表示し続けていた。原因は volumeClaimTemplates[].spec.volumeMode が jsonnet 側で未指定 → server-side で Filesystem が default 補完される → ArgoCD diff が永続発生。実害無いが運用ノイズなので抑制。

(本来は thanos-config 側で明示するのが筋だが、retention 縮退と切り離す方が PR が clean なので ArgoCD ignoreDifferences 側で対処。thanos-config 側に明示する追従 PR は別途出すかどうか相談)

切替え手順 / Test plan

• Grafana 任意ダッシュボード (例: https://grafana.onp-k8s.admin.seichi.click/d/minecraft-servers/minecraft-servers) で過去 1 時間のメトリクスが従来通り表示される
• 同ダッシュボードで時間範囲を 60 日 / 70 日に拡大しても穴なくグラフが描画される (sidecar + store 統合の検証)
• kubectl -n monitoring get pvc prometheus-prometheus-kube-prometheus-prometheus-db-prometheus-prometheus-kube-prometheus-prometheus-0 の使用量が compaction 経由で時間とともに減少していく (今 300GB 使用、最終的に 240GB 弱に収束する見込み)
• ArgoCD で thanos Application が Synced/Healthy になる (現在 OutOfSync/Healthy)
• Prometheus rule の評価が引き続き走る (recording / alert ルールはすべて Querier 経由の評価ではなく、Prometheus 自身の評価なので影響なし、念のため確認)

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the Prometheus configuration to route Grafana queries through Thanos Querier and adjusts local retention settings to align with the Thanos object store's coverage start date. Additionally, it configures ArgoCD to ignore default volumeMode differences in Thanos StatefulSets to prevent persistent OutOfSync states. Feedback suggests increasing the retentionSize to 260GB to ensure the 75-day time-based retention is not preempted by size-based purging, which could otherwise create data gaps between local storage and the long-term store.

[gemini-code-assist]

PRの説明にある「ピーク約 3.4GB/日」という数値に基づくと、retentionSize: "240GB" は約 70.5 日分（240 / 3.4）の保持に相当します。これは設定されている retention: 75d よりも短いため、時間ベースの保持期間に達する前にサイズベースの削除が優先される可能性が高いです。

Garage のカバー開始（2026-03-01）から本日（2026-05-08）までの経過日数が約 68 日であることを考えると、マージンが 2.5 日程度しかなく、将来的にインジェスト量が増加した場合に 68 日を下回り、Thanos Querier 経由で見た際にデータの欠損（ギャップ）が生じるリスクがあります。

PVC サイズが 300Gi（約 322GB）であることを踏まえ、WAL 等のオーバーヘッドを考慮しても retentionSize を 260GB 程度に引き上げ、時間ベースの 75d が優先的に機能するように調整することを検討してください。

            retention: 75d
            retentionSize: "260GB"