Khả năng quan sát (Observability) và OpenTelemetry

1. Tổng quan

Định nghĩa: Khả năng quan sát (observability) là năng lực suy luận trạng thái bên trong của hệ thống chỉ từ telemetry (metric, log, trace) phát ra bên ngoài hệ thống, và có thể làm rõ nguyên nhân ngay cả với những câu hỏi chưa được định nghĩa trước.

Giám sát (monitoring) truyền thống tập trung vào việc xác nhận "có sự cố hay không" bằng ngưỡng và dashboard đã định sẵn. Tuy nhiên, khi microservice, container và serverless lan rộng, một yêu cầu của người dùng đi qua hàng chục dịch vụ, và các instance được tạo ra rồi biến mất theo đơn vị vài phút. Trong môi trường như vậy, không thể dự đoán trước toàn bộ "cái gì sẽ hỏng" để cài sẵn chỉ số, và biểu hiện sự cố cũng xuất hiện dưới dạng "chỉ chậm với một số người dùng, một số đường đi nhất định" hơn là "ngừng hoàn toàn". Khả năng quan sát khác với giám sát truyền thống ở chỗ nó hướng tới việc cho phép đào sâu một cách khám phá sau sự việc vào những vấn đề chưa biết mà ta không biết (unknown-unknowns).

Giám sát và khả năng quan sát không phải là khái niệm đối lập mà gần với quan hệ bao hàm. Giám sát là hoạt động thu thập và cảnh báo chỉ số cho các chế độ hỏng đã biết, còn khả năng quan sát là thuộc tính (property) thiết kế hệ thống để phát ra telemetry đủ phong phú, bao gồm cả những chỉ số đó. Tức là "thực hiện giám sát" là hành vi, còn "có thể quan sát được" là tính chất mà hệ thống phải có. Do đó, khả năng quan sát không phải là vấn đề đưa thêm một công cụ vận hành, mà là đặc tính chất lượng cần bảo đảm từ giai đoạn thiết kế để mã nguồn để lại những tín hiệu có ý nghĩa.

Trong bài thi, đừng kết thúc bằng việc liệt kê khả năng quan sát là "3 yếu tố (metric, log, trace)", mà phải liên kết đến việc ba tín hiệu tại sao bổ trợ lẫn nhau và tạo ra giá trị như thế nào khi được liên kết (correlation), cùng vai trò của OpenTelemetry trong việc chuẩn hóa điều đó mà không phụ thuộc nhà cung cấp, thì mới thành bài làm mang góc nhìn thiết kế.

1.1 Bối cảnh ra đời và sự cần thiết

Thứ nhất, do độ phức tạp của hệ thống phân tán. Ở kiến trúc nguyên khối chỉ cần xem log của một tiến trình, nhưng khi phân rã thành 100 dịch vụ thì không thể biết độ trễ của một yêu cầu phát sinh ở đoạn nào chỉ bằng một log đơn lẻ. Để truy vết quan hệ nhân quả giữa các dịch vụ, distributed tracing — cho phép nối xem yêu cầu từ đầu đến cuối (end-to-end) — trở thành bắt buộc.

Thứ hai, do tính phù du (ephemerality) của hạ tầng. Pod Kubernetes hay hàm serverless khi ta muốn truy cập để điều tra sau khi sự cố xảy ra thì đã biến mất. Do đó, thay vì gỡ lỗi bằng cách truy cập sau sự việc, cần chuyển sang cách phát đủ tín hiệu ra bên ngoài trong khi đang chạy.

Thứ ba, từ góc độ chi phí và trải nghiệm người dùng. Thời gian khôi phục trung bình (MTTR) của sự cố phần lớn tiêu tốn vào "làm rõ nguyên nhân (chẩn đoán sau khi phát hiện)", và nếu khả năng quan sát thấp thì đoạn này kéo dài, khiến tổn thất doanh thu và niềm tin lớn hơn. Khả năng quan sát gắn trực tiếp với rút ngắn MTTR, nên trở thành điều kiện tiên quyết của quản lý độ tin cậy SRE.

1.2 Mục tiêu cốt lõi và phi mục tiêu

Mục tiêu cốt lõi là chẩn đoán khám phá các vấn đề chưa biết, bảo đảm tương quan giữa các tín hiệu, chuẩn hóa việc đo đạc (instrumentation) trung lập với nhà cung cấp, và rút ngắn thời gian chẩn đoán. Ngược lại, thu thập không giới hạn và lưu trữ vĩnh viễn mọi dữ liệu không phải là mục tiêu. Bản thân telemetry gây ra chi phí lưu trữ, truyền tải và truy vấn, nên việc thiết kế cardinality và lấy mẫu (sampling) để quản lý tỷ lệ tín hiệu trên nhiễu mới chính là năng lực cốt lõi.

2. Ba tín hiệu của khả năng quan sát (Three Pillars)

Khả năng quan sát thường được giải thích bằng ba tín hiệu metric, log, trace. Tuy nhiên, nếu xem riêng ba tín hiệu bằng các công cụ khác nhau thì chúng trở thành "silo" và giá trị giảm một nửa. Khả năng quan sát thực sự đạt được khi trong một tình huống sự cố, có thể di chuyển liền mạch từ chỉ số (cái gì, bao nhiêu) → trace (ở đâu) → log (tại sao).

flowchart LR
    A["Ứng dụng/hạ tầng"] -->|Đo đạc| B["Tín hiệu telemetry"]
    B --> M["Metric(Metrics)"]
    B --> L["Log(Logs)"]
    B --> T["Trace(Traces)"]
    M -->|Phát hiện bất thường| Q["Nhận biết vấn đề"]
    Q -->|Ở đâu?| T
    T -->|Tại sao?| L
    L --> R["Làm rõ nguyên nhân gốc"]

2.1 Metric (Metrics)

Metric là các giá trị số được tổng hợp theo thời gian (lưu lượng yêu cầu, tỷ lệ lỗi, độ trễ, mức sử dụng tài nguyên, v.v.). Vì loại bỏ các sự kiện riêng lẻ và nén thành thống kê, chi phí lưu trữ thấp và phù hợp với xu hướng dài hạn và cảnh báo. Ví dụ, "tỷ lệ lỗi 5xx trong 5 phút > 1%" là dạng thích hợp để giám sát bằng metric, và các phương pháp luận như RED (Rate·Errors·Duration) hay USE (Utilization·Saturation·Errors) hệ thống hóa việc nên xem chỉ số nào. Tuy nhiên, metric mất ngữ cảnh của từng yêu cầu riêng lẻ trong quá trình tổng hợp, nên cho biết "cái gì đã sai" nhưng không trả lời được "tại sao". Đặc biệt, khi tổ hợp nhãn (label) tăng lên, cardinality bùng nổ khiến chi phí lưu trữ và truy vấn tăng vọt, nên cần chú ý không dùng những chiều có giá trị vô hạn như ID người dùng làm nhãn metric.

2.2 Log (Logs)

Log là bản ghi các sự kiện riêng lẻ xảy ra tại một thời điểm cụ thể. Log có thể chứa ngữ cảnh phong phú nhất nên là manh mối cuối cùng của phân tích nguyên nhân gốc, nhưng khối lượng lớn nên chi phí lưu trữ và tìm kiếm cao. So với log văn bản phi cấu trúc, dùng log có cấu trúc (JSON, v.v.) cho phép tìm kiếm và tổng hợp theo trường, nâng cao đáng kể khả năng quan sát. Cốt lõi là ghi kèm trace ID vào log để liên kết trace và log với nhau; nếu không có điều này, log lại trở thành silo.

2.3 Trace (Traces)

Trace là việc nối các quan hệ nhân quả và thời gian của các đơn vị công việc (span) mà một yêu cầu tạo ra khi đi qua nhiều dịch vụ. Mỗi span có tên dịch vụ, thời điểm bắt đầu/kết thúc, trạng thái, span cha, và chúng tạo thành cây cho thấy toàn bộ hành trình của yêu cầu. Distributed tracing lan truyền ngữ cảnh (context propagation) vượt qua ranh giới dịch vụ bằng header traceparent của chuẩn W3C Trace Context. Nhờ đó, có thể chỉ ra chính xác nút thắt theo từng đoạn, chẳng hạn "độ trễ p99 của API thanh toán tăng thực ra là do khóa DB của dịch vụ coupon phía dưới".

3. Chuẩn OpenTelemetry (OTel) và pipeline

Trước đây, thư viện đo đạc khác nhau theo từng tín hiệu và từng nhà cung cấp, nên sự phụ thuộc nhà cung cấp lớn: đổi công cụ quan sát thì phải đo đạc lại mã ứng dụng. OpenTelemetry (OTel) là dự án thuộc CNCF, giải quyết vấn đề này bằng cách chuẩn hóa API/SDK đo đạc duy nhất và đặc tả truyền tải (OTLP) bao trùm metric, log, trace. Nhà phát triển chỉ đo đạc một lần bằng OTel API, còn việc gửi dữ liệu đi đâu được thay đổi bằng cấu hình (Exporter). Tức là, tách biệt "đo đạc (mã)" và "backend (công cụ)" để bảo đảm tính trung lập với nhà cung cấp.

flowchart LR
    subgraph APP["Ứng dụng đã được đo đạc"]
        SDK["OTel SDK(đo đạc tự động/thủ công)"]
    end
    SDK -->|"OTLP(gRPC/HTTP)"| COL["OTel Collector"]
    COL -->|"Nhận(Receiver)"| P["Xử lý(batch·lấy mẫu·lọc)"]
    P -->|"Xuất(Exporter)"| BK1["Backend metric(ví dụ: Prometheus)"]
    P --> BK2["Backend trace(ví dụ: Jaeger/Tempo)"]
    P --> BK3["Backend log(ví dụ: Loki/ELK)"]

OTel Collector là bộ phận trung tâm của cấu trúc này, nhận telemetry từ nhiều nguồn (Receiver), xử lý (Processor) bằng batch, lấy mẫu, che dữ liệu nhạy cảm, gán lại nhãn, v.v., rồi xuất ra nhiều backend (Exporter). Ứng dụng chỉ cần gửi tới một nơi là Collector, nên việc thay backend hay gửi đa đích có thể thực hiện mà không đổi mã. Ngoài ra, nếu xử lý lấy mẫu tập trung tại Collector, có thể hiện thực chính sách "nhất định lưu yêu cầu bị lỗi" bằng lấy mẫu dựa trên đuôi (tail-based sampling) — xem toàn bộ trace rồi mới quyết định. Việc đo đạc kết hợp đo đạc tự động (agent tự động bắt các lời gọi HTTP, DB) và đo đạc thủ công (thêm span, thuộc tính tùy chỉnh mang ý nghĩa nghiệp vụ), và cái sau quyết định chất lượng của câu trả lời.

4. So sánh và ví dụ khi triển khai — Tại sao thiết kế như vậy

Xung đột cốt lõi trong thiết kế khả năng quan sát là sự đánh đổi giữa tính đầy đủ và chi phí. Lưu 100% trace của mọi yêu cầu là lý tưởng, nhưng với lưu lượng quy mô lớn thì chi phí lưu trữ và truyền tải không thể gánh nổi. Vì vậy phải chọn chiến lược lấy mẫu. Lấy mẫu dựa trên đầu (head-based) quyết định chọn hay không theo xác suất tại thời điểm yêu cầu bắt đầu nên overhead thấp, nhưng có thể bỏ lỡ "yêu cầu lỗi hiếm khi xảy ra". Lấy mẫu dựa trên đuôi (tail-based) chọn sau khi yêu cầu hoàn tất dựa trên kết quả (lỗi, độ trễ cao), nên lưu có chọn lọc các trace có giá trị chẩn đoán cao, nhưng cần đệm cho đến khi hoàn tất nên tốn thêm tài nguyên Collector. Do đó, cách làm chuẩn trong thực tiễn là kết hợp hai phương thức, chẳng hạn "lưu lượng bình thường lấy mẫu 1%, yêu cầu lỗi và chậm lưu 100%".

Lấy ví dụ về hiệu quả cụ thể, giả sử ở một dịch vụ, khiếu nại về chậm thanh toán của người dùng phát sinh rải rác. Trên dashboard metric, độ trễ p50 tổng thể bình thường nên không thấy nguyên nhân, nhưng khi mở trace đã lưu 100% chỉ cho các yêu cầu lỗi và độ trễ cao, lộ ra rằng ở span con của đường đi một phương thức thanh toán cụ thể, phản hồi của cổng thanh toán (PG) bên ngoài mất hơn 3 giây. Chuyển sang log có cấu trúc gắn với span đó bằng trace ID, có thể xác nhận nguyên nhân là việc thử lại do timeout của một công ty thẻ cụ thể. Như vậy, phải có tương quan nối ba tín hiệu bằng trace ID thì mới chẩn đoán được vấn đề "trung bình bình thường nhưng chỉ một phần chậm", và đây là điểm khả năng quan sát tách khỏi giám sát đơn thuần.

5. Các điểm cần cân nhắc và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

Thứ nhất, khả năng quan sát là chất lượng thiết kế, không phải việc đưa công cụ vào sau. Phải xác định tiêu chuẩn phát triển (quy ước logging, lan truyền trace, correlation ID) ngay ở giai đoạn kiến trúc để mã để lại span, thuộc tính và log có cấu trúc có ý nghĩa; đẩy việc bảo đảm khả năng quan sát cho đội vận hành sẽ thất bại.

Thứ hai, quản trị chi phí và cardinality quyết định thành bại. Nhãn tùy tiện và lưu toàn bộ có thể khiến chi phí nền tảng quan sát lớn hơn cả hạ tầng dịch vụ. Cần quản lý bằng chính sách: phân cấp thời gian lưu trữ theo tín hiệu (metric dài hạn, log và trace ngắn hạn), lấy mẫu, giới hạn trên của cardinality.

Thứ ba, giảm phụ thuộc nhà cung cấp bằng việc áp dụng chuẩn. Nếu đo đạc bằng các chuẩn mở như OpenTelemetry, OTLP, W3C Trace Context, có thể thay thế hoặc chạy song song backend (mã nguồn mở/thương mại/đám mây) mà không đổi mã, bảo đảm năng lực đàm phán và tính di động dài hạn.

Thứ tư, quản lý xung đột với bảo mật và thông tin cá nhân. Telemetry dễ lẫn thông tin nhạy cảm như định danh người dùng, token, nên cần đặt che dữ liệu, lọc ở tầng Collector và kiểm soát truy cập để dữ liệu quan sát không trở thành con đường rò rỉ mới.

Thứ năm, triển vọng liên kết với SRE và AIOps. Dữ liệu quan sát trở thành đầu vào cho SLI/SLO và tính toán ngân sách lỗi (error budget), và xa hơn là dữ liệu huấn luyện cho AIOps tự động hóa phát hiện bất thường và suy luận nguyên nhân gốc. Do đó, khả năng quan sát định vị như hạ tầng nền tảng cho ứng phó sự cố trong ngắn hạn và vận hành tự chủ (self-healing) trong dài hạn.

Tài liệu tham khảo

• Tài liệu chính thức OpenTelemetry: https://opentelemetry.io/docs/
• Chuẩn W3C Trace Context: https://www.w3.org/TR/trace-context/
• Dự án CNCF OpenTelemetry: https://www.cncf.io/projects/opentelemetry/

Tóm tắt một câu: Khả năng quan sát là thuộc tính hệ thống liên kết metric, log, trace với nhau bằng trace ID để làm rõ cả những sự cố chưa biết thông qua khám phá sau sự việc, và được bảo đảm một cách hiệu quả về chi phí, không phụ thuộc nhà cung cấp, nhờ đo đạc theo chuẩn OpenTelemetry cùng quản trị lấy mẫu và cardinality.