การมอนิเตอร์และการจัดการเมื่อล้มเหลว

Webhook เป็นกลไกที่ "เวลาทำงานอยู่จะเงียบ" ด้วยเหตุนี้จึงสังเกตได้ยากว่ากำลังมีปัญหาเกิดขึ้น และเมื่อรู้ตัวก็อาจมีอีเวนต์หลุดหายไปหลายวันแล้ว การใช้งานจริงในโปรดักชันจึงขาดการมอนิเตอร์เชิงรุกไม่ได้

ประวัติการส่งในพอร์ทัลนักพัฒนา

พอร์ทัลนักพัฒนา → แอป → Webhook → เอนด์พอยต์ที่เกี่ยวข้อง → แท็บ "ประวัติการส่ง" คุณสามารถตรวจสอบผลการส่งย้อนหลัง 30 วันได้

ข้อมูลที่แสดง

• วันเวลาที่ส่ง, อีเวนต์ ID, ชนิดอีเวนต์
• สถานะล่าสุด（สำเร็จ / กำลังส่งซ้ำ / dead letter）
• HTTP status code, เวลาตอบสนอง, เรสปอนส์บอดี ของแต่ละครั้งที่ลอง（1KB แรก）
• ปุ่ม "ส่งซ้ำ"（ส่งด้วยมือได้）

การกรอง

• สถานะ（เฉพาะสำเร็จ／เฉพาะล้มเหลว／เฉพาะ dead letter）
• ชนิดอีเวนต์
• ช่วงเวลา（ย้อนหลัง 24 ชั่วโมง／7 วัน／30 วัน）
• อีเวนต์ ID／การจับคู่บางส่วนของ URL รับ

ตัวชี้วัดที่ควรมอนิเตอร์

เป็นตัวชี้วัดที่ควรเฝ้าดูอย่างน้อยที่สุดในการใช้งานจริง นอกจากดูได้ที่ "Webhook แดชบอร์ด" ของพอร์ทัลนักพัฒนาแล้ว แนะนำให้นำเข้าฐานการมอนิเตอร์ของบริษัทเองด้วย

เมตริกที่ควรเก็บไว้ที่ฝั่งรับ

นอกจากการมอนิเตอร์ฝั่งส่งแล้ว หากฝั่งรับเก็บเมตริกต่อไปนี้ด้วย จะช่วยให้ระบุสาเหตุได้เร็วขึ้น

• จำนวนที่รับ（แยกตามชนิดอีเวนต์）
• จำนวนครั้งที่ตรวจสอบลายเซ็นล้มเหลว（หากเพิ่มขึ้นอาจเป็นซีเคร็ตไม่ตรงกันหรือถูกโจมตี）
• จำนวนที่ข้ามด้วย idempotency（เกณฑ์ดูว่าการส่งซ้ำไม่เพิ่มขึ้นหรือไม่）
• ฮิสโตแกรมเวลาประมวลผล（ใกล้ไทม์เอาต์ 10 วินาทีหรือยัง）
• อัตราเออเรอร์ของการประมวลผลทางธุรกิจ（เป็นสาเหตุของลูปส่งซ้ำ）

การออกแบบปลายทางแจ้งอะเลิร์ต

ออกแบบอะเลิร์ตให้อยู่ในรูปที่ไม่ใช่แค่ "รู้ตัวได้" แต่ "จัดการได้"

• ในเวลาทำการ：แชนเนลการดำเนินงานใน Slack
• กลางคืน・วันหยุด：แจ้งไปยังผู้รับผิดชอน on-call ผ่าน PagerDuty / Opsgenie เป็นต้น
• คำเตือนระดับเบา：รวมไว้ในอีเมลสรุปรายวัน
• เกิด dead letter：แจ้งทันที + รีวิวรายสัปดาห์

การส่ง dead letter ซ้ำ

อีเวนต์ที่ล้มเหลวจากการส่งซ้ำอัตโนมัติ 7 ครั้ง จะถูกบันทึกเป็น "dead letter" หลังแก้ไขสาเหตุแล้ว สามารถส่งซ้ำได้ตามขั้นตอนต่อไปนี้

1. เลือกฟิลเตอร์ "dead letter" ในประวัติการส่ง
2. คลิกปุ่ม "ส่งซ้ำ" ทีละรายการ หรือเลือกหลายรายการแล้ว "ส่งซ้ำแบบรวม"
3. ตรวจสอบผลลัพธ์ในประวัติการส่ง

dead letter จะถูกเก็บไว้ 30 วันนับจากการส่ง เมื่อเกิน 30 วันจะหายไป จึงควรจัดการก่อนหน้านั้น หรือดึงข้อมูลย้อนหลังใหม่ผ่าน API

รูปแบบเหตุขัดข้องที่พบบ่อยและการจัดการ

1. Webhook ทั้งหมดล้มเหลวด้วย 5xx

• ตรวจสอบว่าเซิร์ฟเวอร์ฝั่งรับล่มหรือไม่
• ดีพลอยล่าสุดอาจเป็นสาเหตุ → พิจารณาโรลแบ็ก
• หลังกู้คืน "ส่งซ้ำแบบรวม" dead letter

2. ล้มเหลวเฉพาะบางชนิดอีเวนต์

• อาจมีบักในลอจิกการประมวลผลสำหรับอีเวนต์นั้น
• ตรวจสอบสแต็กเทรซจากเรสปอนส์บอดีในประวัติการส่ง
• ค้นหา event_id ที่เกี่ยวข้องในล็อกฝั่งรับ

3. 401（ตรวจสอบลายเซ็นล้มเหลว）เพิ่มขึ้น

• เพิ่งสร้างซีเคร็ตใหม่ แล้วซีเคร็ตเก่ายังทำงานอยู่หรือไม่
• environment variable สะท้อนไม่ครบ（ลืมรีสตาร์ท）
• ใช้ซีเคร็ตของโปรดักชัน／สเตจจิงสลับกันหรือไม่

4. ไทม์เอาต์บ่อย

• การประมวลผลฝั่งรับหนัก → เปลี่ยนดีไซน์เป็นโยนเข้าคิวภายใน
• DB ปลายน้ำหรือ external API หน่วง → บายพาสการประมวลผลนั้นชั่วคราว
• เอนด์พอยต์รับสเกลไม่พอ → เพิ่มจำนวนอินสแตนซ์

5. Webhook ไม่มาเลย

• เอนด์พอยต์ถูกตั้งเป็น "ปิดใช้งาน" หรือไม่
• อีเวนต์ที่สับสไครบ์ถูกเลือกไว้ถูกต้องหรือไม่
• ตัวเองถูกกันออกด้วยฟิลเตอร์ร้านค้าเป้าหมายหรือไม่
• URL รับเข้าถึงได้จากภายนอกหรือไม่（อยู่ใน VPN ภายในบริษัทหรือเปล่า）

เช็กลิสต์การบำรุงรักษาประจำ

แนะนำให้รีวิวรายการต่อไปนี้ประมาณเดือนละ 1 ครั้ง

• ☐ จำนวนและสาเหตุของ dead letter ในเดือนที่ผ่านมา
• ☐ แนวโน้มของอัตราความสำเร็จ（แย่ลงหรือไม่）
• ☐ แนวโน้มของเวลาตอบสนอง P95
• ☐ วันที่อัปเดตซีเคร็ตล่าสุด（เกณฑ์คือหมุนเวียนปีละ 1 ครั้ง）
• ☐ ลบเอนด์พอยต์ที่ไม่จำเป็นแล้ว
• ☐ จัดระเบียบอีเวนต์ที่สับสไครบ์（ยกเลิกตัวที่ไม่ได้ใช้）

การติดต่อซัพพอร์ต

หากระบุสาเหตุไม่ได้ หรือสงสัยว่าเป็นเหตุขัดข้องฝั่ง ReceiptRoller โปรดติดต่อคอมมิวนิตีนักพัฒนาหรือช่องทางซัพพอร์ต การแนบข้อมูลต่อไปนี้จะช่วยให้ดำเนินการได้รวดเร็ว

• แอป ID（ไคลเอนต์ ID）และเอนด์พอยต์ ID
• ช่วงวันเวลาที่เกิดเหตุ（ระบุ UTC หรือ JST）
• event_id ที่ได้รับผลกระทบสัก 2-3 ตัว
• เรสปอนส์โค้ดและตัวอย่างล็อกของฝั่งรับ

คู่มือที่เกี่ยวข้อง

• ภาพรวมของ Webhook
• วิธีลงทะเบียน Webhook
• การตรวจสอบลายเซ็นและความปลอดภัย
• การออกแบบการส่งซ้ำ・ลำดับ・idempotency
• โพสต์คำถามในคอมมิวนิตี
• กลับไปที่หน้าช่วยเหลือสำหรับนักพัฒนา