APM là gì? Giám sát hiệu năng ứng dụng để xử lý đúng điểm nghẽn
APM (Application Performance Monitoring) là việc giám sát hiệu năng ứng dụng: giao dịch có hoàn tất không, mất bao lâu và lỗi xảy ra ở đâu. APM cung cấp dữ liệu để điều tra; dịch vụ AMS tổ chức con người và quy trình để tiếp nhận, xử lý, bảo trì và cải tiến ứng dụng.
APM là gì?
Một trang web mở được chưa có nghĩa người dùng thanh toán được. Với ERP, CRM, cổng khách hàng hay API, điểm cần theo dõi là luồng công việc mà ứng dụng phục vụ. APM giúp quan sát thời gian xử lý, lỗi và các phụ thuộc của những luồng đó. Tên gọi APM cũng được dùng cho Application Performance Management, bao hàm việc quản lý hiệu năng rộng hơn hoạt động thu thập số liệu.
Máy chủ khỏe khác giao dịch thành công thế nào?
Giám sát hạ tầng theo dõi tài nguyên như CPU, bộ nhớ, đĩa và mạng. Ở lớp ứng dụng, đội vận hành còn cần biết yêu cầu nào thất bại, tác vụ nền nào bị kẹt hoặc lời gọi sang hệ thống khác nào bị chậm. Hai lớp dữ liệu bổ sung cho nhau.
Ví dụ minh họa: API trả mã thành công nhưng đơn hàng chưa chuyển được sang ERP. Nếu chỉ kiểm tra mã HTTP, dashboard có thể bỏ sót lỗi nghiệp vụ. Doanh nghiệp nên xác định thêm dấu hiệu hoàn tất của luồng tạo đơn và cách đối soát phù hợp, đồng thời tránh thu thập nội dung giao dịch nhạy cảm không cần thiết.
Chọn dữ liệu để tìm điểm nghẽn
OpenTelemetry mô tả các tín hiệu quan sát gồm traces, metrics và logs: trace thể hiện đường đi của yêu cầu; metric là phép đo khi chạy; log ghi nhận một sự kiện. Có thể đối chiếu các tín hiệu để hiểu cùng một hoạt động từ nhiều góc nhìn. Xem tài liệu Signals của OpenTelemetry.
| Dữ liệu | Câu hỏi cần trả lời | Ví dụ điểm đo |
|---|---|---|
| Metrics | Lỗi tập trung ở luồng nào và tăng từ lúc nào? | Tỷ lệ lỗi, độ trễ, số yêu cầu theo endpoint |
| Logs | Sự kiện nào xảy ra quanh thời điểm lỗi? | Mã lỗi, phiên bản triển khai, mã tương quan |
| Traces | Yêu cầu đi qua đâu và chờ ở bước nào? | Ứng dụng → cơ sở dữ liệu → API phụ thuộc |
Không cần lưu mọi dữ liệu ở cùng độ chi tiết. Khi thiết kế nên cân nhắc chi phí lưu trữ, thời gian giữ dữ liệu, quyền xem, che thông tin cá nhân và tác động của instrumentation. Tránh dùng email hoặc mã giao dịch riêng lẻ làm nhãn metrics vì số lượng giá trị có thể tăng rất lớn.
Ví dụ: API tạo đơn chậm
Đây là tình huống minh họa, không phải kết quả đo của khách hàng UPTECH. Người dùng báo thao tác tạo đơn chậm. Thay vì tăng tài nguyên ngay, đội vận hành có thể kiểm tra theo trình tự:
- Xác định thời điểm, nhóm người dùng và luồng tạo đơn bị ảnh hưởng.
- Đối chiếu độ trễ và tỷ lệ lỗi theo endpoint; xem phân vị độ trễ để nhận biết nhóm yêu cầu chậm, thay vì chỉ nhìn trung bình.
- Theo dấu một yêu cầu mẫu, kiểm tra thời gian truy vấn và lời gọi tới hệ thống khác; so với thay đổi gần nhất.
- Chọn biện pháp xử lý dựa trên bằng chứng, xin phê duyệt nếu cần và chuẩn bị cách hoàn tác.
- Kiểm tra lại giao dịch cùng điểm đo trước và sau thay đổi, trong điều kiện tải có thể so sánh.
Google SRE nêu vai trò của monitoring trong cảnh báo, điều tra, theo dõi xu hướng và so sánh trước/sau thay đổi; đồng thời giải thích vì sao số trung bình có thể che mất yêu cầu chậm. Xem chương Monitoring của SRE Workbook.
Đưa APM vào vận hành AMS
Công cụ không tự quyết định mức ảnh hưởng kinh doanh, người cần thông báo hay quyền thay đổi ứng dụng. Trong dịch vụ quản trị và vận hành ứng dụng AMS 24/7 của UPTECH, điểm giám sát được gắn với đầu mối tiếp nhận, quy trình xử lý, SLA và báo cáo. Phạm vi có thể bắt đầu từ một ứng dụng hoặc nhiều hệ thống kết nối, ở mọi ngành.
Mỗi cảnh báo nên có lý do cần hành động, người nhận, tài liệu thao tác và cách xác nhận đã phục hồi. Sau sự cố, những lỗ hổng giám sát hoặc lỗi lặp lại cần đi vào danh sách cải tiến, có người phụ trách và mức ưu tiên.
Checklist bắt đầu
- Chọn các luồng nghiệp vụ quan trọng và chủ sở hữu của từng luồng.
- Liệt kê điểm tích hợp, môi trường và công cụ đang có.
- Xác định dữ liệu được phép thu thập, cách che dữ liệu và thời gian lưu.
- Thống nhất chỉ số, ngưỡng cảnh báo, kỳ đo và nguồn dữ liệu.
- Thử đường đi của cảnh báo đến người trực; diễn tập bằng môi trường phù hợp.
- Rà lại chi phí, nhiễu cảnh báo và khả năng điều tra sau một kỳ vận hành.
Nếu cần chuyển giao cả trách nhiệm vận hành, xem checklist bàn giao ứng dụng. Có thể bắt đầu bằng việc trao đổi với UPTECH về hệ thống hiện tại, chưa cần gửi tài khoản hay dữ liệu sản xuất.
