查询App Insights trace日志并按customDimensions过滤该用哪种API？

• 2020年之后新创建的App Insights资源，默认采用工作区化存储架构：所有采集的trace、依赖、自定义指标等遥测数据，最终都会持久化到绑定的Log Analytics工作区中，你之前“App Insights数据存在Log Analytics里”的认知完全正确。
• 官方提供的App Insights REST API，本质是针对单个App Insights资源的封装快捷查询接口，底层执行的Kusto查询、计算引擎和Log Analytics REST API完全一致，区别仅仅是它自动帮你绑定了当前App Insights的数据范围，不需要手动传入工作区ID作为查询参数。
• Azure Data Explorer（ADX）是Log Analytics背后的底层分布式分析引擎，对应的预览版.NET SDK是给用户直连自建ADX集群用的接口，并不是用来查托管在Log Analytics里的App Insights数据的。

你的需求非常明确：仅查询单个App Insights下的trace日志，基于customDimensions做过滤，没有跨数据源、大规模实时聚合的需求，直接选App Insights REST API就对了：

• 权限配置最简单：只需要给调用方的服务主体授予对应App Insights资源的读取权限，不需要额外申请Log Analytics工作区的访问权限，完全匹配你“只需要获取App Insights数据源”的目标。
• 查询逻辑最简洁：针对trace的customDimensions过滤不需要额外加范围限定条件，直接写traces | where customDimensions.你的自定义字段 == "过滤值"就能执行，没有额外的语法成本。
• 兼容性兜底：如果你的App Insights是未绑定Log Analytics的经典版资源，它的数据完全独立存储、不会同步到Log Analytics，这种情况下Log Analytics接口根本访问不到对应数据，只有App Insights REST API能正常查询。

关于剩下两个选项的适用边界：

• Log Analytics REST API：只有当你后续需要同时查询同一个工作区内的其他非App Insights数据源（比如虚拟机性能日志、Azure资源审计日志）时才有使用价值，纯查App Insights数据用它属于多做无用功。
• Azure Data Explorer .NET SDK（预览版）：完全不匹配当前场景。首先它是预览版本，生产环境稳定性没有保障；其次它的定位是对接用户自建的ADX集群，要查托管的App Insights数据还需要额外做网络打通、权限适配，徒增不必要的开发和运维成本。

补充注意：不管用哪个查询接口，基于customDimensions过滤的语法都是完全一致的，不存在切换接口就要改语法的迁移成本，所以完全可以从最简单的App Insights REST API开始用，后续有需求再切也不晚。

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