Quan sát hệ thống phía sau bằng OpenTelemetry từ đầu
11 tháng 6, 2026
Khi hệ thống chạy ổn định, nhiều nhóm chỉ chú ý đến việc thêm tính năng. Nhưng khi người dùng tăng, lỗi xuất hiện ở nơi không ai ngờ: một yêu cầu chậm vì gọi dịch vụ thanh toán, một tiến trình nền lặp lại thất bại, hoặc một bản phát hành mới làm tăng tỉ lệ lỗi. Quan sát hệ thống giúp bạn nhìn thấy những dấu hiệu đó trước khi khách hàng báo cáo.
Trong bài này, chúng ta sẽ đi từ tư duy cơ bản đến một cài đặt thực tế bằng OpenTelemetry. Mục tiêu không phải là dựng một nền tảng thật lớn, mà là hình thành thói quen thu thập dữ liệu vận hành ngay từ khi viết mã.
Vì sao cần quan sát hệ thống
Khác với gỡ lỗi cục bộ, quan sát hệ thống trả lời câu hỏi: chuyện gì đang xảy ra trong môi trường thật. Khi một người dùng báo rằng thao tác thanh toán chậm, bạn không cần đoán mò trong hàng chục file nhật ký. Bạn có thể mở một vết truy, xem yêu cầu đi qua những thành phần nào, thời gian chờ ở đâu, và lỗi đầu tiên xuất hiện tại bước nào.
Một hệ thống có khả năng quan sát tốt thường mang lại ba lợi ích rõ ràng:
- Phát hiện lỗi nhanh hơn vì dữ liệu được gom về một nơi.
- So sánh bản phát hành cũ và mới bằng các số liệu thực tế.
- Hiểu hành vi hệ thống khi tải tăng mà không cần tái hiện toàn bộ môi trường trên máy cá nhân.
Điều quan trọng là quan sát hệ thống không nên được xem là bước làm thêm sau khi xong sản phẩm. Nếu để muộn, mỗi dịch vụ sẽ có định dạng nhật ký khác nhau, cách đặt tên khác nhau, và việc nối các dấu vết trở nên rất khó.
Ba tín hiệu nên thu thập trước
Vết truy
Vết truy mô tả hành trình của một yêu cầu qua nhiều phần mềm. Mỗi bước trong hành trình có thể được biểu diễn bằng một đoạn truy vết. Nhờ vậy, bạn biết yêu cầu đã gọi cơ sở dữ liệu, hàng đợi, dịch vụ thanh toán, hoặc bộ nhớ đệm theo thứ tự nào.
Khi đọc vết truy, hãy chú ý thời gian của từng đoạn. Một đoạn kéo dài bất thường không phải lúc nào cũng là lỗi, nhưng nó là manh mối tốt để điều tra tiếp.
Số liệu
Số liệu giúp bạn nhìn xu hướng theo thời gian. Ví dụ, số yêu cầu mỗi phút, thời gian phản hồi trung bình, tỉ lệ lỗi, hoặc số tác vụ nền đang chạy. Số liệu rất phù hợp để đặt cảnh báo: nếu tỉ lệ lỗi vượt ngưỡng trong năm phút, đội vận hành có thể được thông báo sớm.
Nhật ký
Nhật ký vẫn rất hữu ích khi bạn cần biết chi tiết sự kiện: tham số đầu vào, mã lỗi trả về, hoặc thông tin ngữ cảnh của người dùng. Tuy nhiên, nhật ký nên có cấu trúc rõ ràng, tránh ghi quá nhiều dữ liệu nhạy cảm như mật khẩu, mã token, hoặc thông tin cá nhân.
Cài đặt nền tảng tối giản
Giả sử bạn có một dịch vụ Node.js xử lý đơn hàng. Trước tiên, hãy thêm các gói cần thiết để tự động thu thập vết truy từ thư viện phổ biến như trình phục vụ web, máy khách cơ sở dữ liệu, và trình gọi dịch vụ bên ngoài.
npm install @opentelemetry/api @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-trace-otlp-grpc @opentelemetry/resources @opentelemetry/semantic-conventions
Tạo một file khởi tạo quan sát và nhập nó thật sớm trong tiến trình ứng dụng:
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-grpc';
import { Resource } from '@opentelemetry/resources';
import { ATTR_SERVICE_NAME } from '@opentelemetry/semantic-conventions';
const sdk = new NodeSDK({
resource: new Resource({
[ATTR_SERVICE_NAME]: 'checkout-api'
}),
traceExporter: new OTLPTraceExporter(),
instrumentations: [getNodeAutoInstrumentations()]
});
sdk.start();
Đặt biến môi trường để ứng dụng biết nơi gửi dữ liệu:
OTEL_SERVICE_NAME=checkout-api
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
Cách này giúp bạn tách phần quan sát khỏi mã nghiệp vụ. Khi cần đổi nơi lưu vết truy, bạn chỉ thay cấu hình thay vì sửa toàn bộ ứng dụng.
Thêm vết truy vào luồng nghiệp vụ
Tự động thu thập đã giúp bạn có nhiều dữ liệu, nhưng đôi khi cần thêm ngữ cảnh riêng. Ví dụ, khi xử lý đơn hàng, bạn có thể tạo một đoạn truy vết cho bước kiểm tra tồn kho và bước gọi thanh toán.
import { trace } from '@opentelemetry/api';
export async function createOrder(order) {
const tracer = trace.getTracer('checkout-api');
return tracer.startActiveSpan('tao-don-hang', async (span) => {
try {
span.setAttribute('loai-don-hang', order.type);
await kiemTraTonKho(order.items);
await goiThanhToan(order.payment);
await luuDonHang(order);
span.setAttribute('trang-thai', 'thanh-cong');
return { ok: true };
} catch (error) {
span.setAttribute('trang-thai', 'that-bai');
span.recordException(error);
throw error;
} finally {
span.end();
}
});
}
Điểm đáng chú ý là đoạn truy vết nên mang tên dễ hiểu và ổn định. Tránh đặt tên chứa mã đơn hàng hoặc tên người dùng, vì những giá trị này thay đổi liên tục và có thể gây rò rỉ dữ liệu. Thay vào đó, hãy đưa thông tin định danh vào thuộc tính một cách có chọn lọc.
Thu thập bằng bộ thu trung gian
Trong môi trường phát triển, bạn có thể gửi trực tiếp dữ liệu đến công cụ phân tích. Tuy nhiên, trong môi trường nhiều dịch vụ, một bộ thu trung gian giúp chuẩn hóa dữ liệu, lọc thông tin không cần thiết, và gửi đến nhiều đích khác nhau.
Một cấu hình đơn giản có thể trông như sau:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
processors:
batch: {}
exporters:
otlp/jaeger:
endpoint: jaeger:4317
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp/jaeger]
Bộ thu trung gian không chỉ hữu ích cho vết truy. Khi hệ thống mở rộng, bạn có thể thêm đường ống cho số liệu và nhật ký. Cách tổ chức này giúp các ứng dụng chỉ cần biết một giao thức chung, còn việc gửi dữ liệu đi đâu là trách nhiệm của cấu hình vận hành.
Đọc kết quả như một thói quen kỹ thuật
Công cụ quan sát chỉ có giá trị khi được đọc thường xuyên. Sau mỗi bản phát hành, hãy kiểm tra thời gian phản hồi, tỉ lệ lỗi, và những vết truy chậm nhất. Nếu thấy một đoạn truy vết luôn xuất hiện trong các yêu cầu chậm, đó là nơi nên ưu tiên tối ưu hoặc thêm cảnh báo.
Khi điều tra sự cố, đừng bắt đầu bằng việc đọc toàn bộ nhật ký. Hãy tìm một yêu cầu đại diện, theo dõi vết truy của nó, sau đó mới mở nhật ký liên quan. Quy trình này giúp bạn không bị lạc trong quá nhiều dữ liệu.
Những lỗi thường gặp
Một lỗi phổ biến là ghi quá nhiều dữ liệu. Nhật ký chi tiết quá mức làm tăng chi phí lưu trữ và khiến việc tìm manh mối khó hơn. Lỗi thứ hai là đặt tên không thống nhất: cùng một thao tác nhưng mỗi dịch vụ gọi bằng một tên khác nhau. Lỗi thứ ba là quên gắn ngữ cảnh khi gọi bất đồng bộ, khiến vết truy bị đứt đoạn.
Hãy bắt đầu với phạm vi nhỏ: một dịch vụ, ba loại số liệu chính, và một vài đoạn truy vết quan trọng. Khi đội đã quen với cách đọc dữ liệu, bạn có thể mở rộng dần sang các dịch vụ khác.
Kết luận
Quan sát hệ thống không phải là một dự án xa xỉ dành cho nền tảng lớn. Ngay cả một dịch vụ nhỏ cũng cần biết mình đang chạy ra sao. Với OpenTelemetry, bạn có thể xây dựng nền tảng dữ liệu vận hành theo cách mở, ít phụ thuộc vào một nhà cung cấp cụ thể, và dễ mở rộng khi hệ thống phát triển.