Chương 28. Theo Dõi Job Nền

Ở các chương trước, ta đã xây được khá nhiều mảnh:

  • Request không nên ôm việc lâu.
  • Worker xử lý job nền.
  • Queue giữ việc chờ.
  • Concurrency quyết định số việc chạy cùng lúc.
  • Retry, timeout, idempotency giúp job an toàn hơn.
  • Rate limit và quota giúp không vượt giới hạn.

Nhưng còn một câu hỏi cực kỳ thực tế:

> Làm sao biết hệ thống job nền đang khỏe hay đang nghẽn?

Nếu không theo dõi, ta chỉ biết khi người dùng phàn nàn:

Bài của tôi chấm mãi chưa xong.
Email reset password không đến.
Báo cáo export cả tiếng chưa có.
Thanh toán rồi mà đơn chưa cập nhật.

Khi đó mới mở log tìm thì đã muộn.

Job nền không nằm trước mắt người dùng như request HTTP.

Nó chạy phía sau.

Vì vậy càng cần dashboard, metric, log, alert rõ ràng.

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

> Queue và worker không được là hộp đen. Ta phải nhìn thấy job chờ bao lâu, chạy bao lâu, lỗi bao nhiêu, retry bao nhiêu, worker có đang bận không, và bottleneck nằm ở đâu.

---

28.1. Vì sao theo dõi job nền quan trọng?

Web request thường dễ thấy hơn.

Nếu API chậm, dashboard HTTP latency có thể báo ngay.

Nhưng job nền có thể chết âm thầm.

Ví dụ:

Web app vẫn trả response nhanh.
POST /submissions vẫn trả 202.
Nhưng worker AI đã chết.
Queue chấm bài dài dần.
Học viên không có điểm.

Nhìn từ web server:

Mọi thứ xanh.

Nhìn từ người dùng:

Hệ thống hỏng.

Vì vậy job system cần được theo dõi như một phần chính của sản phẩm, không phải phần phụ.

---

28.2. Ví dụ AI Judge: chậm vì đâu?

Học viên nói:

Bài của tôi chấm lâu quá.

Câu "lâu quá" có thể do nhiều nguyên nhân:

Job chưa vào queue.
Job đang chờ queue.
Không có worker chạy.
Worker ít quá.
Worker đang retry nhiều.
Gemini API chậm.
Gemini trả 429.
Database lưu kết quả chậm.
Job lỗi và vào DLQ.
Frontend polling lỗi.

Nếu không có chỉ số, ta chỉ đoán.

Nếu có dashboard, ta có thể trả lời:

Job chờ queue 6 phút.
Gọi Gemini mất 90 giây.
Không có lỗi.
Vậy bottleneck là thiếu AI worker hoặc rate limit thấp.

Hoặc:

Job bắt đầu ngay.
Nhưng Gemini timeout 3 lần.
Vậy bottleneck là external API hoặc prompt quá lớn.

Theo dõi tốt giúp ta tìm đúng chỗ đau.

---

28.3. Chỉ số 1: queue length

Queue length là số job đang chờ trong queue.

Ví dụ:

ai_grading queue length = 2.000
email queue length = 10
report queue length = 50

Queue length giúp biết có bao nhiêu việc đang tồn đọng.

Nhưng queue length một mình chưa đủ.

Vì:

10.000 job nhỏ có thể xử lý trong 1 phút.
100 job lớn có thể xử lý trong 2 giờ.

Do đó queue length phải đọc cùng với:

  • Job processing time.
  • Worker throughput.
  • Oldest job age.
  • Arrival rate.

Queue dài chưa chắc nguy hiểm.

Queue dài và tiếp tục tăng mới đáng lo.

---

28.4. Chỉ số 2: oldest job age

Oldest job age là tuổi của job cũ nhất còn đang chờ.

Ví dụ:

Job cũ nhất trong ai_grading queue đã chờ 18 phút.

Chỉ số này rất quan trọng.

Vì nó gần với trải nghiệm người dùng hơn queue length.

Nếu queue có 10.000 job nhưng job cũ nhất mới chờ 30 giây, có thể vẫn ổn.

Nếu queue chỉ có 50 job nhưng job cũ nhất chờ 2 giờ, chắc chắn có vấn đề.

Với AI Judge, nếu kỳ vọng bài được chấm trong 3 phút, mà oldest job age là 10 phút, hệ thống đang không đạt kỳ vọng.

Một dashboard job nền nên có oldest job age cho từng queue.

---

28.5. Chỉ số 3: queue wait time

Queue wait time là thời gian từ lúc job được tạo đến lúc worker bắt đầu xử lý.

Ví dụ:

created_at = 10:00
started_at = 10:05
queue_wait_time = 5 phút

Chỉ số này trả lời:

> Job mất bao lâu để đến lượt?

Nếu queue wait time cao, vấn đề thường là:

  • Worker không đủ.
  • Rate limit quá thấp.
  • Queue bị job khác chặn.
  • Worker chết.
  • Priority sai.
  • Backlog quá lớn.

Queue wait time khác processing time.

Đừng trộn hai thứ này.

---

28.6. Chỉ số 4: processing time

Processing time là thời gian worker thật sự xử lý job.

Ví dụ:

started_at = 10:05
completed_at = 10:06:30
processing_time = 90 giây

Chỉ số này trả lời:

> Khi job đã bắt đầu, nó chạy mất bao lâu?

Nếu processing time cao, vấn đề có thể là:

  • External API chậm.
  • Query database chậm.
  • File lớn.
  • CPU yếu.
  • Prompt quá dài.
  • Job làm quá nhiều bước.

Với AI Judge, processing time thường gần với thời gian gọi Gemini cộng xử lý kết quả.

Nếu queue wait time thấp nhưng processing time cao, tăng worker chưa chắc giúp nhiều.

Phải tối ưu job hoặc external dependency.

---

28.7. Chỉ số 5: total time

Total time là tổng thời gian từ lúc tạo job đến lúc xong.

total_time = queue_wait_time + processing_time

Ví dụ:

queue_wait_time = 4 phút
processing_time = 90 giây
total_time = 5 phút 30 giây

Người dùng thường cảm nhận total time.

Nhưng kỹ sư cần tách nó ra để biết chậm ở đâu.

Nếu total time cao vì queue wait:

Tăng worker, tách queue, điều chỉnh priority, rate limit.

Nếu total time cao vì processing:

Tối ưu job, giảm input, xem external API, tối ưu DB.

---

28.8. Chỉ số 6: arrival rate

Arrival rate là tốc độ job đi vào queue.

Ví dụ:

ai_grading: 20 job/phút
email: 200 job/phút
report: 5 job/giờ

Nếu arrival rate lớn hơn processing rate trong thời gian dài, queue sẽ dài ra.

Ví dụ:

Job đến: 20 job/phút.
Worker xử lý: 10 job/phút.

Backlog tăng:

10 job/phút.

Không cần đoán.

Chỉ cần so sánh tốc độ vào và tốc độ ra.

---

28.9. Chỉ số 7: processing rate

Processing rate là tốc độ worker xử lý xong job.

Ví dụ:

ai_grading completed = 12 job/phút

Nếu arrival rate cao hơn processing rate:

queue tăng.

Nếu processing rate cao hơn arrival rate:

queue giảm.

Nếu processing rate đột ngột giảm, có thể:

  • Worker chết.
  • External API chậm.
  • Rate limit bị hạ.
  • Error/retry tăng.
  • Database chậm.

Processing rate là nhịp tim của worker pool.

---

28.10. Chỉ số 8: success rate và failure rate

Success rate:

Bao nhiêu job thành công?

Failure rate:

Bao nhiêu job thất bại?

Ví dụ:

ai_grading success rate = 97%
failure rate = 3%

Nhưng cần phân biệt:

  • Failed tạm thời rồi retry thành công.
  • Failed cuối cùng.
  • Failed do input.
  • Failed do external API.
  • Failed do bug.

Một failure rate nhỏ nhưng tăng đột ngột vẫn rất đáng chú ý.

Ví dụ thường 1%, hôm nay 15%.

Có thể provider đang lỗi hoặc deploy mới gây bug.

---

28.11. Chỉ số 9: retry count

Retry count cho biết job phải thử lại bao nhiêu.

Ví dụ:

Gemini timeout retry tăng từ 10/phút lên 500/phút.

Đây là dấu hiệu rất rõ:

  • External API chậm.
  • Timeout quá thấp.
  • Concurrency quá cao.
  • Provider rate limit.
  • Network issue.

Retry tăng làm tải tăng thêm.

Vì vậy cần theo dõi:

  • Retry count theo job type.
  • Retry reason.
  • Retry attempt distribution.

Ví dụ:

80% job thành công lần đầu.
15% thành công sau 1 retry.
5% cần 2-3 retry.

Nếu nhiều job phải retry 3 lần, hệ thống đang có vấn đề.

---

28.12. Chỉ số 10: DLQ count

DLQ count là số job/message vào Dead Letter Queue.

DLQ tăng nghĩa là:

Có job đã retry hết mà vẫn thất bại.

DLQ không nên bị bỏ quên.

Cần:

  • Alert khi DLQ tăng.
  • Dashboard xem job lỗi.
  • Lý do lỗi.
  • Công cụ retry thủ công.
  • Công cụ mark ignored/failed.

Nếu DLQ có 0 trong thời gian dài, tốt.

Nhưng cũng cần chắc là job lỗi thật sự đi vào DLQ, không bị mất âm thầm.

DLQ là nơi hệ thống nói:

Tôi đã cố rồi, cần người hoặc quy trình khác xem.

---

28.13. Chỉ số 11: worker utilization

Worker utilization là mức độ bận của worker.

Ví dụ:

worker-ai utilization = 95%
worker-email utilization = 20%

Nếu queue dài và worker utilization cao:

Worker đang bận hết, có thể cần scale hoặc giảm job.

Nếu queue dài nhưng worker utilization thấp:

Có thể worker không lấy job được, rate limiter chặn, config sai, broker lỗi, hoặc worker chết.

Nếu worker utilization thấp và queue cũng thấp:

Hệ thống rảnh.

Utilization giúp biết worker đang thật sự làm việc hay chỉ tồn tại.

---

28.14. Chỉ số 12: worker online/offline

Cần biết worker nào đang sống.

Ví dụ:

worker-ai expected: 10
worker-ai online: 7

Nếu 3 worker mất, throughput giảm.

Cần alert khi:

  • Worker count thấp hơn kỳ vọng.
  • Worker restart liên tục.
  • Worker không heartbeat.
  • Worker memory tăng bất thường.

Worker chết không phải lúc nào cũng làm web app lỗi ngay.

Nhưng job nền sẽ chậm hoặc dừng.

---

28.15. Chỉ số 13: external API errors

Nếu worker gọi API ngoài, cần theo dõi lỗi bên ngoài.

Ví dụ AI Judge:

  • Gemini latency.
  • Gemini timeout.
  • Gemini 429.
  • Gemini 5xx.
  • Token usage.
  • Cost.

Ví dụ email:

  • Provider 4xx.
  • Provider 5xx.
  • Bounce.
  • Rate limit.

Ví dụ payment:

  • Gateway timeout.
  • Webhook delay.
  • Failed transaction.

Nếu job chậm, external API metrics giúp biết lỗi có nằm ngoài hệ thống không.

Nhưng nhớ:

> Dù lỗi nằm ngoài, hệ thống của ta vẫn phải xử lý được: timeout, retry, backoff, rate limit, thông báo trạng thái.

---

28.16. Chỉ số 14: job stuck

Job stuck là job bị kẹt ở trạng thái như:

RUNNING quá lâu
PENDING quá lâu
RETRYING quá lâu

Ví dụ:

GradingJob RUNNING 2 giờ

Trong khi bình thường chỉ 90 giây.

Cần phát hiện:

  • Job RUNNING quá timeout.
  • Worker chết không cập nhật trạng thái.
  • Job không heartbeat.
  • Job không được retry.

Cách xử lý:

  • Mark stale.
  • Retry.
  • Fail.
  • Alert.
  • Kiểm tra thủ công.

Không nên để job RUNNING mãi mãi.

---

28.17. Chỉ số 15: job size

Không phải job nào cũng nặng như nhau.

Ví dụ AI Judge:

Bài ngắn: 2.000 tokens.
Bài dài: 40.000 tokens.

Nếu processing time tăng, có thể do job size tăng.

Cần theo dõi:

  • Payload size.
  • Input tokens.
  • Output tokens.
  • File size.
  • Số dòng import.
  • Số record export.

Job size giúp giải thích:

Tại sao hôm nay job lâu hơn?

Có thể vì user nộp bài dài hơn hoặc report lớn hơn.

---

28.18. Đừng chỉ đo trung bình

Trung bình có thể che vấn đề.

Ví dụ:

Average grading time = 2 phút.

Nghe ổn.

Nhưng có thể:

90% job xong trong 1 phút.
10% job mất 15 phút.

Người dùng trong 10% kia vẫn rất đau.

Cần nhìn percentile:

  • p50.
  • p90.
  • p95.
  • p99.

Ví dụ:

p50 total time = 2 phút
p95 total time = 8 phút
p99 total time = 20 phút

Nếu p95/p99 cao, hệ thống có tail latency.

Đừng chỉ nhìn average.

---

28.19. Dashboard tối thiểu cho job system

Một dashboard tối thiểu nên có theo từng queue/job type:

Queue length
Oldest job age
Arrival rate
Processing rate
Queue wait time p50/p95/p99
Processing time p50/p95/p99
Total time p50/p95/p99
Success rate
Failure rate
Retry count
DLQ count
Worker online count
Worker utilization
External API latency/error/rate limit

Với AI Judge, thêm:

Gemini requests/min
Gemini 429 count
Gemini timeout count
Tokens/job
Cost/day
Cost/tenant
Jobs blocked by quota

Không cần mọi thứ đẹp ngay từ đầu.

Nhưng thiếu hoàn toàn dashboard là rất nguy hiểm.

---

28.20. Alert tối thiểu

Dashboard để nhìn.

Alert để đánh thức khi có sự cố.

Alert nên có:

  • Oldest job age vượt ngưỡng.
  • Queue length tăng liên tục.
  • Failure rate tăng đột biến.
  • Retry count tăng đột biến.
  • DLQ có job mới.
  • Worker online thấp hơn kỳ vọng.
  • Job stuck quá lâu.
  • External API 429/5xx tăng.
  • Cost/quota gần hết.

Alert cần vừa đủ.

Nếu alert quá nhiều và nhiễu, team sẽ bỏ qua.

Mỗi alert nên trả lời:

> Có cần ai hành động không?

Nếu không, có thể nó chỉ nên là dashboard metric.

---

28.21. Log cần có gì?

Metric cho ta xu hướng.

Log giúp điều tra từng job.

Mỗi job nên log được:

job_id
job_type
queue
status
attempt
created_at
started_at
completed_at
error_code
error_message
external_request_id
correlation_id
tenant_id/user_id nếu phù hợp

Ví dụ:

grading_job_id=job_123
attempt=2
error=GEMINI_TIMEOUT
duration_ms=120000
correlation_id=req_456

Log không nên chứa dữ liệu nhạy cảm quá mức:

  • Token.
  • Secret.
  • Full prompt nếu có dữ liệu riêng tư.
  • Raw payment data.

Log phải hữu ích nhưng an toàn.

---

28.22. Correlation ID

Correlation ID nối các bước trong cùng một luồng.

Ví dụ:

POST /submissions
-> tạo GradingJob
-> enqueue RunGradingJob
-> Worker gọi Gemini
-> GradingCompleted
-> Notification gửi thông báo

Tất cả cùng có:

correlation_id = req_abc_123

Khi user báo lỗi, ta tìm correlation id là thấy cả luồng.

Không có correlation id, log của request, worker, event, notification rời rạc.

Hệ thống job nền nên truyền correlation id qua queue/event.

---

28.23. Trace cho job nền

Distributed tracing không chỉ dành cho HTTP request.

Job nền cũng nên trace được.

Ví dụ trace:

SubmitAssignmentUseCase
  create Submission
  create GradingJob
  enqueue RunGradingJob

RunGradingJobUseCase
  load job
  call Gemini
  save result
  publish GradingCompleted

Trace giúp thấy:

  • Bước nào mất thời gian.
  • External call nào chậm.
  • Database query nào chậm.
  • Event publish có lỗi không.

Nếu có thể, trace job nền cùng hệ thống HTTP.

---

28.24. Phân biệt lỗi tạm thời và lỗi vĩnh viễn

Dashboard nên phân loại lỗi.

Ví dụ:

Temporary:
- timeout
- 503
- network error
- rate limited

Permanent:
- invalid input
- permission denied
- file format invalid
- prompt too long không thể xử lý

Nếu permanent error tăng, có thể:

  • Validation đầu vào kém.
  • User upload sai format.
  • Rule nghiệp vụ chưa rõ.

Nếu temporary error tăng, có thể:

  • Provider lỗi.
  • Network.
  • Concurrency quá cao.
  • Timeout quá thấp.

Không phân loại lỗi thì retry policy và vận hành đều mù.

---

28.25. Theo dõi retry theo attempt

Không chỉ đếm tổng retry.

Cần biết phân bố attempt:

Attempt 1 success: 80%
Attempt 2 success: 15%
Attempt 3 success: 3%
Failed after retries: 2%

Nếu nhiều job chỉ thành công sau retry, hệ thống đang không ổn định.

Nếu attempt 3 gần như không bao giờ thành công, retry lần 3 có thể chỉ tốn tài nguyên.

Nếu attempt 2 cứu được nhiều job, retry lần 2 là có giá trị.

Metric này giúp tinh chỉnh retry policy.

---

28.26. Theo dõi theo tenant/user

Nếu hệ thống nhiều khách hàng, cần nhìn theo tenant.

Ví dụ:

Tenant A tạo 80% AI jobs.
Tenant B có failure rate cao bất thường.
Tenant C dùng gần hết quota.

Theo dõi theo tenant giúp:

  • Phát hiện abuse.
  • Giữ fairness.
  • Tính cost.
  • Hỗ trợ khách hàng.
  • Ưu tiên đúng.

Nhưng phải cẩn thận privacy và quyền xem dữ liệu.

Không phải ai trong công ty cũng nên xem mọi dữ liệu cá nhân.

---

28.27. Theo dõi cost

Với AI, cost là chỉ số vận hành.

Không thể đợi đến cuối tháng xem hóa đơn.

Cần theo dõi:

  • Cost hôm nay.
  • Cost theo tenant.
  • Cost theo model.
  • Cost theo job type.
  • Cost retry.
  • Cost thất bại.
  • Token trung bình/job.

Ví dụ:

Retry chiếm 25% cost AI hôm nay.

Đây là dấu hiệu cần điều tra.

Có thể provider đang lỗi, timeout quá thấp, hoặc job không idempotent tốt.

Cost không tách khỏi kỹ thuật.

Nó là một phần của hệ thống.

---

28.28. Theo dõi worker resource

Worker cũng cần resource metrics:

  • CPU.
  • RAM.
  • Disk.
  • Network.
  • DB connections.
  • File descriptors.
  • Container restarts.

Ví dụ:

worker-report RAM tăng đến OOM.

Có thể report đang load toàn bộ file vào memory.

Ví dụ:

worker-ai CPU thấp nhưng queue dài.

Có thể job đang chờ external API hoặc rate limiter, không phải CPU.

Resource metrics giúp tránh tối ưu nhầm.

---

28.29. Cách đọc vài tình huống thường gặp

Queue dài, worker bận 100%

Có thể thiếu worker hoặc job xử lý quá lâu.

Hành động:

  • Tăng worker nếu tài nguyên/quota cho phép.
  • Tối ưu job.
  • Tách queue.
  • Backpressure nếu cần.

Queue dài, worker rảnh

Có thể:

  • Worker không nghe đúng queue.
  • Rate limiter đang chặn.
  • Broker/config lỗi.
  • Worker chết nhưng dashboard sai.

Retry tăng, 429 tăng

Đang vượt rate limit.

Hành động:

  • Giảm rate.
  • Backoff theo Retry-After.
  • Tạm pause low priority.
  • Kiểm tra concurrency.

Processing time tăng, queue wait thấp

Job bắt đầu nhanh nhưng chạy lâu.

Hành động:

  • Xem external API latency.
  • Xem input size.
  • Xem database query.
  • Xem CPU/RAM.

Queue wait tăng, processing time ổn

Job chạy bình thường nhưng phải chờ lâu.

Hành động:

  • Tăng worker.
  • Tách priority.
  • Giảm arrival rate.
  • Scale theo queue wait time.

---

28.30. SLO cho job nền

SLO là mục tiêu chất lượng dịch vụ.

Ví dụ:

95% bài AI được chấm trong 3 phút.
99% email reset password được gửi trong 30 giây.
95% report nhỏ được tạo trong 2 phút.
Webhook payment được xử lý trong 10 giây.

SLO giúp định nghĩa "chậm" là gì.

Nếu không có SLO, team sẽ tranh luận cảm tính.

Với SLO, ta biết:

  • Khi nào phải alert.
  • Khi nào cần scale.
  • Khi nào cần tối ưu.
  • Khi nào hệ thống vẫn ổn.

Không phải job nào cũng cần SLO nghiêm ngặt.

Nhưng job quan trọng nên có.

---

28.31. Dashboard không thay thế thiết kế đúng

Theo dõi tốt không cứu được thiết kế quá sai.

Nếu job không idempotent, dashboard chỉ cho bạn thấy lỗi sau khi dữ liệu đã trùng.

Nếu không có timeout, dashboard có thể báo job stuck, nhưng worker vẫn bị giữ.

Nếu không có DLQ, job lỗi có thể mất hoặc retry mãi.

Nếu không có rate limiter, dashboard báo 429 tăng, nhưng hệ thống vẫn đang đâm vào provider.

Vì vậy:

Thiết kế đúng + theo dõi tốt

mới là cặp đầy đủ.

---

28.32. Dashboard tối thiểu cho AI Judge

Với AI Judge, nên có:

Job metrics:
- pending jobs
- running jobs
- succeeded/failed jobs
- queue wait p50/p95/p99
- processing time p50/p95/p99
- total time p50/p95/p99
- retry count
- DLQ count
- stuck jobs

Worker metrics:
- worker-ai online
- worker utilization
- concurrency in use
- CPU/RAM
- DB connections

Gemini metrics:
- requests/min
- latency p50/p95/p99
- timeout count
- 429 count
- 5xx count
- tokens/job
- cost/day

Product metrics:
- jobs/user
- jobs/tenant
- quota used
- jobs blocked by quota

Chỉ cần có bảng này, khả năng vận hành đã khác hẳn.

---

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

Lỗi 1: Chỉ theo dõi web request

Web xanh nhưng worker chết.

Lỗi 2: Chỉ nhìn queue length

Không biết job cũ nhất đã chờ bao lâu.

Lỗi 3: Không tách wait time và processing time

Không biết chậm vì chờ hay vì chạy.

Lỗi 4: Không theo dõi retry reason

Không biết retry do timeout, 429 hay bug.

Lỗi 5: DLQ không có alert

Job lỗi nằm đó nhưng không ai biết.

Lỗi 6: Không đo external API

Không biết lỗi do mình hay provider.

Lỗi 7: Không có correlation id

Không lần được một request qua worker/event.

Lỗi 8: Không đo cost

Hệ thống chạy được nhưng tiền bay không kiểm soát.

---

28.34. Checklist theo dõi job nền

Khi xây job system, hãy hỏi:

  • Mỗi job có created_at, started_at, completed_at không?
  • Có đo queue wait time không?
  • Có đo processing time không?
  • Có đo total time không?
  • Có queue length theo từng queue không?
  • Có oldest job age không?
  • Có success/failure rate không?
  • Có retry count và retry reason không?
  • Có DLQ count và alert không?
  • Có stuck job detection không?
  • Có worker online count không?
  • Có worker CPU/RAM/DB connection không?
  • Có external API latency/error/rate limit không?
  • Có correlation id xuyên request -> job -> event không?
  • Có dashboard theo tenant/user nếu cần không?
  • Có cost/quota dashboard không?
  • Có SLO cho job quan trọng không?

Nếu chưa có các thứ này, hệ thống job nền vẫn còn đang chạy trong bóng tối.

---

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

Khi học viên nói:

Bài của tôi chấm lâu.

Ta không nên đoán.

Ta nên nhìn:

Job có được tạo không?
Job có vào queue không?
Job chờ queue bao lâu?
Worker có online không?
Worker có bận không?
Job gọi Gemini mất bao lâu?
Có timeout/429 không?
Job retry mấy lần?
Job có vào DLQ không?
Kết quả đã lưu chưa?
Frontend có polling đúng không?

Một hệ thống tốt trả lời được các câu này trong vài phút, không phải vài giờ.

---

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

Job nền giúp hệ thống xử lý việc lâu tốt hơn, nhưng cũng làm một phần công việc rời khỏi request trực tiếp.

Vì vậy nếu không theo dõi, ta rất dễ mất khả năng nhìn thấy chuyện gì đang xảy ra.

Các chỉ số quan trọng nhất:

  • Queue length.
  • Oldest job age.
  • Queue wait time.
  • Processing time.
  • Total time.
  • Arrival rate.
  • Processing rate.
  • Success/failure rate.
  • Retry count.
  • DLQ count.
  • Worker utilization.
  • External API latency/error.
  • Stuck jobs.
  • Cost/quota nếu có.

Thông điệp quan trọng nhất:

> Không thể vận hành job nền bằng niềm tin. Phải đo được việc đang chờ bao lâu, chạy bao lâu, lỗi ở đâu, retry bao nhiêu, và worker có thật sự đang xử lý không.

Chương này khép lại phần Worker, Job Nền Và Việc Lâu.

Ở phần tiếp theo, ta sẽ đi vào dữ liệu: database quan hệ, transaction, cache, index, replication, backup, migration và những nơi hệ thống thường đau nhất.