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/day？（Phase 3 监控器必需）

5. 在以下所有命令中替换 <deployment> 和 <audit-dataset>。

提示：

• 使用 -h 运行任意脚本，可查看完整用法
• 不要将脚本输出通过管道传给 head 或 tail — 这会导致 SIGPIPE 错误
• JSON 解析需要 jq
• 临时 APL 查询请使用 axiom-sre 的 axiom-query，不要直接使用 CLI

运行哪些阶段

用户请求	运行这些阶段
“降低成本” / “查找浪费”	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. 查询成本峰值 — 使用强化的 z 分数检测，采用 30 天基线、5 天排除间隔，并根据持续性进行门控（median_z > 3、p25_z > 2.5）

峰值监控器使用 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 两次会创建重复项。重新部署前，请先删除现有监控器。

---

参考资料

审计数据集字段

字段	描述
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/day
• 仪表板筛选器使用 GB/month

合约	TB/day	GB/month
5 PB/month	167	5,000,000
10 PB/month	333	10,000,000
15 PB/month	500	15,000,000

优化措施

信号	措施
Work/GB = 0	丢弃或停止摄取
高流量但未查询的值	采样或降低日志级别
系统命名空间中的空值	在摄取时筛选或接受
WoW 激增	检查近期部署