数据保留和存储

Dash 使用 PostgreSQL + TimescaleDB 保存历史数据和关键运行状态。Redis 保存管理员会话和可丢弃的前台缓存。

PostgreSQL 数据

持久化内容：

• 节点元数据。
• 当前指标。
• 历史指标。
• 节点分钟在线时长和小时聚合。
• 磁盘和网卡明细。
• 五分钟流量明细和月度快照。
• 分组和标签。
• 告警规则、事件和通知发送队列。
• 通知渠道密文和投递健康状态。
• 系统设置和主题状态。
• 流量用量累计、五分钟流量明细和节点账期修复的处理进度。

Redis 数据

默认保存：

• 管理会话。
• 前台热点快照。
• 游客可见性缓存。

使用 --no-redis 时，会话和前台缓存改用进程内存。告警待定状态与冷却状态、MTProto 登录握手、节点更新请求和手工流量重建任务在两种模式下都属于进程内状态。

常规指标

配置：

database:
  metrics_raw_retention_days: 8

该字段只控制 server_metrics、disk_metrics、disk_usage_metrics 和 disk_physical_metrics 的原始采样保留期。省略或设置为 0 时使用默认值 8 天；显式值不得小于 2。

原始采样和两级聚合分别执行独立的保留策略：

数据集	保留期	存储方式
原始采样	配置值，默认 8 天	新数据使用 1 小时时间分块；首日不压缩，之后无损压缩
15 分钟聚合	16 天	连续聚合
1 小时聚合	32 天	连续聚合

每个数据集超过各自的保留期后独立删除。调整原始采样保留期不会延长聚合保留期。使用默认配置时，8 天后不再保留原始采样，16 天后不再保留 15 分钟聚合，32 天后不再保留常规指标历史。

历史查询根据查询范围使用固定数据源：

查询范围	数据源
30m、1h、12h、24h	原始采样
1w	15 分钟聚合
15d	按样本数加权的 15 分钟聚合，返回 30 分钟数据点
30d	1 小时聚合

历史聚合会持续刷新，并包含最新的实时采样。原始采样保留期内可以查询完整采样点。

server_online_30m 单独保留 8 天，只统计已经结束的 30 分钟时段。

网卡原始指标和服务检查继续由 database.retention_days 控制。省略或设置为 0 时，默认保留 45 天。网卡指标使用 1 天时间分块，并在 7 天后压缩。

修改保留配置后，Dash 在启动或执行 dash migrate 时同步 TimescaleDB 策略。已经超出新窗口的数据由后续策略任务删除，不会在读取配置时同步扫描删除。

Uptime 在线统计

节点卡片使用独立的 Uptime 数据集：

数据集	保留期	内容
node_online	46 天	每节点、每个已结束分钟的在线毫秒数和观测毫秒数
node_online_1h	46 天	每小时在线时长和观测时长之和
看板日期窗口	最近 45 个自然日，包含今天	按 app.timezone 划分日期

在线率为 100 × 在线时长 / 观测时长，按时长加权。每次上报从服务端接收时间起，在 app.node_offline_threshold 内视为在线，重叠区间只计算一次。首次有效上报前和删除后的节点不生成新的观测；从未上报的节点始终没有 Uptime 记录。

PostgreSQL/TimescaleDB 任务在整分后约 6 秒统计上一分钟。只统计已结束分钟，当前小时通过分钟数据参与查询；小时聚合由数据库任务定期刷新。今天和当前小时最多约滞后一分钟加归集延时。

缺少分钟记录表示未知，不计入在线率分母。任务错过的分钟和跨数据库重启的分钟不会自动补算。API 的 observed_ms 表示实际已观测时长，100% 不代表整天都已覆盖。

这两个数据集的保留期独立于 database.metrics_raw_retention_days 和 database.retention_days。关闭游客展示不会停止采样。首次升级启用 Uptime 时只开始积累新记录，不提供从 CPU 等历史曲线重建 Uptime 的通用功能。

流量保留

配置：

database:
  traffic_retention_days: 90

省略或设置为 0 时使用：

max(database.retention_days, 45)

需要 P95 计费、手工流量重建或更长账期回溯时，应提高该值。traffic_5m 保持可写，并通过滚动保留策略删除旧数据。

月度快照保存历史 P95 计费结果。手工重建范围取网卡原始指标与五分钟流量明细保留期的交集。

流量后台任务

流量后台服务维护两个独立持久化进度：

• 用量累计在 lite 和 billing 模式下维护月度累计、覆盖范围和处理进度。
• 五分钟流量明细仅在 billing 模式下生成。
• 两项任务均按 1 小时时间段提交结果与处理进度。
• 每小时刷新月度快照。
• 手工重建按 6 小时时间段处理，并与常规流量写入互斥执行。

从 lite 切换到 billing 时，系统从切换前 30 分钟开始生成五分钟流量明细。更早的数据不会自动补算；仍在网卡原始指标保留期内的数据可以在 billing 模式下按节点重建。

数据完整性字段

流量响应包含：

• sample_count
• expected_sample_count
• coverage_ratio
• gap_count
• reset_count
• cycle_complete
• data_complete
• status

这些字段用于判断账期内数据是否足够完整。客户端应使用 data_complete、coverage_ratio、gap_count 和 reset_count。废弃字段 partial 已删除。