Observability — Tổng quan và nền tảng

Doc Type

Reference

Technology

observability

Status

Active

Tags

observabilitylgtmopentelemetrymetricslogstracesalloy

Nền tảng Observability, đường đi của telemetry và vai trò của từng thành phần trong stack. Đọc theo thứ tự các chương hoặc chọn chủ đề cần tra cứu trong mục lục.

Phạm vi và mô hình hệ thống

Phạm vi và quy ước

Bài này giải thích cơ chế của OpenTelemetry, Prometheus, Loki, Tempo, Grafana và Alloy theo tài liệu chính thức. Cấu hình collector, file Compose/Alloy và quy trình kiểm tra được trình bày trong bài triển khai và vận hành LGTM.

Các metric name, labels, resource attributes và endpoint khi truy vấn phải lấy từ instrumentation và cấu hình của hệ thống. Mỗi phần có link đến tài liệu nguồn; tính năng phụ thuộc phiên bản được đối chiếu với phiên bản đang chạy.

Observability là gì?

Observability là khả năng hiểu trạng thái và hành vi bên trong hệ thống từ telemetry mà hệ thống phát ra. Một pipeline có giá trị khi dữ liệu giúp xác định service nào bị ảnh hưởng, mức độ ảnh hưởng và chặng xử lý cần điều tra.

Monitoring theo dõi các chỉ số và điều kiện đã chọn để phát hiện bất thường. Observability bổ sung dữ liệu và ngữ cảnh để phân tích nguyên nhân, kể cả khi chưa có dashboard hoặc alert riêng cho tình huống đó. Nền tảng chung là instrumentation và telemetry có chất lượng. OpenTelemetry Observability primer

Metrics, logs và traces

Signal	Dữ liệu thể hiện	Câu hỏi thường trả lời
Metrics	Phép đo theo thời gian: counter, giá trị hiện tại hoặc phân bố observations.	Tải, tỷ lệ lỗi và latency thay đổi như thế nào?
Logs	Bản ghi sự kiện, timestamp và thông tin liên quan.	Sự kiện nào xảy ra, tại service hoặc host nào?
Traces	Các spans liên quan trong một request hoặc workflow.	Request đi qua những chặng nào, chặng nào chậm hoặc lỗi?

OpenTelemetry còn hỗ trợ các loại signal khác. Trang này tập trung vào ba loại trên để thống nhất với các backend trong bộ tài liệu. OpenTelemetry signals

Tên gọi LGTM

Trong tài liệu Grafana, LGTM là Loki, Grafana, Tempo và Mimir. Kiến trúc trong bài triển khai LGTM dùng Prometheus làm metrics backend. Mimir cung cấp metrics storage tương thích Prometheus, có khả năng mở rộng phân tán và multi-tenancy. Xem LGTM stack và Grafana Mimir.

Xem sơ đồ kiến trúc LGTM trong bài triển khai để theo dõi đường đi của telemetry giữa application, Alloy và các backend.

Thành phần và đường đi của telemetry

Vai trò từng thành phần

Layer	Thành phần	Vai trò
Instrumentation	Application SDK, library, exporter	Tạo hoặc expose telemetry từ application và hạ tầng.
Collector	Grafana Alloy / OpenTelemetry Collector	Nhận dữ liệu, xử lý và export theo pipeline.
Metrics backend	Prometheus / Mimir	Lưu time series và phục vụ PromQL.
Logs backend	Loki	Lưu log streams và phục vụ LogQL.
Traces backend	Tempo	Lưu traces và phục vụ trace lookup / TraceQL.
Query và hiển thị	Grafana	Kết nối datasource, dashboard, Explore và alerting.

OpenTelemetry cung cấp API, SDK, protocol và tooling cho telemetry. Dữ liệu được export tới backend để lưu và query. What is OpenTelemetry?

Pull, push và query

Cơ chế	Chiều kết nối	Ý nghĩa
Metrics scrape	Collector → metrics endpoint	Collector gửi HTTP request; samples nằm trong response.
Remote write	Collector → metrics backend	Collector gửi samples đã thu tới receiver.
Docker logs	Collector → Docker API/socket	Collector đọc log stream của container được chọn.
OTLP	SDK / collector → receiver	Sender gửi telemetry theo protocol receiver hỗ trợ.
Query	Grafana → backend API	Backend trả kết quả để hiển thị hoặc phân tích.

Tham khảo prometheus.scrape, prometheus.remote_write và loki.source.docker.

Tần suất lấy mẫu, thời điểm gửi và query time range là các thông số riêng. Đối chiếu từng khoảng thời gian khi dữ liệu chưa xuất hiện trên dashboard.

Metrics và Prometheus

Time series, samples và labels

Prometheus nhận diện một time series bằng metric name và toàn bộ label set. Thêm, bỏ hoặc thay một label value tạo series khác. Một sample chứa timestamp cùng giá trị float hoặc native histogram. Prometheus data model

Labels nên có tập giá trị được kiểm soát, như service, job hoặc route đã chuẩn hóa. user_id, request ID và URL chứa ID dễ tạo nhiều series. Đặt tên metric theo đơn vị cơ bản như seconds, bytes; counter thường dùng hậu tố _total. Metric and label naming

Các loại metric

Type	Cơ chế	Dùng cho
Counter	Giá trị tích lũy, tăng dần; có thể reset khi process restart.	Tổng request, error hoặc bytes đã xử lý.
Gauge	Giá trị hiện tại, có thể tăng hoặc giảm.	Memory đang dùng, queue depth, concurrent requests.
Histogram	Phân bố observations, count và sum.	Request duration hoặc kích thước response.
Summary	Count, sum và quantiles tính phía application khi được cấu hình.	Phân bố cần tính quantile tại nguồn.

Prometheus metric types

Classic histogram tạo các series _bucket, _sum và _count; label le biểu thị giới hạn trên của bucket tích lũy. Native histogram giữ phân bố trong một sample tổng hợp. Histogram cho phép tính quantile khi query; quantiles của summary được tính tại nguồn và không cộng hoặc lấy trung bình để suy ra p95 toàn service. Histograms and summaries, Native histograms

PromQL và cách đọc kết quả

• rate(counter[5m]) tính tốc độ tăng trung bình mỗi giây trong cửa sổ, có xử lý counter reset.
• Với nhiều instance, tính rate trên từng series trước rồi aggregate bằng sum theo labels cần giữ.
• histogram_quantile ước lượng quantile từ histogram. Classic histogram phải giữ le khi aggregate buckets.
• Gauge được đọc hoặc aggregate theo ý nghĩa phép đo; rate dành cho counter.

p95 biểu thị ngưỡng mà khoảng 95% observations nằm dưới; độ chính xác phụ thuộc dữ liệu và cách chia buckets. Đối chiếu đơn vị, time window và nhóm series trước khi kết luận latency của service. Prometheus query functions

Cardinality

Cardinality là số series hình thành từ các tổ hợp labels thực tế. Nhiều giá trị ở nhiều labels có thể làm số series tăng nhanh, kéo theo memory, storage và query cost. Chọn label phục vụ việc phân nhóm; thông tin định danh từng request nên được giữ trong log hoặc trace. Prometheus instrumentation practices

Logs và Loki

Log stream và index labels

Loki nhóm các log có cùng label set thành một log stream. Index labels giúp chọn streams; nội dung log được đọc và lọc khi query. Labels nên nhận diện nguồn với số giá trị hữu hạn, như service, environment hoặc cluster.

trace_id, request_id, user ID và timestamp làm index labels dễ tạo nhiều streams và chunks nhỏ. Đây là chi phí của cách tổ chức dữ liệu, không chỉ của dung lượng nội dung log. Loki labels

Nội dung log và structured metadata

Structured logs giữ các trường như level, message và trace ID trong nội dung có cấu trúc. Loki còn hỗ trợ structured metadata: thuộc tính gắn với log entry, được query nhưng không trở thành index label. Khả năng dùng structured metadata phụ thuộc schema và cấu hình backend. Structured metadata

LogQL

LogQL bắt đầu bằng stream selector, sau đó có thể lọc chuỗi, parse nội dung hoặc tạo metric từ log. Query dưới dùng các labels có trong bản Alloy đã ẩn tên doanh nghiệp:

{job="docker",env="demo-prod"} |= "error"

Selector chọn streams; |= "error" giữ dòng chứa chuỗi đó. Bộ lọc này không yêu cầu log là JSON. Với log có cấu trúc, chọn parser đúng định dạng trước khi lọc theo trường. Query Loki

Traces và Tempo

Trace, span và context propagation

Trace tập hợp các spans liên quan; mỗi span mô tả một đơn vị công việc với thời gian, attributes và status. Quan hệ parent/child giúp theo dõi các chặng xử lý. OpenTelemetry traces

Context propagation truyền thông tin trace qua ranh giới process hoặc service. Với HTTP, instrumentation inject/extract context qua header như traceparent; service nhận tạo span mới trong cùng trace. Cùng service name chưa đủ để nối các request nếu context không được truyền đúng. Context propagation

Tempo và TraceQL

Tempo lưu traces và hỗ trợ tìm theo trace ID hoặc TraceQL. Điều kiện TraceQL có thể dựa trên resource attributes, span attributes và intrinsic fields. Tempo tracing pipeline

Field	Ý nghĩa
resource.service.name	Service phát sinh span.
span.<attribute>	Attribute gắn với operation.
span:status	Status của span.
span:duration	Thời gian của span.
trace:duration	Thời gian từ đầu đến cuối trace.

Khi phân tích latency, phân biệt thời gian một span với toàn trace; kiểm tra các chặng chạy song song và thời gian chờ giữa chúng. TraceQL

Head sampling và tail sampling

Cơ chế	Thời điểm quyết định	Đặc điểm
Head sampling	Khi trace bắt đầu.	Giảm dữ liệu sớm; chưa biết lỗi hoặc latency của các spans về sau.
Tail sampling	Sau khi quan sát spans trong khoảng chờ theo policy.	Chọn theo error/latency; cần memory và giữ trạng thái tại collector.

Tail sampling cần routing để spans của cùng trace tới cùng nơi ra quyết định. Nó không khôi phục spans đã bị head sampling loại bỏ. Sampling policy ảnh hưởng trực tiếp đến dữ liệu còn lại để điều tra. OpenTelemetry sampling

Instrumentation và collector

Resource và attributes

Resource nhận diện nguồn phát telemetry; span/log attributes mô tả operation hoặc sự kiện. service.name là tên logic của service; environment dùng thuộc tính deployment.environment.name theo semantic conventions. Đặt tên thống nhất giúp query và correlation. OpenTelemetry resources, Environment conventions

OTLP và endpoint

OTLP vận chuyển telemetry bằng gRPC hoặc HTTP. Port mặc định thường dùng là 4317 cho gRPC và 4318 cho HTTP. OTLP/HTTP dùng paths /v1/traces, /v1/metrics, /v1/logs; endpoint chung và endpoint riêng cho signal có quy tắc nối path khác nhau trong SDK.

OTLP/gRPC endpoint không thêm các HTTP paths trên.

Protocol, path, TLS và receiver bind address phải khớp ở hai đầu. Port thực tế lấy từ cấu hình receiver và published port. OTLP exporter configuration

Alloy component graph

Alloy nối các components bằng reference tới receiver/output, như forward_to. Đường nối quyết định data flow; thứ tự viết block trong file không quyết định thứ tự xử lý. Discovery tìm targets; source/receiver lấy dữ liệu; relabel/processor xử lý; writer/exporter gửi tới backend. Alloy telemetry flow

Agent pattern đặt collector gần nguồn để thu dữ liệu host/application. Gateway pattern nhận telemetry tập trung để xử lý hoặc export theo policy chung. Việc thêm gateway tạo thêm một tầng cần capacity, routing và giám sát. Agent pattern, Gateway pattern

Queue, retry và backpressure

Queue và retry giúp xử lý backend chậm hoặc mất kết nối tạm thời. Queue đầy, hết retry window, buffer chỉ nằm trong memory hoặc disk gặp sự cố vẫn có thể làm mất dữ liệu. Persistent queue và WAL phụ thuộc component, cấu hình và storage được cấp.

Backpressure truyền trạng thái quá tải về phía nguồn; mỗi pipeline phản ứng theo cơ chế riêng. Theo dõi queue usage, send failures, dropped data và memory để biết pipeline có giữ được dữ liệu khi backend gặp lỗi hay không. Collector resiliency

Grafana và correlation

Datasource, dashboard và Explore

Datasource cấu hình kết nối tới backend; dashboard lưu cách query và hiển thị. Explore phục vụ tra cứu trực tiếp trong lúc điều tra. URL datasource phải reachable từ Grafana; quyền truy cập, TLS và tenant cần khớp với backend. Grafana data sources, Grafana Explore

Liên kết metrics, logs và traces

Correlation dùng service identity, time range và các liên kết được cấu hình để chuyển giữa signals. Log có trace ID giúp mở trace liên quan; trace có service/operation giúp tìm metrics hoặc log tương ứng. Grafana trace integration

Exemplars có thể gắn một metric observation với trace khi instrumentation và backend hỗ trợ. Grafana exemplars

Cách đọc dữ liệu khi điều tra

Chọn service và time range từ metric bất thường, tìm log trong cùng khoảng, rồi mở trace liên quan để đọc các spans. Giữ nguyên ngữ cảnh khi chuyển datasource và đối chiếu với instrumentation của ứng dụng.

Chất lượng dịch vụ và alerting

Golden signals

Google SRE chọn bốn signals để theo dõi service phục vụ user:

Signal	Nội dung cần quan sát
Latency	Thời gian xử lý; phân biệt request thành công và thất bại.
Traffic	Lượng công việc hệ thống đang nhận/xử lý.
Errors	Tỷ lệ request thất bại hoặc trả kết quả sai theo tiêu chí service.
Saturation	Mức sử dụng tài nguyên và dấu hiệu chạm giới hạn.

Chọn phép đo gắn với hành vi của service, như request rate, error ratio, latency distribution và queue depth. Monitoring distributed systems

SLI và SLO

SLI là phép đo chất lượng dịch vụ; SLO là mục tiêu cho phép đo đó trong một cửa sổ thời gian. Với SLI dựa trên request, cần xác định request hợp lệ và điều kiện thành công. Error budget biểu thị phần sai lệch được phép so với mục tiêu; định nghĩa và cửa sổ đo phải thống nhất trước khi dùng để ra quyết định vận hành. Service level objectives

Alert rule và notification

Alert rule query datasource, đánh giá expression/condition và tạo alert instances. Notification policies định tuyến theo labels tới contact points. Tách điều kiện phát hiện khỏi cách gửi thông báo giúp quản lý theo service hoặc team. Grafana Alerting fundamentals

Một alert hữu ích có service, tác động, khoảng thời gian và link đến dữ liệu cần điều tra. Phân biệt lỗi query/no data với giá trị bình thường để tránh kết luận service khỏe chỉ vì pipeline không còn dữ liệu.

Network, bảo mật và storage

Ingest, query và quyền truy cập

Tách endpoint nhận telemetry, endpoint query và UI quản trị theo quyền cần thiết. Collector cần quyền đọc đúng log source; giới hạn filesystem mounts và quyền truy cập config/UI theo phạm vi thu thập. Alloy access and permissions

Loki và Tempo cần lớp kiểm soát truy cập phù hợp trước API. X-Scope-OrgID chọn tenant, không xác minh danh tính user. Loki hỗ trợ mTLS ở transport layer; tenant header vẫn cần được cấp và kiểm soát đúng. Loki authentication, Tempo authentication

Log payload và span attributes cần được chọn theo mục đích vận hành. Giới hạn thông tin nhạy cảm từ nguồn và kiểm soát người được đọc telemetry. Đánh giá cả dữ liệu phát ra và đường truyền tới backend khi thiết kế instrumentation. OpenTelemetry security

Persistence và retention

Backend	Cơ chế cần hiểu
Prometheus	TSDB lưu samples; retention theo thời gian hoặc dung lượng. Khi cấu hình cả hai, giới hạn đạt trước có hiệu lực.
Loki	Retention gắn với storage/schema và cơ chế compactor của deployment.
Tempo	Trace storage và retention được quản lý theo cấu hình backend.
Collector	Queue/WAL/runtime state có lifecycle riêng, phụ thuộc component.

Nguồn: Prometheus storage, Loki retention, Tempo architecture.

Retention quyết định dữ liệu còn lại để query; backup quyết định khả năng phục hồi khi dữ liệu bị mất. Capacity cần xét ingest rate, cardinality, sampling, query load và disk/object storage growth. Thời gian lưu của từng backend được lấy từ cấu hình vận hành.

Theo dõi chính pipeline Observability

Kiểm tra nguồn có phát dữ liệu, collector có nhận/export và backend có ingest/query được. Readiness chỉ phản ánh điều kiện sẵn sàng của component; cần theo dõi lỗi gửi, queue, drops và tốc độ nhận dữ liệu để xác minh toàn tuyến. Collector internal telemetry

Thuật ngữ và lộ trình đọc

Thuật ngữ

Thuật ngữ	Giải thích
Telemetry	Dữ liệu đo và sự kiện hệ thống phát ra để phân tích hoạt động.
Instrumentation	Cơ chế tạo hoặc expose telemetry trong application/hạ tầng.
Time series	Dãy samples có cùng metric name và label set.
Cardinality	Số tổ hợp định danh tạo series hoặc streams.
Log stream	Nhóm log entries có cùng label set trong Loki.
Resource	Thực thể phát telemetry, như service/process/host.
Span	Một đơn vị công việc trong trace.
Trace context	Thông tin nối các spans qua ranh giới service/process.
Sampling	Policy chọn traces được giữ lại.
OTLP	Protocol truyền telemetry của OpenTelemetry.
Relabel	Quy tắc lọc hoặc biến đổi labels/targets.
Correlation	Liên kết dữ liệu giữa các signals theo ngữ cảnh.
Retention	Policy xác định thời gian hoặc lượng dữ liệu được giữ.
SLI / SLO	Phép đo chất lượng dịch vụ / mục tiêu cho phép đo đó.

Đọc tiếp theo chủ đề

• Kiến trúc và triển khai LGTM — sơ đồ, các tuyến telemetry và endpoint.
• Compose và Alloy — bộ file collector và labels đã được cung cấp.
• systemd và PM2 — nguồn log, mount và quyền đọc.
• Xác minh telemetry — kiểm tra backend, metrics, logs và traces.
• Xử lý sự cố — khoanh vùng theo từng chặng của pipeline.

Kết luận

Bắt đầu từ dữ liệu ứng dụng phát ra, lần theo collector tới backend, rồi kiểm tra query và correlation trong Grafana. Labels/resources xác định dữ liệu thuộc nguồn nào; cardinality, sampling và retention quyết định chi phí cùng mức chi tiết còn lại khi điều tra. Đánh giá toàn pipeline qua dữ liệu thực tế đến backend.

Tài liệu liên quan

• LGTM — Kiến trúc, triển khai và vận hành

  Compose/Alloy, systemd/PM2, health checks, queries và xử lý sự cố.