Giám sát heartbeat / cron-job là gì?

Giám sát ngược — tác vụ bạn lên lịch sẽ ping tới URL của chúng tôi khi chạy thành công. Nếu không nhận được ping trong khung thời gian mong đợi, chúng tôi sẽ cảnh báo cho bạn. Điều này giải quyết vấn đề các sự cố âm thầm: cron job bị hỏng không tạo ra lỗi và không kích hoạt cảnh báo uptime truyền thống.

Tích hợp URL heartbeat vào cron của tôi như thế nào?

Hãy thêm curl -fsS <heartbeat_url> vào cuối lệnh cron của bạn. Nếu lệnh trước đó thất bại, curl sẽ không chạy và heartbeat sẽ bị bỏ qua. Bạn cũng có thể ping cả lúc bắt đầu lẫn lúc kết thúc bằng các endpoint khác nhau — cho phép theo dõi riêng tín hiệu "bắt đầu" và "hoàn thành".

Tôi nên đặt thời gian “grace period” bao nhiêu?

Khoảng 2-3 lần thời gian chạy trung bình của tác vụ. Nếu backup hàng ngày của bạn mất 30 phút, hãy đặt grace là 90 phút — cho phép bị chậm trễ mà không cảnh báo nhầm. Với các tác vụ có thời gian chạy không đều, nên đặt rộng rãi và dùng dashboard xác định các trường hợp ngoại lệ.

Tôi có thể giám sát cron job chạy mỗi giờ không?

Có — hãy đặt khoảng thời gian phù hợp (ví dụ 60 phút mong đợi, grace 15 phút). Monitor sẽ mong nhận ping ít nhất mỗi 75 phút. Nếu tác vụ của bạn thường xuyên hơn (mỗi 5 phút), URL heartbeat cũng hoàn toàn hỗ trợ — chỉ cần điều chỉnh lại khoảng thời gian khi cấu hình.

Giám sát heartbeat có dùng được cho AWS Lambda / serverless không?

Có. Thêm một HTTP request gửi về URL heartbeat cuối hàm Lambda. Monitor sẽ xử lý y hệt như heartbeat cron — cảnh báo như nhau, grace period như nhau. Rất hữu ích với các Lambda lên lịch khi cảnh báo của CloudWatch không phát hiện được lỗi âm thầm trong quá trình thực thi.

Giám sát Cron — Heartbeats & Dead-Man

Phát hiện ngay khi các tác vụ định kỳ của bạn ngừng chạy. Sao lưu, queue worker, công việc ETL, đồng bộ mỗi giờ - tất cả đều được giám sát chặt chẽ.

Sự cố với các tác vụ được lên lịch

Một đặc điểm nghiệt ngã của cron là khi nó bị lỗi, không có ai báo cho bạn biết. Ứng dụng web vẫn phục vụ request bình thường, trang chủ vẫn ổn, hệ thống giám sát vẫn báo xanh — nhưng ở đâu đó trên máy chủ, backup ban đêm đã không chạy hai tuần rồi. Queue worker chết sau khi deploy và các công việc tồn đọng ngày càng nhiều. Đồng bộ mỗi giờ âm thầm bị mất dòng do sự cố quyền. Bạn chỉ phát hiện ra khi có thứ gì đó ở downstream cuối cùng cũng sụp đổ — thường đúng lúc bạn cần nó nhất. Nhóm dữ liệu muốn xuất dữ liệu, support có một hàng mail, ops thì hỏi backup. Khi đó, đã quá muộn.

Giám sát uptime tiêu chuẩn sẽ không phát hiện ra điều này, vì không có gì để ping. Cron không mở endpoint HTTP, không mở port, không chạy server. Nó khởi động, chạy, rồi kết thúc. Nếu nó ngừng hoạt động — sẽ không có dấu hiệu gì về sự vắng mặt của nó cho tới khi bạn bắt đầu điều tra.

Mẫu ngược lại: giám sát heartbeat

Giám sát heartbeat (còn gọi là “công tắc người chết” hoặc “giám sát cron”) đảo ngược hướng truyền thống. Thay vì chúng tôi kiểm tra dịch vụ của bạn, dịch vụ của bạn sẽ báo hiệu cho chúng tôi. Bạn chỉ cần thêm một dòng vào cron — curl tới một URL duy nhất mà chúng tôi tạo — và URL đó sẽ lưu lại dấu thời gian mỗi lần nhận ping. Chúng tôi sẽ theo dõi sự vắng mặt của các ping này. Nếu URL không được ping trong khung thời gian (cộng thêm một mức margin), chúng tôi coi đó là một lần chạy bị bỏ lỡ và gửi cảnh báo.

Mô hình này đơn giản, đáng tin cậy và không phụ thuộc ngôn ngữ. Bất cứ thứ gì gửi được HTTP request đều có thể tích hợp. Bash dùng curl, Python dùng requests, Node dùng fetch, PHP dùng curl_init, Task Scheduler trên Windows dùng Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events — bất cứ gì cũng được. Không cần SDK, không cần agent, không cần daemon để cài đặt.

Cách cấu hình

Trong DiagnoSEO Uptime Monitoring, bấm “Thêm monitor”, chọn loại “Heartbeat / cron”. Công cụ này sẽ tạo một URL duy nhất với token — kiểu như https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Thiết lập khoảng thời gian mong muốn (tác vụ chạy bao lâu một lần, tính bằng phút) và margin (cho phép trễ bao nhiêu trước khi cảnh báo). Lưu lại.

Bây giờ sửa cron để ping URL này sau mỗi lần chạy thành công. Ba kiểu điển hình tùy môi trường:

# Bash cron - chỉ gửi ping khi chạy thành công
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Hoặc nếu chấp nhận thành công một phần
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

Từ giờ, mỗi lần chạy thành công sẽ gửi ping cho chúng tôi và chúng tôi sẽ lưu timestamp. Nếu không thấy ping trong vòng khoảng thời gian + margin phút, một sự cố sẽ được mở và cảnh báo sẽ gửi tới tất cả các kênh đã bật: Email, Telegram, Slack, Discord, SMS.

Chọn khoảng thời gian và margin

Khoảng thời gian nên trùng khớp với lịch trình của job. Chạy backup ban đêm lúc 3:00 — khoảng thời gian 1440 phút (24h). Đồng bộ mỗi giờ — 60. Worker kiểm tra mỗi 5 phút — 5.

Margin sẽ hấp thụ các dao động tự nhiên. Cron không chạy đúng chính xác nano giây — có thể bị xếp hàng, chờ lần chạy trước xong, hoặc bị delay do lỗi tạm thời. Job 24h với margin 1h sẽ có buffer thoải mái mà không làm chậm cảnh báo. Worker chạy mỗi 5 phút, margin 2 phút sẽ phát hiện chết thật, không gây cảnh báo giả vì thoáng mất tín hiệu 30 giây. Nói chung: chọn margin ở mức 10-50% khoảng thời gian, tùy mức độ job có hay dao động không.

Những mẫu mà chúng tôi khuyên dùng

Ping chỉ khi thành công. Dùng && trong bash — job lỗi sẽ không gửi ping. Chúng tôi sẽ phát hiện không có ping và cảnh báo.
Ping sau mỗi lần lặp của vòng lặp. Với các worker chạy lâu, hãy ping trong vòng lặp mỗi khi hoàn thành xong đơn vị công việc, thay vì chỉ ping ở cuối. Như vậy worker bị treo sẽ được phát hiện trong khi chạy.
Mỗi heartbeat ứng với một job logic, không phải mỗi script. Nếu ba script tạo nên một pipeline ban đêm, chỉ cần ping một lần ở cuối chuỗi. Sẽ có tín hiệu rõ ràng “pipeline còn hoạt động không”.
Kết hợp với log. Heartbeat xác nhận job có chạy. Log ứng dụng cho biết job đã làm gì. Kết hợp lại, bạn có được bức tranh tổng thể.

Chuyện gì xảy ra khi heartbeat biến mất

Một sự cố được mở ngay khi hết hạn. Dashboard sẽ đánh dấu monitor sang màu đỏ với lỗi “Không nhận được heartbeat trong X phút”. Thông báo sẽ gửi qua tất cả các kênh bạn đã bật. Khi heartbeat mới đến, monitor tự động chuyển lại sang trạng thái up — đánh dấu lại là up, đóng sự cố, và (nếu bật cảnh báo hồi phục) bạn sẽ nhận được thông báo “back online”.

Tất cả được xử lý như các monitor khác — heatmap, phần trăm uptime, lịch sử, tag, tìm kiếm, xuất dữ liệu. Trong giao diện dashboard, monitor heartbeat là một dòng như mọi dòng khác, có thể sắp xếp và lọc cùng với HTTP, ping, port, API.

Checklist

Thêm monitor → chọn loại Heartbeat → sao chép URL đã tạo → thêm vào cron / worker / scheduler → thiết lập khoảng thời gian và margin → lưu → xong. Từ giờ bạn sẽ biết ngay lập tức nếu tác vụ lên lịch bị dừng — điều này về lâu dài là một trong những quyết định quan trọng nhất đối với hệ thống giám sát bạn có thể đưa ra.

Các câu hỏi thường gặp

Giám sát heartbeat / cron-job là gì?
Giám sát ngược — tác vụ bạn lên lịch sẽ ping tới URL của chúng tôi khi chạy thành công. Nếu không nhận được ping trong khung thời gian mong đợi, chúng tôi sẽ cảnh báo cho bạn. Điều này giải quyết vấn đề các sự cố âm thầm: cron job bị hỏng không tạo ra lỗi và không kích hoạt cảnh báo uptime truyền thống.
Tích hợp URL heartbeat vào cron của tôi như thế nào?
Hãy thêm curl -fsS <heartbeat_url> vào cuối lệnh cron của bạn. Nếu lệnh trước đó thất bại, curl sẽ không chạy và heartbeat sẽ bị bỏ qua. Bạn cũng có thể ping cả lúc bắt đầu lẫn lúc kết thúc bằng các endpoint khác nhau — cho phép theo dõi riêng tín hiệu “bắt đầu” và “hoàn thành”.
Tôi nên đặt thời gian “grace period” bao nhiêu?
Khoảng 2-3 lần thời gian chạy trung bình của tác vụ. Nếu backup hàng ngày của bạn mất 30 phút, hãy đặt grace là 90 phút — cho phép bị chậm trễ mà không cảnh báo nhầm. Với các tác vụ có thời gian chạy không đều, nên đặt rộng rãi và dùng dashboard xác định các trường hợp ngoại lệ.
Tôi có thể giám sát cron job chạy mỗi giờ không?
Có — hãy đặt khoảng thời gian phù hợp (ví dụ 60 phút mong đợi, grace 15 phút). Monitor sẽ mong nhận ping ít nhất mỗi 75 phút. Nếu tác vụ của bạn thường xuyên hơn (mỗi 5 phút), URL heartbeat cũng hoàn toàn hỗ trợ — chỉ cần điều chỉnh lại khoảng thời gian khi cấu hình.
Giám sát heartbeat có dùng được cho AWS Lambda / serverless không?
Có. Thêm một HTTP request gửi về URL heartbeat cuối hàm Lambda. Monitor sẽ xử lý y hệt như heartbeat cron — cảnh báo như nhau, grace period như nhau. Rất hữu ích với các Lambda lên lịch khi cảnh báo của CloudWatch không phát hiện được lỗi âm thầm trong quá trình thực thi.

Giám sát tác vụ Cron