BÀI 1: APM LÀ GÌ? TẠI SAO LOGS VÀ METRICS THÔI LÀ CHƯA ĐỦ?

Chào các bạn, khi hệ thống của chúng ta scale lên, hoặc đơn giản là khi nhận được một câu report từ khách hàng: "Anh ơi, web load chậm quá!", bạn sẽ làm gì đầu tiên?

SSH vào server gõ top, htop? Hay mở file log ra và tail -f miệt mài giữa hàng triệu dòng chữ?

Nếu bạn đang giám sát hệ thống theo cách đó, bài viết này dành cho bạn. Hôm nay chúng ta sẽ cùng nhau tìm hiểu về APM (Application Performance Monitoring) – mảnh ghép tối quan trọng trong việc vận hành hệ thống hiện đại, và tại sao nó lại là trợ thủ đắc lực hơn cả Logs hay Metrics truyền thống.

1. Bài toán thực tế: Khi "Mọi thứ đều xanh" nhưng Web vẫn chậm

Thông thường để giám sát hệ thống, chúng ta phải dựa vào 2 yếu tố cổ điểm:

1. Metrics (Chỉ số): CPU đang chạy 40%, RAM trống 50%, Disk còn đầy dư giả, khỏe!
2. Logs (Nhật ký): Không có exception nào bắn ra, HTTP Status Code trả về vẫn là 200 ok. Ngon!

Thế nhưng người dùng vẫn phải đợi 5 giây để tải xong trang thanh toán.

Vấn đề nằm ở đâu?

• CPU cao không có nghĩa là code được tối ưu. Có thể code đang bị block do một hàm sleep(), hoặc đang đợi kết quả từ một API bên thứ 3 (Third party API).
• Logs không có lỗi không có nghĩa là hệ thống chạy được nhanh. Logs chỉ cho bạn biết hệ thống có chuyện gì sảy ra (What), chứ không nói cho bạn biết nó diễn ra trong bao lâu (How long),

Đó chính là lý do APM ra đời.

2. APM là gì?

APM (Application Performance Monitoring) là giám sát hiệu năng của ứng dụng ở múc chuyên sâu (Deep-level monitoring).

Thay vì chỉ nhìn vào hệ thống bên ngoài (Server có chạy được không?). APM đi thẳng vào bên trong "lòng mề" của mã nguồn để đo đạc. Nó theo dõi chính xác hành trình cỉa một request từ lúc chạm vào ứng dụng, đi qua những hàm nào, gọi những câu lệnh SQL nào, mất bao nhiêu mili-giây (ms), cho đến khi trả về kết quả cho user.

Ba trụ cột của Sự quan sát (Observability)

Trong thế giới DevOps/SRE, người ta thường nhắc đến 3 trụ cột (The Three Pillars of Observability):

• Metrics: Cho biết hệ thống có đang ổn định về mặt tài nguyên không (Nhìn tổng quan).
• Logs: Ghi lại các sự kiện đặc biệt hoặc lỗi (Nhìn chi tiết sự kiện).
• Traces (APM): Ghi lại toàn bộ hành trình và thời gian xử lý của Request (Nhìn dòng chảy dữ liệu).

APM chính là đại diện xuất sắc nhất cho cột trụ Traces.

3. Tại sao chọn Elastic APM?

Hiện nay trên thị trường có rất nhiều ông lớn làm APM như New Relic, Dynatrace, Datadog... Tuy nhiên, Elastic APM luôn là một trong những lựa chọn hàng đầu của các kỹ sư vì:

• Mở và Miễn phí (Open & Free): Nằm trong hệ sinh thái Elastic (ELK Stack), bạn có thể tự dựng (Self-hosted) trên hạ tầng của mình mà không tốn chi phí bản quyền đắt đỏ như SaaS.
• Hệ sinh thái mạnh mẽ: Dữ liệu APM được đổ về Elasticsearch, giúp bạn vừa có thể tìm kiếm text, vừa vẽ được biểu đồ cực kỳ trực quan trên Kibana.
• Hỗ trợ đa ngôn ngữ: Có sẵn các Agent chính chủ, tối ưu tốt cho PHP, Node.js, Go, Python, Java, .NET...

4. Elastic APM giúp bạn trả lời những câu hỏi "nhức nhối" nào?

Khi cấu hình thành công Elastic APM cho dự án, bạn có thể tự tin trả lời các câu hỏi mà trước đây phải mất cả ngày dò đoán:

1. Request này chậm ở đoạn nào? Do xử lý logic Code, do câu lệnh SQL chạy thiếu Index, hay do API của bên vận chuyển đang bị timeout?
2. Lỗi này xuất hiện bao nhiêu lần? Elastic APM tự động gom nhóm (grouping) các lỗi giống nhau và chỉ ra chính xác dòng code (Line of code) gây ra lỗi.
3. Hệ thống có bị N+1 Query không? Bạn sẽ thấy trực quan việc code của mình vô tình gọi 100 câu lệnh SELECT giống nhau vào Database chỉ trong 1 request.

Lời kết & Bài học tiếp theo

óm lại, APM không thay thế Logs hay Metrics, nó hoàn thiện chúng. Có APM, bạn sẽ không còn phải "đoán mò" khi hệ thống gặp vấn đề hiệu năng nữa.

Ở Bài 2, chúng ta sẽ bóc tách sâu hơn vào kiến trúc của Elastic APM. Chúng ta sẽ tìm hiểu xem APM Agent, APM Server, Elasticsearch và Kibana phối hợp với nhau như thế nào để mang lại những biểu đồ trực quan sinh động.

Các bạn có câu hỏi nào về khái niệm APM không? Hãy để lại bình luận phía dưới nhé!