通过Log Analytics API访问AppInsights请求数据遇表名无效问题求解

核心原因 #

你当前调用的是Log Analytics工作区API，但默认上下文是整个工作区，和UI里选AppInsights实例作为查询范围的上下文不一致：

• 在UI选择AppInsights实例时，默认使用该实例的专属上下文，requests是合法表名；
• 直接调用工作区API时，工作区中存储的AppInsights数据要么是带App前缀的表名（如AppRequests），要么需要明确指定AppInsights实例范围才能使用原生表名。

三种解决办法 #

办法1：在查询中用app()指定AppInsights范围 #

修改查询内容，通过app()函数明确指定目标AppInsights资源，这样即使请求工作区API，也能使用requests原生表名：

{
    "query": "app('/subscriptions/<你的订阅ID>/resourceGroups/<资源组名>/providers/microsoft.insights/components/<AppInsights实例名>').requests | where success == false "
}

提示：也可以直接将AppInsights的Instrumentation Key作为app()的参数使用。

办法2：改用工作区中的标准表名 #

如果你的AppInsights是工作区关联型，工作区中存储的请求数据对应的表名为AppRequests，将查询里的requests替换为该表名即可：

{
    "query": "AppRequests | where success == false "
}

办法3：直接调用Application Insights专属API #

如果是未关联工作区的经典AppInsights，直接使用它的专属API更适配：

1. 认证请求中的resource参数修改为https://api.applicationinsights.io；
2. 请求URL更换为：

   POST https://api.applicationinsights.io/v1/apps/<你的AppInsights Instrumentation Key>/query?timespan=P1D
   

3. 查询语句保持requests | where success == false不变。

注意事项 #

• 确保你的服务主体（client_id对应的应用）拥有目标AppInsights或Log Analytics工作区的Log Analytics Reader权限；
• 认证时的resource参数要与API域名对应，不要混淆。

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