可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载TTLTime To Live是 SkyWalking OAP Server 控制可观测数据存储生命周期、自动清理过期数据、防止存储无限膨胀的核心机制。本指南以 ttl.md 为骨架结合 OAP 源码CoreModuleConfig、ConfigService、DataTTLKeeperTimer、IHistoryDeleteDAO与真实配置示例完整讲解两类数据Records 与 Metrics的 TTL 配置参数、默认值、环境变量覆盖方式以及底层删除驱动原理帮助你在生产环境按数据特征精确设定保留天数。一、背景为什么需要区分两类数据设置 TTL在 SkyWalking 中可观测数据在存储层面被划分为两种类型二者的数据量级、价值密度和保留需求差异巨大记录型数据Records包括调用链 Tracesegment、日志 Log、TopN 采样语句slow SQL/慢语句和告警 Alarm。这类数据是逐条原始记录数据量最大、增长最快通常只需要短期保留用于排障与审计过期后价值迅速衰减。recordDataTTL作用于这类数据。指标型数据Metrics包括服务Service、实例Instance、端点Endpoint以及拓扑图相关的全部指标。元数据服务、实例、端点的列表也归属于 Metrics。这类数据是聚合后的统计数据量级相对可控且是趋势分析、告警规则和历史对比的基础通常需要更长的保留周期。metricsDataTTL作用于这类数据。之所以将 TTL 拆分成两个独立参数正是为了适配这两类数据截然不同的生命周期诉求让高频、高量的 Trace/Log 快速滚动清理同时让指标和元数据留存更久兼顾存储成本与查询能力。二、核心配置参数与默认值TTL 的配置位于 OAP Server 的core模块配置段中默认配置文件为 oap-server/server-starter/src/main/resources/application.yml打包后即application.yml。完整配置如下core: default: # 记录型数据Trace、Log、TopN、Alarm的超时时间超时后自动删除。单位为天 recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Unit is day # 指标型数据Service/Instance/Endpoint 指标、拓扑与元数据的超时时间超时后自动删除。单位为天 metricsDataTTL: ${SW_CORE_METRICS_DATA_TTL:7} # Unit is day两个参数均为整数天数参数环境变量默认值作用对象recordDataTTLSW_CORE_RECORD_DATA_TTL3天Trace、Log、TopN 采样语句、Alarm 等记录型数据metricsDataTTLSW_CORE_METRICS_DATA_TTL7天Service/Instance/Endpoint 指标、拓扑、元数据列表等指标型数据在源码中这两个默认值定义在 CoreModuleConfig.javaprivate int metricsDataTTL 7; private int recordDataTTL 3;配置加载后会被封装进 ConfigService.java作为CoreModule对外提供的配置服务供其他模块读取private final int metricsDataTTL; private final int recordDataTTL; ... this.metricsDataTTL moduleConfig.getMetricsDataTTL(); this.recordDataTTL moduleConfig.getRecordDataTTL();三、修改方式配置文件与环境变量覆盖TTL 有两条生效路径优先级为环境变量 配置文件默认值直接编辑配置文件修改oap-server/server-starter/src/main/resources/application.yml中core.default段下的recordDataTTL/metricsDataTTL值或在部署目录下的config/application.yml中调整后重启 OAP Server。通过环境变量覆盖推荐用于容器化/K8s 部署无需改动文件利用${SW_CORE_RECORD_DATA_TTL:3}语法任何环境变量会覆盖 yaml 中的默认值。例如在docker-compose.yml或 K8s Deployment 中设置environment: - SW_CORE_RECORD_DATA_TTL3 - SW_CORE_METRICS_DATA_TTL14上述示例将指标保留期延长至 14 天记录数据保持默认 3 天。注意TTL 值必须为正整数单位为天0或负数没有意义。相关辅助配置执行周期与开关与 TTL 删除动作强相关的还有两个配置项同位于core.default段见 application.yml# 关闭后自动指标数据删除将失效 enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # Data Keeper 执行器多久运行一次单位为分钟 dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5}enableDataKeeperExecutor默认true数据清理任务的全局开关置为false则完全停止 TTL 自动删除dataKeeperExecutePeriod默认 5 分钟周期性扫描并执行过期数据删除的间隔。四、底层实现TTL 如何被驱动执行理解 TTL 的执行机制有助于你判断改完配置多久生效谁来执行删除。4.1 核心驱动器DataTTLKeeperTimer删除动作由一个内部定时器 DataTTLKeeperTimer.java 驱动。它采用单线程调度按dataKeeperExecutePeriod默认 5 分钟周期性执行delete()Executors.newSingleThreadScheduledExecutor() .scheduleAtFixedRate( new RunnableWithExceptionProtection(this::delete, t - log.error(Remove data in background failure., t)), moduleConfig.getDataKeeperExecutePeriod(), moduleConfig.getDataKeeperExecutePeriod(), TimeUnit.MINUTES);每次执行时delete()会遍历IModelManager中的全部存储模型Model对每个时序模型model.isTimeSeries()为 true调用存储层 DAO 执行历史删除并按模型类型选择 TTL 值moduleManager.find(StorageModule.NAME) .provider() .getService(IHistoryDeleteDAO.class) .deleteHistory(model, Metrics.TIME_BUCKET, model.isRecord() ? moduleConfig.getRecordDataTTL() : moduleConfig.getMetricsDataTTL());即每个存储模型都会根据自身isRecord()属性自动归入recordDataTTL或metricsDataTTL的管理范围这一判定逻辑在 DataTTLKeeperTimer.java 中。4.2 集群环境下只由一个节点执行DataTTLKeeperTimer在每个 OAP 节点上都会启动但为避免多节点重复删除同一批数据代码通过ClusterNodesQuery获取集群节点列表并排序仅当本节点是列表中的第一个节点时才实际执行删除其余节点直接跳过源码注释见 DataTTLKeeperTimer.javaListRemoteInstance 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; }4.3 存储层实现IHistoryDeleteDAO删除动作最终委托给存储层的IHistoryDeleteDAO接口见 IHistoryDeleteDAO.java/** * Remove all expired data based on TTL configurations. * param ttl the number of days should be kept */ void deleteHistory(Model model, String timeBucketColumnName, int ttl) throws IOException;不同存储插件提供各自的实现例如Elasticsearch 插件HistoryDeleteEsDAO.javaJDBC/H2/MySQL/PostgreSQL 插件JDBCHistoryDeleteDAO.java对应的集成测试见 JDBCHistoryDeleteDAOIT.javaBanyanDB 插件BanyanDBHistoryDeleteDAO.java。另外在指标写入路径上MetricsPersistentWorker.java 还会借助IMetricsDAO.isExpiredCache()判断内存缓存中的指标是否已超过 TTL见 IMetricsDAO.java实现缓存层的过期淘汰default boolean isExpiredCache(Model model, Metrics cachedValue, long currentTimeMillis, int ttl) { long metricTimestamp cachedValue.getTimeBucket(); // If the cached metric is older than the TTL indicated. return currentTimeMillis - metricTimestamp TimeUnit.DAYS.toMillis(ttl); }由此可见TTL 不仅在后台删除环节生效也参与写入期的缓存淘汰两层配合共同约束数据生命周期。五、注意事项与最佳实践单位统一为天两个 TTL 参数均以天为最小单位最小粒度为 1 天无法按小时配置。区分两类数据再设定值Trace/Log 建议 3 天左右默认值即可指标与元数据可放宽到 730 天具体结合存储容量与查询窗口决定元数据归属 Metrics 意味着即使只保留 Trace 3 天服务/实例列表也会按metricsDataTTL保留更久查询 UI 时历史服务仍可见。BanyanDB 分段间隔需小于 TTL若使用 BanyanDB 存储其segmentIntervalDays/superDatasetSegmentIntervalDays的取值应小于等于 TTL 相关设置见 application.yml否则会出现分段覆盖不到过期边界的问题。集群部署无需重复配置TTL 删除由集群中排序第一的节点统一执行所有节点配置一致即可不会发生重复删除。改动即时性TTL 值在 OAP 启动时加载修改后需重启 OAP Server 生效删除任务本身每dataKeeperExecutePeriod默认 5 分钟扫描一轮因此数据过期后最迟会在一个执行周期内被清理。关闭自动清理如需自行管理数据归档可将enableDataKeeperExecutor设为falseSW_CORE_ENABLE_DATA_KEEPER_EXECUTORfalse此后过期数据将不再被自动删除。六、小结SkyWalking 的 TTL 机制通过recordDataTTL与metricsDataTTL两个参数将记录型数据Trace、Log、TopN、Alarm与指标型数据指标、拓扑、元数据的保留策略解耦配合DataTTLKeeperTimer定时器、集群单节点删除机制以及各存储插件实现的IHistoryDeleteDAO实现了过期数据自动、精准、无重复地清理。生产实践中按数据价值与存储成本分别设定两档 TTL即可在查询能力与资源占用之间取得良好平衡。赞分享可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载相关推荐SkyWalking 渐进式 TTLProgressive TTL实践指南基于 BanyanDB 的分层数据保留策略SkyWalking 渐进式 TTLProgressive TTL实践指南基于 BanyanDB 的分层数据保留策略 渐进式 TTLProgressiv可观测性APM链路追踪指标监控日志分析微服务CacheCloud监控数据保留策略时序数据TTL设置指南CacheCloud监控数据保留策略时序数据TTL设置指南 在大规模Redis集群运维中监控数据的有效管理直接影响系统性能与存储成本。CacheCloud作后端运维Apache SkyWalking持续分析结果存储期限数据保留策略Apache SkyWalking持续分析结果存储期限数据保留策略 1. 分布式追踪系统的数据存储挑战 在微服务架构普及的今天分布式追踪Distribut可观测性后端微服务云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考