Linux Cgroups v2 Metric Collection — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

Linux Cgroups v2: พื้นฐานและวิวัฒนาการสู่การจัดการทรัพยากรระดับใหม่

ในโลกของระบบคลาวด์และคอนเทนเนอร์ที่ขับเคลื่อนด้วยไมโครเซอร์วิส การจัดการและควบคุมการใช้ทรัพยากรระบบอย่างมีประสิทธิภาพคือหัวใจสำคัญของการรักษาเสถียรภาพและประสิทธิภาพ Linux Control Groups หรือที่รู้จักกันในชื่อ Cgroups เป็นฟีเจอร์เคอร์เนลที่ทรงพลังซึ่งทำหน้าที่นี้มาตั้งแต่ปี 2007 สำหรับ Cgroups เวอร์ชัน 2 (cgroup v2) ที่เปิดตัวอย่างเป็นทางการใน Linux kernel 4.5 นั้น ถือเป็นการออกแบบใหม่ทั้งหมดที่นำมาซึ่งความเรียบง่าย ความสม่ำเสมอ และความสามารถใหม่ๆ ที่ขาดหายไปในเวอร์ชันแรก การรวบรวมเมตริก (Metric Collection) จาก cgroup v2 จึงกลายเป็นทักษะที่จำเป็นสำหรับ DevOps Engineer, SRE และ Developer ในการดีบัก ปรับแต่งประสิทธิภาพ และรับประกันการทำงานร่วมกันของแอปพลิเคชันในสภาพแวดล้อมที่ทันสมัย

cgroup v2 แก้ไขข้อจำกัดและความซับซ้อนของ cgroup v1 โดยนำเสนอ hierarchical tree เพียงต้นเดียว (unified hierarchy) แทนที่ระบบหลายต้น (multiple hierarchies) ที่ควบคุมทรัพยากรคนละชนิดใน v1 โครงสร้างแบบรวมศูนย์นี้ทำให้การจัดการและการติดตามเป็นไปอย่างมีเหตุผลและครอบคลุมทุกประเภททรัพยากร ได้แก่ CPU, Memory, I/O, และ Network ภายใต้โครงสร้างเดียวกัน นี่คือรากฐานที่ทำให้การรวบรวมเมตริกมีความสมบูรณ์และเชื่อมโยงกันมากกว่าเดิม

สถาปัตยกรรม Cgroups v2 และตำแหน่งของเมตริกในไฟล์ระบบ

หัวใจของการรวบรวมเมตริกจาก cgroup v2 อยู่ที่การเข้าใจโครงสร้างไฟล์ระบบเสมือน (virtual filesystem) โดยทั่วไปแล้ว cgroup v2 จะถูก mount ที่ /sys/fs/cgroup ภายในโฟลเดอร์นี้ คุณจะพบกับ hierarchical tree ของ cgroup ต่างๆ ซึ่งแต่ละโหนดหรือแต่ละ cgroup จะมีไฟล์พิเศษ (special files) ปรากฏอยู่ ไฟล์เหล่านี้แบ่งออกเป็นสองประเภทหลัก: ไฟล์ควบคุม (control files)cgroup.procs, cpu.max และ ไฟล์เมตริก (metric files)memory.current, cpu.stat

โครงสร้างไดเรกทอรีและไฟล์เมตริกสำคัญ

เมื่อคุณสำรวจ /sys/fs/cgroup คุณจะเห็นโครงสร้างดังนี้:

/sys/fs/cgroup/
├── cgroup.controllers
├── cgroup.subtree_control
├── system.slice/
│   ├── docker-.scope/
│   │   ├── memory.current
│   │   ├── memory.stat
│   │   ├── cpu.stat
│   │   ├── io.stat
│   │   └── cgroup.procs
│   └── sshd.service/
├── user.slice/
└── kubepods.slice/
    └── pod-/
        ├── container-1/
        └── container-2/

ไฟล์เมตริกที่สำคัญที่สุดสำหรับการเก็บข้อมูลมีดังนี้:

• CPU: cpu.stat (แสดงสถิติ usage, throttling), cpu.pressure (แสดง Pressure Stall Information)
• Memory: memory.current (การใช้ memory ปัจจุบัน), memory.stat (สถิติแบบละเอียด), memory.swap.current (การใช้ swap), memory.pressure
• I/O: io.stat (แสดง bytes read/write, I/O operations สำหรับแต่ละอุปกรณ์บล็อก)
• Generic: cgroup.events (เช่น โปรเซสที่ถูกฆ่าเนื่องจาก OOM)

เทคนิคการรวบรวมเมตริก: จากคำสั่งพื้นฐานสู่การเขียนสคริปต์

การดึงข้อมูลเมตริกสามารถทำได้หลายระดับ ตั้งแต่การใช้คำสั่ง shell พื้นฐานไปจนถึงการพัฒนาสคริปต์หรือแอปพลิเคชันที่ซับซ้อน

การอ่านเมตริกด้วยมือผ่าน Command Line

สำหรับการตรวจสอบอย่างรวดเร็วหรือการดีบัก คำสั่ง cat และ grep คือเครื่องมือที่ใช้ง่ายที่สุด

# ตรวจสอบการใช้ memory ของคอนเทนเนอร์ Docker
CONTAINER_ID="your_container_id"
CGROUP_PATH="/sys/fs/cgroup/system.slice/docker-${CONTAINER_ID}.scope"

echo "Memory Usage:"
cat ${CGROUP_PATH}/memory.current
echo " bytes"

echo -e "\nCPU Statistics:"
cat ${CGROUP_PATH}/cpu.stat

echo -e "\nI/O Statistics:"
cat ${CGROUP_PATH}/io.stat

นอกจากนี้ยังมีเครื่องมือระดับสูงที่ออกแบบมาสำหรับ cgroup v2 โดยเฉพาะ เช่น systemd-cgtop สำหรับดูการใช้ทรัพยากรแบบเรียลไทม์ หรือ bpftrace สำหรับการติดตามเหตุการณ์ระดับเคอร์เนล

การเขียนสคริปต์ Python สำหรับรวบรวมเมตริกอย่างเป็นระบบ

สำหรับการรวบรวมเมตริกเป็นระยะๆ เพื่อส่งไปยังระบบ monitoring เช่น Prometheus การเขียนสคริปต์ด้วย Python จะมีความยืดหยุ่นมากกว่า ตัวอย่างด้านล่างแสดงการอ่านเมตริกหลักจาก cgroup path ที่กำหนด

#!/usr/bin/env python3
import os
import time
import json

def read_cgroup_metrics(cgroup_path):
    """อ่านเมตริกจาก cgroup path ที่กำหนด"""
    metrics = {}
    
    # อ่าน memory metrics
    try:
        with open(os.path.join(cgroup_path, 'memory.current'), 'r') as f:
            metrics['memory_usage_bytes'] = int(f.read().strip())
        with open(os.path.join(cgroup_path, 'memory.stat'), 'r') as f:
            for line in f:
                key, val = line.split()
                metrics[f'memory_stat_{key}'] = int(val)
    except FileNotFoundError:
        pass
    
    # อ่าน cpu metrics
    try:
        with open(os.path.join(cgroup_path, 'cpu.stat'), 'r') as f:
            for line in f:
                key, val = line.split()
                metrics[f'cpu_stat_{key}'] = int(val)
    except FileNotFoundError:
        pass
    
    # อ่าน io metrics
    try:
        with open(os.path.join(cgroup_path, 'io.stat'), 'r') as f:
            # รูปแบบ: 254:0 rbytes=12345 wbytes=67890 rios=100 wios=50 ...
            io_data = f.read().strip()
            # ... (โค้ดสำหรับ parse io.stat)
    except FileNotFoundError:
        pass
    
    return metrics

if __name__ == "__main__":
    # ตัวอย่าง: อ่านเมตริกจาก cgroup ของคอนเทนเนอร์
    cgroup_path = "/sys/fs/cgroup/system.slice/docker-abc123.scope"
    metrics = read_cgroup_metrics(cgroup_path)
    print(json.dumps(metrics, indent=2))

การผสานรวมกับระบบ Monitoring และ Visualization ระดับองค์กร

เมตริกที่ดึงมาจาก cgroup v2 จะมีค่ามากที่สุดเมื่อถูกส่งไปยังระบบกลางสำหรับการเก็บบันทึก (logging) การตรวจสอบ (monitoring) และการแสดงผล (visualization)

Prometheus และ cAdvisor: คู่หูมาตรฐานสำหรับคอนเทนเนอร์

cAdvisor (Container Advisor) จาก Google เป็นเครื่องมือที่นิยมที่สุดสำหรับการรวบรวมเมตริกจากคอนเทนเนอร์โดยอัตโนมัติ โดย cAdvisor จะสแกน hierarchy ของ cgroup v2 และส่งออกเมตริกในรูปแบบที่ Prometheus สามารถดึงข้อมูล (scrape) ได้ ปัจจุบัน cAdvisor รองรับ cgroup v2 อย่างเต็มที่แล้ว

• การติดตั้ง: cAdvisor สามารถรันเป็นคอนเทนเนอร์หรือ DaemonSet บน Kubernetes ได้โดยตรง
• เมตริกที่ได้: container_cpu_usage_seconds_total, container_memory_working_set_bytes, container_fs_io_current เป็นต้น
• ข้อดี: ติดตั้งง่าย, รองรับหลายรันไทม์ (Docker, containerd, CRI-O), ผสานรวมกับ Prometheus ได้ทันที

การใช้ Node Exporter และ Textfile Collector

สำหรับ workload ที่ไม่ใช่คอนเทนเนอร์หรือการรวบรวมเมตริกแบบเฉพาะทาง เราสามารถใช้ Prometheus Node Exporter ร่วมกับ Textfile Collector ได้ โดยเขียนสคริปต์ (เช่น ใน Python หรือ Bash) เพื่อรวบรวมเมตริกจาก cgroup v2 และเขียนผลลัพธ์ออกมาเป็นไฟล์ข้อความในรูปแบบ Prometheus exposition format ที่ /var/lib/node_exporter/textfile_collector/ จากนั้น Node Exporter จะอ่านไฟล์นี้และส่งออกเมตริกให้ Prometheus ดึงข้อมูลไปได้

การส่งเมตริกไปยังระบบอื่นๆ

• StatsD/Graphite: ส่งเมตริกผ่าน UDP โดยใช้ไลบรารี client ในภาษาต่างๆ
• InfluxDB/Telegraf: ใช้ Telegraf’s exec input plugin เพื่อรันสคริปต์รวบรวมเมตริกและส่งข้อมูลไปยัง InfluxDB
• Datadog/Loki: ใช้ Agent ของแพลตฟอร์มนั้นๆ ซึ่งมักมี built-in support สำหรับ cgroup metrics อยู่แล้ว

การวิเคราะห์เมตริก: การตีความข้อมูลและใช้ในการดีบัก

การได้เมตริกมานั้นเป็นเพียงครึ่งทาง การตีความข้อมูลให้ถูกต้องเพื่อหาสาเหตุของปัญหา (root cause analysis) เป็นทักษะที่สำคัญยิ่ง

การวิเคราะห์ปัญหา Performance ทั่วไป

Pressure Stall Information (PSI) – ตัวบ่งชี้ความแออัดระดับใหม่

หนึ่งในฟีเจอร์ที่สำคัญที่สุดของ cgroup v2 คือ Pressure Stall Information (PSI) ซึ่งวัด “ความแออัด” ของทรัพยากรในรูปของเวลาที่งานต้องรอคอยเนื่องจากทรัพยากรเต็ม PSI จะแสดงในไฟล์ cpu.pressure, memory.pressure, และ io.pressure

• รูปแบบ: avg10=0.00 avg60=0.00 avg300=0.00 total=0
• การตีความ: ค่า avg10=5.00 หมายความว่าในช่วง 10 วินาทีที่ผ่านมา มีบางช่วงเวลาที่งานต้องรอคอยทรัพยากรนี้เฉลี่ย 5% ของเวลา ค่า PSI ที่สูง (มากกว่า 1-2%) มักบ่งชี้ถึงปัญหาคอขวดที่ควรได้รับการแก้ไข

แนวทางปฏิบัติที่ดีที่สุด (Best Practices) สำหรับการรวบรวมเมตริก Cgroups v2

เพื่อให้ระบบการรวบรวมเมตริกมีประสิทธิภาพและยั่งยืน ควรปฏิบัติตามแนวทางดังต่อไปนี้

1. เลือกเลเยอร์การรวบรวมเมตริกที่เหมาะสม

• ระดับคอนเทนเนอร์: เหมาะสำหรับการดีบักและปรับแต่งแอปพลิเคชันแต่ละตัว
• ระดับ Pod (Kubernetes): เหมาะสำหรับการเข้าใจพฤติกรรมของไมโครเซอร์วิสทั้งกลุ่มที่ทำงานร่วมกัน
• ระดับบริการ/ระบบ: เหมาะสำหรับการวางแผนความจุ (capacity planning) และ monitoring ภาพรวมของโหนดหรือ host

2. กำหนดขอบเขตและความถี่ในการเก็บข้อมูล

การรวบรวมเมตริกทุกๆ 1 วินาทีอาจสร้างภาระให้กับระบบมากเกินไป สำหรับการตรวจสอบสุขภาพ (health monitoring) การเก็บข้อมูลทุก 15-30 วินาทีก็เพียงพอแล้ว สำหรับการวิเคราะห์ประสิทธิภาพ (performance analysis) อาจต้องการข้อมูลทุก 1-5 วินาที ควรใช้การสุ่มตัวอย่าง (sampling) สำหรับเมตริกความละเอียดสูงแทนการบันทึกทุกเหตุการณ์

3. จัดการกับเมตริกที่ขาดหาย (Missing Metrics) อย่างสง่างาม

cgroup hierarchy อาจเปลี่ยนแปลงได้ตลอดเวลา (คอนเทนเนอร์ถูกสร้าง/ลบ) สคริปต์หรือ exporter ต้องสามารถรับมือกับกรณีที่ cgroup path หายไปได้โดยไม่ crash และควรมีระบบ alert เมื่อพบว่าเมตริกจาก workload สำคัญขาดหายไปเป็นเวลานาน

4. ความปลอดภัยและสิทธิ์การเข้าถึง

การอ่านไฟล์ใน /sys/fs/cgroup มักต้องการสิทธิ์ root หรือการกำหนด capability ที่เหมาะสม (เช่น CAP_SYS_ADMIN) ควรรัน exporter หรือสคริปต์ด้วยสิทธิ์ที่จำกัดที่สุด (principle of least privilege) และพิจารณาใช้ user namespace หรือ seccomp profiles เพื่อลดความเสี่ยงด้านความปลอดภัย

5. การเปรียบเทียบ Cgroups v1 และ v2 สำหรับการรวบรวมเมตริก

กรณีศึกษาในโลกจริง (Real-World Use Cases)

Use Case 1: การปรับแต่ง Resource Limit บน Kubernetes Cluster

บริษัทหนึ่งพบว่าแอปพลิเคชันบาง Pod บน Kubernetes ถูกฆ่าบ่อยครั้งโดยไม่ทราบสาเหตุ ทีม SRE ใช้ cAdvisor ที่รองรับ cgroup v2 เพื่อรวบรวมเมตริกและพบว่า container_memory_working_set_bytes ใกล้เคียงกับ limit ที่ตั้งไว้เสมอ และพบเหตุการณ์ OOM kill ในเมตริก การแก้ไขคือการเพิ่ม memory limit และ request ให้เหมาะสม พร้อมทั้งเพิ่มการแจ้งเตือนเมื่อการใช้ memory เกิน 80% ของ limit เป็นเวลาต่อเนื่อง

Use Case 2: การดีบัก Performance Degradation ของฐานข้อมูลในคอนเทนเนอร์

แอปพลิเคชันฐานข้อมูลที่รันใน Docker container มี performance ลดลงเป็นช่วงๆ ทีมพัฒนาติดตั้ง Node Exporter พร้อม custom textfile collector script เพื่ออ่าน io.stat และ io.pressure จาก cgroup ของคอนเทนเนอร์ทุก 10 วินาที ผลการวิเคราะห์พบว่า ค่า avg60 ใน io.pressure สูงขึ้นพร้อมๆ กับเวลาตอบสนองที่เพิ่มขึ้น ซึ่งชี้ให้เห็นถึงปัญหาคอขวดด้าน I/O บน host ที่แชร์กันกับคอนเทนเนอร์อื่น การย้าย volume ไปใช้ local SSD แยกส่วนช่วยแก้ปัญหาได้

Use Case 3: การวางแผนความจุ (Capacity Planning) สำหรับ Multi-Tenant Platform

ผู้ให้บริการ Platform-as-a-Service (PaaS) ต้องการทราบว่า tenant แต่ละรายใช้ทรัพยากรจริงเท่าใด เพื่อการคิดค่าบริการและวางแผนขยายระบบ แทนที่จะเชื่อข้อมูลจาก request/limit ใน Kubernetes เท่านั้น ทีมพัฒนาสร้าง internal metric collector ที่อ่าน cpu.stat (usage_usec), memory.current, และ io.stat จาก cgroup v2 ของแต่ละ namespace (tenant) โดยตรง ข้อมูลการใช้ทรัพยากรจริงนี้ถูกนำไปสร้าง chargeback report และใช้ตัดสินใจในการเพิ่มโหนด worker เข้าสู่คลัสเตอร์ได้อย่างแม่นยำ

Summary

การรวบรวมและวิเคราะห์เมตริกจาก Linux Cgroups v2 เป็นความสามารถที่ขาดไม่ได้ในยุคที่คอนเทนเนอร์และระบบคลาวด์-เนทีฟครองโลก เทคโนโลยีนี้ให้หน้าต่างที่มองเห็นการใช้งานทรัพยากรในระดับที่ลึกและแม่นยำกว่าเครื่องมือระดับผู้ใช้ทั่วไป การเริ่มต้นจากความเข้าใจโครงสร้างไฟล์ระบบแบบ unified hierarchy การเลือกใช้เครื่องมือที่เหมาะสม (ไม่ว่าจะเป็น cAdvisor, custom script, หรือ node exporter) และการตีความข้อมูลสำคัญอย่าง Pressure Stall Information (PSI) จะช่วยให้ทีมพัฒนาสามารถป้องกันปัญหา ปรับแต่งประสิทธิภาพ และรับประกันคุณภาพการให้บริการ (SLA) ของแอปพลิเคชันได้อย่างมีประสิทธิภาพ เนื่องจากการรองรับ cgroup v2 กลายเป็นมาตรฐานใน Linux distribution และเครื่องมือ orchestration ยุคใหม่ การลงทุนศึกษาและปรับกระบวนการ monitoring ให้ใช้ประโยชน์จาก cgroup v2 ได้เต็มที่จึงเป็นการลงทุนที่คุ้มค่าและจำเป็นสำหรับองค์กรที่มุ่งเน้นทางด้านเทคนิคในปี 2026 และต่อไปในอนาคต