Sentry หรือ Datadog: ตามบั๊กในโค้ดกับเฝ้าทั้งระบบไม่ใช่งานเดียวกัน

Sentry เหมาะเมื่อการสืบสวนเริ่มจากข้อผิดพลาดในแอปและต้องย้อนถึงโค้ดที่รับผิดชอบ ส่วน Datadog เหมาะเมื่ออาการเดียวกันต้องอธิบายด้วยข้อมูลจากบริการ โฮสต์ คอนเทนเนอร์ และประสบการณ์ผู้ใช้ร่วมกัน การเปรียบเทียบของ Dash0 อธิบายจุดเน้นนี้พร้อมระบุว่าทั้งสองเครื่องมือมี error tracking และ tracing ทับซ้อนกัน คำตอบจึงขึ้นอยู่กับว่าทีมต้องเริ่มจากหลักฐานใดและต้องไล่เหตุไปถึงชั้นไหน

เมื่อเว็บชำระเงินแสดงข้อผิดพลาด ทีมพัฒนาอาจต้องรู้ว่าผู้ใช้ทำอะไรก่อนหน้าและโค้ดส่วนใดล้มเหลว Sentry วางการจัดกลุ่มข้อผิดพลาดและการส่งต่อให้ผู้แก้ไว้กลางงานสืบสวน ส่วน SRE ที่รับแจ้งว่าเว็บช้าหลายบริการพร้อมกันอาจต้องดูเวลาตอบสนอง สถานะโหนด และ log ในคลัสเตอร์ ซึ่งเป็นขอบเขตของ Datadog การใช้สองระบบพร้อมกันมีเหตุผลเมื่อทีมต้องการหลักฐานทั้งสองระดับ แต่ควรกำหนดหน้าที่และปริมาณข้อมูลที่จะส่งเข้าแต่ละระบบ

ข้อผิดพลาดในโค้ดกับอาการของระบบเริ่มสืบต่างกัน

Sentry จัดเหตุการณ์ที่คล้ายกันเป็น issue เพื่อให้ทีมเห็นความถี่ ผู้ใช้ที่ได้รับผลกระทบ stack trace และ breadcrumbs ที่เกิดก่อนข้อผิดพลาด หากผูกข้อมูล release ไว้ ทีมจะแยกได้ว่าเหตุปรากฏในรุ่นใด และหากเตรียม source map สำหรับ JavaScript ที่ย่อไฟล์แล้ว บรรทัดใน trace จะมีความหมายต่อผู้แก้มากขึ้น การเห็นบรรทัดที่โยน exception ยังไม่เท่ากับรู้ต้นเหตุ เพราะสถานะของผู้ใช้หรือคำตอบจากบริการอื่นอาจเป็นตัวกระตุ้น

กรณีเครื่องเล่นเสียงของ Syntax.fm แสดงข้อจำกัดนี้ชัดเจน บันทึกการสืบสวนของ Sentry เล่าว่า stack trace ให้บริบทน้อย แต่ Session Replay แสดงลำดับการกดลิงก์เวลาในรายการแล้วกดหยุดเสียงก่อนที่ไฟล์เสียงจะโหลด ทีมจึงพบเงื่อนไขในขั้นตอนเริ่มเล่นที่ต้องแก้ คุณค่าของ replay ในกรณีนี้อยู่ที่การเห็นการกระทำซึ่งข้อมูลข้อผิดพลาดอย่างเดียวอธิบายไม่ได้

Issue ยังช่วยแยกงานแก้ที่คล้ายกันออกจากเหตุการณ์ดิบจำนวนมาก แต่การจัดกลุ่มต้องอ่านควบคู่กับบริบท หากข้อความ error เดียวกันเกิดจากผู้ใช้คนละกลุ่มหรือหลังการเปลี่ยนโค้ดคนละส่วน ทีมอาจต้องแยกสาเหตุก่อนมอบหมายเจ้าของ การดูเฉพาะจำนวนครั้งที่เกิดก็อาจทำให้บั๊กที่กระทบผู้ใช้จำนวนน้อยแต่ขัดขวางการชำระเงินถูกจัดลำดับต่ำเกินไป

Datadog เริ่มจากอาการได้หลายทาง: อัตราข้อผิดพลาดของบริการสูงขึ้น เวลาตอบสนองเพิ่ม ปริมาณ log เปลี่ยน หรือทรัพยากรของเครื่องตึงตัว APM ช่วยตามคำขอที่ข้ามบริการ ส่วน Infrastructure Monitoring ช่วยอธิบายเครื่องและคอนเทนเนอร์ที่รันบริการนั้น Datadog มี Error Tracking สำหรับข้อผิดพลาดระดับแอปด้วย ทีมจึงควรดูว่าเวิร์กโฟลว์จัดกลุ่มและมอบหมายบั๊กที่มีอยู่ตอบงานจริงได้เพียงใดก่อนเพิ่ม Sentry อีกระบบ

เมื่อเกิดเหตุ หลักฐานชิ้นไหนตอบคำถามได้

เหตุการณ์ต่อไปนี้เป็นสถานการณ์สมมติสำหรับแยกคำถาม ไม่ใช่ผลการทดสอบบริการ การมองเห็นแต่ละสัญญาณขึ้นกับ SDK, agent, sampling การตั้งค่าเก็บข้อมูล และผลิตภัณฑ์ที่เปิดใช้ จึงควรเริ่มจากคำถามที่ผู้รับผิดชอบเหตุต้องตอบ แล้วค่อยดูว่าหลักฐานที่จำเป็นถูกส่งไปที่ใด

• หน้าเว็บชำระเงินแสดงข้อผิดพลาดหลังคลิก: จุดเริ่มของผู้แก้โค้ดคือ issue, stack trace และ breadcrumbs ใน Sentry ถ้าเก็บ replay ของเซสชันที่เกิดเหตุไว้ ลำดับการกระทำอาจช่วยแยกข้อผิดพลาดในหน้าจอออกจากคำตอบผิดพลาดของ API ได้ Datadog RUM และ Error Tracking ก็รับหลักฐานฝั่งผู้ใช้ได้ หากผูกข้อมูลกับ APM แล้ว ทีมอาจตามต่อว่าคำขอสะดุดในบริการหลังบ้านใด
• คำขอสำเร็จแต่ช้าผิดปกติ: การไม่มี exception ทำให้ issue เพียงอย่างเดียวไม่ตอบโจทย์ ทั้ง Sentry tracing และ Datadog APM ช่วยแยกเวลาที่ใช้ในแต่ละ span เช่น งานในแอปหรือการเรียกฐานข้อมูล หากหลายบริการช้าพร้อมกัน ค่าทรัพยากรของโฮสต์และความสัมพันธ์ระหว่างบริการจะช่วยคัดสาเหตุระดับระบบ
• ข้อผิดพลาดกลับมาหลังปล่อยรุ่น: ทีมพัฒนาต้องเทียบ issue กับ release และดูว่าผู้ใช้กลุ่มใดพบอาการ ไม่ควรสรุปจากเวลาเกิดเหตุอย่างเดียวว่าการปล่อยรุ่นเป็นสาเหตุ Sentry ทำให้ข้อมูลรุ่นอยู่ใกล้งานจัดการ issue ส่วน Datadog ช่วยดูความเปลี่ยนแปลงของอัตราผิดพลาดและเวลาตอบสนองในบริการที่เกี่ยวข้อง หากมีการส่งข้อมูลเหล่านั้นเข้าแพลตฟอร์ม
• พ็อด Kubernetes เริ่มใหม่และหลายบริการสะดุด: คำถามย้ายไปที่สถานะพ็อด โหนด และการใช้ทรัพยากร ความสามารถ Kubernetes ของ Datadog ครอบคลุมข้อมูลพ็อดกับโหนดและการดู metrics, traces, logs ในบริบทเดียวกัน Sentry อาจแสดง exception ที่ตามมา แต่ข้อมูลนั้นลำพังยังไม่บอกว่าสภาพโหนดหรือการจัดตารางงานเกี่ยวข้องกับเหตุอย่างไร

การจับคู่สัญญาณกับเหตุช่วยแยกสิ่งที่เครื่องมือเห็นออกจากสิ่งที่ทีมต้องพิสูจน์ ตัวอย่างเช่น การพบ exception หลังพ็อดเริ่มใหม่บอกลำดับเวลา แต่ยังไม่พิสูจน์ว่าพ็อดเป็นสาเหตุของข้อผิดพลาด ทีมต้องดูเหตุการณ์ของคลัสเตอร์และ trace ของคำขอเดียวกันประกอบ ในทางกลับกัน การเห็น CPU สูงบนโหนดไม่ได้บอกว่าผู้ใช้กดอะไรจนหน้าชำระเงินล้มเหลว

ทั้งสองฝั่งอาจแสดง trace ของคำขอเดียวกัน แต่ Sentry ใช้ข้อมูลนั้นพาผู้แก้เข้าใกล้ issue ขณะที่ Datadog ผูก trace กับสัญญาณของบริการและโครงสร้างพื้นฐาน หากทีมมีระบบ metrics ของคลัสเตอร์อยู่แล้วและปัญหาหลักคือจัดการบั๊กหน้าเว็บช้า ความกว้างของแพลตฟอร์มอาจไม่ใช่ประโยชน์ที่ต้องซื้อเพิ่ม หากเหตุสำคัญมักเริ่มในโหนดหรือบริการภายนอก การมี issue ของแอปอย่างเดียวก็ยังทิ้งคำถามต้นเหตุไว้

ราคาต้องแยกตามหน่วยที่บริการนับจริง

หน่วย tracing ของ Sentry ต้องแยกจากจำนวนคำขอ คำอธิบายแผน Developer เดิมของ Sentry ระบุว่าการวัดโควตา tracing เปลี่ยนจาก transactions รายเดือนเป็น spans รายเดือน โดยแผนยังฟรีและโควตา errors, replays, attachments, cron monitors และ uptime monitors ไม่เปลี่ยน การเปลี่ยนนี้เกี่ยวกับแผน Developer เดิมที่ถูกย้ายไปแผนปัจจุบัน คำขอที่ผ่านงานย่อยหลายจุดอาจสร้างหลาย spans จึงต้องวัดปริมาณที่ส่งจริงหลังตั้ง sampling

หน้าราคาของ Datadog แสดง Infrastructure Pro เริ่มที่ 15 ดอลลาร์ต่อโฮสต์ต่อเดือน และ APM เริ่มที่ 31 ดอลลาร์ต่อ APM host ต่อเดือนเมื่อใช้ร่วมกับ Infrastructure Monitoring โดยเป็นราคาเริ่มต้นแบบชำระรายปี ขณะที่ log ingestion อยู่ที่ 0.10 ดอลลาร์ต่อ GB และ Standard Indexing ที่เก็บ 15 วันอยู่ที่ 1.70 ดอลลาร์ต่อหนึ่งล้านเหตุการณ์ หน้าเดียวกันแยก RUM Measure, RUM Investigate และ Session Replay เป็นรายการที่นับ sessions ราคาเหล่านี้เป็นราคาประกาศของแต่ละผลิตภัณฑ์ ไม่ใช่ยอดรวมของชุดใช้งานหรือราคาในสัญญาของทุกทีม

APM ของ Datadog เริ่มจากโฮสต์ที่ส่ง trace แต่มีปริมาณ ingested spans และ indexed spans รวมตามจำนวน APM hosts ด้วย การส่งข้อมูลเข้าเพื่อดูชั่วคราวกับการเลือกเก็บให้ค้นย้อนหลังเป็นคนละขั้น หากทีมส่ง trace จำนวนมากแต่เก็บค้นย้อนหลังเพียงบางส่วน ต้นทุนส่วนเกินและความสามารถในการสืบเหตุภายหลังจะเปลี่ยนไปพร้อมกัน ยอด spans ทั้งหมดจึงยังไม่พอสำหรับประมาณค่า APM: ต้องรู้ขนาดข้อมูลที่รับเข้า สัดส่วนที่ถูก index และระยะเก็บด้วย

สำหรับ Kubernetes โฮสต์ที่เฝ้าระวังคือโหนด ไม่ใช่จำนวนพ็อดทั้งหมด แต่คอนเทนเนอร์ที่เกินสิทธิ์รวมในแผนอาจมีมาตรวัดเพิ่ม APM host คือโฮสต์ที่สร้างและส่ง trace จริง จึงอาจเป็นเพียงบางส่วนของ infra hosts การขยายคลัสเตอร์อาจเพิ่มจำนวนโฮสต์ที่คิดเงินแม้จำนวนผู้ใช้ไม่เปลี่ยน ส่วนการเปิด debug logging อาจเพิ่มทั้งปริมาณ GB ที่รับเข้าและจำนวนเหตุการณ์ที่เก็บค้นย้อนหลัง

คนหนึ่งคนไม่เท่ากับหนึ่ง RUM session เพราะผู้ใช้เดิมอาจกลับมาเริ่มรอบใหม่ ในโครงสร้างราคาที่ Datadog แสดง RUM Measure ใช้วัดเซสชันที่ส่งเข้า ส่วน RUM Investigate เก็บเซสชันที่ผ่านตัวกรองเพื่อสืบย้อนหลัง และ Session Replay มีมาตรวัดแยก ทีมที่ต้องการ replay เฉพาะเหตุผิดพลาดจึงต้องคำนวณจำนวนเซสชันทั้งหมด จำนวนที่เก็บเพื่อสืบ และจำนวนที่มี replay แทนการนำยอดผู้เข้าชมเว็บมาแทนทุกหน่วย

ความเสี่ยงด้านงบไม่ได้มาจากการใช้งานเพิ่มเพียงทางเดียว อัตราการสุ่ม trace ที่สูงขึ้นทำให้หลักฐานละเอียดขึ้นพร้อมกับปริมาณ spans ที่มากขึ้น การขยายระยะเก็บช่วยให้ย้อนสืบเหตุเก่าได้แต่เพิ่มปริมาณข้อมูลที่คิดเงิน และการลด log มากเกินไปอาจทำให้พบอาการโดยไม่มีข้อความอธิบายช่วงเกิดเหตุ การตัดสินใจเรื่อง sampling และ retention จึงเป็นการเลือกระดับหลักฐานด้วย ไม่ใช่การปรับตัวเลขในใบเสนอราคาอย่างเดียว

แม่แบบประมาณ spans, logs, hosts และ sessions

เริ่มจากปริมาณใช้งานของระบบจริงและทำสองกรณี คือวันปกติกับวันที่ทราฟฟิกพุ่ง การเอาตัวเลขวันสงบไปคูณทั้งเดือนจะมองไม่เห็นค่า telemetry จากวันปล่อยรุ่นหรือช่วงแคมเปญ ส่วนการเอาวันหนักที่สุดไปคูณทั้งเดือนก็อาจประเมินเกินจริง ให้แยกปริมาณที่สร้าง ปริมาณที่ส่งเข้า และปริมาณที่เก็บค้นย้อนหลัง แล้วจับแต่ละส่วนกับโควตาของแผนที่พิจารณา

Spans: จำนวนคำขอต่อวัน × spans เฉลี่ยต่อคำขอ × สัดส่วนที่ส่ง × จำนวนวัน เป็นประมาณการ tracing ของ Sentry ในตัวอย่างสมมติ หากมี 300,000 คำขอต่อวัน คำขอละ 4 spans ส่ง 20% เป็นเวลา 30 วัน ผลคือ 7.2 ล้าน spans ต้องรวมงานคิวหรือเบื้องหลังด้วยหากทีม instrument งานเหล่านั้น สำหรับ Datadog ให้เติมขนาดเฉลี่ยของ span เพื่อประมาณ GB ที่รับเข้า แล้วแยกสัดส่วน indexed spans อีกบรรทัด เพราะข้อมูลที่ส่งกับข้อมูลที่ค้นย้อนหลังได้ไม่ใช่ก้อนเดียวกัน

ค่าเฉลี่ย spans ต่อคำขอควรมาจากเส้นทางที่แอปใช้จริง คำขออ่านข้อมูลสั้น ๆ กับคำขอชำระเงินที่ผ่านหลายบริการอาจสร้างจำนวนงานย่อยต่างกันมาก หากใช้ค่าเฉลี่ยรวมเพียงค่าเดียว ให้ดูด้วยว่าคำขอชนิดใดสร้างข้อมูลส่วนใหญ่ มิฉะนั้นการสุ่มในอัตราเดียวกันทุกเส้นทางอาจเก็บคำขอทั่วไปมาก แต่เหลือหลักฐานของธุรกรรมสำคัญน้อยเกินไป

Logs: จำนวนเหตุการณ์ต่อวัน × ขนาดเฉลี่ยต่อเหตุการณ์ × จำนวนวัน ให้ปริมาณก่อนตัวกรอง สมมติระบบสร้าง 2 ล้านเหตุการณ์ต่อวัน เหตุการณ์ละ 1 KB เป็นเวลา 30 วัน จะได้ราว 60 GB ในหน่วยฐานสิบ จากนั้นแยก log ที่ส่งเข้าออกจาก log ที่ถูก index ตามระยะเก็บที่ต้องการ การดูเฉพาะ GB แล้วลืมจำนวนเหตุการณ์อาจทำให้ประเมินผิด เพราะข้อความสั้นจำนวนมากใช้พื้นที่รับเข้าไม่สูงนักแต่เพิ่มจำนวนรายการที่ต้องเก็บค้น

การวัด log ควรแยกตามบริการและระดับความรุนแรงด้วย บริการที่เขียนข้อความซ้ำทุกครั้งที่ retry อาจเป็นแหล่งปริมาณหลักในวันที่ระบบมีปัญหา หากทีมลดข้อมูลส่วนนี้โดยไม่มีตัวระบุคำขอหรือเวลาที่ชัด การประหยัดค่าเก็บอาจทำให้เชื่อม log เข้ากับ trace ไม่ได้ ตรงกันข้าม log รายละเอียดที่ไม่ช่วยแยกสาเหตุอาจตัดก่อนส่งเข้าได้โดยไม่ลดคุณภาพการสืบสวน

Hosts: จดจำนวน infra hosts และ APM hosts แยกกันตามชั่วโมง ไม่ใช่จดจำนวนเครื่องในภาพรวมเพียงครั้งเดียว ในตัวอย่างสมมติ คลัสเตอร์มี 12 โหนดตามปกติและขยายเป็น 24 โหนดช่วงทราฟฟิกสูง ให้ระบุว่าช่วงขยายกินเวลากี่ชั่วโมงและโหนดใดส่ง trace ด้วย ตัวเลขนี้ช่วยแยกผลของ autoscaling ต่อ Infrastructure Monitoring และ APM ก่อนดูเงื่อนไขการคิดเฉลี่ยหรือการใช้เกินสัญญา ไม่ควรคูณจำนวนสูงสุดด้วยราคาต่อเดือนแล้วเรียกเป็นใบแจ้งหนี้ เพราะวิธีคิดขึ้นกับแผนและสัญญา

ในตัวอย่างสมมติอีกแบบ หากเฝ้า infra hosts 12 เครื่อง และมีเพียง 8 เครื่องที่ส่ง trace การใช้ราคาเริ่มต้นแบบรายปีข้างต้นจะได้ค่าฐาน 12 × 15 บวก 8 × 31 เท่ากับ 428 ดอลลาร์ต่อเดือนก่อน logs, RUM และส่วนเกินอื่น ผลคำนวณนี้ช่วยให้เห็นว่าจำนวน infra hosts กับ APM hosts ไม่จำเป็นต้องเท่ากัน และไม่ควรถูกนำไปคูณด้วยราคา APM ทั้งคู่

Sessions: ใช้จำนวนรอบการใช้งานที่ SDK นับจริง ไม่ใช่จำนวนบัญชีผู้ใช้ สมมติมี 50,000 เซสชันที่ส่งเข้า RUM และตัวกรองเก็บ 25% ไว้ Investigate จะมี 12,500 เซสชันให้สืบย้อนหลัง หากเปิด Replay เพียงบางส่วน ให้คูณอัตราเก็บ replay แยกอีกชั้น อย่าลดจำนวนที่อยู่ใน RUM Measure ลงเหลือ 12,500 ตามตัวกรอง Investigate เพราะการวัดภาพรวมกับการเก็บเซสชันเพื่อสืบย้อนหลังใช้คนละมาตรวัด

เมื่อรวมการประมาณทั้งสี่หน่วย ให้ใส่โควตาที่รวมในแผน อัตราเมื่อเกินโควตา และระยะเก็บไว้ข้างปริมาณประเภทเดียวกัน หากทราฟฟิกเพิ่มโดย sampling คงเดิม spans กับ sessions มีแนวโน้มเพิ่มตามการใช้งาน ส่วน hosts อาจเพิ่มเป็นขั้นเมื่อระบบขยายโหนด ขณะที่ logs อาจกระโดดจากการเปลี่ยนระดับบันทึกแม้ทราฟฟิกคงเดิม การแยกตัวขับต้นทุนเช่นนี้ช่วยให้ลดข้อมูลที่ไม่จำเป็นโดยยังเก็บหลักฐานของเหตุที่ทีมพบจริง

เลือกเครื่องมือเดียวหรือใช้คู่กันอย่างไร

ถ้างานที่กินเวลาทีมส่วนใหญ่คือแยกกลุ่มข้อผิดพลาด หาโค้ดต้นเหตุ ผูกกับ release แล้วส่งให้ผู้พัฒนาแก้ Sentry เป็นแกนที่ตรงกับกระบวนการนั้น โดยเฉพาะเมื่อมีระบบเฝ้าโครงสร้างพื้นฐานอื่นอยู่แล้ว ถ้าเหตุสำคัญมักเริ่มจาก latency ของหลายบริการ สถานะคลัสเตอร์ หรือ log ที่ไม่ได้มาจากแอป Datadog มีขอบเขตให้ SRE ไล่สัญญาณหลายชั้นในแพลตฟอร์มเดียว การตัดสินใจควรยึดเหตุที่ต้องสืบจริงและข้อมูลที่ต้องเก็บเพื่อปิดเหตุ

หากใช้ทั้งสอง ให้กำหนดว่า issue และเจ้าของบั๊กแอปอยู่ที่ใด ส่วนสัญญาณของบริการกับโครงสร้างพื้นฐานอยู่ที่ใด จากนั้นระบุจุดเชื่อมด้วยรหัสคำขอหรือ trace context ที่ส่งต่อระหว่างบริการ เพื่อให้เหตุในหน้าเว็บตามไปถึงบริการหลังบ้านได้โดยไม่เดาจากเวลาอย่างเดียว เลือกด้วยว่า trace และ replay ชุดใดจำเป็นต้องส่งเข้าทั้งคู่ เพราะการเก็บซ้ำเพิ่มค่าใช้จ่ายและอาจสร้างการแจ้งเตือนสองทางสำหรับเหตุเดียวกัน

ทีมที่มีงบจำกัดควรดูคำถามที่ทำให้การสืบสวนติดขัดบ่อยที่สุด หากบั๊กหน้าเว็บมีหลักฐานไม่พอ การเก็บ issue, breadcrumbs และ replay เฉพาะเหตุสำคัญอาจตอบโจทย์กว่าเปิดทุกสัญญาณเต็มปริมาณ หากข้อผิดพลาดในแอปมักเป็นปลายทางของปัญหา Kubernetes การเห็นโหนด พ็อด และ trace ของบริการย่อมมีประโยชน์ต่อการหาต้นเหตุมากกว่าเพิ่มจำนวน error events ที่เก็บไว้ การเลือกที่คุ้มค่าคือเลือกหลักฐานให้ตรงกับเหตุ พร้อมรู้ว่าหลักฐานแต่ละชิ้นถูกนับเงินอย่างไร

อ่านเพิ่มเติม:

• Grafana Cloud หรือ Datadog: ถูกกว่าสามเท่าอาจต้องแลกเวลาดูแล