【App Service】排查App Service中发送Application Insights日志数据问题的神级脚本: Test-AppInsightsTelemetryFlow.ps1

简介: 本文介绍 Azure 中国区 Application Insights 日志无数据问题的排查利器——微软官方诊断脚本 `Test-AppInsightsTelemetryFlow.ps1`。该脚本可逐层验证 SDK、网络、TLS、ingestion endpoint 等遥测链路,精准定位日志丢失环节,支持 PowerShell(Windows)和 Bash(Linux),大幅提升故障排查效率。(239字)

问题描述

在 Azure Application Insights 故障排查过程中,经常会遇到这样一类典型问题:

  • SDK 已经部署
  • Connection String 已配置
  • 应用运行正常
  • 但 App Insights Portal 中完全没有任何日志数据(指标,请求记录,应用中输出的日志)

我们通常会问一个问题:“我的代码到底有没有成功把日志数据发到 Application Insights?”

遗憾的是,而我们几乎无法确定,且没有有效的工具来帮助定位问题,到底这个问题发生在那里呢?

  • 日志数据是在 SDK 层丢失?
  • 还是被网络拦截?
  • 还是 ingestion endpoint (https://chinanorth3-0.in.applicationinsights.azure.cn/v2/track) 不通?
  • .... ....

 

问题解答

非常好的消息是,微软Application Insights团队提供了一个神级脚本 (Test-AppInsightsTelemetryFlow.ps1) , 可以在你的应用环境中通过执行PowerShell脚本来监测日志收集过程中的全部环节。

它的官方介绍:https://github.com/microsoft/appinsights-telemetry-flow

适用于 Azure Application Insights 的自助诊断脚本。

直接在运行您的应用程序的机器上,验证连接性、TLS、AMPLS/Private Link、数据引入、采样、工作区健康状况以及代理安装。

支持 PowerShell(Windows)和 Bash(Linux)。

遥测流程概览

从宏观层面来看,遥测数据从您的应用程序(或此诊断脚本)出发,依次流经以下阶段:

每个方框代表一个层,该层可能会独立发生故障、性能下降或静默丢失数据。脚本会从上到下测试每一层。

要详细了解每一层的功能、故障原因以及脚本如何检测故障,请参阅官方文档中的架构介绍部分: https://github.com/microsoft/appinsights-telemetry-flow/blob/main/docs/architecture.md , 本文主要是通过在中国区Azure的App Service上演示如何使用这个神级脚本:Test-AppInsightsTelemetryFlow.ps1

 

实际演示

第一步:登录App Service的Kudu站点( https://<your app service name>.scm.chinacloudsites.cn ),进入Debug Console Powershell

使用脚本尝试下载脚本Test-AppInsightsTelemetryFlow.ps1

Invoke-WebRequest -Uri "https://raw.githubusercontent.com/microsoft/appinsights-telemetry-flow/main/powershell/Test-AppInsightsTelemetryFlow.ps1" -OutFile "Test-AppInsightsTelemetryFlow.ps1"

因为中国区Azure App Service的所在的环境访问github会出现连不上的情况,所以可以在一个稳定访问github的环境中下载这个脚本文件后,直接拖拽到App Service上或通过新建文件把脚本内容复制上去也可。


PS: 也可以从这里下载脚本文件:https://files.cnblogs.com/files/lulight/Test-AppInsightsTelemetryFlow.zip?t=1776861726&download=true


 

第二步:直接运行 .\Test-AppInsightsTelemetryFlow.ps1 并检查运行结果

执行  .\Test-AppInsightsTelemetryFlow.ps1  或者  .\Test-AppInsightsTelemetryFlow.ps1 -AutoApprove

然后进入Application Insights中查看 availabilityResults 中是否有数据

 

演示动画

 

 

参考资料

Application Insights Telemetry Flow Troubleshooters :https://github.com/microsoft/appinsights-telemetry-flow

 



当在复杂的环境中面临问题,格物之道需:浊而静之徐清,安以动之徐生。 云中,恰是如此!

相关文章
|
14天前
|
NoSQL 网络协议 Cloud Native
【Azure Redis】云原生环境下的 Redis 超时之谜:为什么 15 分钟后应用才恢复?
云原生中Redis短暂不可用后应用持续超时15分钟?问题不在Redis,而在Linux TCP默认重传机制(tcp_retries2=15)与长连接模型的错位。需三管齐下:调低内核重传次数、客户端显式配置超时与自动重连、应用层引入断路器与弹性重试。
136 20
|
17天前
|
网络协议 虚拟化 Docker
【Azure Developer】.NET Aspire 启动报错:listen tcp bind: An attempt was made to access a socket in a way forbidden by its access permissions
.NET Aspire在Windows启动时因Hyper-V端口保留机制,导致DCP代理无法绑定53209等端口(报错“访问被拒绝”)。虽端口未被占用,但已被系统保留。推荐方案:修改launchSettings.json,将服务端口改为7xxx等安全范围;或临时重启winnat服务、永久排除指定端口。
352 20
|
11天前
|
前端开发 应用服务中间件 Linux
【Azure App Service】PHP页面上传文件413错误的解决方案
在使用 Azure App Service(Linux + PHP) 部署 Web 应用时,如果上传文件大于1MB,就会遇到 HTTP 413(Request Entity Too Large) 错误。 # 问题解答 ### 一、HTTP 413 错误的本质含义 413 Request Entity Too Large 是标准 HTTP 状态码,表示: > 客户端提交的请求体(Request Body)大小超过了服务器当前允许的最大限制。 在 Azure App Service(Linux)环境中,这个错误并不一定来自前端网关(Frontend),而更常见的来源是 App...
332 12
|
3天前
|
人工智能 监控 网络协议
【App Service】常规排查 App Service 启动 Application Insights 无数据的步骤 (.NET版本)
本文详解Application Insights在Azure App Service中无日志数据的三大原因及排查方法:1)网络连通性(验证到AI端点的443端口访问);2)w3wp.exe进程是否成功加载AI模块;3)DLL冲突(检查并移除重复的Microsoft.ApplicationInsights等组件)。
64 10
|
10天前
|
数据采集 开发框架 监控
【Azure Developer】IIS w3wp.exe 的 -m 参数:一个未被记录的管道模式标识
本文揭秘了IIS中未公开的`w3wp.exe -m`启动参数:`-m 0`表示Integrated管道模式(推荐),`-m 1`为Classic模式。该发现源于Application Insights自动检测失效的排查,解释了其为何不支持Classic模式——因HttpModule无法全面拦截请求。
97 11
|
1月前
|
人工智能 安全 索引
【Azure AI Search】AI Search的索引器(Indexer)中使用解码函数base64Decode报错
Azure AI Search索引器使用base64Decode时失败,因默认启用URL安全解码(useHttpServerUtilityUrlTokenDecode=true),而源数据为标准Base64编码。解决方案:在mappingFunction中显式设置`&quot;useHttpServerUtilityUrlTokenDecode&quot;: false`,即可正确解码。
158 6
|
30天前
【Azure App Service】为什么 Azure Web App 禁用公网后 Advanced Tools 会失效?
Azure Web App运行正常但Advanced Tools(Kudu)无法访问?根源在于网络访问限制:Kudu作为独立SCM站点,默认沿用主站规则。若主站禁用公网访问而未单独放行Kudu端点,请求将在网络层被阻断。只需为Advanced Tools站点配置独立访问规则即可解决。
【Azure App Service】为什么 Azure Web App 禁用公网后 Advanced Tools 会失效?
|
25天前
|
编解码 前端开发 JavaScript
【Azure APIM】API导入功能报错 Unable to parse specified file.
Azure APIM导入OpenAPI文件报“Unable to parse specified file”错误,表面是格式问题,实则因导出文件含非法Unicode字符(如с),导致UTF-8编码被误读。通过Swagger Editor定位并修正后可正常导入。
|
7月前
|
Java API 开发工具
【Azure Developer】Java代码实现获取Azure 资源的指标数据却报错 "invalid time interval input"
在使用 Java 调用虚拟机 API 获取指标数据时,因本地时区设置非 UTC,导致时间格式解析错误。解决方法是在代码中手动指定时区为 UTC,使用 `ZoneOffset.ofHours(0)` 并结合 `withOffsetSameInstant` 方法进行时区转换,从而避免因时区差异引发的时间格式问题。
363 4
|
8月前
|
API C++
【Azure 环境】VS Code登录China Azure(Function)报错 An error occurred while signing in: invalid_request - AADSTS65002
An error occurred while signing in: invalid_request - AADSTS65002: Consent between first party application 'c27c220f-ce2f-4904-927d-333864217eeb' and first party resource '797f4846-ba00-4fd7-ba43-dac1f8f63013' must be configured via preauthorization - applications owned and operated by Microsoft mus
416 13