Communityライティング&編集github.com

PixiBixi/claude-skills - Thanos デプロイメントレビュー

Thanos デプロイメント(Helm values、マニフェスト、コンポーネントフラグ、アラートルール、キャッシュ設定)のレビュー、作成、規模見積もり、またはThanos読み取りパスの飽和診断(ストアゲートウェイゲートのピン留め、遅いグローバルクエリ、アイドル後の最初のクエリが終わらない、ReceiveのOOM、絶対または常に発報するコンパクターアラート、Redis/Memcached/Dragonflyのキャッシュサイジング)に使用します。

claude-skills - Thanos デプロイメントレビュー とは?

このスキルは、Thanos デプロイメントのレビューと診断を自動化するためのものです。GKE上でグローバルクエリアの背後に20のシングルテナントThanosスタックを運用した経験から得られた、100以上のルール(R1-R102)に基づいています。ルールはフラグ、デフォルト値、メトリクス、アンカーを含み、`references/rules.md`に全文が記載されています。主な機能は、コンポーネントごとのチェックリスト(クエリア、ストアゲートウェイ、キャッシュ、Receive、コンパクター)と読み取りパス飽和の診断手順(D1-D10)です。このスキルは、データ損失や無音の誤った結果、ダウンタイムリスク、コスト、衛生状態をランク付けして報告します。並行性不変条件の計算や、キャッシュサイジングの実用的なガイダンス(ワーキングセットベース、Redisの分離など)も提供します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/PixiBixi/claude-skills/tree/HEAD/plugins/wiki/skills/reviewing-thanos-deployments

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Thanos デプロイメントのレビュー

GKE上のグローバルクエリアの背後で約20のシングルテナントThanosスタック(Thanos 0.42、キャッシュ0.35+)を運用して得たフィールドルール。数値と理由を含む信頼できる情報源:

完全なルールセット(R1-R102、フラグ、デフォルト値、メトリクス、アンカー)は references/rules.md にあります。変更が影響する各コンポーネントのセクションを結論を出す前に読んでください。

レビュー手順

  1. Thanosのバージョン(イメージタグ)を確認します。フラグとデフォルト値は変更されます:すべてのフラグをバージョンに対して確認します(ルールR92)。
  2. ラッパーチャート(bitnami thanos、ローカルの umbrella chart、手書きの extraFlags/args)を使用する場合、レンダリングされたマニフェスト(スタックごとに helm template)でフラグを読み取ります。valuesファイルではありません。レイヤーが互いに上書きし合い、一部のフラグはテンプレートにのみ存在します。
  3. デプロイメント固有の名前(ラベルがプルーニングされるスタック、テナントラベル、クラスタまたはデータセンターラベル)は設定自体から取得します。差分に表示されない場合は、名前を推測せずにGitOpsリポジトリを尋ねてください。
  4. 存在する各コンポーネントについて、以下のチェックリストを実行し、その後 references/rules.md の該当セクションを参照します。
  5. 4つのフラグのいずれかが設定されているか、デフォルトのままになっている場合は、実際の値を使用して並行性不変条件を計算します。
  6. アラートルールを、コンポーネントが実際にどのように実行されるか(CronJob、スポット、Pendingポッド)に対して確認します。
  7. 以下の出力形式で報告します。

コンポーネント別チェックリスト

並行性不変条件(クエリフロントエンド + クエリア + ストアゲートウェイ)。 --query-range.max-query-parallelism(デフォルト14) x min(selectors, --query.max-concurrent-select)(デフォルト4)は、min(--store.grpc.series-max-concurrency, --query.max-concurrent)(両方ともデフォルト20)未満に保たれなければなりません。デフォルトですでにこれを破っています(56 vs 20)。並列性だけがゲートキャップに達すると、1つのクエリですべてのスタックのゲートが飽和します。--query.max-concurrent-select を4より大幅に上げるとキャップがなくなります:乗数が生のセレクタ数になります。OOMキル後に設定されたストアゲートウェイRSSをバインドするようにサイジングされたゲートはメモリ境界であり、それを維持します。この不変条件は幅広いクエリにバインドします:測定されたクエリは平均1.5セレクタであり、ゲート飽和は1つの幅広いクエリではなく、履歴シャードに対する複数の同時クエリから発生しました。グローバルクエリアはStoreAPIを介して地域クエリアに到達しますが、これはそれらのPromQLゲートをバイパスします。両方の乗数を一緒に修正し、グローバルフロントエンドも含め、--query.max-concurrent をクエリアプール全体で計算し、各乗数に、それが尊重しなければならないダウンストリームのキャップをコメントします。

クエリア。

  • 部分応答はデフォルトでオンです(--query.partial-response のデフォルトは true):フラグがないことは安全なデフォルトではありません。エラーを起こしたストアをドロップしますが、遅いストアはドロップしません:--store.response-timeout のデフォルトは 0ms(無効)であるため、1つの遅いストアは、ドロップされる代わりに --query.timeout(デフォルト2m)でクエリ全体を失敗させます。
  • ルーラーやアラートで使用されるクエリアで部分応答を有効にすると、アラートが黙って失われる可能性があり、部分応答は決してキャッシュされません。人間向けのGrafanaデータソースでのみ、リクエストごとに有効にしてください。
  • --selector-label はテンプレートのデフォルトにしてはいけません:ラベルの2つの値を取り込むスタックは、2番目の値に対してEMPTYを返します(データの無音損失)。スタックごとにオプトインし、クエリが実際に運ぶ単一値のラベルを設定します。設定されているすべてのスタックを、そのスタックが実際に取り込むものと照らし合わせて確認してください。
  • --grpc-compression はv0.43.0以降で非推奨です。後継の client_config.compression は --endpoint.sd-config 内のエンドポイントごとに設定しますが、そのエンドポイントも独自の tls_config(例:enabled: false)を設定しない限り無視されます:それ以外の場合はグローバルフラグが優先されます。

ストアゲートウェイ。

  • 飽和を治すために --store.grpc.series-max-concurrency を決して上げないでください:ゲートはキューイングを行い、拒否はしません。飽和はタイムアウトとして現れ、ほとんどの分はキャップをはるかに下回っており、それを上げるとスパイク中の唯一の境界が取り除かれます。クエリフロントエンドのスローログでクライアントを見つけてください。
  • --store.limits.request-series=2000000 はコピーされた値で、決して発動しません(測定された最大呼び出し:200000シリーズ)。最初に thanos_bucket_store_series_data_touched_bucket{data_type="series"} を測定してください。
  • thanos_bucket_store_queries_dropped_total が0であっても何も証明しません:デフォルトで0(オフ)のリミッターのみをカウントします。
  • タイムシャードは重複しなければなりません;突き合わせた --min-time/--max-time 境界は、レプリカが欠落している場合にブラインドウィンドウを保証します。--min-time は最も古い境界です。正の --max-time(例:3h)は上限ではありません:シャードはReceiveの上に、現在までを提供します。
  • ノードのブートディスクに emptyDir を配置しないでください:インデックスヘッダーのダウンロードがそれを飽和させます(復旧に30分)。プロビジョニングされたIOPS/スループットを持つ専用PVCを使用してください;Hyperdisk Balancedでは容量はパフォーマンスを購入しません。
  • キャッシングバケットの背後では、デフォルトの15mより低い --sync-block-duration はほとんどコストがかかりません(それに依存するのは iter 呼び出しのみ、測定されたフリート全体で約1 USD/月):専用のロールアウトには価値がなく、次の計画された再起動時に修正します。
  • Lazyリーダーは維持し、lazyインデックスヘッダーダウンロードは決して行わないでください(p99 ~224秒)。デフォルトの5mアイドルタイムアウトでは、各ギャップ後の最初のクエリは完全なリロードを支払います;隠しフラグ --store.index-header-lazy-reader-idle-timeout を稼働日(10h)に上げると、1つのスタックでロード時間が84%削減されましたが、常駐メモリが犠牲になります。隠しフラグ:アップグレード時に再確認してください。

キャッシュ。

  • Thanos < v0.35.0 でのテナント間の共有キャッシングバケット:キー衝突、ストアゲートウェイは Ready のままで履歴データを提供しません。Redis prefix は任意のバージョンで分離します。シングルテナントのカナリアではそれを捕捉できません。
  • 同じRedis上のインデックスキャッシュとキャッシングバケット:別の db(インデックス db: 1)。
  • インメモリキャッシュサイズから共有キャッシュをサイジングしないでください(ポッドのアップタイムを測定します)。TTLウィンドウ(明示的なステップを持つローリング >= 24 hサブクエリのP95)上のワーキングセットに基づいてサイジングし、シャードのレプリカ間の測定された重複で割り、決してポッド数では割らないでください。レプリカは同じブロックをロードしますが、異なるチャンクをキャッシュします:2つのレプリカで測定されたのは1.4、2ではありません。
  • キャッシングバケットのサブレンジは24時間存続します(chunk_subrange_ttl);Redis expiration はそれらを管理しません。
  • クエリフロントエンドキャッシュファイルは厳密に解析されます:ttl なし、enabled_items なし、TTLは config: の下の expiration です。未知のキー:コンポーネントは起動を拒否します。
  • Sentinelの背後にあるRedis:Sentinelサービス + master_name、そうでなければフェイルオーバー後に書き込みが古いマスターに送られます。

Receive。

  • 専用の優先クラスを持つオンデマンドのままにします:まだアップロードされていないデータを保持する唯一のコンポーネントです。他のすべてはスポットに配置します。
  • メモリ制限をピークアクティブシリーズにサイジングします。head_series_limit は共有マルチテナントReceiveまたはレプリケーションがある場合にのみ効果を発揮します:1つのレプリカでは、429はテナントのすべての書き込みをブロックし、OOMは再起動とWALリプレイのみをコストとします。到達可能な meta_monitoring_url がなければ無効です。リクエスト制限は413を返し(Prometheusはデータをドロップします)、シリーズ制限は429を返します(リトライされます)。
  • プールサイズが変更される場合は、hashmod ではなくKetamaハッシュリング。
  • Goヒープをバインドします:ポッドメモリ制限からの GOMEMLIMIT、または --enable-auto-gomemlimit(デフォルトではオフ、コンテナ制限の0.9)。Goは1.25以降、cgroupからGOMAXPROCSを設定しますが、GOMEMLIMITは決して設定しません。ReceiveのOOMは、再び提供する前のWALリプレイを意味します。

コンパクター。

  • CronJobとして:concurrencyPolicy: Forbid は必須です(1つのバケット上の2つのコンパクターはブロックを破損します)。
  • thanos_compact_todo_* ゲージは --wait でのみ登録されます:CronJobモードでは、それらのアラートは決して発報しません。標準の ThanosCompactIsDown は23時間/24時間発報します。kube-state-metricsのCronJobルールとストアゲートウェイの thanos_blocks_meta_synced バックログプロキシに置き換えてください。コンパクターメトリクス(thanos_compact_group_compactions_failures_total...)のアラートは、CronJobモードでは決して発報しません:実行間にスクレイプターゲットがありません。
  • Thanosバケットにバケットライフサイクルルールやアーカイブストレージクラスを決して設定しないでください:コンパクターのみがブロックの依存関係を知っています;リトライループがAPIコストを節約額の10倍に増やしました。
  • 保持階層は、ストアゲートウェイが提供するものに合わせます。

横断的。

  • スタックのすべてのコンポーネントを1つのゾーンに配置します:ゾーン間トラフィックはデータパスのすべての矢印で課金されます。スタックにゾーン分散制約を設定することはコストバグであり、そうでないと明記する意図的なトレードオフです。
  • for: 30m を持つStatefulSetの desired vs ready レプリカに関するストア準備完了アラート:up == 0 は退避されたPendingポッドに対して決して発報せず、for: 5m は通常のスポット復旧時にページングします。

飽和の診断

references/rules.md の手順D1-D10を使用します。D1の中核:in_flight = throughput x duration(リトルの法則)、ポッドごとに測定;通常はdurationが支配的です(フィールドではx190 vs x4.5)。max_over_time(...[$__interval:1m]) でゲートパネルを読み取り、p999/p9999のレイテンシ、count(group by (pod) (up == 1)) でフリートサイズを確認します。

出力形式

重大度でランク付けされた所見:データ損失または無音の誤った結果、次にダウンタイムリスク(コンポーネントが起動を拒否する設定はここにカウント)、次にコスト、次に衛生状態。各所見:

  • フィールドまたはフラグ、該当行
  • 問題とその具体的な結果
  • 修正、正確な値またはスニペットとして
  • references/rules.md からコピーしたアンカー付きのwiki URL(ルールIDは内部的なもので、含めないでください)

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

関連スキル