很多人第一次试用监控系统，不是被复杂查询劝退，而是还没看到一张图，就先掉进了部署链条：安装采集器、部署时序库、配置写入地址、创建数据源，最后才轮到仪表盘和告警规则。
这套架构在生产环境里很合理，但对个人试用、分支机构和小团队并不友好。用户只是想确认“这套东西能不能监控我的机器”，却要先做一次小型基础设施项目。
夜莺 v9.1 内置 Prometheus TSDB，改变的是这段起步路径。Categraf 上报的指标可以直接保存在夜莺所在节点，本地完成查询、仪表盘和告警。对合适的场景来说，从安装到第一条测试告警之间，少了一个必须先部署外部时序库的前置条件。
内置时序库解决的是启动成本
启用后，夜莺会在本地保存 Categraf 推送的指标，并提供 Prometheus 兼容的查询能力。首次启动时，如果环境里没有已启用的 Prometheus 数据源，会自动注册一个名为 embedded-tsdb 的数据源，仪表盘、即时查询和告警规则可以直接使用。
默认配置保留 15 天数据，磁盘上限为 10GiB，并允许 10 分钟内的乱序样本。它足以支持试用、开发环境以及一部分小规模监控，不需要用户先理解 Prometheus 的完整部署和运维方式。
v9.1 还补齐了前后步骤：Categraf 安装与采集配置向导可以生成目标机器上执行的命令；数据源保存后，系统会探测近期存在的指标，推荐可以直接导入的仪表盘和告警规则模板；主机页面还提供测试告警和下一步提示。内置时序库并不是一个孤立开关，而是把“机器上线—看到数据—导入模板—验证通知”这段路线缩短了。
哪些人会真正受益
第一类是第一次接触夜莺的用户。过去很难判断问题出在采集器、时序库还是夜莺配置，现在依赖更少，能够先把最小链路跑通，再逐步理解各组件。
第二类是规模不大、没有专门监控平台团队的环境，例如实验室、门店、分支机构或内部开发环境。为了少量主机单独维护一套外部时序库，部署和升级成本可能高于实际收益。
第三类是方案验证和演示。需要快速证明采集、查询和告警能否满足需求时，内置存储可以先给出结果，不必把时间花在搭建外围组件上。
如果继续使用外部 Prometheus 或 VictoriaMetrics，也没有任何问题。v9.1 没有改变夜莺的多数据源定位，已有成熟存储的团队不需要为了使用新版本而迁移数据。
它不是大型 Prometheus 集群的替代品
内置 TSDB 的数据保存在单个中心节点的本地磁盘，适合单实例部署和约 10 万活跃序列以内的小规模场景。中心节点多副本时，每个实例只会持有收到的那部分数据，无法形成一份完整视图；规模继续增长后，容量、可用性和运维能力也更适合交给外部时序库。
所以，选型标准很清楚：想快速起步、规模较小，可以使用内置 TSDB；中心多副本、数据量大、对存储高可用有要求，应继续使用 Prometheus 兼容的外部存储。
迁移时也不必一次切换。内置 TSDB 和外部写入可以同时开启做双写，先验证查询和告警，再决定后续去向。这个过程仍需要关注磁盘容量和数据一致性，不能把双写当成长期无成本方案。
升级用户要注意两个容易忽略的细节
从旧版本原地升级，只替换二进制不会自动启用内置时序库，因为旧配置里没有对应配置段。希望使用时，需要显式补充并检查数据目录、保留时间和磁盘上限。
如果系统里已经存在启用状态的 Prometheus 数据源，夜莺也不会自动注册 embedded-tsdb，避免打扰现有部署。此时即使数据已经写入本地，也需要手工创建指向内置 TSDB 的 Prometheus 数据源才能查询。
内置时序库真正减少的，是“看到价值之前”的投入。它让用户可以先获得第一张图和第一条告警，再决定是否建设更完整的存储架构。对于小规模场景，这是开箱即用；对于大型生产环境，它更像一条起跑线，而不是终点。
