Monitoring & Observability: Giám Sát Hệ Thống Toàn Diện
"Nếu không đo được, không cải thiện được" — Peter Drucker. Trong software engineering, monitoring cho biết hệ thống có đang chạy không, observability cho biết tại sao hệ thống chạy chậm. Sự khác biệt quan trọng: monitoring là hệ thống dashboards xanh/đỏ cho bạn biết những gì bạn đã biết trước cần đo, còn observability là khả năng debug bất kỳ vấn đề nào — kể cả vấn đề chưa từng gặp — chỉ từ telemetry data mà không cần reproduce lỗi trên môi trường local. Google SRE book khẳng định observability là nền tảng của reliable systems — bạn không thể vận hành ổn định thứ bạn không quan sát được.
Monitoring vs Observability: Khác Biệt Căn Bản
Monitoring trả lời các câu hỏi đã biết: CPU có quá tải không? Disk còn bao nhiêu dung lượng? API đang trả về bao nhiêu lỗi 500? Bạn cấu hình trước những gì cần theo dõi — nếu vấn đề nằm ngoài các metrics đã cấu hình, monitoring sẽ không phát hiện được. Observability trả lời các câu hỏi chưa biết: Tại sao request này mất 8 giây thay vì 200ms? Tại sao chỉ 5% users ở khu vực Hà Nội gặp lỗi timeout? Observability cho phép bạn "drill down" từ symptom đến root cause mà không cần biết trước pattern lỗi.
Trong thực tế, bạn cần cả hai. Monitoring là hàng rào bảo vệ đầu tiên — alert khi hệ thống vượt ngưỡng. Observability là công cụ điều tra — khi alert bắn, giúp bạn tìm nguyên nhân nhanh chóng thay vì đoán mò. Theo Gartner (2024), tổ chức có chiến lược observability toàn diện giảm MTTR (Mean Time To Restore) trung bình 60% so với chỉ dùng traditional monitoring.
3 Trụ Cột Observability
📊 Metrics (Số liệu)
Số đo quantitative theo thời gian: CPU usage, request latency (p50, p95, p99), error rate, throughput (requests/sec), connection pool utilization. Google SRE định nghĩa 4 Golden Signals: Latency (thời gian response), Traffic (lượng requests), Errors (tỷ lệ lỗi), Saturation (mức độ đầy tài nguyên). Nếu chỉ đo 4 thứ, đo 4 Golden Signals này. Tools: Prometheus (collection + storage time-series) scrape metrics từ /metrics endpoint mỗi 15s. Grafana visualize dashboards. BanhCuonFlow expose .NET metrics: request duration histograms, active connections, DB pool size, SignalR connection count.
📝 Logs (Nhật ký)
Event records ghi lại chi tiết những gì xảy ra: "2025-12-03 14:23:45 ERROR TaskService.CreateTask: Unique constraint violated for code PRJ-156." Structured logging (JSON) là best practice bắt buộc — thay vì plain text, mỗi log entry là JSON object có timestamp, level, message, correlation ID, user ID, request ID. Điều này cho phép query, filter, aggregate cực kỳ hiệu quả. Centralized logging với ELK Stack (Elasticsearch + Logstash + Kibana) hoặc Grafana Loki (nhẹ hơn, tích hợp tốt với Prometheus/Grafana). BanhCuonFlow sử dụng Serilog → structured JSON → file và console → tích hợp với bất kỳ log aggregator nào.
🔗 Traces (Distributed Tracing)
Theo dõi 1 request xuyên suốt nhiều services trong kiến trúc microservices: API Gateway → Auth Service → Task Service → PostgreSQL → Redis Cache → SignalR broadcast. Mỗi "hop" giữa services là 1 span, toàn bộ hành trình là 1 trace. Traces giúp phát hiện chính xác: "Request chậm 3s vì DB query ở TaskService mất 2.8s do missing index." OpenTelemetry (OTel) là tiêu chuẩn mới được CNCF backing, hỗ trợ mọi ngôn ngữ lập trình, vendor-neutral. Jaeger hoặc Grafana Tempo để visualize traces. Context propagation tự động — trace ID được truyền qua HTTP headers để liên kết tất cả services tham gia xử lý một request.
OpenTelemetry: Tương Lai Của Observability
OpenTelemetry (OTel) là dự án CNCF lớn thứ 2 sau Kubernetes, hợp nhất từ 2 dự án trước đó (OpenTracing + OpenCensus). OTel cung cấp một bộ APIs, SDKs, và tools vendor-neutral để thu thập cả 3 trụ cột (metrics, logs, traces) từ ứng dụng của bạn. Lợi ích lớn nhất: instrumentation 1 lần, export đến bất kỳ backend nào (Prometheus, Jaeger, Datadog, New Relic, Grafana). Không bị vendor lock-in.
Trong .NET (stack mà BanhCuonFlow sử dụng), OpenTelemetry tích hợp
native từ .NET 8+. Chỉ cần thêm vài dòng code trong Program.cs: builder.Services.AddOpenTelemetry() với HTTP instrumentation,
SQL instrumentation, và custom metrics. OTel Collector đóng vai trò trung
gian — nhận telemetry data từ ứng dụng, xử lý (sampling, enriching, filtering),
rồi export đến backend(s). Năm 2025, OTel đã trở thành tiêu chuẩn de facto,
được adopt bởi hầu hết cloud providers và observability vendors.
SLI / SLO / SLA: Ngôn Ngữ Chung Của Reliability
SLI (Service Level Indicator): Metric cụ thể đo chất lượng service. Ví dụ: "99% requests respond trong < 200ms" hoặc "tỷ lệ request thành công là 99.95%." SLI phải đo từ perspective của user — không phải từ server. User không care server CPU thấp nếu page load mất 10 giây.
SLO (Service Level Objective): Target cho SLI trong một khoảng thời gian. "Uptime SLO: 99.9% trong 30 ngày rolling" có nghĩa bạn cho phép tối đa ~43 phút downtime mỗi tháng. 99.9% nghe cao nhưng vẫn cho phép 43 phút — đủ để deploy và rollback nếu có lỗi. 99.99% SLO (4 nines) chỉ cho phép 4.3 phút/tháng — cực kỳ khắt khe, cần invest nặng vào automation.
SLA (Service Level Agreement): Hợp đồng chính thức với customer — vi phạm SLA sẽ bị phạt bồi thường (thường dạng credit). AWS EC2 có SLA 99.99% uptime — nếu vi phạm, họ credit 10-30% bill. SLA luôn nên đặt thấp hơn SLO để có "error budget" — khoảng đệm cho phép team thử nghiệm và deploy mà không sợ vi phạm hợp đồng. BanhCuonFlow internal SLOs: API p95 < 500ms, uptime > 99.5%, error rate < 0.1%.
Alert Fatigue: Kẻ Thù Thầm Lặng
Alert quá nhiều → team bắt đầu ignore alerts → miss critical incident → production down mà không ai biết. Đây gọi là alert fatigue — hiện tượng phổ biến hơn bạn nghĩ. Nghiên cứu từ PagerDuty cho thấy kỹ sư trung bình nhận 3.5 alerts/giờ ngoài giờ làm việc, và sau 1 tuần, họ bắt đầu tắt notifications.
Giải pháp: Alert chỉ khi actionable — ai đó cần làm gì đó ngay lập tức. Phân loại: P1 (production down, ảnh hưởng nhiều users → page on-call engineer ngay, kèm auto-incident creation), P2 (degraded performance, ảnh hưởng một phần → Slack notification, resolve trong giờ làm việc), P3 (warning thresholds, không ảnh hưởng user → log for weekly review, không notification). Tỷ lệ vàng: < 5 actionable alerts/ngày cho team SRE.
Mỗi alert phải kèm runbook: "Khi nhận alert 'PostgreSQL connection pool exhausted', thực hiện: 1) Kiểm tra active connections qua pg_stat_activity, 2) Tìm long-running queries, 3) Kill idle connections, 4) Nếu không giải quyết được, restart app service." Runbook giúp on-call engineer mới xử lý incident mà không cần kinh nghiệm sâu về hệ thống. Google SRE yêu cầu 100% alerts phải có runbook kèm theo.
Stack Monitoring Khuyên Dùng Cho Startup/SME
Không phải team nào cũng cần Datadog ($15/host/month) hay New Relic. Cho startup và SME tại Việt Nam, stack open-source sau đây là đủ mạnh và miễn phí: Prometheus thu thập metrics, Grafana visualize dashboards, Loki aggregation logs, Tempo distributed tracing. Tất cả tích hợp native với nhau trong "Grafana Stack" — 1 UI xem được metrics, logs, và traces. Cài đặt qua Docker Compose hoặc Helm chart trên Kubernetes.
Cho ứng dụng .NET như BanhCuonFlow: sử dụng OpenTelemetry .NET SDK
export metrics đến Prometheus, structured logs (Serilog) đến Loki qua
Promtail, và traces đến Tempo. Dashboard mẫu có sẵn trên Grafana
community — import bằng 1 click. Health check endpoints (/health, /health/ready) cho liveness và readiness probes khi
deploy trên Docker hoặc Kubernetes.