Chương 49. Vì sao cần quan sát hệ thống?

Từ chương này, ta bước sang phần:

Observability và reliability.

Nói dễ hiểu:

Làm sao biết hệ thống đang xảy ra chuyện gì?
Làm sao biết nó khỏe hay sắp nghẽn?
Làm sao debug khi lỗi chỉ xảy ra ở production?
Làm sao quyết định tối ưu cái gì bằng số liệu?

Ở production, nếu không quan sát được hệ thống, ta gần như chỉ đoán.

User nói:

App chậm.
Chấm bài lâu.
Không tải được file.
Điểm chưa hiện.
Dashboard lỗi.

Nếu không có log, metrics, trace, alert, dashboard, ta không biết bắt đầu từ đâu.

Thông điệp chính của chương:

> Không đo thì chỉ đoán. Observability giúp ta nhìn vào bên trong hệ thống đang chạy để debug, phát hiện nghẽn, bảo vệ reliability, và ra quyết định kiến trúc bằng bằng chứng.

---

49.1. Ví dụ dễ hiểu: lái xe không đồng hồ

Hãy tưởng tượng bạn lái xe nhưng không có:

• Đồng hồ tốc độ.
• Đèn báo xăng.
• Đèn báo nhiệt.
• Đèn báo lỗi máy.
• Gương.
• GPS.

Bạn vẫn có thể lái một đoạn.

Nhưng khi xe có vấn đề, bạn chỉ đoán.

Xe chậm vì hết xăng?
Máy nóng?
Đường tắc?
Lốp non?
Động cơ lỗi?

Hệ thống production cũng vậy.

Nếu không có observability, app vẫn có thể chạy.

Nhưng khi có lỗi, bạn không biết:

Lỗi ở frontend?
API?
Database?
Queue?
Worker?
AI provider?
Object storage?
Network?
Deploy mới?

Observability là bảng đồng hồ của hệ thống.

---

49.2. Observability là gì?

Observability là khả năng hiểu trạng thái bên trong của hệ thống từ tín hiệu bên ngoài nó phát ra.

Các tín hiệu phổ biến:

• Logs.
• Metrics.
• Traces.
• Events.
• Alerts.
• Dashboards.

Nói đơn giản:

Hệ thống tự kể chuyện gì đang xảy ra.

Không chỉ khi lỗi.

Mà cả khi:

• Traffic tăng.
• Latency xấu dần.
• Queue backlog lớn dần.
• Cost tăng.
• Database gần đầy.
• External API chậm.
• Worker retry nhiều hơn.

Observability giúp bạn thấy xu hướng trước khi user chịu đau.

---

49.3. Monitoring và observability khác nhau không?

Hai từ này hay dùng lẫn nhau.

Ở mức thực dụng:

Monitoring thường là:

Theo dõi các chỉ số đã biết.
Khi vượt ngưỡng thì alert.

Ví dụ:

CPU > 90%
Error rate > 5%
Queue backlog > 10.000

Observability rộng hơn:

Có đủ tín hiệu để điều tra cả những lỗi chưa biết trước.

Ví dụ:

Vì sao một số grading job của tenant A chậm hơn tenant B?
Request này đi qua service nào?
Job này retry vì lỗi gì?
Deploy mới có làm p95 latency tăng không?

Không cần tranh luận thuật ngữ quá lâu.

Điểm quan trọng:

> Hệ thống phải phát ra đủ tín hiệu để con người hiểu được nó.

---

49.4. Ba trụ cột cơ bản: log, metrics, trace

Ba loại tín hiệu hay được nhắc nhất:

Logs
Metrics
Traces

Log trả lời:

Chuyện gì đã xảy ra?

Metric trả lời:

Nó xảy ra bao nhiêu lần, nhanh/chậm thế nào, xu hướng ra sao?

Trace trả lời:

Một request/job đi qua những bước nào và chậm ở đâu?

Ví dụ AI Judge:

Log:

Job job_123 failed because Gemini timeout.

Metric:

Gemini timeout rate = 8% trong 10 phút qua.

Trace:

Submit request -> create submission -> enqueue job -> worker -> object storage -> Gemini API -> save result.

Ba thứ bổ sung nhau.

Không nên chỉ có một thứ.

---

49.5. Log là gì?

Log là dòng ghi lại sự kiện cụ thể.

Ví dụ:

2026-05-12T10:00:00Z INFO grading job_started job_id=job_123
2026-05-12T10:01:32Z ERROR grading ai_timeout job_id=job_123 model=gemini

Log tốt giúp debug:

• Request nào lỗi.
• Job nào fail.
• Vì sao fail.
• User/tenant nào bị ảnh hưởng.
• Service nào trả lỗi.
• Deploy nào liên quan.

Log xấu chỉ nói:

Something went wrong.

Hoặc log quá nhiều mà không tìm được gì.

Chương 50 sẽ nói kỹ hơn về logging.

---

49.6. Metrics là gì?

Metrics là số đo theo thời gian.

Ví dụ:

request_count
error_rate
latency_ms
queue_backlog
worker_active_count
db_connection_count
ai_api_timeout_count

Metric giúp nhìn xu hướng.

Ví dụ:

API latency p95 tăng từ 300ms lên 2s.
Queue backlog tăng từ 100 lên 20.000.
Worker retry rate tăng sau deploy.
AI cost tăng 3 lần trong 1 giờ.

Metric rất tốt cho dashboard và alert.

Chương 51 sẽ nói kỹ hơn về metrics.

---

49.7. Trace là gì?

Trace là đường đi của một request hoặc một job qua nhiều bước.

Ví dụ:

POST /submissions
  -> auth check: 10ms
  -> permission check: 15ms
  -> save submission: 40ms
  -> create grading job: 20ms
  -> enqueue: 8ms

Hoặc với job:

grading job
  -> download file: 300ms
  -> extract: 800ms
  -> call AI: 90s
  -> parse result: 200ms
  -> save result: 50ms

Trace giúp biết:

Chậm ở bước nào?
Service nào làm request lâu?
Dependency nào lỗi?

Chương 52 sẽ nói kỹ hơn về tracing.

---

49.8. Vì sao không đo thì chỉ đoán?

Khi user nói:

App chậm.

Nếu không có số liệu, bạn có thể đoán:

• Database chậm.
• API chậm.
• Frontend nặng.
• Network chậm.
• AI provider chậm.
• CDN lỗi.
• Worker backlog.

Nhưng đoán không đủ.

Bạn cần hỏi:

Chậm endpoint nào?
Chậm với user nào?
Chậm từ khi nào?
p50 hay p95 chậm?
Database query nào chậm?
Queue backlog có tăng không?
Deploy nào vừa xảy ra?
External API latency thế nào?

Không đo thì cuộc thảo luận dễ thành cảm giác.

Có số liệu thì ta khoanh vùng.

---

49.9. Observability giúp debug nhanh hơn

Khi production lỗi, thời gian rất quan trọng.

Nếu có observability tốt:

Alert báo error rate tăng.
Dashboard cho thấy chỉ endpoint /submissions lỗi.
Log cho thấy lỗi database timeout.
Trace cho thấy permission query chậm.
Deploy log cho thấy migration mới chạy 10 phút trước.

Bạn có đường điều tra.

Nếu không có:

User báo lỗi.
Team mở server nhìn log text hỗn loạn.
Không biết request nào.
Không biết tenant nào.
Không biết deploy nào.
Không biết lỗi bắt đầu khi nào.

Debug trở thành mò mẫm.

Observability không ngăn mọi lỗi.

Nhưng giảm thời gian từ "có vấn đề" đến "biết vấn đề ở đâu".

---

49.10. MTTD và MTTR

Hai khái niệm hữu ích:

MTTD:

Mean Time To Detect.
Mất bao lâu để phát hiện sự cố?

MTTR:

Mean Time To Recover.
Mất bao lâu để khôi phục?

Observability giúp giảm cả hai.

Nếu không có alert, bạn phát hiện khi user phàn nàn.

MTTD cao.

Nếu không có log/metric/trace, bạn mất lâu để tìm nguyên nhân.

MTTR cao.

Reliability không chỉ là "ít lỗi".

Nó còn là:

Lỗi thì phát hiện nhanh và phục hồi nhanh.

---

49.11. Observability giúp biết sắp nghẽn

Không phải lúc nào ta cũng đợi hệ thống chết.

Metric có thể cho thấy hệ thống đang xấu dần:

Database CPU tăng đều.
Connection pool gần đầy.
Queue wait time tăng.
Disk usage tăng.
Cache hit rate giảm.
p95 latency tăng dần.
Error rate nhỏ nhưng tăng liên tục.

Nếu thấy sớm, ta có thể xử lý trước:

• Tối ưu query.
• Tăng worker.
• Thêm index.
• Tăng quota.
• Dọn dữ liệu.
• Scale instance.
• Sửa retry storm.

Observability tốt giúp team chủ động.

Không chỉ chữa cháy.

---

49.12. Observability giúp ra quyết định kiến trúc

Nhớ lại các chương trước:

• Có cần cache không?
• Có cần read replica không?
• Có cần tăng worker concurrency không?
• Có cần tách service không?
• Có cần CDN không?
• Có cần sharding không?

Không nên quyết định bằng cảm giác.

Ví dụ:

App chậm.

Nếu metric cho thấy:

90% thời gian nằm ở gọi AI API.

Thêm cache database không giúp nhiều.

Nếu trace cho thấy:

Dashboard chậm vì query aggregate live.

Cần aggregate table/warehouse, không phải thêm API server.

Nếu queue metric cho thấy:

Worker chỉ xử lý 4 job song song trong khi Gemini quota còn nhiều.

Cần tăng worker concurrency/worker count.

Observability giúp chọn đúng thuốc.

---

49.13. Observability khác analytics như thế nào?

Analytics trả lời:

Người dùng dùng sản phẩm thế nào?

Ví dụ:

• Bao nhiêu học sinh mở feedback.
• Funnel nộp bài rơi ở đâu.
• Course nào active.

Observability trả lời:

Hệ thống vận hành thế nào?

Ví dụ:

• API latency.
• Error rate.
• Queue backlog.
• Worker retry.
• Database connection.
• AI provider timeout.

Hai thứ có giao nhau.

Ví dụ AI cost vừa là observability vừa là business/cost analytics.

Nhưng mục tiêu chính khác nhau:

Analytics:
  hiểu user/product/business.

Observability:
  hiểu health/behavior kỹ thuật của hệ thống.

---

49.14. Golden signals

Một cách nhớ đơn giản cho service:

• Latency.
• Traffic.
• Errors.
• Saturation.

Latency:

Request mất bao lâu?

Traffic:

Bao nhiêu request/job?

Errors:

Bao nhiêu request/job lỗi?

Saturation:

Tài nguyên đầy đến đâu?
CPU, memory, database connection, queue, disk.

Không phải chỉ nhìn CPU.

Một service có CPU thấp nhưng queue cao vẫn có vấn đề.

---

49.15. RED và USE

RED thường dùng cho request/service:

Rate
Errors
Duration

USE thường dùng cho resource:

Utilization
Saturation
Errors

Không cần học thuộc như công thức thi.

Chỉ cần nhớ:

Với service:
  có bao nhiêu request, lỗi bao nhiêu, mất bao lâu?

Với resource:
  dùng bao nhiêu, có nghẽn không, có lỗi không?

Đây là cách chọn metric rất thực dụng.

---

49.16. Observability cho web API

Web API nên có:

• Request count.
• Status code count.
• Latency p50/p95/p99.
• Error rate.
• Endpoint-level metrics.
• Request id.
• Logs cho error.
• Trace cho request chậm.

Ví dụ:

POST /submissions p95 = 250ms
GET /teacher/dashboard p95 = 3s
5xx rate = 0.5%

Nếu dashboard chậm, ta biết endpoint nào.

Không phải chỉ nói:

Backend chậm.

---

49.17. Observability cho database

Database nên có:

• CPU.
• Memory.
• Disk.
• IOPS.
• Connection count.
• Slow queries.
• Lock wait.
• Replication lag nếu có.
• Transaction duration.
• Cache hit ratio tùy database.

App cũng nên log/metric:

• Query duration.
• Connection pool wait.
• Query timeout.

Nhiều vấn đề "API chậm" thật ra là database chậm.

Nhưng nếu không đo database, ta không biết.

---

49.18. Observability cho queue/worker

Queue/worker cần metric riêng.

Ví dụ:

• Queue length.
• Oldest job age.
• Job processing time.
• Job success/fail count.
• Retry count.
• Dead letter count.
• Worker active count.
• Worker concurrency.
• Time in queue.
• Time in processing.

Với AI Judge, đây là nhóm cực kỳ quan trọng.

Nếu user hỏi:

Sao bài em chưa chấm xong?

Bạn cần biết:

Job đang queued hay processing?
Đã retry chưa?
Worker nào xử lý?
AI provider timeout không?
Queue wait bao lâu?

Không có metric/log job, bạn chỉ đoán.

---

49.19. Observability cho external API

External API như AI provider/email/payment cần theo dõi:

• Request count.
• Latency.
• Error rate.
• Timeout.
• Rate limit.
• Retry count.
• Cost.
• Response status/type.

Ví dụ AI:

gemini_request_count
gemini_latency_p95
gemini_timeout_count
gemini_rate_limit_count
gemini_cost_usd

Nếu AI provider chậm, hệ thống của bạn cũng chậm.

Nhưng nếu không đo external dependency, bạn dễ đổ lỗi sai cho backend.

---

49.20. Observability cho cost

Cost cũng cần quan sát.

Đặc biệt với:

• AI API.
• Database.
• Object storage.
• CDN bandwidth.
• Logs/metrics ingestion.
• Queue/message volume.

Ví dụ:

AI cost tăng 3 lần sau deploy.
CDN bandwidth tăng bất thường.
Log ingestion tăng vì log debug bật.
Object storage tăng vì cleanup job chết.

Cost spike là một loại incident.

Với AI product, cost observability là bắt buộc.

---

49.21. Alert là gì?

Alert là thông báo khi hệ thống cần chú ý hoặc hành động.

Ví dụ:

5xx rate > 5% trong 5 phút.
Queue oldest job age > 10 phút.
Database connection > 90%.
AI timeout rate > 10%.
Disk usage > 85%.

Alert tốt nên:

• Có ý nghĩa.
• Có người nhận.
• Có mức độ nghiêm trọng.
• Có hướng xử lý.
• Không quá ồn.

Alert xấu làm team mệt và bị bỏ qua.

Không phải metric nào cũng cần alert.

---

49.22. Dashboard là gì?

Dashboard là nơi nhìn trạng thái hệ thống.

Dashboard tốt cho thấy:

• Hệ thống có khỏe không?
• Vấn đề đang ở đâu?
• Xu hướng gần đây thế nào?
• Deploy mới có ảnh hưởng không?

Ví dụ dashboard AI Judge:

API latency/error.
Submission rate.
Queue backlog.
Worker active.
Grading duration.
AI provider latency/error/cost.
Database connections.
Job failure reasons.

Dashboard không thay alert.

Alert gọi bạn khi cần.

Dashboard giúp bạn nhìn và điều tra.

---

49.23. Correlation ID

Correlation ID giúp nối log/trace/metric quanh cùng một request hoặc job.

Ví dụ:

request_id=req_123
job_id=job_456

Khi request tạo job, log nên ghi:

request_id=req_123 job_id=job_456

Worker xử lý job cũng ghi:

job_id=job_456 submission_id=sub_789

Nếu user báo lỗi, bạn có thể lần theo request/job.

Không có correlation id, log phân tán rất khó nối.

---

49.24. High cardinality là gì?

Cardinality là số lượng giá trị khác nhau của một label/tag.

Ví dụ label:

endpoint="/submissions"
status="200"

cardinality thấp.

Label:

user_id="..."
request_id="..."
submission_id="..."

cardinality rất cao.

Metrics với cardinality quá cao có thể làm hệ thống metric đắt/chậm.

Nguyên tắc:

Metrics:
  label vừa phải.

Logs/traces:
  chứa id chi tiết hơn.

Đừng nhét user_id hoặc request_id làm metric label bừa bãi.

---

49.25. Sampling

Sampling là chỉ thu một phần dữ liệu.

Ví dụ:

Trace 10% request bình thường.
Trace 100% request lỗi.
Trace 100% request chậm.

Sampling giúp giảm chi phí observability.

Nhưng cần cẩn thận:

Nếu sample quá ít, có thể bỏ lỡ lỗi hiếm.

Nếu không sample, chi phí có thể quá cao.

Thực tế thường cần:

• Log lỗi đầy đủ.
• Metric đầy đủ.
• Trace sample thông minh.
• Event quan trọng không mất.

---

49.26. Observability cũng có chi phí

Log/metric/trace không miễn phí.

Chi phí gồm:

• Storage.
• Ingestion.
• Query.
• Retention.
• Network.
• CPU app để tạo tín hiệu.
• Tool subscription.

Sai lầm:

Bật debug log toàn bộ production.

Kết quả:

• Tốn tiền log.
• Khó tìm thông tin.
• Có thể lộ dữ liệu.

Observability tốt không phải ghi mọi thứ.

Là ghi đúng thứ để trả lời câu hỏi quan trọng.

---

49.27. Không log dữ liệu nhạy cảm

Observability không được làm lộ dữ liệu.

Không nên log:

• Password.
• Token.
• Secret.
• Refresh token.
• Full API key.
• Dữ liệu học sinh nhạy cảm nếu không cần.
• Nội dung bài nộp private nếu không cần.
• Prompt/response AI chứa dữ liệu private quá mức.

Log/trace thường được nhiều người và tool đọc.

Nếu log chứa secret, secret coi như đã lộ.

Bảo mật và observability phải đi cùng nhau.

---

49.28. Observability cho bảo mật

Observability cũng giúp security.

Ví dụ:

• Login failed tăng.
• Password reset spam.
• API key dùng bất thường.
• Admin export dữ liệu nhiều.
• File download private tăng lạ.
• WAF block tăng.
• Request từ IP lạ.
• Permission denied tăng đột biến.

Security alert cần thiết kế cẩn thận.

Không phải mọi deny đều là attack.

Nhưng không quan sát thì không biết có gì bất thường.

---

49.29. Observability từ ngày đầu nên có gì?

Không cần bộ công cụ khổng lồ ngay.

Nhưng production tối thiểu nên có:

• Centralized logs.
• Error tracking.
• Basic metrics.
• Uptime check.
• Health check.
• Request latency/error.
• Database basic metrics.
• Queue/worker metrics nếu có worker.
• Alert cho lỗi nghiêm trọng.
• Deployment log.

Với AI Judge, thêm:

• Job status/queue backlog.
• AI provider latency/error/cost.
• Worker retry/fail.
• Grading duration.

Đừng đợi hệ thống lớn mới bắt đầu quan sát.

Khi lớn rồi mới thêm, thường rất đau.

---

49.30. Tool nào?

Công cụ có nhiều lựa chọn:

• Cloud provider monitoring.
• Prometheus/Grafana.
• Grafana Cloud.
• Datadog.
• New Relic.
• Honeycomb.
• Sentry.
• OpenTelemetry.
• Loki/ELK/OpenSearch.
• Better Stack.

Không nên bắt đầu bằng câu hỏi:

Dùng tool nào ngầu nhất?

Hãy bắt đầu bằng câu hỏi:

Ta cần trả lời câu hỏi nào khi production lỗi?
Team vận hành được tool nào?
Chi phí chấp nhận bao nhiêu?
Tích hợp với stack hiện tại ra sao?

Tool theo sau nhu cầu.

---

49.31. OpenTelemetry là gì?

OpenTelemetry là bộ chuẩn/công cụ mở để thu thập telemetry:

• Logs.
• Metrics.
• Traces.

Nó giúp instrument app theo cách tương đối vendor-neutral.

Ý tưởng:

App phát telemetry theo chuẩn.
Bạn gửi dữ liệu đến backend observability khác nhau.

Không bắt buộc mọi app nhỏ phải dùng OpenTelemetry từ đầu.

Nhưng nếu hệ thống nhiều service và muốn trace/metric/log chuẩn hóa, OpenTelemetry rất đáng biết.

---

49.32. Quan sát để học workload thật

Rất nhiều quyết định kiến trúc cần workload thật.

Ví dụ:

• Endpoint nào được gọi nhiều?
• p95 latency thật là bao nhiêu?
• User upload file lớn cỡ nào?
• Queue peak vào giờ nào?
• AI job mất bao lâu?
• Database table nào tăng nhanh?
• Tenant nào tạo tải lớn?
• Cache hit rate bao nhiêu?

Nếu không có dữ liệu, ta dễ tối ưu sai.

Observability là cách hệ thống dạy lại ta về chính nó.

---

49.33. AI Judge: những gì cần quan sát

AI Judge nên quan sát:

Web/API:

request rate
latency p95/p99
error rate
endpoint-level errors

Queue/worker:

queue length
oldest job age
job processing time
retry count
dead letter count
worker active count

AI provider:

latency
timeout
rate limit
token usage
cost
model/prompt version

Database:

slow query
connection count
lock wait
CPU/disk

File:

upload fail
download fail
storage usage
processing fail

Business/reliability:

submission created
grading completed
grading failed
time from submission to result
teacher override rate

---

49.34. AI Judge: câu hỏi observability phải trả lời được

Khi user hỏi:

Vì sao bài của em chưa có điểm?

Hệ thống nên trả lời được:

Submission có được tạo không?
File upload xong chưa?
Grading job có được enqueue không?
Job đang ở queue hay worker?
Worker nào xử lý?
AI provider có timeout/rate limit không?
Job có retry không?
Result có lưu DB không?
Notification có gửi không?

Khi admin hỏi:

Sao hôm nay chấm bài chậm?

Ta nên biết:

Submission rate tăng?
Worker thiếu?
Queue wait tăng?
AI latency tăng?
Database chậm?
Retry storm?
Deploy mới?
Quota bị limit?

Đây là giá trị thật của observability.

---

49.35. Alert tối thiểu cho AI Judge

Một số alert đáng có:

API 5xx rate cao.
API p95 latency cao.
Queue oldest job age vượt ngưỡng.
Grading failed rate cao.
AI provider timeout/rate limit cao.
Dead letter jobs tăng.
Database connection gần max.
Worker count thấp bất thường.
Storage upload fail tăng.
AI cost tăng bất thường.

Không nên alert quá nhiều từ đầu.

Nhưng những thứ ảnh hưởng trực tiếp đến user và tiền nên có.

---

49.36. Những lỗi observability phổ biến

Lỗi 1:

Chỉ có log text rời rạc, không có request_id/job_id.

Lỗi 2:

Chỉ nhìn CPU, không nhìn queue/latency/error.

Lỗi 3:

Không có alert, chỉ biết khi user báo.

Lỗi 4:

Log quá nhiều debug làm tốn tiền và khó tìm.

Lỗi 5:

Log token/secret/dữ liệu nhạy cảm.

Lỗi 6:

Metric label cardinality quá cao.

Lỗi 7:

Không theo dõi external API.

Lỗi 8:

Không theo dõi worker/job, chỉ theo dõi web API.

Lỗi 9:

Dashboard đẹp nhưng không trả lời được câu hỏi incident.

Lỗi 10:

Không gắn deploy event vào metrics/logs.

---

49.37. Checklist observability

Hỏi:

• Khi user báo lỗi, tìm request/job bằng gì?
• Có request_id/correlation_id không?
• Có log tập trung không?
• Có metric latency/error/traffic không?
• Có queue/worker metrics không?
• Có database metrics không?
• Có external API metrics không?
• Có alert cho lỗi nghiêm trọng không?
• Có dashboard cho service chính không?
• Có biết deploy nào đang chạy không?
• Có log dữ liệu nhạy cảm không?
• Có cost metric cho tài nguyên đắt không?
• Có biết p95/p99 không, hay chỉ average?
• Có trace cho request/job chậm không?

Nếu câu trả lời là "không", đó là nơi nên cải thiện.

---

49.38. Bảng chọn nhanh

| Câu hỏi | Tín hiệu hữu ích | |---|---| | Chuyện gì đã xảy ra? | Logs | | Bao nhiêu lần, xu hướng ra sao? | Metrics | | Request/job chậm ở bước nào? | Traces | | Hệ thống có cần người xử lý không? | Alerts | | Trạng thái tổng quan thế nào? | Dashboards | | Deploy mới có gây lỗi không? | Deploy events + metrics | | Queue có nghẽn không? | Queue length, oldest job age | | AI provider có vấn đề không? | Latency, timeout, rate limit, cost | | Database có nghẽn không? | Slow query, connection, lock, CPU/disk | | Có lộ dữ liệu không? | Audit/security logs |

---

49.39. Tóm tắt bằng AI Judge

Với AI Judge, observability không phải phần phụ.

Nó giúp trả lời:

Bài đã nộp chưa?
Job đã vào queue chưa?
Worker có xử lý không?
AI provider có timeout không?
Kết quả đã lưu chưa?
Tại sao chấm chậm?
Tenant nào gây tải?
Chi phí AI tăng vì đâu?
Deploy mới có làm lỗi tăng không?

Ba tín hiệu chính:

Logs:
  câu chuyện cụ thể của request/job.

Metrics:
  số đo và xu hướng.

Traces:
  đường đi và điểm chậm.

Nếu không có chúng, bạn sẽ đoán.

Nếu có chúng, bạn điều tra bằng bằng chứng.

---

49.40. Kết luận của chương

Observability là điều kiện để vận hành hệ thống nghiêm túc.

Nó giúp phát hiện lỗi nhanh hơn, debug nhanh hơn, nhìn thấy nghẽn trước khi quá muộn, và ra quyết định kiến trúc bằng số liệu.

Thông điệp cần nhớ:

> Không đo thì chỉ đoán. Hệ thống production phải phát ra đủ tín hiệu để con người hiểu được nó đang khỏe, chậm, lỗi, hay sắp nghẽn ở đâu.

Ở chương tiếp theo, ta sẽ đi sâu vào logging: log tốt phải giúp trả lời chuyện gì đã xảy ra, structured log là gì, log level dùng thế nào, correlation ID quan trọng ra sao, và vì sao log quá nhiều hoặc log dữ liệu nhạy cảm đều là vấn đề.