Axiom Cost Control

Axiom 使用最適化のためのダッシュボード、モニター、および廃棄物の特定。

開始する前に

1. 必要なスキルを読み込みます:

   skill: axiom-sre
   skill: building-dashboards
   

   building-dashboards は以下を提供します: dashboard-list, dashboard-get, dashboard-create, dashboard-update, dashboard-delete

2. 監査データセットを見つけます。まず axiom-audit を試してください:

   ['axiom-audit']
   | where _time > ago(1h)
   | summarize count() by action
   | where action in ('usageCalculated', 'runAPLQueryCost')
   

   • 見つからない → ユーザーに確認してください。一般的な名前: axiom-audit-logs-view, audit-logs
   • 見つかったが usageCalculated イベントがない → 間違ったデータセット、ユーザーに確認してください

3. axiom-history へのアクセスを確認します (Phase 4 に必須):

   ['axiom-history'] | where _time > ago(1h) | take 1
   

   見つからない場合、Phase 4 の最適化は機能しません。

4. ユーザーに確認します:

   • デプロイメント名は?
   • 監査データセット名は?
   • 契約制限は TB/日? (Phase 3 モニターに必須)

5. 以下のすべてのコマンドで <deployment> と <audit-dataset> を置き換えます。

ヒント:

• -h オプション付きでスクリプトを実行すると、完全な使用方法が表示されます
• スクリプト出力を head または tail にパイプしないでください — SIGPIPE エラーが発生します
• JSON パースに jq が必要です
• 直接 CLI ではなく axiom-sre の axiom-query をアドホック APL に使用してください

どの Phase を実行するか

ユーザーリクエスト	実行する Phase
「コストを削減したい」 / 「無駄を見つけたい」	0 → 1 → 4
「コスト管理をセットアップしたい」	0 → 1 → 2 → 3
「ダッシュボードをデプロイしたい」	0 → 2
「モニターを作成したい」	0 → 3
「ドリフトをチェックしたい」	0 のみ

---

Phase 0: 既存セットアップの確認

# 既存ダッシュボード?
dashboard-list <deployment> | grep -i cost

# 既存モニター?
axiom-api <deployment> GET "/v2/monitors" | jq -r '.[] | select(.name | startswith("Cost Control:")) | "\(.id)\t\(.name)"'

見つかった場合は dashboard-get で取得し、templates/dashboard.json と比較してドリフトをチェックします。

---

Phase 1: 発見

scripts/baseline-stats -d <deployment> -a <audit-dataset>

日単位のインジェスト統計をキャプチャし、Analysis Queue (Phase 4 に必要) を作成します。

---

Phase 2: ダッシュボード

scripts/deploy-dashboard -d <deployment> -a <audit-dataset>

インジェストトレンド、バーン率、予測、廃棄物の候補、トップユーザーを含むダッシュボードを作成します。詳細は reference/dashboard-panels.md を参照してください。

---

Phase 3: モニター

契約が必須です。 プリフライトステップ 4 から契約制限を取得する必要があります。

ステップ 1: 利用可能な通知者をリストします

scripts/list-notifiers -d <deployment>

リストをユーザーに提示し、どの通知者をコスト警告に使用したいかを確認してください。 通知を望まない場合は、-n なしで続行してください。

ステップ 2: モニターを作成します

scripts/create-monitors -d <deployment> -a <audit-dataset> -c <contract_tb> [-n <notifier_id>]

3 つのモニターを作成します:

1. Total Ingest Guard — 日単位のインジェストが契約の 1.2 倍を超える、または 7 日間の平均がベースラインから 15% 以上成長した場合にアラート
2. Per-Dataset Spike — 堅牢な z スコア検出、データセットごとの帰属を伴うアラート
3. Query Cost Spike — 強化された z スコア、30 日ベースライン、5 日間の除外ギャップ、永続性ベースのゲーティング (median_z > 3, p25_z > 2.5)

スパイクモニターは notifyByGroup: true を使用するため、各データセットが個別のアラートをトリガーします。

閾値の導出については reference/monitor-strategy.md を参照してください。

---

Phase 4: 最適化

Analysis Queue を取得します

まだ実行していない場合は scripts/baseline-stats を実行してください。優先順位付きリストを出力します:

優先度	意味
P0⛔	インジェストのトップ 3、または総量の 10% 以上 — 必須
P1	クエリされていない — 削除の有力候補
P2	ほとんどクエリされていない (Work/GB < 100) — 無駄の可能性あり

Work/GB = クエリコスト (GB·ms) / インジェスト (GB)。低いほど = データからの価値が少ない。

データセットを順番に分析します

トップから順に進めてください。各データセットについて:

ステップ 1: 列分析

scripts/analyze-query-coverage -d <deployment> -D <dataset> -a <audit-dataset>

クエリが 0 件 → DROP を推奨、次に進みます。

ステップ 2: フィールド値分析

提案されたリストからフィールドを選択します (通常は app, service, または kubernetes.labels.app):

scripts/analyze-query-coverage -d <deployment> -D <dataset> -a <audit-dataset> -f <field>

高ボリュームだがクエリされていない値を記録します (⚠️ マーク)。

ステップ 3: 空の値を処理します

(empty) のボリュームが 5% を超える場合、別のフィールド (例: kubernetes.namespace_name) でドリルダウンする必要があります。

ステップ 4: 推奨事項を記録します

各データセットについて以下を記録します: 名前、インジェストボリューム、Work/GB、クエリされていない値の上位、アクション (DROP/SAMPLE/KEEP)、推定削減量。

完了条件

すべての P0⛔ と P1 データセットが分析されたら、reference/analysis-report-template.md を使用してレポートをコンパイルします。

---

---

クリーンアップ

# モニターを削除
axiom-api <deployment> GET "/v2/monitors" | jq -r '.[] | select(.name | startswith("Cost Control:")) | "\(.id)\t\(.name)"'
axiom-api <deployment> DELETE "/v2/monitors/<id>"

# ダッシュボードを削除
dashboard-list <deployment> | grep -i cost
dashboard-delete <deployment> <id>

注意: create-monitors を 2 回実行するとデュプリケートが作成されます。再デプロイする場合は、まず既存のモニターを削除してください。

---

リファレンス

監査データセットフィールド

フィールド	説明
action	usageCalculated または runAPLQueryCost
properties.hourly_ingest_bytes	時単位のインジェスト (バイト)
properties.hourly_billable_query_gbms	時単位のクエリコスト
properties.dataset	データセット名
resource.id	組織 ID
actor.email	ユーザーメール

価値分析のための一般的なフィールド

データセットタイプ	プライマリフィールド	代替フィールド
Kubernetes ログ	kubernetes.labels.app	kubernetes.namespace_name, kubernetes.container_name
アプリケーションログ	app または service	level, logger, component
インフラストラクチャ	host	region, instance
トレース	service.name	span.kind, http.route

単位と変換

• スクリプトは TB/日 を使用します
• ダッシュボードフィルターは GB/月 を使用します

契約	TB/日	GB/月
5 PB/月	167	5,000,000
10 PB/月	333	10,000,000
15 PB/月	500	15,000,000

最適化アクション

シグナル	アクション
Work/GB = 0	ドロップまたはインジェスト停止
クエリされていない高ボリュー値	サンプリングまたはログレベルを削減
システムネームスペースから空の値	インジェスト時にフィルタリング、または受け入れ
WoW スパイク	最近のデプロイをチェック