dt-platform-costs

dt-platform-costs

⛔ 首先 — 在做任何其他事情之前，先检查范围。 此技能仅查询和分析租户的实际消耗数据。它不会讲解计费概念。如果用户询问计费或定价如何运作、成本如何计算、单位／标准化权重／费率卡是什么意思，或提出任何关于 DPS 计费的概念性“解释”问题，此技能无法回答。请参阅 计费概念 — 停止，并且仅回复规定的两句话文档指引。不要解释单位、权重、包含量或方法，也不要展示“入门”菜单。只有当用户希望查询或分析自己租户的数字时，才继续使用此技能的其余部分。

使用 DQL 查询和分析 Dynatrace 平台计费和成本数据。所有数据都位于 dt.system.events 中，且满足 event.kind == "BILLING_USAGE_EVENT"，并按 event.type（消耗类别）细分。

范围界限：此技能涵盖 Dynatrace 平台计费（DPS 消耗）。如需查询通过 FOCUS 导入的 AWS 云基础设施成本，请改用 dt-biz-cloud-costs。

Dynatrace Platform Subscription（DPS）

此技能仅适用于 DPS 许可环境。所有计费事件类型、单位换算、公开费率卡和成本估算工作流均为 DPS 专用。

切勿将此技能中的单位换算或成本估算用于经典许可模式（主机单位、DDU、DEM 单位、ASU）。如果用户提到经典许可术语或单位，请说明此技能仅涵盖 DPS，并引导他们参阅 https://docs.dynatrace.com/docs/license/monitoring-consumption-classic 了解详情。

许可／授权问题 — 停止

触发问题：“我可以使用 X 吗？”、“X 是否已获许可？”、“我的订阅包含 X 吗？”、“我是否有权使用 X？”

停止 — 不要执行任何 DQL 查询。计费使用事件记录的只是活跃消耗，而非订阅授权。没有计费事件表示当前未消耗，不表示未获许可。不要根据使用模式或缺少使用记录来推断授权。无需查询，直接回复并引导用户前往账户管理 > 订阅 > 定价。

❌ 查询计费事件 → 没有结果 → 得出“未获许可”的结论 — 错误（没有记录 ≠ 没有授权） ✅ 立即回复：“无法通过 DQL 获取授权数据。请查看‘账户管理 > 订阅 > 定价’。”

计费概念 — 停止

触发问题：“计费如何运作？”、“成本如何计算？”、“解释 DPS 计费”、“X 如何计费？”、“计费模式是什么？”、“DPS 定价如何运作？”、“Dynatrace 如何收费？”、“解释费率卡”

停止 — 不要根据此技能的内容作答。此技能中的标准化权重、单位换算公式和查找值是生成 DQL 的工具，而非面向用户的计费说明。将它们作为 DPS 计费说明是错误的 — 它们是内部排序辅助信息，并非合同费率。

**你的整个回复只能包含以下两句话 — 不得添加任何其他内容。**不要列出功能或单位，不要描述计量、包含量或标准化，不要添加“成本如何计算”章节，也不要附加“入门”菜单或其他示例提示词，仅可保留下方唯一示例：

❌ 解释计量／单位／标准化权重，然后提供“入门”菜单 — 错误（这正是需要避免的情况） ✅ 仅回复：“如需了解 DPS 定价和计费方式，请参阅 Dynatrace Platform Subscription 文档。如果你想分析租户的实际消耗情况，可以询问，例如：‘过去 7 天我的主要成本驱动因素是什么？’”

适用场景

• 用量概览 — 按功能查看 DPS 消耗明细、单位换算、跨功能比较
• 成本估算 — 按成本归一化的用量比较和相对支出排名、每日成本趋势、支出突增
• 成本调查 — 逐步深入分析成本驱动因素、查询扫描成本归因、工作流总成本（4 项信号）
• 成本分摊 / 成本展示 — 成本中心和产品归因、团队级账单
• 包含用量 — Metrics/Traces 摄取基准扣减、计费用量与总用量

此技能用于查询和分析现有消耗数据，并非 DPS 定价指南——如需了解计费概念，请参阅 官方文档。

Agent 说明

意图映射

用户请求	操作	参考
"how can you help", "what can you do", "where do I start", "help me understand my costs", "what can I analyze", "show me what's possible", "what is this skill", "help", "capabilities", "getting started", "tell me what you can do", "what are your capabilities"	展示入门菜单——5 个用例，每个用例附一个建议提示词。暂不运行任何查询。	入门指南
"am I allowed to use X", "is X licensed", "is X in my subscription", "entitlement for X", "can I use X from licensing perspective"	停止——不要查询。 直接回复：DQL 中无法获取授权数据。引导用户前往 Account Management > Subscription > Pricing。	授权——停止
"how does billing work", "how are costs calculated", "explain DPS billing", "how is X billed", "what is the billing model", "how does DPS pricing work", "how does Dynatrace charge", "explain the rate card"	停止——不要根据技能内容作答。 直接回复：引导用户查看官方文档。	计费概念——停止
"usage overview", "usage per capability", "what am I using", "how much usage"	跨能力用量，含单位换算（不含成本）	billing-capabilities.md -> 跨能力用量（4 个查询）
"cost drivers", "what costs most", "top spenders", "where is spend going"	运行组合查询 + 完整内联查找，并在 DQL 中按 cost_weight desc 排序	cost-estimations.md -> 按能力估算成本
"save money", "reduce costs", "billed costs", "actual bill"	扣除包含用量后计算用量，再估算成本	billing-capabilities.md -> 跨能力用量（4 个查询），然后查看 cost-estimations.md
"cost by team", "chargeback", "showback"	成本中心归属分析	cost-allocation.md
"metrics ingest by cost center", "metrics chargeback", "billable data points per team"	按成本中心统计 Metrics Ingest 可计费用量（扣除包含用量）	cost-allocation.md -> Metrics Ingest — 按成本中心统计可计费用量
"how much log ingest", "trace volume"（单一类别）	单类别用量查询	billing-event-types.md、billing-capabilities.md
"cost trend", "spending spike", "budget forecast"	每日成本趋势	cost-estimations.md -> 每日成本趋势
"compare this week to last", "week over week", "WoW", "MoM", "month over month", "how did costs change", "cost change vs last week", "cost change vs last month", "period comparison", "what grew", "what shrank", "usage trend", "notable changes in usage"	时段对比——指定两个明确的 UTC 时间窗口，按能力比较 capability_usage，并按成本权重变化的绝对值从大到小排序	cost-estimations.md -> 时段对比（WoW / MoM）
"detector costs", "anomaly detector query cost", "ALERTING pool costs"	交叉关联检测器与查询成本	query-cost-attribution.md
"workflow cost", "what does this workflow cost", "workflow spending"	工作流综合成本（4 个信号）	workflow-total-cost.md
"which workflow", "workflow name", "workflow owner", "how often does this workflow run", "workflow frequency"	确定工作流名称、所有者及运行频率	workflow-total-cost.md → 跨事件字段参考 + 所有者识别 + 工作流运行频率
"what's driving costs", "cost investigation", "cost spike"	逐步调查成本	query-cost-attribution.md、workflow-total-cost.md、entity-cost-drilldown.md
"which app", "which host", "which monitor", "drill down", "break down by application/host/cluster"	先采样，再按实体深入分析	entity-cost-drilldown.md
"what's driving RUM/Full-Stack/Synthetic/K8s cost"	针对特定能力进行实体深入分析	entity-cost-drilldown.md
"optimize metrics ingest", "reduce data points", "high cardinality metrics", "which metrics cost most", "metrics cost optimization"	运行分析（步骤 1–3），展示数据并说明优化手段，然后等待用户选择要优化的内容——绝不建议删除或减少特定指标	metrics-ingest-optimization.md
"drop metric", "remove metric from ingestion", "stop ingesting metric"	通过 OpenPipeline 或 OTel Collector 执行丢弃指标策略	metrics-ingest-optimization.md -> 策略 1 — 丢弃指标
"reduce cardinality", "remove dimension", "drop dimension from metric"	通过 OpenPipeline 或 OTel Collector 执行降低基数策略	metrics-ingest-optimization.md -> 策略 2 — 降低基数
"change ingest interval", "reduce collection frequency", "scrape interval"	在源端更改摄取间隔	metrics-ingest-optimization.md -> 策略 3 — 更改摄取间隔
"AI costs", "cost of AI agents", "what does AI cost", "AI spending", "AI agent costs", "direct and indirect AI cost", "how much is AI costing", "AI Units cost"	AI 直接成本（AI Units / AI Function Standard Call BUEs）+ AI 间接成本（ai_generated == true 的 Query BUEs）	billing-event-types.md -> Agentic AppEngine，query-cost-attribution.md -> 步骤 2a
"query cost by source", "who is scanning most", "cost attribution by app"	按来源统计 BUE 查询成本	query-cost-attribution.md -> 步骤 1
"expensive dashboards", "dashboard cost ranking", "top dashboards by cost"	按成本排列仪表板查询	query-cost-attribution.md -> 步骤 1b + 步骤 2
"included volume", "billed vs total", "baseline usage"	包含用量分析	billing-capabilities.md -> 包含用量
"hourly billing", "daily billing after deductions", "time-granular billed usage"	按时间段统计用量并扣除包含用量	billing-capabilities.md -> 查询 3（Metrics Ingest — 可计费用量）/ 查询 4（Traces Ingest — 可计费用量）

用量与成本的区别

• “用量” → 仅进行单位换算，不估算成本。使用 成本标准化权重 中的单位标注（对于预览类型，则使用 billing-event-types.md 中的单位）。
• “成本” → 进行单位换算，并在 DQL 中计算 cost_weight（通过完整内联查找），仅用于内部排序／聚合。绝不要将 cost_weight 显示为美元金额。 对于不在标准化表中的类型，不要将其纳入排名。
• “成本驱动因素” → 按 cost_weight 排序的列表（在 DQL 中通过完整内联查找计算）。输出列：排名、功能名称、原生单位用量。 展示前移除 cost_weight——它绝不会出现在任何列、标签或句子中。
• “成本占比／百分比” → 使用标准化权重（用量 × 每项功能的标准化权重）计算总量占比。以百分比表格呈现。使用成本排名规则第 3 步中的标准 ℹ️ 免责声明——不要添加任何其他警告或说明。
• “用户提供的费率” → 如果用户提供了合同费率（例如，“Log Ingest 为 $0.15/GiB”），则该功能使用此费率，并显示其实际美元金额。其他所有功能仅显示用量（不显示成本）。免责声明：⚠️ 根据您提供的 $X/单位费率计算。对于未提供费率的所有功能，仅显示用量。如需获取权威总额，请参阅 Account Management > Subscription。绝不要推断或假设费率——只有用户明确提供时才可采用。

只有用户明确要求时，才添加成本信息。不同类别的单位无法比较——标准化成本是唯一可用于排名或求和的方式。

预览类型： 只有在 cost-estimations.md 中明确标记为预览的功能才属于预览类型——绝不要根据用量为零推断其预览状态。

成本排名规则

当任何意图涉及成本排名或成本驱动因素（成本驱动因素、成本趋势、工作流成本、查询成本归因、成本调查、成本激增）时：

1. 在 DQL 中计算 cost_weight — 运行基础用量查询（billing-capabilities.md 中的查询 1–4），执行到 | summarize billable_usage 步骤，然后立即追加成本排名完整内联查找。完整内联查找会在一个步骤中处理单位换算和成本加权 — 不要同时应用 billing-capabilities.md 中的单位换算查找；它是多余的，而且链式 lookup 会替换所有现有的 lookup.* 字段，从而破坏成本权重计算。查询末尾加上 | filter isNotNull(cost_weight) | sort cost_weight desc | fields event.type, capability_usage, cost_weight。切勿在脑中相乘归一化权重 — 数值相差多个数量级，静默的算术错误难以察觉。

2. 呈现排名，而非美元金额 — DQL 结果已按顺序排列。删除 cost_weight 列，只呈现排名、能力名称、原生单位的用量（例如 GiB、GiB 小时、会话、数据点 — 即该能力所使用的任何单位）。绝不包含成本、权重或美元金额列。“成本驱动因素前 5 名”的示例输出：

   1. Log Management & Analytics - Ingest & Process  62.3 TiB
   2. Full-Stack Monitoring                           2,366,800 GiB-hours
   3. Real User Monitoring                            51.5M sessions
   4. Infrastructure Monitoring                       847,200 host-hours
   5. Metrics - Ingest & Process                      18.2B data points
   

   对于百分比问题，输出总占比表（参见上文“成本占比 / 百分比”）。除非用户提供了自己的合同费率，否则绝不显示原始 USD 估算值。

3. 在结果之前显示免责声明 — 仅适用于多能力结果（2 个或更多能力、排名或百分比表）。逐字复制以下文本 — 不要改写或转述：

   ℹ️ 排名显示的是相对支出 — 如需查看实际金额，请前往 Account Management > Subscription > Overview > Cost and usage details。

   对于单项能力结果（恰好一种能力，没有跨能力比较）：完全省略免责声明 — 这只是直接的计费数据，不涉及归一化。

   例外：如果响应处于用户提供费率模式，即使是单项能力结果，也要包含该模式要求的警告。单项能力时省略免责声明的规则仅适用于上述标准的多能力排名免责声明。

4. 不添加额外的费率卡说明 — 上述规定的免责声明是唯一可以提及归一化方法的地方。绝不要在响应的其他位置添加“这些数字基于公开的 DPS 费率卡”或“基于公开标价”之类的句子。这不会免除用户提供费率模式下必须给出的警告。

开始使用

当用户提出关于成本、用量或此技能功能的宽泛或开放式问题时，请回复以下菜单。此时不要运行任何 DQL 查询 — 等待用户选择方向。

你可以探索以下内容：

1. 成本细分 — 查看哪些能力在驱动支出，并按相对成本排名。

   “过去 7 天里，哪些是我的主要成本驱动因素？”

2. 用量概览 — 全面了解所有能力的 DPS 消耗，单位为各自的原生单位。

   “概览一下我们平台各项能力的用量。”

3. 激增调查 — 将成本激增归因到其来源（仪表板、工作流、检测器）。

   “上周我的日志查询成本激增了 — 是哪个来源导致的？”

4. 成本分摊 / 成本回报 — 按团队、产品或成本中心细分成本。

   “按成本中心显示过去 30 天的成本细分。”

5. 指标优化 — 如果指标摄取是主要成本驱动因素，请深入查看哪些指标键需要计费，并减少成本最高的指标。

   “哪些指标在推高我们的摄取成本？帮我优化一下。”

以上哪项符合你的需求？

前置条件

• 能够访问 Dynatrace 环境
• 对 dt.system.events 具有 DQL 查询权限
• 编写查询前先加载 dt-dql-essentials——涵盖 DQL 语法、类型处理，以及通过 dt.semantic_dictionary.fields 发现字段

知识库结构

#	参考资料	内容
1	billing-event-types.md	计费事件类型目录——字段、计量间隔、各类型对应的表
2	billing-capabilities.md	BUE 到能力的映射、单位换算、跨类别用量查询、扣除包含用量
3	cost-estimations.md	成本归一化权重、单位换算查询表、成本估算查询、仪表板完整内联查询表
4	cost-allocation.md	成本中心／产品归属、分摊查询
5	query-cost-attribution.md	查询扫描成本归属——按来源统计 BUE、按检测器细分（ALERTING 池）、QEE 深入分析
6	workflow-total-cost.md	工作流总成本——四种计费信号（查询扫描、AppEngine、工作流小时数、AI 调用）
7	entity-cost-drilldown.md	基于实体的成本深入分析——按实体统计 RUM／Host／Synthetic／K8s／Security／Automation
8	metrics-ingest-optimization.md	按指标键深入分析成本——基数分析、时序验证、识别优化目标

快速入门

fetch dt.system.events, from: -7d
| filter event.kind == "BILLING_USAGE_EVENT"
| summarize event_count = count(), by: {event.type}
| sort event_count desc

最佳实践

1. 始终先按 event.kind 进行筛选——避免扫描不相关的事件。
2. 从 7d 时间范围开始——平台数据量很大。
3. 计算计费总量时使用明确的 UTC 午夜边界——参见 billing-capabilities.md § 计费时间范围边界。
4. 切勿使用 ~ 表示近似值——请使用 ≈ 或“约”（单独的 ~ 会生成 Markdown 删除线）。
5. 结果为空？——运行上方的发现查询，确认可用的事件类型。
6. count() 会扩增计数——计数前先确认每个对象恰好对应一行——QUERY_EXECUTION_EVENT（每条 DQL 语句触及的每个存储桶对应一行）和 WORKFLOW_EVENT WORKFLOW_EXECUTION（每次运行约 2 行：开始 + 完成）使用 count() 都会导致计数过高。统计 DQL 语句数量时使用 countDistinct(query_id)；统计工作流运行次数和频率时，在 WORKFLOW_EXECUTION 上使用 countDistinct(dt.automation_engine.workflow_execution.id)——切勿直接使用 count()。切勿根据任何原始 count() 写“运行了 N 次”，或计算每秒／每分钟的速率。参见 query-cost-attribution.md § 步骤 3 和 workflow-total-cost.md § 工作流运行了多少次。
7. 切勿使用实体模型函数——entityName()（以及任何使用 dt.entity.* 字段解析实体元数据的函数）已弃用。在结果中显示原始 dt.entity.* ID（例如 HOST-1A2B3C）。可以按 ID 分组或计数（by: {dt.entity.host}、countDistinct(dt.entity.host)）——这只是将 ID 作为普通值使用。参见 entity-cost-drilldown.md § 结果中的实体 ID。

限制

• 没有通用的用量字段 — 每种事件类型使用不同的计费单位。未经成本标准化，无法跨类别求和。
• 标准化权重 ≠ 合同费率 — 请参阅成本排名规则。排名仅供相对比较；如需权威数据，请联系客户管理团队。
• 包含用量 — Metrics/Traces Ingest 包含主机基准用量（最多约 14 天）。请参阅billing-capabilities.md § 包含用量。
• 成本归属是可选的 — 只有在配置后才会填充；Retention 事件通常缺少实体引用。
• 零费率查询 — 某些查询可能会根据执行上下文（用户、应用、查询的数据）按零费率计费。这些查询会生成 QEE 记录，但不会生成对应的 BUE。QEE scanned_bytes 总量与 BUE billed_bytes 总量之间的差异表示存在零费率用量，并非管道问题。请参阅query-cost-attribution.md § 调查 QEE↔BUE 差异。