1. 可观测性工程在Snowflake中的定位

在传统数据平台运维中，“监控”几乎是稳定性的代名词：我们采集CPU、内存、磁盘、查询耗时等指标，设置阈值告警，出问题后登录控制台排查。但Snowflake作为云原生、多租户、存算分离的数据平台，其运行形态与传统自建数仓有本质差异——查询性能可能受仓库规格、缓存命中、微分区裁剪、并发排队、云服务层调度等多重因素共同影响。仅靠“某个指标超过阈值”的监控方式，往往只能告诉你“出问题了”，却很难回答“为什么出问题、影响谁、从哪一步开始变慢”。这正是可观测性工程要解决的核心命题。

从监控到可观测性：关注点的迁移

监控（Monitoring）回答的是“系统是否处于已知的正常状态”，它依赖预先定义的指标和阈值，适合发现已知故障模式。可观测性（Observability）则强调“能否通过系统对外输出的数据，推断出内部任意状态”，它不预设问题类型，而是通过指标（Metrics）、日志（Logs）、追踪（Traces）以及事件（Events）等多类信号，支持对未知问题的探索式分析。

在Snowflake场景中，这种迁移体现得非常具体。例如，一个报表查询突然从3秒变成90秒。监控视角可能只看到“查询时长超过阈值”的告警；而可观测性视角会进一步关联：该查询使用的虚拟仓库是否发生了排队？QUERY_HISTORY中compilation_time、execution_time、queuing_time各占多少？是否命中了结果缓存或微分区缓存？同一时段是否有其他大查询争抢资源？这些信息分散在ACCOUNT_USAGE、INFORMATION_SCHEMA、仓库事件和查询计划中，只有把它们组织成可关联的信号链，才能完成从“报警”到“定位”的闭环。

Snowflake平台特性对可观测性的影响

理解Snowflake可观测性，必须先理解它的几个平台特性，因为这些特性直接决定了“哪些信号可见、哪些不可见、信号之间如何关联”。

• 存算分离与虚拟仓库：计算资源以虚拟仓库为单位独立伸缩，查询性能与仓库规格、集群数量、自动挂起/恢复策略强相关。可观测性必须把“查询”与“仓库”两个维度关联起来，否则无法解释同一SQL在不同时间表现差异巨大的现象。
• 多租户与云服务层：Snowflake的云服务层负责元数据、优化、事务和调度，用户无法直接观测其内部状态，只能通过QUERY_HISTORY中的编译时间、排队时间等间接推断。这意味着可观测性需要更多依赖平台暴露的“结果性信号”，而非底层主机指标。
• 微分区与自动优化：数据以微分区存储，裁剪效果直接影响扫描量。查询变慢可能不是计算资源不足，而是微分区裁剪失效或数据倾斜。可观测性需要把执行计划、分区扫描统计纳入信号体系。
• 缓存机制：结果缓存、微分区缓存、仓库缓存共同影响响应时间。缓存命中率的变化往往是性能波动的第一线索，但缓存状态并不总是直接暴露，需要通过查询历史中的相关字段间接判断。
• ACCOUNT_USAGE延迟：ACCOUNT_USAGE视图通常有45分钟到数小时的延迟，而INFORMATION_SCHEMA更实时但保留时间短。可观测性方案必须明确“用哪个数据源回答哪类问题”，避免用延迟数据做实时告警。

核心目标与价值主张

Snowflake可观测性工程的目标可以归纳为四个层次，它们由浅入深，共同构成从“看见”到“解释”再到“预防”的能力阶梯。

以一个具体示例说明这种价值。假设某团队发现每日凌晨ETL任务耗时从20分钟增长到55分钟。仅看监控，可能只收到“任务超时”告警。引入可观测性后，可以按以下路径分析：首先从QUERY_HISTORY中提取该时段所有相关query_id，按warehouse_name分组，发现同一仓库上并行运行了三个大查询；进一步查看WAREHOUSE_EVENTS，发现仓库在凌晨2:10触发了扩容，但扩容完成前查询已进入排队；再查看QUERY_PLAN，发现其中一个查询的微分区扫描量是前一天的3倍，原因是上游表新增了大量未聚簇的小文件。最终结论是：并发争抢叠加分区裁剪退化，而非单纯资源不足。处置动作包括调整任务错峰、对上游表启用聚簇、并为关键任务配置独立仓库。这个过程中，可观测性提供的不是某一个指标，而是一条可追溯的证据链。