Observability

🇬🇧 Read the English version of this article on tanhdev.com Việc giám sát (Monitoring) các hệ thống Go microservices phức tạp đòi hỏi nhiều thứ hơn là chỉ các file logs độc lập riêng lẻ. Khi một request (yêu cầu) đi xuyên qua các HTTP APIs, luồng sự kiện (event streams) Kafka, và các worker pools bất đồng bộ (asynchronous worker pools), bạn cần một mức độ hiển thị tuyệt đối (absolute visibility) để có thể xác định chính xác các điểm nghẽn độ trễ (latency bottlenecks) cũng như các lỗi thất bại. ...

🇬🇧 Read the English version of this article on tanhdev.com Yêu cầu tiên quyết: Hướng dẫn này đề cập đến việc profile và chẩn đoán các sự cố hiệu năng phức tạp trên production. Nếu bạn đang xử lý tình trạng số lượng goroutine tăng trưởng không kiểm soát, hãy chắc chắn rằng bạn đã hiểu các khái niệm nền tảng trong bài viết Phát hiện và Xử lý Goroutine Leak trên Production Go Services. ...

🇬🇧 Read the English version of this article on tanhdev.com Bạn đã gắn các bộ thu thập đo lường cho service Go của mình với net/http/pprof, chạy thử lệnh go tool pprof cục bộ (local) kiểm tra file binary lúc dev, và đã nhìn rõ mồn một các “hot path” (đường nghẽn cổ chai tốn thời gian nhất) trên biểu đồ ngọn lửa (flame graph). Thế rồi bạn triển khai lên Kubernetes và các điểm nghẽn ấy biến mất hoàn toàn — bởi vì hồ sơ tải (workload profile) trong Kubernetes khác xa với việc test cục bộ (mix request khác nhau, áp lực pool kết nối khác nhau, hành vi GC cũng khác dưới mức chịu tải thực tế, và cả sự can thiệp từ bộ lập lịch (scheduler) của các pod nằm chung node). ...

🇬🇧 Read the English version of this article on tanhdev.com Một pod Kubernetes đột ngột khởi động lại với mã thoát (exit code) 137. Biểu đồ giám sát bộ nhớ (memory metrics dashboard) hiển thị một mô hình bậc thang tăng dần đều đặn kéo dài suốt ba ngày. Không có bất kỳ log panic nào trong stdout, không có lỗi database, và không có mức tăng đột biến CPU bất thường nào. Chỉ là một cái chết êm đềm và từ từ do lỗi OOM (Out Of Memory). ...