SkyWalking 数据生命周期管理：OAP TTL（Time To Live）机制完整指南

可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载导读本文聚焦 Apache SkyWalking OAP 后端的 TTLTime To Live生存时间机制讲解如何通过recordDataTTL与metricsDataTTL自动清理超过保留期的观测数据并深入剖析其底层实现DataTTLKeeperTimer 定时清理、集群节点协调、存储层 IHistoryDeleteDAO 调用链同时覆盖 BanyanDB 存储后端下 Progressive TTL 的替代配置方式。读完本文你将掌握 SkyWalking 数据保留策略的配置方法、生效原理与排查手段。一、TTL 是什么为什么观测数据需要生命周期管理TTLTime To Live是 SkyWalking OAP 提供的一种自动删除机制用于清理超过指定保留时间的观测数据。在生产环境中Trace、日志、指标会随业务流量持续增长如果不加以控制存储占用将无限膨胀最终拖垮 Elasticsearch、MySQL、BanyanDB 等存储后端并显著降低查询性能。通过 TTLOAP 可以按天为单位设定每类数据的保留期到期后自动执行删除。TTL 配置位于 OAP 核心模块core的配置块中默认配置文件为 oap-server/server-starter/src/main/resources/application.ymlcore: selector: ${SW_CORE:default} default: # 是否启用数据清理执行器设为 false 将关闭自动删除 enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # 数据清理执行器周期性运行的间隔单位分钟 dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5} # Record 数据Trace、日志、topN 采样语句、告警等的 TTL单位天 recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Metrics 数据服务/实例/端点指标、拓扑指标、元数据的 TTL单位天 metricsDataTTL: ${SW_CORE_METRICS_DATA_TTL:7}上述 YAML 配置对应的代码默认值定义在 oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/CoreModuleConfig.java/** * The time to live of all metrics data. Unit is day. */ private int metricsDataTTL 7; /** * The time to live of all record data, including tracing. Unit is Day. */ private int recordDataTTL 3;从源码注释可以看出recordDataTTL默认值为3天metricsDataTTL默认值为7天两者单位均为“天”。这意味着默认情况下超过 3 天的 Trace/日志会被清理超过 7 天的指标数据会被清理。二、两类观测数据Record 与 MetricsSkyWalking 将可观测性数据划分为两大类两者适用不同的 TTL 配置数据类型涵盖内容适用配置默认值Record记录型Trace链路、日志、topN 采样语句慢 SQL 等、告警记录recordDataTTL3 天Metrics指标型服务/实例/端点的全部指标、拓扑图数据、以及元数据服务、实例、端点列表metricsDataTTL7 天这里有一个容易忽略的关键点元数据Metadata也属于 Metrics 类别。服务、实例、端点的注册信息同样受metricsDataTTL约束因此在设置指标 TTL 时需要一并考虑元数据的保留需求——如果元数据被过早清理历史 Trace 将无法关联到对应的服务名与端点名。这一分类在代码中同样有明确体现。oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/storage/ttl/TTLDefinition.java 在生成 TTL 状态描述时写道Metrics TTL 涵盖服务/实例/端点/拓扑的元数据、由 OAL 与 MAL 引擎生成的指标数据Records TTL 涵盖Trace、日志、采样慢 SQL 语句、Rover 采集的 HTTP 请求、告警等。从该源码还可以看到SkyWalking 内部其实将数据进一步细分metrics.metadata、metrics.minute/hour/day、records.normal/trace/zipkinTrace/log/browserErrorLog等但在非 BanyanDB 存储后端下这些细分维度统一由metricsDataTTL与recordDataTTL两个配置项控制。三、TTL 的底层执行原理DataTTLKeeperTimer 与集群协调TTL 的删除动作并不是由存储后端自行完成的在 Elasticsearch/MySQL/PostgreSQL 等后端下而是由 OAP 内置的一个守护定时器驱动。核心实现位于 oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/storage/ttl/DataTTLKeeperTimer.java。3.1 定时触发机制DataTTLKeeperTimer是一个单例枚举INSTANCE在 OAP 启动时通过start(moduleManager, moduleConfig)注册一个名为DataTTLKeeper的守护线程调度器按照dataKeeperExecutePeriod配置默认 5 分钟周期性地执行删除逻辑VirtualThreads.createScheduledExecutor(DataTTLKeeper, ...) .scheduleAtFixedRate( new RunnableWithExceptionProtection( this::delete, t - log.error(Remove data in background failure., t) ), moduleConfig.getDataKeeperExecutePeriod(), moduleConfig.getDataKeeperExecutePeriod(), TimeUnit.MINUTES);异常被RunnableWithExceptionProtection包裹单次执行失败只记录错误日志不会中断后续周期任务。3.2 集群场景下的“单节点执行”协调一个重要的实现细节是每个 OAP 节点都会启动DataTTLKeeperTimer但真正执行删除的只有集群节点列表中的第一个节点。源码中通过ClusterNodesQuery获取所有远端节点并排序仅当排序后的第一个节点地址是当前节点自身时才继续执行删除ListRemoteInstance remoteInstances clusterNodesQuery.queryRemoteNodes(); Collections.sort(remoteInstances); if (CollectionUtils.isNotEmpty(remoteInstances) !remoteInstances.get(0).getAddress().isSelf()) { log.info(The selected first getAddress is {}. The remove stage is skipped., ...); return; }这种设计避免了多节点并发删除同一批数据造成的重复写放大与锁竞争——无论集群中有多少个 OAP 实例同一时刻只有“第一个”节点在承担历史数据清理工作。3.3 逐模型删除调用链与 Record/Metrics 分流delete()方法从IModelManager获取全部存储模型Model逐个执行删除execute(Model model)内部先跳过非时间序列模型!model.isTimeSeries()再根据模型是否为 Record 类型选择对应的 TTLmoduleManager.find(StorageModule.NAME) .provider() .getService(IHistoryDeleteDAO.class) .deleteHistory(model, Metrics.TIME_BUCKET, model.isRecord() ? moduleConfig.getRecordDataTTL() : moduleConfig.getMetricsDataTTL());完整的调用链为DataTTLKeeperTimer→IHistoryDeleteDAO.deleteHistory(model, timeBucket, ttl)→ 各存储插件的具体实现如 Elasticsearch 的按索引删除、JDBC 的按时间桶 DELETE SQL。IHistoryDeleteDAO接口定义于 oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/storage/IHistoryDeleteDAO.java。在 RecordStreamProcessor.java 与 MetricsStreamProcessor.java 中均能看到这两个 TTL 配置在数据处理链路中的引用印证了 Record 与 Metrics 两条流分别消费各自 TTL 值。3.4 关闭自动清理如果希望完全关闭自动删除例如由外部任务或存储层策略接管清理可将enableDataKeeperExecutor设为false对应环境变量SW_CORE_ENABLE_DATA_KEEPER_EXECUTORfalse。此时DataTTLKeeperTimer不再启动调度数据将无限期保留需自行评估存储容量风险。四、实战配置如何调整 TTL4.1 通过 YAML 配置config/application.yml在 oap-server/server-starter/src/main/resources/application.yml 的core.default段直接修改core: default: # 例如Trace 保留 7 天指标保留 30 天 recordDataTTL: 7 metricsDataTTL: 304.2 通过环境变量覆盖推荐用于容器化部署所有配置项均支持环境变量注入格式为${ENV_VAR:默认值}配置项环境变量默认值说明recordDataTTLSW_CORE_RECORD_DATA_TTL3Record 数据保留天数metricsDataTTLSW_CORE_METRICS_DATA_TTL7Metrics 数据保留天数enableDataKeeperExecutorSW_CORE_ENABLE_DATA_KEEPER_EXECUTORtrue是否启用自动清理执行器dataKeeperExecutePeriodSW_CORE_DATA_KEEPER_EXECUTE_PERIOD5清理周期分钟例如在 Docker 中启动 OAP 时docker run -e SW_CORE_RECORD_DATA_TTL7 -e SW_CORE_METRICS_DATA_TTL30 apache/skywalking-oap-server4.3 配置建议依据存储容量规划Trace 与日志通常是数据量最大的部分TTLDefinition 源码中将其称为 super dataset建议单独评估通常比指标保留更短元数据保留需覆盖指标窗口元数据属于 Metrics 类别若metricsDataTTL过短历史 Trace 可能因服务元数据被清理而无法正确展示集群内统一配置由于删除由集群首个节点执行各节点应保持一致的 TTL 配置避免行为漂移不要随意调小清理周期dataKeeperExecutePeriod默认 5 分钟已足够及时过短的周期会增加存储层压力。五、BanyanDB 后端使用 Progressive TTL 替代 core TTL这是一个重要的特例当使用 BanyanDB 作为存储后端时recordDataTTL与metricsDataTTL不再生效官方文档明确说明这两个配置被弃用/deprecated。TTL 需要在storage.banyandb中直接配置。5.1 BanyanDB 的 Progressive TTL 机制BanyanDB 采用基于时间的分段Segment轮转机制实现渐进式 TTL每个分组group有两项关键设置segmentInterval天每隔多少天创建一个新 Segmentttl天数据在自动删除前保留多久。部分分组支持多阶段Stage存储hot热默认阶段始终存在warm温可选启用后默认查询会覆盖 hot warmcold冷可选用于更长期、更低成本的归档存储。启用 warm/cold 阶段后数据会随时间推移按hot → warm → cold流动每个阶段拥有独立的ttl、segmentInterval和nodeSelector节点亲和性可将不同阶段数据调度到不同类型的存储节点。这一机制的详细说明见 docs/en/banyandb/ttl.md。5.2 BanyanDB 默认 TTL 一览根据官方文档中的 bydb.yml 默认值各分组Kind的 TTL 如下warm/cold 列的值仅在启用对应阶段时生效Kind分组ttlwarm ttlcold ttlrecords3730trace3730zipkinTrace3730recordsLog3730recordsBrowserErrorLog3730metricsMinute71560metricsHour1530120metricsDay1530120metadataindex-mode15——property———注意事项源自官方文档— 表示默认 bydb.yml 中未指定metadata 不支持 warm/cold 阶段property 类型没有 TTL因为它走的是不同的 KV-engine 机制metadata 分组的 TTL 应大于等于所有指标分组的最大 TTL以确保保留数据的索引覆盖完整。5.3 在storage.banyandb中配置 TTLBanyanDB 的完整配置位于 docs/en/setup/backend/storages/banyandb.md其groups段以records分组为例的结构如下节选全部键均支持环境变量覆盖storage: banyandb: groups: # Record 类通用分组 records: shardNum: ${SW_STORAGE_BANYANDB_RECORDS_SHARD_NUM:1} segmentInterval: ${SW_STORAGE_BANYANDB_RECORDS_SI_DAYS:1} ttl: ${SW_STORAGE_BANYANDB_RECORDS_TTL_DAYS:3} replicas: ${SW_STORAGE_BANYANDB_RECORDS_REPLICAS:0} enableWarmStage: ${SW_STORAGE_BANYANDB_RECORDS_ENABLE_WARM_STAGE:false} enableColdStage: ${SW_STORAGE_BANYANDB_RECORDS_ENABLE_COLD_STAGE:false} warm: shardNum: ${SW_STORAGE_BANYANDB_RECORDS_WARM_SHARD_NUM:1} segmentInterval: ${SW_STORAGE_BANYANDB_RECORDS_WARM_SI_DAYS:2} ttl: ${SW_STORAGE_BANYANDB_RECORDS_WARM_TTL_DAYS:7} nodeSelector: ${SW_STORAGE_BANYANDB_RECORDS_WARM_NODE_SELECTOR:typewarm} cold: shardNum: ${SW_STORAGE_BANYANDB_RECORDS_COLD_SHARD_NUM:1} segmentInterval: ${SW_STORAGE_BANYANDB_RECORDS_COLD_SI_DAYS:4} ttl: ${SW_STORAGE_BANYANDB_RECORDS_COLD_TTL_DAYS:30} nodeSelector: ${SW_STORAGE_BANYANDB_RECORDS_COLD_NODE_SELECTOR:typecold}分组trace、zipkinTrace、recordsLog、recordsBrowserErrorLog、metricsMinute、metricsHour、metricsDay、metadata的结构与此类似分别对应环境变量SW_STORAGE_BANYANDB_*_TTL_DAYS系列如SW_STORAGE_BANYANDB_TRACE_TTL_DAYS、SW_STORAGE_BANYANDB_METRICS_MINUTE_TTL_DAYS、SW_STORAGE_BANYANDB_METADATA_TTL_DAYS等默认值见上文表格。阶段流转规则源自 banyandb.md 配置注释仅启用 warm 阶段hot 阶段 TTL 到期后数据移入 warm 阶段仅启用 cold 阶段hot 阶段 TTL 到期后数据直接移入 cold 阶段同时启用 warm 与 coldhot 到期移入 warmwarm 到期再移入 cold默认查询覆盖 hot warm当 warm 阶段启用时。六、TTL 状态查询与运维观测SkyWalking 提供了 TTL 运行状态的查询入口。核心查询服务为 oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/query/TTLStatusQuery.javagetTTL()返回生效中的 TTL 定义。其逻辑是优先从存储插件StorageTTLStatusQueryBanyanDB 等会返回自定义 TTL获取若存储层未提供返回 null则回退使用 core 模块的metricsDataTTL/recordDataTTLgetMetricsTTL(Model model)查询指定指标模型的有效 TTL当存储层返回 -1表示未按模型定制时回退到coreMetricsDataTTL。结合 oap-server/server-starter/src/main/resources/application.yml 中的status模块说明可以看到/status/config/ttl端点同时绑定在管理端口admin-server默认 17128与公开 REST 端口默认 12800上便于生态工具在发起 GraphQL 查询前先发现 TTL 配置。运维人员可以通过该端点核验 TTL 配置是否按预期生效尤其要区分 core TTL 与 BanyanDB 分组 TTL 哪一套在起作用。七、FAQ常见问题与注意事项Q1改了recordDataTTL/metricsDataTTL需要重启吗需要。这些配置在 OAP 启动时由CoreModuleConfig装载属于静态配置。SkyWalking 支持通过动态配置中心Apollo、Nacos、Consul、etcd、ZooKeeper、K8s ConfigMap见 docs/en/setup/backend/dynamic-config.md热更新部分配置但 TTL 相关项不在其中修改后应滚动重启 OAP 节点。Q2为什么集群中删数据慢/没删删除由集群节点列表中排序后的首个节点执行见 3.2 节其余节点会打印 The remove stage is skipped. 日志。若该节点异常或网络分区删除可能延迟可通过 OAP 日志中的 Beginning to remove expired metrics from the storage. 观察执行情况。Q3Elasticsearch / MySQL / PostgreSQL 与 BanyanDB 的 TTL 配置有何区别前者使用core.default下的recordDataTTL/metricsDataTTL由 OAP 侧DataTTLKeeperTimer驱动删除后者BanyanDB弃用这两个配置改在storage.banyandb.groups中按分组配置segmentInterval与ttl含可选 warm/cold 阶段由 BanyanDB 自身按 Segment 轮转删除。Q4BanyanDB 的 metadata 分组 TTL 需要注意什么metadata 分组 TTL 应大于等于所有指标分组的最大 TTL以保证被保留数据的索引覆盖完整否则可能出现数据仍在、但元数据索引已被清理导致查询结果不完整的情况。八、小结SkyWalking 的 TTL 机制按数据性质分治Record 类数据Trace、日志、topN、告警默认保留 3 天Metrics 类数据指标、拓扑、元数据默认保留 7 天二者由core.default下的recordDataTTL与metricsDataTTL控制底层由DataTTLKeeperTimer周期性驱动IHistoryDeleteDAO执行删除且集群中仅排序后的首个节点实际执行避免并发删除。当存储后端切换为 BanyanDB 时TTL 配置迁移至storage.banyandb.groups采用基于 Segment 轮转的 Progressive TTLhot/warm/cold 多阶段实现按时间粒度精细化的数据保留与成本控制。合理规划 TTL 是保障 SkyWalking 长期稳定运行、控制存储成本的关键一步。参考文档与源码索引官方 TTL 文档docs/en/setup/backend/ttl.mdBanyanDB Progressive TTLdocs/en/banyandb/ttl.mdBanyanDB 存储配置docs/en/setup/backend/storages/banyandb.md默认配置文件oap-server/server-starter/src/main/resources/application.ymlTTL 配置默认值CoreModuleConfig.javaTTL 清理定时器DataTTLKeeperTimer.javaTTL 状态查询TTLStatusQuery.java赞分享可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载相关推荐ScyllaDB 中基于 CQL 的 TTLTime to Live机制从语法使用到过期数据回收原理ScyllaDB 中基于 CQL 的 TTLTime to Live机制从语法使用到过期数据回收原理 本篇技术指南围绕 ScyllaDB 的经典 per数据库分布式数据库后端大数据Minecraft基岩版启动器解锁游戏自由度的终极工具Minecraft基岩版启动器解锁游戏自由度的终极工具 还在为官方启动器的限制感到束手束脚吗BedrockLauncher为你带来完全不同的游戏体验。这款开桌面应用游戏开发超实用Apache SkyWalking数据生命周期管理从TTL策略到存储优化全攻略超实用Apache SkyWalking数据生命周期管理从TTL策略到存储优化全攻略 你是否遇到过SkyWalking监控系统运行一段时间后存储占用飙升、可观测性后端微服务云原生上一篇从SQLite到PostgreSQLOpenStatus数据库迁移终极指南下一篇如何快速安装和配置BlockBlockmacOS恶意软件防护的10个关键步骤创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考