Observability & MonitoringObservability & Monitoring

Thuộc bộ kiến thức Backend Roadmap.

Tổng quan

Khi một backend service rời khỏi máy của bạn và bắt đầu nhận traffic thật, câu hỏi quan trọng nhất không còn là “code có chạy không?” mà trở thành “nó đang làm gì ngay lúc này, và tại sao?”. Monitoring trả lời liệu hệ thống có khỏe mạnh hay không dựa trên những câu hỏi bạn đã quyết định đặt ra từ trước (CPU, error rate, request latency), và báo động (page) cho ai đó khi một ngưỡng bị vượt qua. Observability là một thuộc tính rộng hơn: mức độ mà telemetry do hệ thống phát ra cho phép bạn giải thích bất kỳ trạng thái nội bộ nào — kể cả những lỗi không ai lường trước — mà không cần deploy code mới chỉ để thêm một dòng print. Monitoring là một tập con của những gì observability tốt cho phép làm.

Sự phân biệt này ánh xạ rõ ràng với known-unknowns vs unknown-unknowns. Known-unknown là lỗi bạn đã lường trước (“database có thể chậm”) — bạn dựng một dashboard và một alert cho nó. Unknown-unknown là lỗi bạn chưa từng tưởng tượng (“checkout chậm chỉ với user Android trên app version 4.2 ở eu-west, và chỉ khi cache còn lạnh”). Monitoring không giúp được ở đây vì không ai vẽ biểu đồ đó từ trước. Observability thì có thể — nhưng chỉ khi telemetry của bạn mang đủ nhiều chiều (dimension) như user, region, version, endpoint, cache state để bạn có thể cắt lát (slice) theo chúng một cách ad hoc ngay trong lúc sự cố. Trong một backend microservice hay serverless hiện đại, nơi một request tỏa ra hàng chục service, unknown-unknowns chiếm ưu thế — đó là lý do observability đã trở thành một kỹ năng cốt lõi của backend chứ không còn là chuyện phụ của ops.

Note này tập trung vào góc nhìn của backend engineer: cách instrument service của bạn, cần emit những gì, và cách suy luận trong lúc sự cố. Về phía platform/hạ tầng — vận hành Prometheus ở quy mô lớn, monitoring Kubernetes, topology alerting cấp cluster — xem note đồng hành ../devops/vi/15-monitoring-and-observability.md. Observability cũng chính là vòng phản hồi (feedback loop) giúp các kỹ thuật reliability và scaling trong ./17-scalability-and-reliability.md trở nên đo lường được: bạn không thể quản lý thứ mình không thấy được. Nó bổ trợ cho các đảm bảo về tính đúng đắn mà bạn xây bằng ./13-testing.md (test bắt các bug đã biết trước khi deploy; observability bắt mọi thứ còn lại sau khi deploy).

Kiến thức nền tảng

Ba trụ cột: metrics, logs, traces

Mô hình tư duy kinh điển của observability là ba trụ cột (three pillars) — metrics, logs, và traces — thường được mở rộng thêm events (deploy, bật/tắt feature flag, thay đổi config) để trả lời “cái gì đã thay đổi?”. Mỗi trụ cột giỏi ở một câu hỏi khác nhau, và các team trưởng thành tương quan (correlate) chúng với nhau: một alert kích hoạt trên một metric, bạn nhảy sang một trace mẫu để tìm chỗ nào tốn thời gian, rồi chuyển sang logs của span bị lỗi để biết tại sao.

Trụ cột	Là gì	Tốt nhất cho	Chi phí / lưu ý	Trả lời
Metrics	Chuỗi thời gian (time series) dạng số (counter, gauge, histogram) kèm label	Alerting, xu hướng, dashboard, SLO	Rẻ & nhanh, nhưng đã pre-aggregated — không có chi tiết từng request; giới hạn cardinality của label	Có gì đó sai không?
Logs	Bản ghi sự kiện có timestamp, lý tưởng là structured (JSON)	Điều tra pháp y (forensics), chi tiết đầy đủ, debug một request cụ thể	Đắt khi volume lớn; nhiễu; khó aggregate nếu không index	Tại sao sai?
Traces	Hành trình của một request qua các service dưới dạng cây các span có tính thời gian	Bóc tách latency, tìm service chậm/lỗi qua ranh giới	Cần instrumentation; thường bị sampling; storage phình nhanh	Sai ở đâu?
Events	Các thay đổi rời rạc: deploy, config, flag, scaling	Tương quan tìm nguyên nhân gốc (“cái gì thay đổi ngay trước đó?”)	Chỉ hữu ích nếu được ghi lại và canh thời gian với các signal khác	Cái gì đã thay đổi?

Một cách nhìn hiện đại hữu ích (từ cộng đồng “observability 2.0”) là coi wide, structured events (sự kiện rộng, có cấu trúc) như primitive hợp nhất: emit một event được chú thích phong phú cho mỗi đơn vị công việc, mang hàng chục field, rồi dẫn xuất metrics, traces, logs từ nó. Dù bạn theo mô hình đó hay ba trụ cột kinh điển, nguyên tắc vẫn giống nhau — nắm bắt context, giữ cardinality có thể query được, tương quan giữa các signal.

OpenTelemetry: chuẩn cho instrumentation

OpenTelemetry (OTel) là chuẩn trung lập với vendor của CNCF để tạo và xuất telemetry. Nó quan trọng vì tách rời instrumentation (nằm trong code của bạn) khỏi backend lưu trữ và query telemetry (Prometheus, Jaeger, Tempo, Loki, Datadog, v.v.). Instrument một lần bằng OTel API, và bạn có thể đổi vendor observability chỉ bằng cách thay đổi config của exporter — không cần sửa code. Nó định nghĩa:

• API và SDK cho mọi ngôn ngữ lớn, cho metrics, logs, và traces.
• Semantic conventions — tên attribute chuẩn (http.request.method, db.system, server.address) để telemetry từ các service khác nhau có thể so sánh được.
• Giao thức OTLP — một định dạng truyền chung cho cả ba signal.
• Collector — một agent/gateway độc lập nhận, xử lý (batching, filtering, sampling, redaction) và export telemetry, để app của bạn không hardcode logic của vendor.

Auto-instrumentation móc vào các library phổ biến (HTTP server, DB driver, gRPC client) để phát span và metric mà không cần sửa code — cách nhanh nhất để có độ phủ cơ bản. Manual instrumentation thêm span, attribute, và metric mang tính nghiệp vụ mà auto-instrumentation không thể biết (“đây có phải khách quay lại không?”, “giỏ hàng có bao nhiêu món?”). Hệ thống thực tế dùng cả hai: auto cho độ rộng, manual cho các chi tiết quan trọng về nghiệp vụ.

SLIs, SLOs, và error budgets

Reliability cần một định nghĩa, nếu không “đáng tin cậy” chỉ là ý kiến chủ quan. Framework SRE của Google đưa ra ba khái niệm liên kết:

• SLI (Service Level Indicator) — một thước đo định lượng cho một khía cạnh của dịch vụ, thường biểu diễn dưới dạng tỉ lệ giữa sự kiện tốt trên tổng sự kiện. Ví dụ: tỉ lệ HTTP request được phục vụ dưới 300 ms, hoặc tỉ lệ request trả về status không phải 5xx.
• SLO (Service Level Objective) — mục tiêu cho một SLI trong một khoảng thời gian. Ví dụ: 99.9% request thành công trong 28 ngày. SLO nên phản ánh những gì user thực sự cảm nhận, không phải sự tiện lợi nội bộ.
• Error budget — 100% − SLO. SLO 99.9% cho phép 0.1% lỗi ≈ 43 phút downtime mỗi 30 ngày. Ngân sách này là một loại tiền tệ: khi còn budget, ship feature nhanh; khi cạn budget, đóng băng các thay đổi rủi ro và dành thời gian kỹ thuật cho reliability. Nó biến căng thẳng muôn thuở dev-vs-ops thành một quyết định chung, dựa trên dữ liệu.

SLA (Service Level Agreement) là cam kết hợp đồng, đối mặt với khách hàng, kèm phạt tài chính — luôn lỏng hơn SLO nội bộ của bạn để bạn có khoảng đệm phản ứng trước khi vi phạm hợp đồng.

Four golden signals (bốn tín hiệu vàng)

Từ cuốn Google SRE, nếu chỉ đo được bốn thứ cho một hệ thống hướng người dùng, hãy đo những thứ này:

Signal	Ý nghĩa	Metric điển hình
Latency	Một request mất bao lâu — tách latency thành công vs lỗi (một lỗi 500 nhanh không nên trông “tốt”)	p50 / p95 / p99 request duration
Traffic	Nhu cầu bao nhiêu	requests/sec, connections, messages/sec
Errors	Tỉ lệ request thất bại (5xx tường minh, nội dung sai ngầm định, hoặc theo policy — quá chậm)	error ratio
Saturation	Service “đầy” tới mức nào — tài nguyên nào gần chạm giới hạn nhất	CPU %, memory, queue depth, connection pool usage

Phương pháp RED (Rate, Errors, Duration) là tập con hướng request, lý tưởng cho service và API. Phương pháp USE (Utilization, Saturation, Errors) là phần bổ trợ hướng tài nguyên, lý tưởng cho hạ tầng (CPU, disk, network). Dùng RED cho các endpoint của bạn và USE cho máy móc, queue bên dưới.

Khái niệm chính

Metrics và Prometheus

Prometheus là hệ thống metrics mã nguồn mở de-facto (CNCF graduated). Các ý chính:

• Pull model — Prometheus server scrape (cạo) một HTTP endpoint /metrics trên mỗi target theo lịch, khám phá target qua service discovery (Kubernetes, Consul, static config). Pull khiến “nó có sống không?” trở nên quan sát được miễn phí (scrape thất bại = down) và tránh việc mọi app phải giữ credential để push. Pushgateway chỉ tồn tại cho các batch job ngắn hạn chết trước khi kịp bị scrape — không phải endpoint push đa dụng.
• Data model — mỗi time series là một metric name cộng một tập label dạng key/value; bạn query bằng PromQL.

Các loại metric:

Loại	Hành vi	Dùng cho	Ví dụ
Counter	Chỉ tăng đơn điệu (reset về 0 khi restart)	Đếm số lượng — request, error, byte	http_requests_total — luôn vẽ bằng rate()
Gauge	Lên và xuống	Một giá trị hiện tại — nhiệt độ, queue depth, request đang xử lý	queue_depth, memory_bytes
Histogram	Các bucket quan sát + sum + count	Phân bố latency/kích thước; tính được quantile	http_request_duration_seconds_bucket
Summary	Quantile tính ở phía client	Quantile khi không thể aggregate qua nhiều instance	rpc_duration_seconds{quantile="0.99"}

Ưu tiên histogram hơn summary cho latency: bucket của histogram aggregate được qua nhiều instance (bạn tính được p99 toàn fleet), trong khi quantile của summary là theo từng instance và không thể lấy trung bình một cách có ý nghĩa.

Một metric được expose trên /metrics:

# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="POST",route="/checkout",status="200"} 24571
http_requests_total{method="POST",route="/checkout",status="500"} 37

Một query PromQL tính error ratio trong 5 phút gần nhất:

sum(rate(http_requests_total{status=~"5..", route="/checkout"}[5m]))
/
sum(rate(http_requests_total{route="/checkout"}[5m]))

Cardinality — cạm bẫy số một của metrics. Mỗi tổ hợp giá trị label duy nhất là một time series riêng biệt mà Prometheus phải lưu và index. Đưa một giá trị không bị chặn (user ID, email, request ID, URL đầy đủ kèm query param) vào label sẽ gây cardinality explosion có thể làm OOM Prometheus. Nguyên tắc: label phải là chiều có số lượng bị chặn, cardinality thấp (method, route template, status code, region). Các định danh cardinality cao thuộc về traces và logs, không phải label của metric.

# XẤU — user_id và path không bị chặn → hàng triệu series
http_requests_total{user_id="8f3a...", path="/users/8f3a/orders/91?ref=x"}

# TỐT — label bị chặn; route là template, không phải path cụ thể
http_requests_total{route="/users/:id/orders/:oid", status="200"}

Logging

Một log là bản ghi có timestamp của một sự kiện rời rạc. Nâng cấp có tác động lớn nhất cho một backend là structured logging — emit JSON (hoặc định dạng máy đọc được khác) với tên field nhất quán thay vì chuỗi văn bản tự do. Structured log query được và aggregate được; grep trên văn bản thô thì không.

{
  "timestamp": "2026-07-19T10:32:11.482Z",
  "level": "ERROR",
  "service": "checkout-api",
  "message": "payment authorization failed",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "user_id": "u_8f3a91",
  "order_id": "o_44821",
  "payment_provider": "stripe",
  "error_code": "card_declined",
  "duration_ms": 812
}

Log levels — dùng chúng một cách nhất quán:

Level	Khi nào	Có page không?
ERROR	Một thao tác thất bại và cần chú ý	Thường có
WARN	Điều gì đó bất thường nhưng đã xử lý được (retry, fallback)	Đôi khi
INFO	Sự kiện quan trọng bình thường (khởi động, request hoàn tất)	Không
DEBUG	Thông tin chẩn đoán chi tiết, thường tắt ở prod	Không

Correlation ID. Để tái dựng hành trình của một request qua các service, hãy truyền (propagate) một định danh dùng chung — lý tưởng là trace_id từ hệ thống tracing — qua mọi dòng log và mọi cuộc gọi downstream (qua một HTTP header). Trong lúc sự cố, lọc toàn bộ log theo một trace_id sẽ ráp lại toàn bộ câu chuyện qua các ranh giới service.

Centralized logging. Chuyển log ra khỏi host vào một kho có thể tìm kiếm: ELK/Elastic Stack (Elasticsearch + Logstash/Beats + Kibana) là lựa chọn kinh điển, nặng ký; Grafana Loki là phương án nhẹ hơn, rẻ hơn, chỉ index label và lưu phần thân log ở dạng nén (kết hợp tự nhiên với Prometheus + Grafana). Sampling kiểm soát chi phí: giữ 100% log ERROR nhưng sample các log INFO/DEBUG volume cao (ví dụ 1%), và cân nhắc tail-based sampling để luôn giữ log cho các request bị lỗi hoặc chậm.

Distributed tracing

Một trace biểu diễn hành trình đầu-cuối của một request qua hệ thống phân tán, mô hình hóa thành cây các span. Mỗi span là một đơn vị công việc có tên (một HTTP handler, một DB query, một cache lookup) với thời điểm bắt đầu, duration, một trace_id (dùng chung cả trace), một span_id, một parent_span_id, một status, và các attribute (tag key/value như http.status_code, db.statement).

Context propagation là cơ chế ghép các span qua ranh giới tiến trình: bên gọi inject trace context vào request đi ra (header HTTP W3C traceparent là chuẩn), và bên nhận extract nó để biến span của mình thành con của span bên gọi. Không có propagation thì bạn chỉ có các mảnh rời rạc thay vì một trace mạch lạc.

00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

• 00version
• 4bf92f3577b34da6a3ce929d0e0e4736trace-id (16 bytes)
• 00f067aa0ba902b7parent-span-id
• 01flags (sampled)

Tạo span thủ công với OpenTelemetry (Python):

from opentelemetry import trace

tracer = trace.get_tracer("checkout-api")

def process_checkout(order):
    with tracer.start_as_current_span("process_checkout") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("order.item_count", len(order.items))
        try:
            charge = charge_payment(order)          # span con, auto-instrumented
            span.set_attribute("payment.provider", charge.provider)
        except PaymentError as e:
            span.record_exception(e)
            span.set_status(trace.Status(trace.StatusCode.ERROR))
            raise

Backend: Jaeger và Grafana Tempo là các kho trace mã nguồn mở phổ biến; Zipkin là bậc tiền bối cũ hơn. Tất cả đều nhận OTLP từ OpenTelemetry. Vì lưu mọi span thì đắt, trace được sampling — head-based (quyết định ngay từ đầu, ví dụ giữ 5%, rẻ nhưng có thể bỏ sót lỗi hiếm) hoặc tail-based (buffer cả trace rồi giữ lại nếu nó lỗi hoặc chậm — giá trị hơn, tốn hạ tầng hơn). Exemplars liên kết một đỉnh (spike) trên histogram metric trực tiếp tới một trace ví dụ, cho bạn cú nhảy một-cú-click từ “p99 tăng” tới “đây là một request chậm”.

Dashboard, alerting, và on-call

• Grafana là lớp visualization chuẩn, query Prometheus, Loki, Tempo và hầu hết backend thương mại từ một nơi. Dashboard tốt được tổ chức theo golden signals / RED, hiển thị p50/p95/p99 (không chỉ trung bình — trung bình che giấu tail latency), và phủ (overlay) các mốc deploy.
• Alertmanager (đi kèm Prometheus) lo việc định tuyến alert, grouping (gộp một cơn bão alert liên quan thành một thông báo), deduplication, silencing trong lúc bảo trì, và inhibition (chặn các alert downstream khi nguyên nhân gốc đã kích hoạt).
• Alert theo triệu chứng, không theo nguyên nhân. Page theo những gì user cảm nhận (SLO burn rate, error ratio cao, latency cao), không theo mọi metric nội bộ — một máy CPU cao đơn lẻ mà không gây hại cho ai thì không nên đánh thức người ta lúc 3 giờ sáng. SLO burn-rate alerting (đa cửa sổ, ví dụ fast-burn 1h + slow-burn 6h) là best practice hiện đại: nó kích hoạt tỉ lệ với tốc độ bạn tiêu error budget, cắt giảm page giả.
• On-call & runbook. Mọi alert nên khả thi hành động và liên kết tới một runbook — một tài liệu ngắn gọn nói alert đó nghĩa là gì, cách xác nhận tác động, và các bước chẩn đoán/giảm thiểu đầu tiên. Theo dõi chất lượng alert: page không cần hành động là nhiễu và nên được tinh chỉnh hoặc xóa (alert fatigue là một rủi ro reliability thật sự). Một postmortem không đổ lỗi (blameless) sau sự cố sẽ đưa các sửa chữa quay lại hệ thống.

APM và công cụ thương mại

Các nền tảng APM (Application Performance Monitoring) gói metrics, logs, traces, dashboard, và alerting vào một sản phẩm tích hợp với agent auto-instrumentation:

Công cụ	Ghi chú
Datadog	SaaS all-in-one rộng, bóng bẩy; tích hợp mạnh; giá theo usage có thể leo thang
New Relic	APM lâu đời; giá theo mức tiêu thụ
Dynatrace	Hướng enterprise; mapping phụ thuộc tự động mạnh và root cause hỗ trợ AI
Grafana Cloud / Elastic	Bản managed hosting của các stack mã nguồn mở
Honeycomb	Tiên phong “observability 2.0” dựa trên event cardinality cao và khám phá ad-hoc nhanh

Đánh đổi: APM thương mại tiết kiệm khổng lồ công sức thiết lập và tích hợp nhưng tạo ra vendor lock-in và chi phí tăng theo volume dữ liệu. Vì OpenTelemetry trung lập với vendor, instrument bằng OTel giữ cho lối thoát của bạn luôn mở dù bạn bắt đầu với backend nào.

Continuous profiling

Metrics/logs/traces cho biết một function hay service chậm; profiling cho biết dòng code nào đốt CPU hay cấp phát memory. Continuous profiling (Grafana Pyroscope, Parca, Datadog Profiler, Google Cloud Profiler) lấy mẫu stack production với overhead thấp (thường vài phần trăm) và lưu chúng dưới dạng flame graph có timestamp, cho phép bạn so sánh profile CPU/heap/lock qua các version và theo thời gian — ví dụ xác nhận một bản deploy làm tăng CPU và thấy chính xác function nào chịu trách nhiệm, tất cả từ production, không cần tái hiện ở local.

Best Practices

• Instrument bằng OpenTelemetry ngay từ ngày đầu. Bắt đầu với auto-instrumentation cho độ phủ cơ bản, rồi thêm span/attribute thủ công cho các thao tác nghiệp vụ quan trọng. Tránh agent độc quyền trong code — giữ lựa chọn vendor ở exporter/Collector.
• Emit structured (JSON) logs với tên field nhất quán, và luôn kèm trace_id/span_id để logs, traces, metrics tương quan với nhau. Một bộ lọc trace_id nên tái dựng được cả một request.
• Canh chừng cardinality của metric. Chỉ dùng giá trị cardinality thấp, bị chặn làm label (route template, status, region). Không bao giờ dùng user ID, request ID, hay path thô — những thứ đó thuộc về traces/logs.
• Đo four golden signals (hoặc RED cho service, USE cho tài nguyên) cho mọi service hướng người dùng trước khi thêm dashboard cầu kỳ hơn.
• Ưu tiên histogram hơn summary cho latency, và theo dõi p95/p99, không phải trung bình — tail latency mới là thứ user nhận ra.
• Định nghĩa SLO từ góc nhìn của user và điều khiển page từ SLO burn rate, không phải từ metric tài nguyên thô. Alert theo triệu chứng, không theo nguyên nhân.
• Mọi alert đều khả thi hành động và liên kết tới runbook. Mạnh tay cắt bỏ các alert không cần hành động — alert fatigue bào mòn reliability.
• Sampling một cách thông minh. Tail-based sampling để luôn giữ trace lỗi/chậm; sample log volume cao nhưng giữ 100% lỗi.
• Kiểm soát chi phí có chủ đích. Telemetry có thể tốn hơn cả service. Đặt các tầng retention, tỉ lệ sampling, và ngân sách cardinality một cách chủ động, không phải tình cờ.
• Chú ý sức mạnh debug từ cardinality cao. Thiết kế telemetry sao cho bạn có thể cắt lát theo các chiều (user, version, region, endpoint) mà bạn không nghĩ tới việc vẽ biểu đồ từ trước — đó là thứ biến unknown-unknowns thành câu hỏi trả lời được.
• Chạy postmortem không đổ lỗi và đưa bài học của mỗi sự cố quay lại instrumentation, alert, và runbook.

Tài liệu tham khảo

• OpenTelemetry Documentation — khái niệm, signal, instrumentation, Collector
• Prometheus Documentation — data model, metric type, PromQL, exporter
• Google SRE Book — Monitoring Distributed Systems — four golden signals, triệu chứng vs nguyên nhân
• Google SRE Book — Service Level Objectives — SLI, SLO, error budget
• Google SRE Workbook — Alerting on SLOs — multi-window burn-rate alerting
• W3C Trace Context — chuẩn propagation traceparent
• Grafana Observability Documentation — Grafana, Loki, Tempo, Pyroscope
• The RED Method (Grafana) — Rate, Errors, Duration

# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="POST",route="/checkout",status="200"} 24571
http_requests_total{method="POST",route="/checkout",status="500"} 37

sum(rate(http_requests_total{status=~"5..", route="/checkout"}[5m]))
/
sum(rate(http_requests_total{route="/checkout"}[5m]))

# BAD — user_id and path are unbounded → millions of series
http_requests_total{user_id="8f3a...", path="/users/8f3a/orders/91?ref=x"}

# GOOD — bounded labels; the route is a template, not the concrete path
http_requests_total{route="/users/:id/orders/:oid", status="200"}

{
  "timestamp": "2026-07-19T10:32:11.482Z",
  "level": "ERROR",
  "service": "checkout-api",
  "message": "payment authorization failed",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "user_id": "u_8f3a91",
  "order_id": "o_44821",
  "payment_provider": "stripe",
  "error_code": "card_declined",
  "duration_ms": 812
}

from opentelemetry import trace

tracer = trace.get_tracer("checkout-api")

def process_checkout(order):
    with tracer.start_as_current_span("process_checkout") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("order.item_count", len(order.items))
        try:
            charge = charge_payment(order)          # child span, auto-instrumented
            span.set_attribute("payment.provider", charge.provider)
        except PaymentError as e:
            span.record_exception(e)
            span.set_status(trace.Status(trace.StatusCode.ERROR))
            raise