Observability là khả năng hiểu được trạng thái bên trong của system bằng cách quan sát các tín hiệu mà system phát ra trong runtime.

Trong DevOps và SRE, Observability giúp bạn triage incident nhanh hơn, debug các tình huống mới nhanh hơn, và giảm thời gian service recovery trong production.

Ví dụ: User report API chậm và thỉnh thoảng 5xx. Nếu bạn có metrics, logs, traces và correlation tốt, bạn có thể trả lời nhanh các câu hỏi như request nào chậm, endpoint nào bị ảnh hưởng, dependency nào đang chậm, lỗi phát sinh ở layer nào.

Observability phản ánh mức độ bạn có thể đặt câu hỏi về system và tìm được câu trả lời từ telemetry, thay vì chỉ nhìn một vài dashboard cố định.

Observability cho biết điều gì?

Observability giúp trả lời nhanh các câu hỏi cơ bản:

• Khi có incident, vấn đề nằm ở service nào, endpoint nào, dependency nào?
• Latency tăng là do queueing, DB chậm, cache miss, hay network issue?
• Một thay đổi sau deploy có gây regression về Latency hoặc Error rate không?

Tuy nhiên, cần lưu ý: Observability không tự tạo ra reliability. Nếu instrumentation kém, dữ liệu thiếu context, hoặc correlation không có, bạn vẫn triage chậm và dễ kết luận sai.

Observability khác monitoring ra sao?

Monitoring thường tập trung vào các chỉ số và dashboard đã định trước, mục tiêu là phát hiện vấn đề và alert đúng lúc. Observability tập trung vào khả năng điều tra sâu khi gặp tình huống mới, mục tiêu là giảm thời gian tìm nguyên nhân và giảm MTTR.

Trong thực tế, monitoring và Observability đi cùng nhau:

• Monitoring giúp detect nhanh và paging đúng.
• Observability giúp triage nhanh, khoanh vùng nhanh, và tìm root cause nhanh.

Ba tín hiệu thường gặp trong Observability

Trong hệ thống web hiện đại, telemetry thường được chia thành các nhóm sau:

• Metrics: số liệu dạng time series, dùng để xem xu hướng và phát hiện bất thường.
• Logs: chi tiết theo event, dùng để xem context khi có lỗi hoặc khi cần tra cứu.
• Traces: dòng chảy của một request qua nhiều service, giúp xác định bước nào đang tốn thời gian hoặc lỗi.

Ngoài ra còn có events, profiling, nhưng ba nhóm trên là nền tảng dễ bắt đầu nhất.

Cách hiểu Observability

Một số nguyên tắc cơ bản khi triển khai Observability:

• Observability phải gắn với câu hỏi vận hành, không chỉ gắn với tool.
• Telemetry phải có context đủ để query, ví dụ service name, endpoint, status code, trace id, user id hoặc tenant id nếu phù hợp.
• Correlation là điểm tạo ra khác biệt, ví dụ từ metric spike bạn nhảy được sang log và trace của nhóm request gây spike.

Ví dụ:

• RPS tăng và p95 Latency tăng: bạn cần trace để biết đoạn nào chậm, và log để biết lỗi cụ thể.
• Error rate tăng: bạn cần breakdown theo status code, endpoint, dependency để tìm nhóm lỗi chiếm tỷ trọng lớn.
• Một endpoint có Latency tăng nhưng tổng thể vẫn ổn: cần breakdown theo endpoint để không bị che mất regression.

Observability thường được triển khai ở đâu?

Tuỳ kiến trúc, Observability thường có các lớp triển khai sau:

• Edge layer như Load balancer, Ingress, API Gateway: giúp nhìn user facing signals và traffic patterns.
• Service layer: metrics và logs theo service, breakdown theo endpoint, status code.
• Tracing layer: traces xuyên suốt nhiều service để thấy dependency chain và thời gian spent ở từng hop.
• Infrastructure layer: CPU, memory, Disk IOPS, network, và các saturation signals khác.

Trong vận hành thực tế, nên chọn 1-2 measurement point chính cho user impact và service health, rồi bổ sung tracing để debug nhanh.

Những yếu tố làm Observability kém hiệu quả

Một số nguyên nhân phổ biến khiến Observability không giúp được nhiều khi incident xảy ra:

• Instrumentation thiếu tag quan trọng, dẫn tới không breakdown được theo service hoặc endpoint.
• Logs không có trace id hoặc request id, nên khó correlation với traces.
• Sampling quá mạnh ở traces, làm thiếu dữ liệu đúng lúc cần điều tra.
• Dữ liệu quá nhiều noise do log spam hoặc metrics cardinality không kiểm soát, làm query khó và tốn chi phí.
• Alert rule không gắn với user impact, dẫn tới paging nhiều nhưng không actionable.

Vì vậy, Observability tốt thường bắt đầu từ việc chuẩn hoá instrumentation, chuẩn hoá correlation, rồi mới tối ưu dashboard và alerting.

Observability được dùng để làm gì trong DevOps?

Ở mức cơ bản, Observability thường được dùng cho:

• Triage incident nhanh hơn và giảm MTTR.
• Phát hiện regression sau deploy bằng cách theo dõi Latency, Error rate và saturation.
• Hỗ trợ capacity planning bằng cách xem Throughput, Latency và saturation theo mức tải.
• Hỗ trợ SLO và error budget bằng cách theo dõi SLI gắn với user impact.

Kết luận

Observability là nền tảng để hiểu system khi nó chạy trong runtime, đặc biệt trong microservices và distributed systems.

Để Observability có giá trị trong production, bạn cần telemetry đủ context, correlation giữa metrics, logs, traces, và cách đọc gắn với user impact. Đây là cách thực tế để triage nhanh, debug nhanh và vận hành ổn định hơn.