常见问题¶

版本选择与结算方式¶

会话重放能否像日志那样单独设置 3 天或 7 天的存储时长？

这取决于您的版本：

• 商业版：不支持。会话重放数据存储策略与用户访问监测（RUM）绑定，统一使用 RUM 的存储策略（3 天/7 天/14 天），无法单独调整。
• 部署版：支持在管理后台单独配置会话重放的存储策略。

我的业务主要在中国区，但部分用户在海外，结算时该选择人民币还是美元？

观测云存在两套结算中心系统：

币种选择影响发票类型和支付方式，需在注册工作空间时确定。若业务跨多个区域，建议分别创建不同区域的工作空间，各自使用当地币种结算。

已经使用人民币结算一段时间，能否切换为美元结算？

不能直接自助切换。由于涉及不同结算中心系统（中国区 vs 全球区）和账务迁移，需要：

1. 联系客户经理提交币种切换申请
2. 原工作空间的历史账单保持人民币结算
3. 切换后新产生的费用按美元结算

建议切换前结清人民币账户欠款，并评估汇率波动对预算的影响。

我的日志量很大但访问频率低，商业版和企业版哪个更划算？

这取决于您的“写入流量”与“存储总量”的比例关系：

• 商业版：按写入量（条数或流量）+ 存储时长梯度计费。适合数据访问频率高、需要长期存储且需频繁查询的场景。若只是短期存储（3-7天），商业版通常更经济。

• 企业版：按压缩后写入流量 + 存储总量计费，与存储时长无关。适合日志量极大但查询频率低、需要长期归档的场景。即使存储 360 天，单价也不会因时长而梯度上涨，但需持续为存储总量付费。

若您的数据压缩比高（如文本日志可压缩至 20%），且存储周期为 30 天，建议联系客户经理评估企业版方案。

数据存储策略变更¶

将日志存储时长从 14 天缩短到 3 天，为什么账单费用没有立即下降？

这是滚动计费机制导致的。非指标数据（日志、Trace 等）变更策略后：

1. 历史数据：在达到原存储时长（14 天）前继续保留，并按原策略的较高单价计费
2. 新增数据：立即按新策略的较低单价计费

因此，费用下降会有 14 天的过渡期。若需立即降低成本，需手动删除历史数据（但将导致数据丢失）。

指标数据存储策略变更后，旧数据会立即删除，费用立即下降，但数据不可恢复。

同一天多次修改存储策略，以哪次为准？

当天首次修改立即生效，后续修改次日生效。

场景示例：

• 09:00：将日志从 14 天改为 7 天 → 立即生效，当天开始按 7 天单价计费
• 15:00：又将日志从 7 天改为 3 天 → 次日 0 点生效，今天仍按 7 天计费

建议一天内不要多次调整，以免产生混乱的计费记录。

数据存储策略变更后，指标数据和非指标数据的处理为何不同？

• 指标数据：变更后立即生效，旧数据立即删除，不可恢复。这是因为指标数据量大且更新频繁，系统采用即时清理策略。

• 非指标数据（日志、Trace、Profile、RUM 等）：变更后新数据按新策略计费，旧数据保留至原存储周期结束。这是因为非指标数据通常具有审计价值，需保证数据连续性。

缩短指标存储时长可立即降低成本，但缩短非指标存储时长需等待过渡期后才能看到完整降本效果。

开启“自定义多索引”后，为什么存储策略变更只能改“默认”索引，其他索引怎么办？

每个索引独立绑定存储策略。变更步骤：

1. 进入日志 > 索引管理
2. 对每个自定义索引分别设置存储时长
3. 各索引按各自的时长策略计费

若某自定义索引未单独设置策略，默认继承 default 索引的策略。但计费时各索引独立统计，不会合并计算。

计费项与计算逻辑¶

商业版中日志按条数计费与按写入流量计费，何时切换更有利？

关键看单条日志的平均大小：

• 单条 < 1KB：按条数计费通常更优（1GB 约 100 万条，按条计费可能只需 1 个单位）
• 单条 > 10KB（ES）或 > 2KB（SLS）：按流量计费更优，避免大日志被拆分多条计费

监控器检测区间设置为 30 分钟，任务调用是计算 2 次（30/15）还是 6 次（基础 5 次 + 1 次超出）？

后者正确。计费公式为：

总次数 = 检测类型基础次数 + ⌈(检测区间 - 15分钟) / 15分钟⌉

对于“突变检测”（基础 5 次），30 分钟区间：

• 基础：5 次
• 超出部分：(30-15)/15 = 1，向上取整为 1 次
• 总计：6 次

为什么智能监控的“用户访问智能检测”比“主机智能检测”贵 10 倍？

因为计费系数不同：

• 主机/日志/应用智能检测：10 次/执行
• 用户访问智能检测：100 次/执行

这是由于用户访问数据量通常更大、计算复杂度更高。若预算有限，建议优先使用主机智能检测，或通过监控器自定义检测规则替代智能检测。

链路数据有时按 Trace 计费，有时按 Span 计费，如何预测我的账单？

系统自动选择较优方式：

• 若 Trace 数量 ≥ Span 数量/10，按 Trace 计费（每百万个 Trace）
• 否则按 Span 计费（每千万条 Span）

可查看应用性能监测的服务概览，若平均每个 Trace 包含的 Span 数 > 10，则大概率按 Span 计费；若 < 10，则按 Trace 计费。您可以通过调整采样策略控制 Trace 数量，从而影响计费方式。

升级策略通知每次触发扣 100 次任务调用，是每次发送通知都扣吗？

是的，每命中一次升级策略，在发送通知时记录 100 次任务调用。

商业版中，事件和自建拨测数据为何默认使用日志 default 索引的存储策略？

因为这两类数据物理存储在日志的 default 索引中：

• 事件数据（监控器、SLO、智能巡检产生）存储于 default 索引
• 自建拨测数据通过 DataKit 上报，同样存储于 default 索引

因此它们的存储时长和计费单价继承 default 索引的配置。若需单独调整，目前无法直接为事件或自建拨测设置独立的存储策略，只能通过调整 default 索引的时长间接影响。

例外：观测云节点的拨测数据虽然也存储在 default 索引，但拨测执行本身按拨测次数单独计费，与存储计费是两个维度。

数据拆分与压缩计费¶

超大日志在 ES 和 SLS 存储中的拆分阈值不同，如何计算我的实际条数？

根据您的存储类型分别计算：

ES 存储：

• 单条 ≤ 10 KB：计 1 条
• 单条 > 10 KB：计费条数 = ⌈实际大小/10 KB⌉

示例：15 KB 日志计 2 条，25 KB 计 3 条

SLS 存储：

• 单条 ≤ 2 KB：计 1 条
• 单条 > 2 KB：计费条数 = ⌈实际大小/2 KB⌉

示例：3 KB 日志计 2 条，5 KB 计 3 条

会话重放的 Session 持续 5 小时，被拆分为 2 个计费单位，这两个单位是连续计费还是按实际活跃时间分配？

按向上取整的整数倍计费，与时间分布无关：

计费单位 = ⌈time_spent / 4小时⌉ = ⌈5/4⌉ = 2 个单位

这 2 个单位是一次性计入当天账单，不是按小时分段计费。即使 Session 中间有 1 小时不活跃，只要 time_spent 字段显示总时长为 5 小时，就按 2 个单位计。

Profile 文件超过 300KB 被拆分，是按拆分后的条数分别存储，还是仅计费拆分？

仅计费拆分，存储仍按原始文件。系统会将大 Profile 文件切分为多条记录进行索引和计费（每 300KB 计 1 条），但存储层面仍关联为一次 Profile 采集。这样做是为了避免单条记录过大影响查询性能，同时保证计费与存储资源消耗成正比。

PV 计费中的“取 PV 与 PV/100 较大值”是什么意思？

这是针对低流量场景的保底计费机制：

• 若当天 PV 数为 500，则 500/100=5，取较大值 500，按 500 计费
• 若当天 PV 数为 50，则 50/100=0.5，取较大值 50，仍按 50 计费（不是按 0.5 或 1）

只有当 PV 数 > 100 时，“PV/100” 才会大于 1，此时取 PV 数本身。这个规则主要是为了避免超小流量时的计算精度问题，对正常业务流量（>100 PV/天）无实际影响。

敏感数据扫描中，同一条日志的多个字段脱敏，为什么会产生多次费用？

因为计费基于字段级别的扫描流量：

• 每个需要脱敏的字段都会单独计算原始流量
• 即使这些字段属于同一条日志，也会分别计费

示例：一条 1KB 的日志包含 3 个敏感字段，扫描计费按 3 个字段的总原始流量（可能 > 1KB，取决于字段内容大小）计算，而不是按单条日志 1KB 计算。

版本切换与数据流转¶

体验版升级到商业版后，为什么看不到体验期间的数据？

体验版数据存储在独立实例，升级后：

• DataKit 配置：会自动指向商业版工作空间，数据继续上报
• 历史数据：保留在体验版环境，通常 7 天后自动清理，无法在商业版查看

体验版的历史数据无法迁移到商业版。如需保留，需在升级前通过数据导出功能备份。