LangSmith 自托管允许启用自动 TTL 和跟踪数据保留。如果您需要遵守数据隐私法规，或者想要更有效地利用空间并自动清理跟踪，这将非常有用。跟踪的数据保留期也会根据特定操作或运行规则的应用自动延长。
您可以通过 Helm 或环境变量设置来配置保留。有几个选项可以配置：
- 启用： 数据保留是启用还是禁用。如果启用，您可以通过 UI 设置默认的组织和项目 TTL 层级以应用于跟踪（详见数据保留指南）。
- 保留期： 您可以为短期和长期跟踪配置系统范围的保留期。配置完成后，您可以在每个项目级别管理保留级别，并为新项目设置组织范围的默认值。
config:
ttl:
enabled: true
ttl_period_seconds:
# -- 400 day longlived and 14 day shortlived
longlived: "34560000"
shortlived: "1209600"
ClickHouse TTL 清理作业
从版本 0.11 开始，一个 cron 作业会在周末运行，以协助删除 ClickHouse 内置 TTL 机制可能未清理的过期数据。
此作业使用可能长时间运行的变异（`ALTER TABLE DELETE`），这些操作是开销很大的操作，可能会影响 ClickHouse 的性能。我们建议仅在非高峰时段（夜间和周末）运行这些操作。在测试 1 个并发活动变异（默认）时，我们未观察到显著的 CPU、内存或延迟增加。
默认计划
默认情况下，清理作业在以下时间运行：
- 周六：世界协调时晚上 8 点和晚上 10 点
- 周日：世界协调时凌晨 12 点、凌晨 2 点和凌晨 4 点
禁用作业
要完全禁用清理作业：
queue:
deployment:
extraEnv:
- name: "ENABLE_CLICKHOUSE_TTL_CLEANUP_CRON"
value: "false"
配置计划
您可以通过修改 cron 表达式来自定义清理作业的运行时间。
queue:
deployment:
extraEnv:
# UTC: Sunday 12am/2am/4am
- name: "CLICKHOUSE_TTL_CLEANUP_CRON_WEEKEND_MORNING"
value: "0 0,2,4 * * 0"
# UTC: Saturday 8pm/10pm
- name: "CLICKHOUSE_TTL_CLEANUP_CRON_WEEKEND_EVENING"
value: "0 20,22 * * 6"
要在单个 cron 计划上运行作业，请将 `CLICKHOUSE_TTL_CLEANUP_CRON_WEEKEND_EVENING` 和 `CLICKHOUSE_TTL_CLEANUP_CRON_WEEKEND_MORNING` 都设置为相同的值。作业锁定可防止重叠执行。
配置每个部分的最小过期行数
该作业逐表进行，扫描分区并从包含最少数量过期行的分区中删除数据。此阈值平衡了效率和彻底性。
- 过低：作业扫描整个分区以清除少量数据（效率低下）
- 过高：作业遗漏了包含大量过期数据的分区
queue:
deployment:
extraEnv:
- name: "CLICKHOUSE_TTL_CRON_MIN_EXPIRED_ROWS_PER_PART"
value: "100000" # 100k expired rows
检查过期行
使用此查询分析表中过期行，并相应地调整您的最小值。
-- Query for Runs table. For other tables, replace 'ttl_seconds' with 'trace_ttl_seconds'
SELECT
_part,
count() AS expired_rows
FROM runs
WHERE trace_first_received_at IS NOT NULL
AND ttl_seconds IS NOT NULL
AND toDateTime(assumeNotNull(trace_first_received_at) + toIntervalSecond(assumeNotNull(ttl_seconds))) < now()
GROUP BY _part
ORDER BY expired_rows DESC
配置最大活动变异数
删除操作可能非常耗时（100GB 分区约 50 分钟）。您可以增加并发变异以加快过程。
queue:
deployment:
extraEnv:
- name: "CLICKHOUSE_TTL_CRON_MAX_ACTIVE_MUTATIONS"
value: "1"
增加并发 DELETE 操作可能会严重影响系统性能。请仔细监控您的系统，并且只有在您能够容忍潜在的较慢的插入和读取延迟时才增加此值。
紧急情况：停止运行中的变异
如果您遇到延迟峰值并且需要终止正在运行的变异：
-
查找活动变异:
SELECT * FROM system.mutations WHERE is_done = 0;
-
终止变异:
KILL MUTATION WHERE mutation_id = '<mutation_id>';
备份和数据保留
如果运行此作业后磁盘空间没有减少，或者持续增加，可能是备份通过创建文件系统硬链接导致了问题。这些链接阻止了 ClickHouse 清理数据。 要验证，请检查 ClickHouse pod 内的以下目录：
/var/lib/clickhouse/backup/var/lib/clickhouse/shadow
如果存在备份，请将其复制到外部文件系统或 Blob 存储（例如 S3），然后清空目录。几分钟之内，您将注意到磁盘空间得到释放。
