AKS中.NET Core应用崩溃诊断方案咨询（基于Application Insights）

我来帮你梳理几个实用的方案，刚好覆盖你需要的崩溃告警和诊断信息收集两大需求：

一、崩溃告警机制 #

1. Prometheus + Alertmanager 组合 #

这是Kubernetes生态里最常用的监控告警方案：

• 先在AKS集群用Helm一键部署Prometheus，它会自动采集kube_pod_container_status_restarts_total这类Pod重启核心指标。
• 编写自定义告警规则，比如设置“5分钟内Pod重启次数≥2”就触发告警（阈值可以根据你的业务稳定性要求调整）。
• 搭配Alertmanager，配置邮件、Slack、Teams等常用通知渠道，一旦触发告警就能第一时间收到提醒。

2. Azure Monitor 原生告警 #

如果你更倾向于Azure原生工具链，Azure Monitor for Containers完全能满足需求：

• 开启AKS的Azure Monitor集成后，直接在Azure门户创建告警规则，比如选择“Pod异常终止”“Pod重启次数过多”这类预设信号。
• 还能关联Application Insights的日志数据，比如写查询语句筛选包含StackOverflow、OutOfMemory或非0退出码的应用日志，设置告警阈值。
• 支持邮件、短信、Azure Logic Apps等多种通知方式，甚至能自动触发后续的故障排查流程。

3. Application Insights 自定义日志告警 #

虽然ApplicationInsights-Kubernetes没有自带崩溃告警，但可以手动捕获崩溃信号：

• 确保你的应用把崩溃时的异常日志输出到容器标准输出/错误流，通过容器日志采集把这些日志同步到Application Insights。
• 在AI里创建日志查询告警，比如用下面的Kusto语句筛选崩溃相关日志：

  ContainerLogs
  | where Message contains "StackOverflowException" or Message contains "OutOfMemoryException" or ExitCode != 0
  | summarize count() by bin(TimeGenerated, 5m)
  | where count_ > 0
  

• 设置当查询结果非空时触发告警，配置邮件通知即可。

二、崩溃转储与诊断信息收集 #

1. 容器内配置自动生成崩溃转储 #

针对不同技术栈，在Dockerfile里配置转储工具，让进程崩溃时自动生成转储文件：

• .NET应用：安装procdump工具，在启动命令里配置捕获转储：

  RUN apt-get update && apt-get install -y wget
  RUN wget https://download.sysinternals.com/files/Procdump.zip && unzip Procdump.zip && rm Procdump.zip
  ENTRYPOINT ["procdump", "-ma", "-e", "-f", "", "your-app.exe"]
  

  然后把转储文件挂载到Persistent Volume（PV），或者用azcopy工具自动上传到Azure Blob Storage。
• Java应用：使用jmap或jstack，在启动脚本里添加捕获逻辑：

  trap 'jmap -dump:format=b,file=/dump/heapdump.hprof $PID' EXIT
  

2. 利用Azure Monitor收集诊断数据 #

• 开启AKS的诊断设置，把Pod事件、容器日志、节点指标都发送到Log Analytics Workspace。
• 对于生成的崩溃转储文件，在容器里配置自动上传到Azure Blob Storage，之后可以在Log Analytics里通过日志查询关联转储文件路径，方便后续下载分析。
• 还可以查看Kubernetes的Pod事件，比如当Pod因OOM被Kill时，Kubernetes会记录OOMKilled事件，查询KubePodEvents表就能快速定位这类问题。

3. 应用级异常追踪工具（比如Sentry） #

如果是应用代码层面的崩溃，集成Sentry会更高效：

• 在你的应用里添加Sentry SDK，它能自动捕获未处理异常，生成包含堆栈跟踪、上下文信息的崩溃报告。
• Sentry支持设置告警规则，当特定类型的异常出现时，立即发送通知。
• 在AKS里可以把Sentry作为Sidecar容器部署，或者直接使用Sentry的云服务，配置起来灵活又省心。

三、最佳实践 #

• 确保应用输出足够的上下文日志：比如崩溃前的内存使用、请求参数、线程状态，这些信息能大大降低排查难度。
• 给Pod设置合理的资源限制（CPU/内存），并监控资源使用率，提前预警OOM风险。
• 定期测试告警和转储功能：模拟一次StackOverflow或OOM崩溃，验证告警是否触发、转储文件是否正常生成并可访问。

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