Dashboard ผลตอบแทนเพียงอย่างเดียวไม่บอกว่าระบบแข็งแรงหรือไม่ Monitoring ที่ใช้งานได้ต้องเห็นทั้งสุขภาพซอฟต์แวร์ คุณภาพการส่งคำสั่ง ขอบเขตความเสี่ยง และทรัพยากรของ VPS ก่อนปัญหาจะขยายตัว
สี่ชั้นของ Monitoring
ชั้น strategy ดู signal และ state ชั้น execution ดู order, fill, rejection และ latency ชั้น risk ดู exposure/drawdown/limit และชั้น infrastructure ดู CPU, RAM, disk, network และ process heartbeat
กำหนด metric จาก failure mode ไม่ใช่จากสิ่งที่เก็บง่าย เช่น หากกลัว bot ค้าง ควรมี heartbeat และ last market event แทนการดูเพียงว่า process ยังเปิดอยู่
Alert ที่นำไปปฏิบัติได้
ทุก alert ควรบอก severity, เวลา, environment, ระบบที่ได้รับผล และขั้นตอนแรก หลีกเลี่ยง alert ถี่จนทีมเพิกเฉย ใช้ deduplication และ escalation เมื่อไม่มีผู้รับทราบ
เหตุวิกฤต เช่น position limit เกินหรือ state ไม่ตรง broker ควรเชื่อมกับมาตรการหยุดที่กำหนดไว้ ส่วน warning เช่น disk ใกล้เต็มอาจมีเวลาจัดการมากกว่า
Log และ Incident Review
ใช้ structured log พร้อม correlation ID ของ signal/order และเก็บตามระยะเวลาที่เหมาะสม ปกป้องข้อมูลบัญชีและ credential ทำ snapshot config เพื่อย้อนว่าเหตุการณ์เกิดกับเวอร์ชันใด
หลัง incident ให้จัด timeline, impact, root cause และ corrective action โดยไม่แก้เฉพาะอาการ การเฝ้าระวังช่วยลดเวลาตรวจพบ แต่ไม่รับประกันว่าระบบหรือผลลัพธ์จะเป็นไปตามคาด