Chào các bạn, ở bài viết trước, chúng ta đã hiểu được tầm quan trọng của APM trong việc "khám bệnh" hiệu năng cho ứng dụng. Tuy nhiên, để có được những biểu đồ trực quan, những dòng trace chi tiết trên giao diện Kibana, có một hệ thống ngầm vận hành phía sau.
Hôm nay, chúng ta sẽ cùng nhau bóc tách Kiến trúc của Elastic APM. Việc hiểu rõ kiến trúc này là điều bắt buộc trước khi bắt tay vào gõ lệnh cấu hình, giúp bạn dễ dàng debug khi hệ thống giám sát gặp sự cố (ví dụ: Tại sao app chạy mà không thấy data APM đổ về?).
1. Sơ đồ tổng quan kiến trúc Elastic APM
Để Elastic APM hoạt động, chúng ta cần sự phối hợp của 4 thành phần cốt lõi:
- APM Agent (Nằm trong ứng dụng của bạn)
- APM Server (Bộ xử lý trung gian)
- Elasticsearch (Kho lưu trữ dữ liệu)
- Kibana (Giao diện hiển thị)
Hãy cùng xem dòng chảy của dữ liệu (Data Flow) qua sơ đồ dưới đây:
Dòng chảy này diễn ra theo cơ chế:
$$\text{APM Agent} \xrightarrow{\text{Gửi dữ liệu}} \text{APM Server} \xrightarrow{\text{Đẩy vào}} \text{Elasticsearch} \xrightarrow{\text{Truy vấn}} \text{Kibana}$$
2. Chi tiết nhiệm vụ của từng thành phần
1. APM Agent: "Kẻ gián điệp" đáng yêu trong lòng ứng dụng
APM Agent thực chất là một thư viện (hoặc extension/plugin) được cài đặt trực tiếp vào bên trong mã nguồn ứng dụng của bạn (PHP, Node.js, Golang, v.v.).
- Nhiệm vụ: Nó hoạt động như một "camera giám sát", tự động đo đạc thời gian chạy của hàm, các truy vấn SQL, các request HTTP ra ngoài.
- Cơ chế: Nó gom các dữ liệu này lại thành các đoạn mã nhỏ (gọi là Spans và Transactions) rồi gửi bất đồng bộ (Asynchronous) về cho APM Server. Nhờ chạy bất đồng bộ, APM Agent gần như không làm ảnh hưởng đến tốc độ trải nghiệm của người dùng cuối.
2. APM Server: "Cửa ngõ" điều phối và chuẩn hóa
APM Server là một component chạy độc lập (thường được viết bằng Go). Nó đứng ở giữa để làm nhiệm vụ "gác cổng" và giảm tải cho Elasticsearch.
- Nhiệm vụ: * Nhận dữ liệu từ hàng trăm, hàng ngàn APM Agent gửi về qua giao thức HTTP/HTTPS.
- Xác thực (Authentication) xem Agent đó có hợp lệ không.
- Chuẩn hóa, chuyển đổi dữ liệu thô từ Agent thành các tài liệu JSON tối ưu.
- Đẩy dữ liệu đã chuẩn hóa vào Elasticsearch theo cấu trúc index phù hợp.
- Tại sao không gửi thẳng từ Agent lên Elasticsearch? Vì nếu bạn có 1000 container chạy app, việc để cả 1000 container này kết nối trực tiếp vào Elasticsearch sẽ làm nghẽn kết nối (connection pool). APM Server đóng vai trò như một buffer giảm tải cực kỳ hiệu quả.
3. Elasticsearch: "Bộ não" lưu trữ và tìm kiếm
Thành phần này thì quá quen thuộc trong ELK Stack rồi. Dữ liệu APM sau khi được chuẩn hóa sẽ được lưu trữ tại đây dưới dạng các Time-series Documents.
- Nhiệm vụ: Lưu trữ toàn bộ lịch sử trace, index dữ liệu để phục vụ cho việc tìm kiếm, phân tích và tính toán các chỉ số (ví dụ: tính toán ra biểu đồ tỷ lệ lỗi %, phân vị thời gian phản hồi $p95, p99$).
4. Kibana: "Gương mặt thương hiệu"
Kibana là giao diện Web trực quan giúp các kỹ sư tương tác với toàn bộ hệ thống.
- Nhiệm vụ: Elastic tích hợp sẵn một UI chuyên biệt cho APM (APM App) nằm trong Kibana. Bạn không cần tự tay vẽ biểu đồ, Kibana sẽ tự động dựng sẵn các Dashboard cực kỳ xịn mịn: từ Service Map (sơ đồ tương tác giữa các service), danh sách các Request chậm nhất, cho đến biểu đồ lỗi theo thời gian thực.
3. Bản chất của việc "Cấu hình APM" là làm gì?
Sau khi đã hiểu kiến trúc trên, khi ai đó bảo bạn: "Hãy cấu hình Elastic APM cho dự án này đi", trong đầu bạn sẽ tự động bật ra các bước cần làm:
- Dựng cụm lưu trữ và hiển thị: Chuẩn bị Elasticsearch và Kibana (Thường có sẵn nếu công ty dùng ELK, hoặc tự dựng).
- Triển khai APM Server: Cấu hình cho APM Server biết Elasticsearch nằm ở đâu để nó đẩy data vào.
- Tích hợp APM Agent vào Code: Khai báo cho Agent biết địa chỉ của APM Server (ELASTIC_APM_SERVER_URL) và đặt tên cho ứng dụng (ELASTIC_APM_SERVICE_NAME).
Lời kết & Bài học tiếp theo
Kiến trúc Elastic APM thực ra rất tường minh và phân rã trách nhiệm rõ ràng. Chính sự phân rã này giúp hệ thống giám sát có thể scale một cách độc lập khi lượng request của hệ thống tăng cao.
Nhưng làm sao APM biết được một Request đi qua những đâu? Làm sao nó liên kết được câu lệnh SQL này thuộc về Request của khách hàng A chứ không phải khách hàng B?
Ở Bài 3, chúng ta sẽ đi sâu vào các khái niệm "sống còn" cấu thành nên một bản tin APM: Transaction, Span, Trace ID và Parent ID.
Các bạn đã từng gặp khó khăn khi cài đặt hay kết nối giữa các thành phần này chưa? Hãy chia sẻ ở phần bình luận nhé!
