准备把夜莺接入现有监控体系时，很多团队会卡在一个很琐碎的问题上：Prometheus、Loki、Elasticsearch 和数据库早已配置在 Grafana 里，地址、名称、鉴权方式都有人维护；到了新的告警平台，却要再填一遍。
手工重配本身不难，麻烦的是数量一多就容易出错。地址复制错、数据源名称不一致、遗漏一套集群，都会让后续告警规则选错目标。夜莺 v9.1 增加从 Grafana 导入数据源，解决的正是这笔重复接入成本。
导入过程不是“黑盒复制”
用户填写 Grafana 地址和 Token，也可以使用用户名与密码连接。夜莺读取 Grafana 中的数据源列表，映射成自己支持的配置，然后先展示预览，不会未经确认直接批量写入。
当前覆盖 Prometheus、Loki、Elasticsearch、MySQL 和 PostgreSQL。预览会逐条标出哪些数据源可以导入、哪些类型暂不支持、哪些与现有名称冲突，以及哪些还需要补充鉴权信息。用户选择后再执行导入，完成时会收到逐条结果，知道每个数据源是成功、待补凭证还是被跳过。
这个过程的价值不只是少填几个 URL。Grafana 已经是很多企业事实上的数据源目录，从它开始导入，能够降低遗漏环境和命名不一致的概率，也让平台团队更快把注意力转向真正重要的工作：哪些数据要告警、规则归哪个业务组、通知应该发给谁。
为什么有些数据源导入后仍然是禁用状态
Grafana 的接口不会返回已保存密钥的明文。夜莺能够拿到数据源类型、地址和部分配置，却无法凭空恢复 MySQL、PostgreSQL 或 Elasticsearch 的密码。
因此，SQL 类和 Elasticsearch 数据源缺少凭证时，会先以禁用状态保存，等待管理员补齐密码后再显式启用。这个设计看起来少了“一键完成”的爽感，却避免系统生成一批表面导入成功、实际无法连接的数据源。
同样，不受支持的数据源类型会在预览中标记并禁止选择。导入工具不会为了追求成功率，把未知类型强行映射成错误配置。
导入完成只是接入的起点
数据源进入夜莺后，建议按顺序完成几项检查：
- 补齐缺失的用户名、密码和其他鉴权字段；
- 逐个执行连接测试，确认夜莺所在网络能够访问目标地址；
- 检查同名数据源和环境命名，避免生产、测试集群混淆；
- 确认数据源对应的告警引擎和业务组使用方式；
- 执行一次实际查询，再创建或导入告警规则。
网络可达性尤其容易被忽略。Grafana 能访问某个内网地址，不代表夜莺部署节点也能访问；导入的是配置，不是 Grafana 的网络位置。涉及边缘数据源时，还需要选择能够连通目标的告警引擎。
v9.1 在数据源保存后还会用哨兵指标探测近期有哪些组件数据，并推荐可能可用的内置仪表盘和告警规则模板。对于 Prometheus 系数据源，用户不必先浏览整个模板库，可以从真正有数据的组件开始导入。
它不会迁移 Grafana 的全部内容
需要明确的是，这项能力导入的是数据源配置，不是完整的 Grafana 迁移工具。现有 Dashboard、Panel、告警规则、用户权限和组织关系不会因为导入数据源自动搬到夜莺。
这反而符合实际边界。很多团队仍会继续使用 Grafana 看图，只把夜莺作为多数据源告警引擎；它们需要共享数据源，却不需要复制全部可视化资产。对于确实要迁移仪表盘的团队，还需要单独评估面板类型和查询兼容性。
不用导入功能，手工配置当然也能完成接入。损失主要发生在规模扩大之后：重复录入占用平台人力，不同系统的名称逐渐漂移，新环境也更容易被漏掉。一次性几条配置看不出差别，几十套数据源和多个团队共同维护时，差别就很明显。
从 Grafana 导入数据源不是一个宏大的功能，却解决了新平台接入时最容易消耗耐心的一段工作。少配一遍只是起点，更重要的是让夜莺更快站在企业已有的监控资产上，而不是要求用户从头再来。
