Observability

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Distributed tracing trong Go microservices sử dụng OpenTelemetry SDK truyền W3C trace context qua HTTP/gRPC interceptors và Kafka header carriers. Kiến trúc OTel Collector DaemonSet kết hợp Gateway xử lý tail-based sampling, lọc PII qua OTTL và liên kết chặt chẽ ba trụ cột Traces, Metrics và Logs. 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 Answer-first: Profiling Go trong production với pprof cho phép chẩn đoán chính xác CPU hotspots, phân biệt cấp phát bộ nhớ (alloc_space vs inuse_space) và định vị goroutine leaks với overhead dưới 2%. Bật endpoint trên port nội bộ cô lập, dùng kubectl port-forward và custom pprof labels để phân tích đa chiều. 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 Answer-first: Remote profiling Go trong Kubernetes được thực hiện an toàn qua 3 mô hình: tạo tunnel tức thời bằng kubectl port-forward trên cổng admin cô lập, gắn container sidecar cho cụm tăng cường bảo mật, hoặc tích hợp Pyroscope continuous profiling (1–3% CPU). Phân tích flame graph phát hiện hot-path và tối ưu GC latency. 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 Answer-first: Rò rỉ Goroutine xảy ra khi goroutine bị block vĩnh viễn trên unbuffered channel, context thiếu hủy, hoặc HTTP body chưa đóng, dẫn đến giữ heap memory và gây sự cố Kubernetes OOM (exit code 137). Chẩn đoán bằng pprof goroutine profile, chặn đứng qua goleak trong CI và áp dụng Go 1.26 goroutine leak detection. 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). ...