如何使用Azure Monitor监控Snowflake：日志传输内容与传输方式对比

针对你提出的两个核心问题，结合落地实践经验整理答案如下：

一、需要传输的核心日志/表数据 #

你只需要同步Snowflake的系统视图数据即可覆盖90%以上的通用监控场景，核心需要同步的视图如下：

• QUERY_HISTORY：记录所有SQL查询的全链路执行信息，包括执行时长、扫描数据量、返回行数、错误信息、执行用户、关联仓库，是慢查询告警、异常SQL排查、资源使用率统计的核心数据源
• WAREHOUSE_METERING_HISTORY：记录虚拟仓库的信用消耗、计算资源使用率数据，用于成本监控、仓库负载过高/过低告警、资源优化
• LOGIN_HISTORY：记录所有账号的登录事件，包含登录结果、来源IP、客户端版本，用于异常登录检测、合规审计
• COPY_HISTORY：记录所有数据导入导出操作的执行情况，包括处理文件数、错误行数、吞吐量，用于数据管道的可用性监控
• 如果你开启了Snowflake的其他高级功能，也可以按需同步对应的系统视图，比如查询加速功能对应QUERY_ACCELERATION_HISTORY，搜索优化服务对应SEARCH_OPTIMIZATION_HISTORY

二、push模式与pull模式选型建议 #

本场景下的pull模式指由Azure侧定期调用Snowflake接口查询系统视图拉取日志，push模式指Snowflake侧通过任务调度、外部函数主动将生成的日志推送到Azure Log Analytics的采集端点。
两种模式的选型可以参考以下规则：

• 优先选择pull模式：适用于日志量中等以下、监控延迟要求在5~15分钟的场景，配置成本极低，只需要给Azure侧的服务账号授予Snowflake系统视图的只读权限，配置定时拉取任务即可，不需要在Snowflake侧开发额外逻辑，后期维护成本很低
• 当满足以下任意条件时选择push模式：日志量级非常大、需要近实时（1分钟以内）的告警能力、企业已经在Snowflake侧搭建了统一的日志出口流程。push模式的延迟更低，不会因为日志量过大出现拉取超时、数据遗漏的问题，但是需要在Snowflake侧开发推送逻辑，配置复杂度更高

内容的提问来源于stack exchange，提问作者sasikant