oodle-drop-rules

Oodle ドロップルール — コスト管理

このスキルでは、大量のメトリクスを安全にドロップする方法を説明します。まず影響を見積もり、最初は範囲を絞ったルールを設定し、ダッシュボードが依存しているメトリクスを気づかれないまま削除しないようにします。サンプリングモードはありません。ルールに一致するすべての時系列がドロップされ、ドロップされたデータは復元できません。

前提条件

brew install oodle-ai/oodle/oodle
oodle configure

ドロップルールのエンドポイントが動作することを確認します。

oodle drop-rules list -o json | jq 'length'

コマンドの実行順序

oodle コマンドを実行する前に、次の手順を行います。

1. 対象のメトリクスプレフィックスとマッチャーがすでにコンテキストにあるか確認します。
2. なければ、oodle metrics query --query 'count({__name__=~"<prefix>.*"})' -o json を実行して影響を見積もります。
3. 影響を受ける時系列に重要なダッシュボードやモニターが依存していないことを確認します（「ルール作成前の影響の見積もり」を参照）。
4. 最初の試行では範囲を絞ったルール（1 つのメトリクスと、本番以外の 1 つの env）から始め、その環境のダッシュボードやモニターに問題がないことを確認してから filters の範囲を広げます。
5. oodle drop-rules create -f rule.json を実行します。

クイックリファレンス

タスク	コマンド
ルールの一覧表示	oodle drop-rules list -o json
ルールの取得	oodle drop-rules get <id> -o json
ルールの作成	oodle drop-rules create -f rule.json
ルールの更新	oodle drop-rules update <id> -f rule.json
ルールの削除	oodle drop-rules delete <id> --force

よく使う操作

ルールのスキーマ

{
  "rule_name": "drop-noisy-debug-metrics",
  "metric_name": {"type": 2, "name": "__name__", "value": "debug_.*"},
  "filters": [
    {"type": 0, "name": "level", "value": "debug"},
    {"type": 0, "name": "env",   "value": "staging"}
  ],
  "type": "series"
}

フィールド	意味
rule_name	必須。ルール名
metric_name	メトリクス名に対するマッチャー（"name": "__name__"）
filters	ラベルマッチャー。ルールが適用されるにはすべて一致する必要があります（論理 AND）
type	必須。"series" である必要があります

マッチャーの type：0 は等しい、1 は等しくない、2 は正規表現に一致、3 は正規表現に一致しない、を表します。

ルール作成前の影響の見積もり

# ✅ CORRECT — count series that will be affected
oodle metrics query --query 'count({__name__=~"debug_.*"})' -o json

# ✅ CORRECT — confirm no dashboard panel queries the metric (list has no panels; get each dashboard)
for uid in $(oodle dashboards list -o json | jq -r '.[].uid'); do
  oodle dashboards get "$uid" -o json | grep -q 'debug_traffic_total' && echo "$uid"
done

# ✅ CORRECT — confirm no monitor depends on it
oodle monitors list -o json | jq '.[] | select(.promql_query | contains("debug_traffic_total"))'

# ❌ WRONG — create the rule first, find out from on-call later
oodle drop-rules create -f rule.json

範囲を絞ったルールの作成（より安全な最初のステップ）

{
  "rule_name": "drop-debug-traffic-staging",
  "metric_name": {"type": 0, "name": "__name__", "value": "debug_traffic_total"},
  "filters": [
    {"type": 0, "name": "env", "value": "staging"}
  ],
  "type": "series"
}

# ✅ CORRECT — one metric in staging; observe for a week before widening
oodle drop-rules create -f rule.json

ルールの範囲を広げる

# ✅ CORRECT — get → change filters → update
oodle drop-rules get dr_123 -o json > rule.json
jq '.filters = [{"type": 2, "name": "env", "value": "staging|dev"}]' rule.json > rule.new.json
oodle drop-rules update dr_123 -f rule.new.json

# ❌ WRONG — partial payload nulls metric_name and filters
oodle drop-rules update dr_123 -f <(echo '{"filters":[]}')

削除（取り込みの再有効化）

# ✅ CORRECT
oodle drop-rules get dr_123 -o json > /dev/null
oodle drop-rules delete dr_123 --force

# ❌ WRONG — speculative delete by name match
oodle drop-rules delete "$(oodle drop-rules list | grep debug | awk '{print $1}')" --force

ベストプラクティス

ルール作成前に oodle metrics query --query 'count({__name__=~"<prefix>.*"})' で影響を見積もる

想定より多くの時系列に一致するドロップルールは、重要なシグナルを隠してしまう可能性があります。

# ✅ CORRECT
oodle metrics query --query 'count({__name__=~"kube_pod_.*"})' -o json | jq -r '.data.result[0].value[1]'
# 1742 series — confirm with the team that all 1742 are safe to drop before creating a rule

# ❌ WRONG — create rule based on a guess; later discover a critical metric was matched
oodle drop-rules create -f rule.json

最初の反復では、本番以外の env で範囲を絞ったルールから始める

サンプリングモードはありません。最初に範囲を絞ったルールを使うことで、すべての環境でドロップする前に、そのメトリクスの価値が本当に低いことを確認できます。

# ✅ CORRECT — week 1: drop in staging only, observe dashboards
"filters": [{"type": 0, "name": "env", "value": "staging"}]
# week 2: if no dashboards or monitors regressed, widen the filters

# ❌ WRONG — drop everywhere on first attempt; can break a dashboard nobody remembered
"filters": []

マッチャーには必ず env と service（または正確な metric_name）の両方を含める

{level: debug} のみのような広範なマッチャーは、たまたま同じラベルを持つ本番メトリクスにも一致する可能性があります。

# ✅ CORRECT — scoped to one env
"filters": [{"type":0,"name":"level","value":"debug"},{"type":0,"name":"env","value":"staging"}]

# ❌ WRONG — also drops debug metrics in prod
"filters": [{"type":0,"name":"level","value":"debug"}]

フィールドを保持するため、必ず update の前に get を実行する

更新はドキュメント全体を置き換えます。

# ✅ CORRECT
oodle drop-rules get dr_123 -o json > rule.json
jq '.filters += [{"type": 0, "name": "service", "value": "api"}]' rule.json > rule.new.json
oodle drop-rules update dr_123 -f rule.new.json

# ❌ WRONG — drops metric_name and type
oodle drop-rules update dr_123 -f <(echo '{"filters":[{"type":0,"name":"service","value":"api"}]}')

ルール名には drop-<metric-or-domain>-<scope> を使う

一貫性のある名前を付けると、ダッシュボードに問題が起きた際にルールを見つけて元に戻しやすくなります。

# ✅ CORRECT
"rule_name": "drop-debug-metrics-staging"
"rule_name": "drop-kube-pod-info-prod"

# ❌ WRONG
"rule_name": "rule1"

エラーへの対処

エラー	原因	対処方法
401 Unauthorized	API キーが無効、または設定されていません	oodle configure を実行するか、OODLE_API_KEY を設定します
404 Not Found	ドロップルール ID が存在しません	oodle drop-rules list -o json で確認します
connection refused	OODLE_DEPLOYMENT の URL が正しくありません	OODLE_DEPLOYMENT 環境変数を確認します
rule_name cannot be empty	rule_name がありません	rule_name を追加します
type cannot be empty / invalid type "...", must be "series"	type が未設定、または正しくありません	"type": "series" を設定します
ダッシュボードのパネルが突然空になった	ドロップルールがパネルのクエリ対象メトリクスに一致しました	oodle drop-rules list -o json を実行してルールを特定し、削除する（oodle drop-rules delete <id> --force）か、マッチャーの範囲を絞ります
モニターが no data になった	ドロップルールがモニターのメトリクスに一致しました	上記と同じ方法で対処します
コストが減らない	マッチャーが大量の時系列に実際には一致していません	ルールのマッチャーを使って count(...) クエリを再実行し、ラベルセットを比較します
429 Too Many Requests	ドロップルールを一括同期しています	--retries 3 を追加し、作成速度を 1 秒あたり 10 件未満に抑えます

References

• Oodle CLI repo
• Oodle docs