在需要降低 Axiom 成本时，分析查询与摄取模式…

用于减少 Axiom 成本、发现未使用列或字段值、识别数据浪费并跟踪 ingest 支出。

适用场景

解决思路

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')`。
3. 如果找不到审计数据集，询问用户；常见名称：`axiom-audit-logs-view`、`audit-logs`。
4. 如果找到了但没有 `usageCalculated` 事件，说明数据集错误，询问用户。
5. 验证 `axiom-history` 访问（Phase 4 需要）：`['axiom-history'] | where _time > ago(1h) | take 1`；如果找不到，Phase 4 优化将无法工作。
6. 与用户确认：部署名称？审计数据集名称？合同限制（TB/day）？合同限制是 Phase 3 监控所需。
7. 将所有命令中的 `<deployment>` 和 `<audit-dataset>` 替换为实际值。
8. 运行任何脚本时使用 `-h` 查看完整用法。
9. 不要将脚本输出管道到 `head` 或 `tail`，否则会导致 SIGPIPE 错误。
10. 需要 `jq` 解析 JSON。
11. 使用 axiom-sre 的 `axiom-query` 做临时 APL，不要直接用 CLI。
12. 如果用户请求“reduce costs”或“find waste”，运行 Phase 0 → 1 → 4。
13. 如果用户请求“set up cost control”，运行 Phase 0 → 1 → 2 → 3。
14. 如果用户请求“deploy dashboard”，运行 Phase 0 → 2。
15. 如果用户请求“create monitors”，运行 Phase 0 → 3。
16. 如果用户请求“check for drift”，只运行 Phase 0。
17. 检查已有 dashboard：`dashboard-list <deployment> | grep -i cost`。
18. 检查已有 monitors：`axiom-api <deployment> GET "/v2/monitors" | jq -r '.[] | select(.name | startswith("Cost Control:")) | "\(.id)\t\(.name)"'`。
19. 如果找到，使用 `dashboard-get` 获取并与 `templates/dashboard.json` 比较漂移。
20. 运行 `scripts/baseline-stats -d <deployment> -a <audit-dataset>`，捕获每日 ingest 统计并生成 Analysis Queue（Phase 4 需要）。
21. 运行 `scripts/deploy-dashboard -d <deployment> -a <audit-dataset>`，创建包含 ingest 趋势、燃烧率、预测、浪费候选、top users 的 dashboard；详见 `reference/dashboard-panels.md`。
22. 确保已有合同限制（来自 preflight 第 4 步）；合同是必填项。
23. 列出可用 notifiers：`scripts/list-notifiers -d <deployment>`。
24. 向用户展示列表并询问他们想用哪个 notifier 接收成本告警。
25. 如果用户不要通知，继续执行但不带 `-n`。
26. 创建 monitors：`scripts/create-monitors -d <deployment> -a <audit-dataset> -c <contract_tb> [-n <notifier_id>]`。
27. 创建 3 个 monitors：Total Ingest Guard — 当每日 ingest >1.2x 合同或 7 日均值相比 baseline 增长 >15% 时告警。
28. 创建 Per-Dataset Spike — 使用 robust z-score 检测，按数据集告警并归因。
29. 创建 Query Cost Spike — 使用 hardened z-score，带 30d baseline、5d exclusion gap、基于持续性的 gating（median_z > 3, p25_z > 2.5）。
30. spike monitors 使用 `notifyByGroup: true`，使每个数据集触发单独告警。
31. 阈值推导详见 `reference/monitor-strategy.md`。
32. 获取 Analysis Queue：如果尚未运行，运行 `scripts/baseline-stats`；它输出优先级列表。
33. 优先级含义：P0⛔ 按 ingest 前 3 或 >10% 总量 — 强制；P1 从未查询 — 强删除候选；P2 很少查询（Work/GB < 100）— 可能浪费。
34. 计算 Work/GB = query cost (GB·ms) / ingest (GB)；越低表示数据价值越低。
35. 按顺序分析数据集：按 Work/GB 从上到下；对每个数据集执行后续列分析、字段值分析、空值处理和建议记录。
36. Step 1 列分析：`scripts/analyze-query-coverage -d <deployment> -D <dataset> -a <audit-dataset>`；如果 0 次查询，推荐 DROP，继续下一个。
37. Step 2 字段值分析：从建议列表选字段（通常是 `app`、`service` 或 `kubernetes.labels.app`）：`scripts/analyze-query-coverage -d <deployment> -D <dataset> -a <audit-dataset> -f <field>`；记录高 volume 但从未查询的值（⚠️ 标记）。
38. Step 3 处理空值：如果 `(empty)` 占 >5% volume，必须用替代字段（例如 `kubernetes.namespace_name`）深入分析。
39. Step 4 记录建议：对每个数据集记录 name、ingest volume、Work/GB、top unqueried values、action（DROP/SAMPLE/KEEP）、estimated savings。
40. 完成条件：所有 P0⛔ 和 P1 数据集分析完；然后使用 `reference/analysis-report-template.md` 汇总报告。
41. 删除 monitors：先列出 `axiom-api <deployment> GET "/v2/monitors" | jq -r '.[] | select(.name | startswith("Cost Control:")) | "\(.id)\t\(.name)"'`，再执行 `axiom-api <deployment> DELETE "/v2/monitors/<id>"`。
42. 删除 dashboard：先 `dashboard-list <deployment> | grep -i cost`，再 `dashboard-delete <deployment> <id>`。
43. 注意：运行 `create-monitors` 两次会创建重复；重新部署前先删除现有 monitors。
44. 审计数据集字段：`action` 为 `usageCalculated` 或 `runAPLQueryCost`；`properties.hourly_ingest_bytes` 为每小时 ingest 字节；`properties.hourly_billable_query_gbms` 为每小时查询成本；`properties.dataset` 为数据集名；`resource.id` 为 Org ID；`actor.email` 为用户邮箱。
45. 常见值分析字段：Kubernetes logs 用 `kubernetes.labels.app`，替代 `kubernetes.namespace_name`、`kubernetes.container_name`；Application logs 用 `app` 或 `service`，替代 `level`、`logger`、`component`；Infrastructure 用 `host`，替代 `region`、`instance`；Traces 用 `service.name`，替代 `span.kind`、`http.route`。
46. 单位与转换：脚本使用 TB/day；dashboard filter 使用 GB/month。5 PB/month = 167 TB/day = 5,000,000 GB/month；10 PB/month = 333 TB/day = 10,000,000 GB/month；15 PB/month = 500 TB/day = 15,000,000 GB/month。
47. 优化动作：Work/GB = 0 → Drop 或停止 ingest；高 volume 未查询值 → 采样或降低日志级别；来自 system namespaces 的空值 → 在 ingest 时过滤或接受；WoW spike → 检查近期部署。

适用边界 · 注意事项

• 未安装或无法访问 Axiom，且未加载 `axiom-sre`、`building-dashboards` 或缺少 `jq` 时，不应使用。
• 找不到审计数据集、无法确认合同限制（TB/day），或没有 `axiom-history` 访问时，不要运行依赖这些信息的 Phase 3/4。
• 只需要临时 APL 查询、或不想部署 dashboard/monitors 时，不要完整执行所有阶段。