Heartbeat / cron-job monitoring คืออะไร?

มอนิเตอร์กลับด้าน — งานที่ตั้งเวลาไว้ของคุณจะ ping URL ของเราเมื่อสำเร็จ ถ้าไม่มีสัญญาณตามเวลาที่กำหนด เราจะแจ้งเตือน ช่วยแก้ปัญหา failure แบบเงียบ: cron ที่ล้มไม่สร้าง error และไม่มี alert แบบ uptime แบบเดิม

จะผูก URL heartbeat กับ cron ของฉันอย่างไร?

เติม curl -fsS <heartbeat_url> ต่อท้ายคำสั่ง cron ถ้าคำสั่งก่อนหน้านั้นล้ม curl จะไม่รัน และจะไม่ได้ heartbeat หรือจะ ping ทั้งตอนเริ่มต้นและจบงานแยกตาม path - จะได้สัญญาณ "started" และ "completed" แยกกัน

ควรตั้ง grace period เท่าไหร่?

ประมาณ 2-3 เท่าของเวลารันงานปกติ เช่น backup รายวันกินเวลา 30 นาที ให้ตั้ง grace เป็น 90 นาที รองรับความล่าช้าโดยไม่มี false alert งานที่ใช้เวลาผันผวน ให้กำหนดกรุณาเผื่อไว้หน่อย แล้วดู outlier เพิ่มใน dashboard

สามารถมอนิเตอร์ cron job ที่รันรายชั่วโมงได้หรือไม่?

ได้ - แค่ตั้งช่วงเวลาให้ตรง (เช่น 60 นาที + grace อีก 15 นาที) มอนิเตอร์จะรอ ping อย่างน้อยทุก 75 นาทีถ้าตารางถี่กว่านั้น (ทุก 5 นาที) URL heartbeat ก็รองรับ - ปรับช่วงเวลาให้ตรงกับงานของคุณ

heartbeat monitoring ใช้กับ AWS Lambda / serverless ได้หรือไม่?

ได้ ใส่ HTTP request ไปที่ URL heartbeat ตอนท้ายของฟังก์ชัน Lambda Monitor จะดูเหมือนกับ cron heartbeat ทุกอย่าง ทั้งแจ้งเตือนและ grace period ของเดิม เหมาะมากสำหรับ Lambdas ที่ตั้งเวลาล่วงหน้าในกรณีที่ CloudWatch alarm จับ failure เงียบ ๆ ไม่ได้

การตรวจสอบ cron — Heartbeats & Dead-Man

ทราบทันทีเมื่อกำหนดเวลางานของคุณหยุดทำงาน ไม่ว่าเป็นการสำรองข้อมูล queue worker งาน ETL หรือการซิงค์ประจำชั่วโมง — ทั้งหมดนี้ได้รับการติดตามโดยไม่รบกวน

ปัญหาเกี่ยวกับงานที่ตั้งเวลาไว้

สิ่งที่โหดร้ายของ cron คือเมื่อมันล้มเหลว จะไม่มีใครบอกคุณ เว็บแอปพลิเคชันยังคงให้บริการรีเควส หน้าแรกก็ดูปกติ การมอนิเตอร์ยังคงขึ้นไฟเขียว - แต่บางแห่งบนเซิร์ฟเวอร์ backup กลางคืนไม่ได้รันมาแล้วสองสัปดาห์ Worker ในคิวล้มหลัง deploy และงานที่ค้างก็เริ่มกองพะเนิน การซิงค์รายชั่วโมงเงียบ ๆ สูญหายแถวข้อมูลบางบรรทัดเพราะปัญหาสิทธิ์ คุณจะมารู้ก็ต่อเมื่อสิ่งที่อยู่ downstream พังในที่สุด - มักจะเกิดตอนที่คุณต้องการที่สุด ทีมข้อมูลอยาก export, support อยากได้คิวอีเมล, ops ต้องการแบ็กอัป ตอนนั้นก็สายเกินไปแล้ว

มอนิเตอร์ uptime แบบทั่วไปจับสิ่งนี้ไม่ได้ เพราะไม่มีอะไรให้มัน ping cron ไม่ได้ให้ endpoint HTTP, ไม่ได้เปิดพอร์ต, ไม่ได้รันเซิร์ฟเวอร์ มันแค่เรียกตัวเอง ทำงาน เสร็จสิ้น ถ้ามันหยุดทำงาน - จะไม่มีสัญญาณของการหายไป จนกว่าคุณจะลองหาเอง

รูปแบบแก้ไข: การมอนิเตอร์ heartbeat

มอนิเตอร์ heartbeat (หรือที่เรียกว่า "dead man's switch" หรือ "monitoring cron") เปลี่ยนทิศทางไป แทนที่ เรา จะไปเช็ก บริการของคุณ ตอนนี้กลับเป็น บริการของคุณ มารายงาน เรา คุณเพิ่มเพียงบรรทัดเดียวใน cron - curl ไปยัง URL เฉพาะที่เราสร้างขึ้น - URL นี้จะบันทึกเวลาทุกครั้งที่มี ping เราจะคอยเฝ้าดูว่ามี ping ขาดหายไหม ถ้า URL ไม่ถูกเรียกตามช่วงเวลาที่ตั้งไว้ (รวม margin) เราจะถือว่ามีการข้ามรอบและส่งสัญญาณแจ้งเตือน

โมเดลนี้เรียบง่าย เชื่อถือได้ และไม่ขึ้นกับภาษา ทุกสิ่งที่สามารถ HTTP request ได้ก็อินทิเกรตได้ Bash ด้วย curl, Python ด้วย requests, Node ด้วย fetch, PHP ด้วย curl_init, Task Scheduler บน Windows ด้วย Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events - อะไรก็ได้ ไม่ต้องใช้ SDK, ไม่ต้องลง agent, ไม่ต้องติดตั้ง daemon

วิธีตั้งค่า

ใน DiagnoSEO Uptime Monitoring ให้คลิก “เพิ่มมอนิเตอร์” เลือกชนิด “Heartbeat / cron” เครื่องมือจะสร้าง URL เฉพาะที่มี token มาให้ - หน้าตาแบบ https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 กำหนดช่วงเวลา (ว่าควรทำงานบ่อยแค่ไหน หน่วยเป็นนาที) และ margin (จะยอมให้ช้ากว่าได้กี่นาทีก่อนจะแจ้งเตือน) แล้วกดบันทึก

ตอนนี้ให้แก้ไข cron เพื่อให้ ping URL หลังจากจบงานแต่ละรอบแบบสำเร็จ มี 3 สไตล์ตามแต่ละสภาพแวดล้อม:

# Bash cron - ping เฉพาะเมื่อสำเร็จ
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# หรือถ้าถือว่าบางส่วนสำเร็จก็พอใจ
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

ตั้งแต่นี้เป็นต้นไป ทุกครั้งที่งานรันสำเร็จจะ ping มาหาเรา และเราจะบันทึก timestamp ถ้าไม่มีการ ping เกิน ช่วงเวลา + margin นาที จะเกิด incident และส่งการเตือนไปยังช่องทางที่เปิดใช้งาน Email, Telegram, Slack, Discord, SMS

การเลือกช่วงเวลาและ margin

ช่วงเวลาควรตรงกับตารางของ job ตัวอย่าง backup กลางคืนเวลา 3:00 - ให้ตั้ง 1440 นาที (24ชม.) ซิงค์รายชั่วโมง 60 นาที Worker ที่ run ทุก ๆ 5 นาที ให้ใส่ 5

Margin จะช่วยรองรับ jitter ธรรมชาติ Cron ไม่ได้รันเป๊ะตรงนาโนวินาที - มันเข้าคิว รอรอบก่อนหน้าจบ บางทีก็ back-off จากข้อผิดพลาดเล็ก ๆ งาน 24 ชม. บวก margin 1 ชม. จะให้ buffer พอดีโดยไม่หน่วงการเตือน Worker 5 นาทีที่มี margin 2 นาที จะจับการล้มจริงได้เร็ว ไม่มี false positive จากการ delay 30 วินาทีโดยไม่จำเป็น โดยประมาณ: ตั้ง margin ไว้ที่ 10-50% ของช่วงเวลา ตามนิสัยของงานนั้น ๆ

รูปแบบที่เราแนะนำ

Ping เฉพาะเมื่อสำเร็จ ใช้ && ใน bash - ถ้างานล้มเหลวจะไม่ ping เราจะตรวจจับได้เมื่อขาด ping และแจ้งเตือน
Ping ทุก ๆ รอบในลูป สำหรับ worker ที่ทำงานยาว ให้ ping ในลูปหลังจากงานย่อยสำเร็จแต่ละรอบ ไม่ใช่ค่อย ping ตอนจบ จะช่วยให้ worker ที่ค้างถูกตรวจเจอระหว่าง run
Heartbeat เดียวต่อ 1 งานหลัก ไม่ใช่แยกสคริปต์ ถ้าสคริปต์ 3 ตัวทำงานเป็น pipeline กลางคืนเดียวกัน ให้ ping แค่ปลายสุดของ chain เพื่อให้ signal ชัดเจนว่าทั้ง pipeline ยังรอด
ผสมกับ log Heartbeat แสดงว่างานเริ่มแล้ว Log แอปพลิเคชันแสดงว่างานทำอะไรไปบ้าง ถ้ามีทั้งสองอย่างจะเห็นภาพรวมครบถ้วน

จะเกิดอะไรขึ้นเมื่อ heartbeat หาย

Incident จะถูกเปิดเมื่อข้าม deadline dashboard จะโชว์ monitor เป็นสีแดงและแจ้งข้อผิดพลาด "ไม่มี heartbeat มานาน X นาที" จะมีการแจ้งเตือนผ่านทุกช่องที่เปิดใช้งาน เมื่อ heartbeat ใหม่มาถึง monitor จะกลับเขียวอัตโนมัติ ถูก mark เป็น up incident จะปิดและ (ถ้ามี alert ฟื้นตัวเปิดไว้) คุณจะได้ notification "back online"

ทั้งหมดนี้เหมือนกับ monitor อื่น ๆ - heatmap, % uptime, ประวัติ, tag, การค้นหา, export จากมุมมอง dashboard monitor heartbeat ก็เป็นแค่แถวหนึ่งที่ sort/กรอง ต่อจาก HTTP, ping, port และ API ได้เลย

เช็กลิสต์

เพิ่มมอนิเตอร์ → เลือก Heartbeat → ก๊อป URL ที่สร้าง → ไปใส่ใน cron / worker / scheduler → ตั้งช่วงเวลาและ margin → บันทึก → เสร็จ ตอนนี้คุณจะรู้ภายในวินาทีเมื่องานที่ตั้งเวลาไว้หยุดรัน - ซึ่งในระยะยาวนี่คือหนึ่งในการตัดสินใจด้านการมอนิเตอร์ที่สำคัญที่สุดที่คุณทำได้

คำถามที่พบบ่อย

Heartbeat / cron-job monitoring คืออะไร?
มอนิเตอร์กลับด้าน — งานที่ตั้งเวลาไว้ของคุณจะ ping URL ของเราเมื่อสำเร็จ ถ้าไม่มีสัญญาณตามเวลาที่กำหนด เราจะแจ้งเตือน ช่วยแก้ปัญหา failure แบบเงียบ: cron ที่ล้มไม่สร้าง error และไม่มี alert แบบ uptime แบบเดิม
จะผูก URL heartbeat กับ cron ของฉันอย่างไร?
เติม curl -fsS <heartbeat_url> ต่อท้ายคำสั่ง cron ถ้าคำสั่งก่อนหน้านั้นล้ม curl จะไม่รัน และจะไม่ได้ heartbeat หรือจะ ping ทั้งตอนเริ่มต้นและจบงานแยกตาม path - จะได้สัญญาณ "started" และ "completed" แยกกัน
ควรตั้ง grace period เท่าไหร่?
ประมาณ 2-3 เท่าของเวลารันงานปกติ เช่น backup รายวันกินเวลา 30 นาที ให้ตั้ง grace เป็น 90 นาที รองรับความล่าช้าโดยไม่มี false alert งานที่ใช้เวลาผันผวน ให้กำหนดกรุณาเผื่อไว้หน่อย แล้วดู outlier เพิ่มใน dashboard
สามารถมอนิเตอร์ cron job ที่รันรายชั่วโมงได้หรือไม่?
ได้ - แค่ตั้งช่วงเวลาให้ตรง (เช่น 60 นาที + grace อีก 15 นาที) มอนิเตอร์จะรอ ping อย่างน้อยทุก 75 นาทีถ้าตารางถี่กว่านั้น (ทุก 5 นาที) URL heartbeat ก็รองรับ - ปรับช่วงเวลาให้ตรงกับงานของคุณ
heartbeat monitoring ใช้กับ AWS Lambda / serverless ได้หรือไม่?
ได้ ใส่ HTTP request ไปที่ URL heartbeat ตอนท้ายของฟังก์ชัน Lambda Monitor จะดูเหมือนกับ cron heartbeat ทุกอย่าง ทั้งแจ้งเตือนและ grace period ของเดิม เหมาะมากสำหรับ Lambdas ที่ตั้งเวลาล่วงหน้าในกรณีที่ CloudWatch alarm จับ failure เงียบ ๆ ไม่ได้

การตรวจสอบ cron job