Ác mộng on-call: Khi dashboard đỏ rực mà không rõ nguyên nhân
2 giờ sáng, chuông PagerDuty réo liên hồi. Mở laptop ra, bạn thấy chục dashboard Grafana đồng loạt chuyển sang màu đỏ. CPU database chạm đỉnh 98%, latency API tăng vọt lên 3.5 giây, còn frontend liên tục quăng mã lỗi 504. Câu hỏi kinh điển xuất hiện: Service nào kéo sập cả dây chuyền?
Trước đây, stack Prometheus và Grafana của mình theo dõi 15 node server khá tròn vai. Phần cứng có biến là phát hiện được ngay. Thế nhưng, ác mộng thực sự bắt đầu khi team dev tách monolith thành hơn 20 microservice độc lập.
Service thanh toán gọi sang database, database đợi ổ cứng ghi log, trong khi queue gửi email nghẽn mạng cục bộ. Prometheus lúc này chỉ nói: "Node 02 quá tải CPU". Nó chịu chết, không thể chỉ ra query SQL cụ thể nào đang khóa dòng khiến các service phía trước đứng hình.
Cách xử lý truyền thống thường là gắn OpenTelemetry SDK hoặc APM agent vào mã nguồn từng ứng dụng. Nghe thì chuẩn chỉ, nhưng thực tế ngốn cả tháng refactor code và config container. Chỉ cần dev quên gắn trace ở một endpoint là toàn bộ chuỗi theo dõi bị đứt gãy. Chúng ta cần một hướng đi khác: giám sát toàn diện mà không chạm vào một dòng code nào.
eBPF và cơ chế tìm nguyên nhân gốc của Coroot
Coroot là nền tảng observability mã nguồn mở giải quyết đúng bài toán nhức nhối này. Sức mạnh của nó đến từ sự kết hợp giữa công nghệ eBPF và engine tự động phân tích nguyên nhân gốc (Root Cause Analysis – RCA).
eBPF: "Camera hành trình" đặt ngay trong nhân Linux
Hãy xem Linux Kernel như trạm kiểm soát trung tâm của toàn bộ hệ điều hành. Mọi packet mạng, tác vụ đọc ghi ổ cứng hay yêu cầu cấp phát RAM của container đều phải đi qua đây.
Trước kia, muốn theo dõi hành vi ứng dụng, bạn buộc phải nhúng thư viện vào source code. Với eBPF (Extended Berkeley Packet Filter), chúng ta gắn các chương trình sandbox siêu nhỏ chạy trực tiếp trong kernel. Không cần đụng đến code ứng dụng (zero-code instrumentation). Kernel tự ghi lại mọi biến động: tiến trình nào mở kết nối TCP, câu lệnh PostgreSQL chạy mất bao nhiêu ms, hay socket nào bị rớt gói. Mọi thứ diễn ra trong suốt với overhead cực thấp, thường chiếm dưới 1% CPU của node.
Coroot xâu chuỗi dữ liệu thế nào?
Dữ liệu raw thu về từ eBPF rất nhiều. Giá trị thực sự của Coroot nằm ở chỗ nó không bắt kỹ sư ngồi ghép từng mảnh đồ thị để phán đoán. Nền tảng này tích hợp sẵn các mô hình kiểm tra sức khỏe hệ thống (Health Checks):
- Tự động vẽ Service Map: Quét lưu lượng mạng thực tế để dựng sơ đồ luồng dữ liệu giữa các container, microservice và database theo thời gian thực.
- Telemetry Correlation: Khi một endpoint API phản hồi chậm, Coroot tự dò ngược dòng: do mạng drop packet, cgroup bị throttle CPU, hay do transaction database bị lock?
- Chỉ mặt đặt tên Root Cause: Thay vì spam 20 cảnh báo riêng lẻ khi xảy ra hiệu ứng domino, Coroot gom lại thành một cảnh báo duy nhất nêu đích danh mắt xích đầu tiên gặp lỗi.
Thực hành: Cài đặt Coroot Community Edition
Bản Coroot Community Edition hoàn toàn miễn phí. Kiến trúc gồm hai thành phần: coroot (server xử lý trung tâm và web UI) và coroot-node-agent (chạy trên từng node máy chủ để thu thập số liệu qua eBPF).
Bước 1: Kiểm tra môi trường
Do sử dụng eBPF, máy chủ Linux cần kernel tối thiểu từ phiên bản 4.19 trở lên. Các bản phân phối phổ biến như Ubuntu 20.04/22.04/24.04 hay Debian 11/12 đều hỗ trợ sẵn. Bạn kiểm tra bằng lệnh:
uname -rNếu terminal hiển thị phiên bản 5.x hoặc 6.x, hệ thống đã sẵn sàng.
Bước 2: Dựng Coroot Server với Docker Compose
Chạy Coroot Server qua Docker Compose là cách nhanh nhất trên node quản trị. Bạn tạo thư mục làm việc:
mkdir -p /opt/coroot && cd /opt/coroot
nano docker-compose.ymlNội dung file cấu hình như sau:
version: '3.8'
services:
coroot:
image: ghcr.io/coroot/coroot:latest
container_name: coroot-server
restart: always
ports:
- "8080:8080"
volumes:
- coroot_data:/data
volumes:
coroot_data:Khởi chạy container:
docker compose up -dMở trình duyệt truy cập http://<IP-server>:8080. Tại đây, bạn đăng ký tài khoản admin, tạo một project mới và sao chép lại API Key được cấp.
Bước 3: Cài đặt Coroot Node Agent
Agent cần quyền truy cập kernel và cgroup để lắng nghe sự kiện eBPF. Chạy lệnh sau trên từng máy chủ cần theo dõi (thay IP và API Key tương ứng):
docker run -d --name coroot-node-agent \
--privileged \
--pid host \
--net host \
--restart always \
-v /sys/kernel/debug:/sys/kernel/debug:rw \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
ghcr.io/coroot/coroot-node-agent:latest \
--cgroupfs-root=/sys/fs/cgroup \
--coroot-url=http://192.168.1.100:8080 \
--api-key=<API_KEY_CUA_BAN>Nếu chạy cụm Kubernetes, bạn triển khai nhanh chóng qua Helm chart:
helm repo add coroot https://coroot.github.io/helm-charts
helm repo update
helm install coroot-operator coroot/coroot-operator \
--namespace coroot --create-namespace \
--set "coroot.url=http://<IP-coroot-server>:8080" \
--set "coroot.apiKey=<API_KEY_CUA_BAN>"Bước 4: Trải nghiệm khả năng định vị sự cố
Sau khoảng 2 phút nhận metrics, Coroot Dashboard bắt đầu hiển thị các báo cáo trực quan:
- Bản đồ liên kết (Service Map): Mọi service từ Nginx, backend Node.js/Go đến Redis, Postgres tự động liên kết thành sơ đồ luồng. Từng line kết nối thể hiện rõ throughput (RPS), độ trễ (p95, p99) và error rate.
- Bắt slow query không cần log: Coroot đọc payload qua network socket ở tầng kernel để ghi nhận câu truy vấn database chậm, không làm tăng I/O disk do bật slow log.
- Chẩn đoán tự động: Giả sử pool kết nối database bị nghẽn do một query chạy mất 4.2 giây, dashboard sẽ highlight đỏ service đó và hiển thị rõ: "PostgreSQL connection pool exhausted due to query X". Bạn không còn phải đào bới hàng GB log file để đoán mò.
Lời kết
Tận dụng eBPF giúp công việc vận hành hệ thống nhẹ nhàng hơn đáng kể. Bạn không cần thuyết phục team dev nhúng thêm SDK giám sát, cũng không phải mày mò chắp vá dữ liệu giữa 5-6 tab công cụ mỗi khi có outage.
Coroot không thay thế hoàn toàn hạ tầng logging hay tracing hiện có của bạn. Nó đóng vai trò như một bộ lọc thông minh, khoanh vùng chính xác điểm nghẽn và kéo giảm thời gian xử lý sự cố (MTTR) từ hàng giờ xuống vài phút.
