Observability & Production-ready — tổng quan

TL;DR: Actuator mở ra bề mặt để hỏi TaskFlow những câu hỏi vận hành cơ bản — còn sống không, sẵn sàng nhận request chưa, connection pool còn trống bao nhiêu. Health indicator gán đúng câu trả lời đó vào hai loại probe Kubernetes khác hẳn nhau. Micrometer đo số lượng bằng đúng loại meter, còn percentile đọc đúng những con số đó thay vì để trung bình cộng giấu đi phần tệ nhất. Observation API gộp việc đo metric và mở trace vào một lần khai báo, rồi tracing OTLP theo dấu một request xuyên nhiều service, nối thẳng vào dòng log JSON. Sáu bài đi theo đúng thứ tự đó, từng bước dựng một hệ quan sát thật cho TaskFlow.

Vì sao module này tồn tại

TaskFlow chạy được không có nghĩa là chạy tốt. Module trước làm cho TaskFlow dùng đúng công cụ Java hiện đại, nhưng khi có sự cố thật, câu hỏi luôn là "chuyện gì đang xảy ra bên trong, ngay lúc này". Không có observability, câu trả lời duy nhất là SSH vào container đọc log tay, hoặc restart mù rồi hy vọng — đúng tình huống mở đầu bài 01.

Sáu bài trong module này không đứng độc lập — mỗi bài dùng thẳng dữ liệu bài trước vừa tạo ra, không phải một chuỗi chủ đề xếp cạnh nhau cho tiện đọc. Health indicator ở bài 02 cần bề mặt Actuator bài 01 đã mở. Percentile ở bài 04 đọc đúng con số Timer mà Micrometer bài 03 vừa ghi lại. Observation API ở bài 05 thay thế đúng ba đoạn code rời rạc mà bài 03–04 từng dùng riêng lẻ. Tracing OTLP ở bài 06 xuất đúng span mà Observation vừa sinh ra ở bài 05. Bỏ một bài giữa chừng, bài sau mất luôn nguyên liệu để chạy ví dụ của nó — đây là phụ thuộc thật, không phải thứ tự trình bày tiện tay.

Cả module xoay quanh đúng một luận điểm: metric cho biết CÓ vấn đề, trace cho biết vấn đề Ở ĐÂU. Hai công cụ trả lời hai câu hỏi khác nhau, không cái nào thay được cái kia — bài 04 và bài 06 chứng minh điều đó bằng chính ví dụ TaskFlow.

flowchart LR
    A["Actuator<br/>mo be mat"] --> B["Health<br/>song hay san sang"]
    B --> C["Micrometer<br/>do dung loai meter"]
    C --> D["Percentile<br/>doc dung do tre"]
    D --> E["Observation API<br/>gop do"]
    E --> F["Tracing OTLP<br/>chi ra cho cham"]

Sau module này bạn sẽ

• Design bề mặt Actuator cho production: expose endpoint nào, chặn endpoint nào, vì sao tách cổng quản trị
• Implement health indicator riêng và map đúng vào readiness so với liveness probe
• Implement metric Micrometer đúng loại meter và kiểm soát cardinality của tag
• Diagnose độ trễ bằng percentile P99 và explain vì sao trung bình cộng che mất sự cố
• Trace một request xuyên nhiều service bằng Observation API và OTLP, nối trace ID vào log

Lộ trình module

• Bài 01 — Actuator: bề mặt vận hành — endpoint nào TaskFlow nên mở ra ngoài, endpoint nào phải khoá lại.
• Bài 02 — Health indicator và hai loại probe — TaskFlow còn sống, hay chỉ đang tạm không sẵn sàng?
• Bài 03 — Micrometer, metric và tag — chọn đúng loại meter, và vì sao một tag sai chỗ làm hoá đơn monitoring phình ra.
• Bài 04 — Percentile và SLO — vì sao độ trễ trung bình đẹp trong khi người dùng vẫn kêu chậm.
• Bài 05 — Observation API — một lần khai báo, ra cả metric lẫn span, thay vì ba đoạn code rời rạc dễ lệch nhau.
• Bài 06 — Tracing và OTLP — một request cụ thể chậm ở chặng nào, khi metric của mọi service liên quan đều báo bình thường.
• Mini-challenge — TaskFlow v5 — gắn cả bộ quan sát trên vào TaskFlow, đúng lab khép vòng module.

Yêu cầu trước khi bắt đầu

Module này dùng lại, không dạy lại, ba thứ đã học ở course trước:

• Autoconfiguration — Actuator tự bật khi thấy dependency đúng trên classpath, cùng cơ chế @ConditionalOn* đã học ở spring-core, module 05.
• SecurityFilterChain — bài 01 dùng nguyên DSL đã học ở spring-security, module 01 để bảo vệ endpoint quản trị.
• Structured logging JSON và MDC — đã dạy đủ ở spring-core, bài Structured logging. Module này không dạy lại cách bật log JSON hay cách MDC hoạt động — chỉ dùng nó làm nơi traceId hạ cánh ở bài 06.

Time budget

Cách học module này hiệu quả

• Đọc bài 01–02 xong thì gọi thử /actuator/health trên một project Spring Boot thật, đừng chỉ đọc JSON mẫu trong bài.
• Bài 03–04 nên chạy kèm Prometheus local — tự viết một histogram_quantile() query thay vì tin lời giải thích suông.
• Bài 05–06 dễ hiểu sai nếu chỉ đọc code — dựng Jaeger hoặc Tempo local, tự nhìn một trace thật trước khi qua mini-challenge.
• Tới mini-challenge, đừng mở lại từng bài để copy — thử tự nhớ trước, chỉ tra lại đúng phần đang bị kẹt.