Theo Dõi OOM Kill Trong Container Bằng eBPF: Hướng Dẫn Chi Tiết Cho Thám Tử Kernel

Lê Lân

06/07/2025

Giám Sát Container Bị OOM Kill Bằng eBPF: Hướng Dẫn Toàn Diện

Mở Đầu

Out Of Memory (OOM) kills là tín hiệu cảnh báo sớm về tình trạng bão hòa tài nguyên hệ thống trên Linux, đặc biệt trong môi trường container như Kubernetes hay Docker.

Không có gì tệ hơn việc một dịch vụ quan trọng đột ngột ngừng hoạt động vì thiếu bộ nhớ. Khi container vượt quá giới hạn bộ nhớ quy định, hệ thống Linux sẽ kích hoạt cơ chế OOM killer để buộc dừng tiến trình gây tiêu thụ quá mức. Điều này dẫn đến sự cố khó đoán và mất dấu vết của nguyên nhân do tiến trình bị "xóa sổ" không còn tồn tại. Trong bài viết này, chúng ta sẽ khám phá cách sử dụng eBPF - một công cụ giám sát hệ thống hiện đại để theo dõi và phân tích sự kiện OOM kill trong container, giúp bạn chủ động phát hiện và xử lý kịp thời.

OOM Kill Trong Container Xảy Ra Như Thế Nào?

Cơ Chế Giới Hạn Bộ Nhớ Qua cgroups

Container trên Linux thường bị giới hạn tài nguyên thông qua cgroups. Khi bộ nhớ sử dụng vượt quá mức cho phép, kernel sẽ quyết định tiến trình nào bị dừng lại để giải phóng tài nguyên.

Các Nguyên Nhân Gây OOM Kill Container

Bộ nhớ cấp phát không đủ: Container được cấu hình giới hạn bộ nhớ thấp hơn nhu cầu thực tế.

Ứng dụng trong container bị lỗi: Tiến trình chứa rò rỉ bộ nhớ hoặc xử lý không hiệu quả khiến bộ nhớ tăng quá mức.

Kết hợp cả hai: Một ứng dụng không tối ưu chạy trong môi trường giới hạn tài nguyên nghiêm ngặt.

Ảnh Hưởng Của OOM Kill

OOM kill sẽ gửi tín hiệu SIGKILL đến tiến trình bị chọn, khiến tiến trình đó bị chấm dứt ngay lập tức. Nếu tiến trình chính bị kill, container sẽ dừng và thường được khởi động lại, gây gián đoạn dịch vụ và có thể dẫn đến sự cố chuỗi lặp (cascading failures) khi tải lại phân phối cho các container còn lại.

Trường hợp OOM kill nhắm vào tiến trình con thì dấu hiệu rất mơ hồ khiến việc phát hiện nguyên nhân trở nên phức tạp hơn.

eBPF – Công Cụ Theo Dõi OOM Kill Mạnh Mẽ

eBPF Là Gì?

eBPF (extended Berkeley Packet Filter) là công nghệ cho phép chạy các chương trình nhỏ trong kernel Linux một cách an toàn, không cần chỉnh sửa mã nguồn kernel.

Điều này giúp chúng ta có thể "hook" vào hàm kernel như oom_kill_process() để ghi lại các thông số thời gian thực khi OOM xảy ra.

Bộ Công Cụ eBPF Phổ Biến

BCC: Một bộ công cụ truyền thống với nhiều ví dụ phong phú.

bpftrace: Ngôn ngữ khai báo cao cấp, cú pháp dễ đọc và viết nhanh.

Ví dụ: Probe oomkill.bt tích hợp trong bpftrace cho phép ghi lại sự kiện OOM kill kèm PID, tên tiến trình và bộ nhớ sử dụng.

Ví Dụ Kết Quả Chạy bpftrace oomkill.bt

19:44:13 Triggered by PID 1516777 ("python3"), OOM kill of PID 1516777 ("python3"), 32768 pages, loadavg: 0.72 0.64 0.71 3/2230 1517322

Tuy nhiên đầu ra này thiếu ngữ cảnh về container, cần cải tiến probe để hiển thị thông tin container.

Khám Phá Chi Tiết Kernel: oom_kill_process và struct oom_control

Cấu Trúc Tham Số Hàm oom_kill_process

Hàm oom_kill_process(struct oom_control *oc, const char *message) nhận tham số đầu là một struct chứa các thông tin quyết định tiến trình bị kill.

struct oom_control {
    struct mem_cgroup *memcg;        // Nhóm bộ nhớ cgroup container
    struct task_struct *chosen;      // Tiến trình bị chọn OOM kill
    unsigned long totalpages;        // Tổng trang nhớ sử dụng
    long chosen_points;              // Điểm xấu của tiến trình (oom_badness)
    // ... các thành phần khác
};

Ý Nghĩa Các Trường Quan Trọng

Trường	Mô tả
`memcg`	Thông tin cgroup bộ nhớ container, bao gồm giới hạn & sử dụng
`chosen`	Tiến trình bị OOM kill, chứa thông tin bộ nhớ, namespace, PID
`totalpages`	Tổng số trang bộ nhớ yêu cầu khi OOM
`chosen_points`	Điểm oom_badness – thước đo mức độ "xấu" của tiến trình

Điểm oom_badness giúp kernel chọn tiến trình gây áp lực bộ nhớ nhất để tiêu diệt.

Công Thức Tính oom_badness (Tóm Tắt)

PAGE_SIZE thường là 4096 bytes.

Bpftrace Probe Cải Tiến Theo Dõi OOM Kill Trong Container

Mục Tiêu

Hiển thị đầy đủ thông tin liên quan container, bao gồm cgroup, container ID, thông số bộ nhớ.

Phân tích chi tiết bộ nhớ RAM và swap của tiến trình.

Hiển thị điểm oom_badness và các số liệu bộ nhớ trong kernel.

Đoạn Mã bpftrace Cốt Lõi (Đã Rút Gọn)

kprobe:oom_kill_process {
  $oc = (struct oom_control *)arg0;
  printf("%s,%03d probe=\"%s\"\n", strftime("%Y-%m-%d %H:%M:%S", nsecs), (nsecs % 1000000000)/1000000, probe);
  printf("message=\"%s\"\n", str(arg1));
  printf("host_pid=\"%d\" container_id=\"%s\" command=\"%s\"\n", $oc->chosen->pid, $oc->chosen->nsproxy->uts_ns->name.nodename, $oc->chosen->comm);
  printf("oc_totalpages=\"%d\" oc_chosen_points=\"%d\"\n", $oc->totalpages, $oc->chosen_points);
  printf("memcg_memory_usage_pages=\"%d\" memcg_memory_max_pages=\"%d\"\n", $oc->memcg->memory.usage.counter, $oc->memcg->memory.max);
  printf("mm_rss_filepages=\"%d\" mm_rss_anonpages=\"%d\" mm_rss_swapents=\"%d\" mm_rss_shmempages=\"%d\"\n",
          $oc->chosen->mm->rss_stat[0].count,
          $oc->chosen->mm->rss_stat[1].count,
          $oc->chosen->mm->rss_stat[2].count,
          $oc->chosen->mm->rss_stat[3].count);
  printf("proc_oom_score_adj=\"%d\" proc_min_flt=\"%d\" proc_maj_flt=\"%d\"\n", $oc->chosen->signal->oom_score_adj, $oc->chosen->min_flt, $oc->chosen->maj_flt);
}

Thông Tin Ghi Lại

ID container qua namespace UTS

PID tiến trình bị kill

Tổng số trang bộ nhớ, điểm xấu

Sử dụng bộ nhớ cgroup và giới hạn

Thống kê bộ nhớ thực tế chia theo loại (file-backed, anonymous, swap...)

Thông tin page faults (minor & major)

Triển Khai Probe Trong Container

Dockerfile Gợi Ý

FROM debian:stable-slim
RUN apt-get update && \
    apt-get install -y linux-headers-generic bpftrace && \
    rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY *.bt /app/
CMD ["bpftrace", "container_oomkill.bt"]

Chạy Container Probe

docker build -t container-oomkill-probe .
docker run --privileged --pid=host -v /sys:/sys:ro container-oomkill-probe

Cờ --privileged và mount /sys để probe truy cập kernel và cgroup.

Mô Phỏng Kịch Bản Gây OOM Kill Để Kiểm Thử

Script Python Tạo Áp Lực Bộ Nhớ

#!/usr/bin/env python3
import logging, time

logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s: %(message)s")
i = 0
memory = []

while True:
    i += 1
    logging.info(f"Allocating {i * 4} MiB...")
    memory.append(bytearray(4 * 1024 * 1024))
    time.sleep(0.1)

Mỗi vòng lặp cấp phát thêm 4 MiB RAM.

Chạy script trong container có giới hạn bộ nhớ chặt chẽ (ví dụ 128MiB) sẽ sớm bị OOM kill.

Định Nghĩa docker-compose.yml Gồm Probe & Stress-Mem Service

services:
  probe:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - /sys:/sys:ro
    privileged: true
    pid: host

  stress-mem:
    image: python:3-slim
    volumes:
      - ./stress-mem:/app
    working_dir: /app
    command: python3 main.py
    restart: on-failure
    deploy:
      replicas: 1
    resources:
      limits:
        memory: 128MiB
      reservations:
        memory: 64MiB
    memswap_limit: 128MiB  # Disable swap

Kết Quả Thực Tế Quan Sát

Khi swap chưa bị vô hiệu hóa, container sử dụng bộ nhớ vượt quá giới hạn do kernel hoán đổi sang swap (quan sát qua mm_rss_swapents và proc_maj_flt ).

Khi memswap_limit được thiết lập bằng giới hạn bộ nhớ, swap bị vô hiệu hóa, tiến trình bị OOM kill ở mức bộ nhớ gần đúng giới hạn cấu hình.

Vô hiệu hóa swap trong container giúp tránh trường hợp sử dụng hơn bộ nhớ giới hạn gây ra các vấn đề khó dự đoán.

Kết Luận

Chúng ta đã cùng nhau:

Khám phá nguyên lý OOM kill trong môi trường container và tầm quan trọng của việc giám sát.

Hiểu sâu về hàm kernel oom_kill_process và cấu trúc oom_control .

Áp dụng eBPF cùng bpftrace để tạo probe giám sát đầy đủ, chi tiết chỉ số bộ nhớ ngay trong kernel.

Tạo môi trường thử nghiệm thực tế với Docker và docker-compose để kiểm tra hoạt động của probe.

Lời khuyên thực tiễn về cấu hình bộ nhớ và swap trong container để tránh sự cố OOM kill khó kiểm soát.

Hãy bắt đầu sử dụng các công cụ này để chủ động phát hiện và phân tích chính xác các sự cố OOM kill, giảm thiểu tối đa gián đoạn dịch vụ.

Tham Khảo

Brendan Gregg, "Linux Extended BPF (eBPF) Tracing Tools"

Memory Management in Linux - Kernel Documentation

Linux Kernel Source Code - oom_kill_process

cgroups v2 - Kernel Documentation

Docker Compose File Reference

bpftrace Official Repository

SRE Book - Saturation Monitoring

Chúc bạn thành công trong việc nâng cao khả năng giám sát hệ thống container với eBPF! Giữ cho hệ thống của bạn luôn ổn định và tránh khỏi nỗi lo OOM kills không rõ lý do.