Azure Kubernetes Service：查找因OOM被终止Pod的日志及原因

1. 先确认日志采集配置 #

• 检查AKS集群是否开启了kubelet日志采集：在Azure门户进入AKS集群，到「监控」→「日志」，确认已勾选kubelet日志类别。如果没开启，需要重新配置日志采集，否则kubelet生成的OOM事件不会进入Log Analytics。
• 验证采集是否生效，运行以下KQL查询：

  AzureDiagnostics
  | where Category == "kubelet"
  | take 10
  

  无结果则说明日志未被正确采集，先解决采集问题再查日志。

2. 精准查询OOM相关记录 #

方案1：从kubelet日志中筛选OOM事件 #

AzureDiagnostics
| where Category == "kubelet"
| where Message has_any ("OOMKilled", "memory limit exceeded")
| project TimeGenerated, 
          PodName = tostring(parse_json(Message).pod.name),
          ContainerName = tostring(parse_json(Message).container.name),
          Message
| sort by TimeGenerated desc

方案2：查询Kubernetes事件表（KubeEvents） #

Kubernetes会为OOM终止的Pod生成事件，直接查这个表更高效：

KubeEvents
| where Reason == "OOMKilled"
| project TimeGenerated, PodName, Namespace, Message, Reason
| sort by TimeGenerated desc

方案3：检查容器自身日志 #

如果容器在OOM前有内存告警输出，可查ContainerLog表：

ContainerLog
| where LogEntry has_any ("out of memory", "OOM")
| project TimeGenerated, PodName, ContainerName, LogEntry
| sort by TimeGenerated desc

3. 直接在集群内排查 #

如果Log Analytics查询无结果，直接通过kubectl查看Pod详情：

kubectl describe pod <你的Pod名称> -n <命名空间>

在输出的Events板块，会明确显示Pod是否因OOMKilled被终止，同时能看到内存限制和实际使用量的对比。

如果有权限登录AKS节点，还可以查看kubelet的本地日志：

journalctl -u kubelet | grep -i oom

4. 常见坑点 #

• 遗漏命名空间：查询时记得加上Namespace过滤，避免跨命名空间的Pod干扰结果。
• 时间范围错误：确保查询的时间窗口完全覆盖Pod终止的时间段，尤其是短生命周期的Pod。
• 混淆日志表：不要只盯着AzureDiagnostics，KubeEvents是Kubernetes事件的专属存储，OOM事件大概率在这里。

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