CPU 100% — hoảng không? Chưa chắc. USE method (Utilization, Saturation, Errors) cho tài nguyên chỉ ra rằng utilization cao một mình là tín hiệu mơ hồ. Bài này dựng thật một worker pool bị nạp quá sức: utilization chạm 100% nhưng không nói lên mức độ quá tải; chính saturation (hàng đợi đầy 20/20) và errors (41 job/s bị rớt) mới định lượng được service đang chết ngạt thế nào.
Thêm nhãn user_id vào một metric nghe tiện — lọc theo user mà. Nhưng bài này đo thật cái giá: cùng một app, metric gắn nhãn route tạo 3 chuỗi thời gian, metric gắn nhãn user_id tạo 10000; chỉ một metric sai làm tổng số chuỗi của Prometheus nhảy từ 729 lên 10732 (~14 lần). Và đó mới 10000 user — nhân thêm status, endpoint là nổ tổ hợp đủ làm Prometheus OOM mà chết.
Metric báo checkout p99 = 127ms. Nhưng 127ms đó tiêu ở đâu — validate, query DB, hay gọi payment? Metric không biết. Bài này dựng thật tracing với OpenTelemetry và Jaeger: tạo span lồng nhau, export, rồi query Jaeger API lấy trace thật — và thấy ngay queryDB ngốn 91ms (72% tổng) trong khi validate chỉ 3.85ms. Đây là thứ metric tổng hợp không bao giờ chỉ ra được.
Log văn bản thuần đọc bằng mắt thì được, nhưng máy khó truy vấn — grep với regex mong manh. Bài này chạy thật slog của Go in log JSON có cấu trúc, rồi dùng jq lọc theo level, theo độ trễ, tổng hợp doanh thu ngay trên log. Và cú chốt: gắn trace_id thật từ OpenTelemetry vào mỗi dòng log — thấy lỗi trong log là nhảy thẳng tới đúng trace trong Jaeger, khớp đã kiểm chứng.
REST + JSON có mặt khắp nơi và dễ đọc — vậy vì sao nhiều hệ chuyển sang gRPC cho giao tiếp nội bộ? Bài này đo thật: cùng một Order, protobuf chỉ 26 byte so với JSON 70 byte (gọn hơn 63%), và một unary gRPC call đạt gần 14.000 call/s với 0,072 ms/call. Giải thích vì sao protobuf nhỏ thế, gRPC nhanh thế, và cái giá phải trả: cần .proto, codegen, và byte nhị phân không đọc được bằng mắt.
REST chỉ có một mô hình: request rồi response. gRPC có bốn, mở khoá bằng từ khoá stream trong .proto. Bài này chạy thật cả bốn trong một service: unary (1 req→1 resp), server streaming (1 req→5 resp), client streaming (4 req→1 resp tổng đúng 500), và bidirectional (3 msg↔3 msg xen kẽ). Mỗi kiểu hợp một dạng dữ liệu khác nhau, và chọn đúng kiểu là một quyết định thiết kế API thật.