Spring Boot服务在Kubernetes中OOMKilled：OOM Score相关Prometheus指标问询

1. 是否存在与oom_score相关的Prometheus指标？ #

存在，通过node-exporter可以采集到两个核心进程OOM相关指标：

• node_process_oom_score: 进程当前的实际OOM分数（范围0-1000，分数越高越容易被OOM Killer选中终止）
• node_process_oom_score_adj: 进程的OOM分数调整值（可通过/proc/<pid>/oom_score_adj手动设置，范围-1000到1000，负数会降低进程被杀死的优先级）

这两个指标会携带进程PID、命令行参数（node_process_cmdline）、节点名等标签，可精准定位到Kubernetes容器内的目标进程（比如你的Java Spring Boot进程）。

2. 如何监控oom_score并设置自动告警？ #

步骤1：确认node-exporter部署状态 #

确保集群每个节点都部署了node-exporter，且默认启用proc采集模块（默认开启，无需额外配置）——该模块负责读取/proc文件系统下的进程OOM相关数据。

步骤2：编写PromQL查询定位目标进程 #

结合命令行标签过滤，定位你的Spring Boot进程的OOM分数：

node_process_oom_score{node="目标节点名", node_process_cmdline=~".*spring-boot.*|.*your-app.jar.*"}

若需关联Kubernetes Pod信息，可通过节点标签关联kube_pod_info指标：

node_process_oom_score
  * on(node) group_left(pod) kube_pod_info{namespace="你的命名空间", pod=~"你的应用Pod前缀.*"}

步骤3：配置Prometheus告警规则 #

在告警规则文件中添加以下规则，当进程OOM分数接近危险阈值（比如900）时触发告警：

groups:
- name: oom-risk-alerts
  rules:
  - alert: HighOOMScoreRisk
    expr: node_process_oom_score{node_process_cmdline=~".*spring-boot.*"} >= 900
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "进程OOM分数过高（{{ $value }}）"
      description: "节点 {{ $labels.node }} 上的进程 {{ $labels.node_process_cmdline }} OOM分数已达{{ $value }}，存在被OOM Killer终止的高风险"

3. 可用于预警OOMKilled发生的其他指标 #

除了OOM分数，以下几类指标可提前发现容器OOM风险：

Kubernetes容器层面指标 #

• 内存使用率：监控容器内存使用接近限制的情况，提前触发扩容或配置调整：

  (container_memory_usage_bytes{namespace="你的命名空间", pod=~"你的应用Pod前缀.*"} / container_memory_limit_bytes{namespace="你的命名空间", pod=~"你的应用Pod前缀.*"}) * 100 >= 80
  

• 容器重启次数：重启次数激增是OOMKilled的直接表现之一：

  increase(kube_pod_container_status_restarts_total{namespace="你的命名空间", pod=~"你的应用Pod前缀.*"}[10m]) > 0
  

• 历史终止原因：监控是否出现过OOMKilled记录，提前排查潜在问题：

  kube_pod_container_status_last_terminated_reason{namespace="你的命名空间", pod=~"你的应用Pod前缀.*", reason="OOMKilled"} == 1
  

JVM与进程内存细节指标 #

• 非堆内存与直接内存：JVM的非堆内存（元空间、代码缓存）、直接内存（DirectByteBuffer）不计入堆内存，但会占用容器内存：

  jvm_memory_used_bytes{area="nonheap", namespace="你的命名空间", pod=~"你的应用Pod前缀.*"} + jvm_buffer_memory_used_bytes{namespace="你的命名空间", pod=~"你的应用Pod前缀.*"}
  

• 进程常驻内存（RSS）：container_memory_rss反映进程实际占用的物理内存，若持续接近容器limit，风险极高：

  container_memory_rss{namespace="你的命名空间", pod=~"你的应用Pod前缀.*"} / container_memory_limit_bytes{namespace="你的命名空间", pod=~"你的应用Pod前缀.*"} * 100 >= 90
  

节点层面指标 #

• 节点可用内存：节点整体内存不足时，容器被OOM Kill的概率会显著提升：

  (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 <= 20
  

补充说明 #

你提到的提升resources.requests.memory和resources.limits.memory确实能直接解决当前的OOMKilled问题，但通过上述指标监控可以提前发现内存瓶颈，避免业务突发中断。

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