Truy tìm “bóng ma”: Khi các công cụ tiêu chuẩn không nói lên sự thật
Mọi thứ trên lý thuyết đều có vẻ ổn. top cho thấy mức sử dụng CPU chỉ 5%, iostat báo cáo thời gian chờ đĩa không đáng kể, nhưng thời gian phản hồi API của bạn lại tăng vọt lên hàng trăm mili giây. Khi các công cụ tiêu chuẩn ở tầng user-space không thể chỉ ra điểm nghẽn, vấn đề có khả năng nằm sâu trong kernel. Đây chính là lúc Ftrace trở thành công cụ chẩn đoán mạnh mẽ nhất của bạn.
Các công cụ trace truyền thống như strace rất tốt để debug logic, nhưng chúng cực kỳ nặng. Chạy strace trên một tiến trình production có lưu lượng truy cập cao có thể làm nó chậm đi từ 10 đến 50 lần. Ftrace (viết tắt của “Function Tracer”) được tích hợp trực tiếp vào Linux kernel (từ phiên bản 2.6.27). Nó hoạt động với overhead tối thiểu — thường ít hơn 1-2% — cho phép bạn quan sát các system call và sự chậm trễ trong lập lịch (scheduling) theo thời gian thực mà không làm ảnh hưởng đến hiệu năng.
Kiến trúc: Tại sao Ftrace lại khác biệt
Ftrace là một khung làm việc (framework) để tracing, không phải là một file thực thi độc lập. Nó cho phép bạn theo dõi cách các hàm được gọi, đo thời gian thực thi và thấy chính xác cách các tiến trình tương tác với phần cứng. Trong khi perf rất xuất sắc trong việc phân tích hiệu năng (profiling) ở mức tổng quát, thì Ftrace lại vượt trội trong việc tìm ra lý do “tại sao” đằng sau các đợt tăng vọt latency cụ thể. Nó có thể cho bạn biết liệu một tiến trình có đang bị chặn bởi một driver mạng cụ thể hay do scheduler đang thực hiện chuyển đổi ngữ cảnh (context switch) không hiệu quả.
Sau khi quản lý một cụm hơn 50 node có lưu lượng truy cập cao, tôi nhận ra rằng việc trace ở mức kernel là một công việc đòi hỏi sự chính xác. Bạn cần lọc các dấu vết (trace) của mình một cách cẩn thận. Nếu không có các bộ lọc phù hợp, một máy chủ đang bận rộn có thể tạo ra 500MB dữ liệu trace trong chưa đầy 10 giây, khiến việc tìm kiếm các sự kiện liên quan trở nên gần như không thể.
Khởi tạo: Xác định vị trí mount của Tracefs
Các bản phân phối hiện đại như Ubuntu 22.04 hoặc AlmaLinux 9 đều đã bật sẵn Ftrace theo mặc định. Nó giao tiếp với người dùng thông qua một hệ thống tệp ảo. Kể từ kernel 4.1, đây thường là tracefs, mặc dù nó vẫn thường được mount bên trong debugfs để đảm bảo tính tương thích.
Kiểm tra thư mục tracing bằng lệnh sau:
ls /sys/kernel/tracingNếu đường dẫn đó không tồn tại, hãy thử vị trí cũ:
ls /sys/kernel/debug/tracingNếu thư mục trống, có thể bạn cần mount hệ thống tệp debug một cách thủ công:
mount -t debugfs nodev /sys/kernel/debugThực thi: Nhắm mục tiêu cuộc điều tra
Ftrace sử dụng các tệp ảo để điều khiển logic của nó. Bạn cấu hình nó bằng cách ghi (echo) các chuỗi ký tự vào các tệp này. Để bắt đầu, hãy xác định những tracer nào mà kernel của bạn hỗ trợ.
cat /sys/kernel/tracing/available_tracers
# Kết quả mong đợi: function_graph function blk mmiotrace nop1. Trực quan hóa Call Stack
Tracer function_graph là tiêu chuẩn vàng để debug. Nó cung cấp một cấu trúc phân cấp trực quan theo kiểu ngôn ngữ C cho mọi lệnh gọi hàm kernel, bao gồm cả thời gian bắt đầu và kết thúc. Điều này giúp bạn dễ dàng thấy hàm con nào thực sự đang làm chậm hàm cha.
# Kích hoạt graph tracer
echo function_graph > /sys/kernel/tracing/current_tracer2. Kỹ thuật lọc chính xác
Để tránh bị ngập trong dữ liệu, hãy thu hẹp phạm vi của bạn. Nếu bạn nghi ngờ latency do đĩa, hãy tập trung vào lớp Virtual File System (VFS). Bạn có thể sử dụng các ký tự đại diện (wildcards) để bắt tất cả các hàm liên quan.
# Giới hạn tracing cho các hàm liên quan đến VFS
echo 'vfs_*' > /sys/kernel/tracing/set_ftrace_filterNếu bạn đã xác định được một tiến trình cụ thể đang hoạt động sai, hãy lọc theo PID của nó để bỏ qua các nhiễu nền từ các dịch vụ khác:
# Thay thế 1234 bằng ID tiến trình thực tế của bạn
echo 1234 > /sys/kernel/tracing/set_ftrace_pid3. Thu thập dữ liệu
Tracer có thể được bật tắt tức thì. Cách tốt nhất là giữ nó ở trạng thái tắt trong khi cấu hình, sau đó bật lên trong khoảng 5-10 giây ngắn ngủi để bắt lấy hiện tượng bất thường.
# Bắt đầu thu thập
echo 1 > /sys/kernel/tracing/tracing_on
# Đợi cho đến khi hiện tượng lag xảy ra, sau đó tắt ngay lập tức
echo 0 > /sys/kernel/tracing/tracing_onPhân tích: Tìm ra “tang chứng vật chứng”
Dữ liệu thu thập được nằm trong tệp trace. Sử dụng less -S để xem; cờ -S rất quan trọng vì nó ngăn các dòng dài bị xuống dòng, giữ cho cấu trúc phân cấp trực quan nguyên vẹn.
less -S /sys/kernel/tracing/traceKết quả đầu ra cung cấp một dòng thời gian thực thi rõ ràng:
# CPU DURATION FUNCTION CALLS
# | | | | | | |
0) | vfs_write() {
0) | rw_verify_area() {
0) 0.124 us | security_file_permission();
0) 0.512 us | }
0) 1.230 us | }Giải mã các ký hiệu Latency
Ftrace tự động đánh dấu các hàm chậm bằng các ký hiệu đặc biệt trong cột thời gian (duration):
+: Trên 10 micro giây (us)!: Trên 100 micro giây#: Trên 1 mili giây (ms)*: Trên 10 mili giây@: Trên 100 mili giây
Trong một môi trường hiệu năng cao, việc nhìn thấy ký hiệu ! hoặc # trong một thao tác ghi file thông thường là một dấu hiệu cảnh báo đỏ. Tôi đã từng debug một máy chủ nơi một module bảo mật của bên thứ ba đã thêm một khoảng trễ 2ms (#) vào mỗi bước xử lý gói tin; Ftrace đã làm điều đó trở nên hiển nhiên chỉ trong một màn hình.
Dọn dẹp sau khi Debug
Đừng bao giờ để tracer ở trạng thái hoạt động. Ngay cả khi tracing_on được đặt thành 0, các bộ lọc và lựa chọn tracer vẫn còn trong bộ nhớ. Hãy reset mọi thứ để đảm bảo quản trị viên tiếp theo có một hệ thống sạch sẽ.
# Khôi phục về trạng thái mặc định
echo nop > /sys/kernel/tracing/current_tracer
echo > /sys/kernel/tracing/set_ftrace_filter
echo > /sys/kernel/tracing/set_ftrace_pidMẹo nhỏ: Công cụ bao bọc Trace-cmd
Nếu các lệnh echo mang lại cảm giác quá thủ công, hãy sử dụng tiện ích trace-cmd. Nó đơn giản hóa quá trình ghi và báo cáo thành một quy trình làm việc tương tự như tcpdump.
# Cài đặt
sudo apt install trace-cmd
# Ghi lại các lệnh gọi hàm cụ thể cho một câu lệnh
sudo trace-cmd record -p function_graph -g vfs_write ls /home
# Tạo báo cáo
trace-cmd reportFtrace là một framework rộng lớn, nhưng những kiến thức cơ bản này sẽ giải quyết được 90% các vấn đề latency “không giải thích được” của bạn. Hãy thực hành trên một VM staging để làm quen với cú pháp bộ lọc, và bạn sẽ sẵn sàng khi các chỉ số production của mình gặp vấn đề.
