controlling-costs

Axiom のコスト管理

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 が必要です
• アドホックな APL には、CLI を直接使わず axiom-sre の axiom-query を使用します

実行するフェーズ

ユーザーの依頼	実行するフェーズ
「コストを削減したい」／「無駄を見つけたい」	0 → 1 → 4
「コスト管理を設定したい」	0 → 1 → 2 → 3
「ダッシュボードをデプロイしたい」	0 → 2
「モニターを作成したい」	0 → 3
「ドリフトを確認したい」	0 のみ

---

Phase 0：既存の設定を確認する

# Existing dashboard?
dashboard-list <deployment> | grep -i cost

# Existing monitors?
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>

日次の取り込み統計を記録し、分析キュー（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. 合計取り込み量ガード — 日次取り込み量が契約の 1.2 倍を超えた場合、または 7 日間の平均がベースライン比で 15% を超えて増加した場合にアラートを発します
2. データセット別の急増 — 堅牢な z スコア検出を行い、原因の内訳を含めてデータセットごとにアラートを発します
3. クエリコストの急増 — 30 日間のベースライン、5 日間の除外期間、持続性に基づくゲート条件（median_z > 3、p25_z > 2.5）を用いた強化版 z スコア

急増モニターでは notifyByGroup: true を使用するため、データセットごとに個別のアラートが発生します。

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

---

Phase 4：最適化

分析キューを取得する

まだ実行していない場合は 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 の場合は、削除を推奨して次へ進みます。

ステップ 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 を使ってレポートをまとめます。

---

---

クリーンアップ

# Delete monitors
axiom-api <deployment> GET "/v2/monitors" | jq -r '.[] | select(.name | startswith("Cost Control:")) | "\(.id)\t\(.name)"'
axiom-api <deployment> DELETE "/v2/monitors/<id>"

# Delete dashboard
dashboard-list <deployment> | grep -i cost
dashboard-delete <deployment> <id>

注： create-monitors を 2 回実行すると、重複が作成されます。再デプロイする場合は、先に既存のモニターを削除してください。

---

リファレンス

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

フィールド	説明
action	usageCalculated または runAPLQueryCost
properties.hourly_ingest_bytes	1 時間あたりの取り込み量（バイト）
properties.hourly_billable_query_gbms	1 時間あたりのクエリコスト
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 の急増	最近のデプロイを確認します