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

งานศึกษาของ Mert Öztürk ประเมินจากการจำลองว่า Grafana Cloud มีค่าบริการรายเดือนราวหนึ่งในสามของ Datadog สำหรับกรณีที่ศึกษา แต่ทีมที่ทดลองส่งข้อมูลเข้า Grafana Cloud พบปัญหาในการตั้งค่า OpenTelemetry Collector ด้วย ตัวเลขนี้เป็นการประมาณค่าบริการของกรณีนั้น ส่วนปัญหา Collector เป็นสิ่งที่พบระหว่างทดลองใช้งาน ไม่ใช่ผลวัดชั่วโมงดูแลของบริการทั้งสอง
คำตอบเรื่องความคุ้มค่าจึงมีสองชั้น: Grafana Cloud อาจมีค่าบริการต่ำกว่าอย่างมากเมื่อเทียบขอบเขตข้อมูลที่ต้องการจริง แต่ Datadog อาจมีต้นทุนรวมต่ำกว่าสำหรับทีมที่ใช้เครื่องมือของตนแล้วลดงานติดตั้งและดูแลได้มากพอ การเปรียบเทียบต้องนับ metrics, logs และ traces พร้อมระยะเก็บข้อมูล แล้วบวกค่าแรงครั้งแรกและชั่วโมงดูแลรายเดือนของแต่ละทางเลือก
ราคาเริ่มต้นรวมข้อมูลอะไรไว้บ้าง
ตารางราคา Grafana Cloud ระบุว่าแผน Free เก็บ metrics, logs, traces และ profiles ได้ 14 วันภายใต้ขีดจำกัดการใช้งาน ส่วน Pro เริ่มที่ 19 ดอลลาร์ต่อเดือนบวกการใช้งาน โดยรวม 10,000 active series สำหรับ metrics และข้อมูลที่รับเข้าอย่างละ 50 GB สำหรับ logs และ traces ระยะเก็บพื้นฐานของ Pro คือ 13 เดือนสำหรับ metrics และ 30 วันสำหรับ logs กับ traces ค่ารายเดือนเริ่มต้นจึงไม่ใช่ราคาคงที่เมื่อปริมาณข้อมูลเกินสิทธิ์ที่รวมไว้
หน้าเดียวกันแสดงราคาเริ่มต้นของ metrics ส่วนเกินที่ 6.50 ดอลลาร์ต่อ 1,000 series ส่วน logs และ traces แยกอัตรา process 0.05 ดอลลาร์, write 0.40 ดอลลาร์ และ retain 0.10 ดอลลาร์ต่อ GB ชื่อรายการเหล่านี้สำคัญกว่าการเห็นเพียงราคาต่อ GB เพราะข้อมูลที่รับเข้า ข้อมูลที่เขียนเก็บ และระยะเวลาที่เก็บอาจมีปริมาณต่างกัน การเก็บตามระยะพื้นฐานกับการขยายเวลาเก็บจึงไม่ควรถูกคิดเป็นกรณีเดียวกัน
ตารางราคา Datadog แยกรายการตามผลิตภัณฑ์และหน่วยคิดเงิน: อัตรารายเดือนแบบจ่ายรายเดือนของ Infrastructure Pro คือ 18 ดอลลาร์ต่อ host, APM คือ 36 ดอลลาร์ต่อ host, logs ingestion คือ 0.10 ดอลลาร์ต่อ GB และ indexed logs ที่เก็บ 15 วันคือ 2.04 ดอลลาร์ต่อหนึ่งล้านรายการ ตารางเดียวกันมี Managed Platform OTLP ที่ 0.50 ดอลลาร์ต่อ GB ของ spans ที่รับเข้า ซึ่งเป็นรายการสำหรับช่องทางนั้นโดยเฉพาะ ไม่ใช่อัตรารวมของ traces ทุกแบบ
Datadog ยังแสดงราคาแบบสัญญารายปีและแบบจ่ายตามการใช้ควบคู่กับราคาแบบจ่ายรายเดือน การนำราคาสัญญารายปีของฝั่งหนึ่งไปเทียบกับราคาจ่ายรายเดือนของอีกฝั่งจะทำให้ส่วนต่างผิดตั้งแต่ต้น เช่นเดียวกับการนำค่า logs ingestion ไปแทนค่า logs ที่ต้องทำดัชนีค้นย้อนหลัง ทีมที่ต้องใช้ APM ควบกับการค้น logs จึงต้องรวมหมวดที่เปิดใช้จริง แทนการเลือกเลขต่ำสุดจากแต่ละหน้าราคา
จำนวน metrics เท่ากันทำไมจ่ายไม่เท่ากัน
คำอธิบายการคิดเงิน metrics ของ Grafana ระบุว่าระบบดูทั้ง active series และจำนวนจุดข้อมูลต่อนาที หรือ DPM โดยใช้ค่าที่เปอร์เซ็นไทล์ 95 ของรอบบิล แผน Pro รวมความถี่พื้นฐาน 1 จุดต่อนาทีต่อ series; การเก็บทุก 60 วินาทีจึงต่างจากการเก็บทุก 15 วินาทีซึ่งส่ง 4 จุดต่อนาทีต่อ series หากส่งถี่ขึ้น ปริมาณที่ใช้คิดเงินอาจสูงขึ้นแม้จำนวนชื่อ metric และจำนวนเครื่องไม่เปลี่ยน
คำว่า series ยังหมายถึงชุดค่าที่แยกตาม label ไม่ใช่เพียงชื่อ metric หากเพิ่ม label ที่มีค่าหลากหลาย เช่น รหัสปลายทางหรือรหัสคำขอ จำนวน series อาจเพิ่มเร็วกว่าเครื่องที่ติดตั้งหลายเท่า ข้อมูลที่ละเอียดขึ้นอาจช่วยสืบหาปัญหา แต่ต้องแลกกับปริมาณที่จัดเก็บและความถี่ที่ส่ง จึงต้องดู metric พร้อมชุด label ที่ใช้งานจริงก่อนตีราคา
ฝั่ง Datadog มีทั้งค่าต่อ host และหมวด custom metrics แยกต่างหาก ทำให้จำนวนเครื่องอย่างเดียวอธิบายบิลทั้งหมดไม่ได้ การเทียบที่มีความหมายควรเริ่มจากคำถามที่ต้องตอบ เช่น บริการใดช้า จุดใดมีข้อผิดพลาด และต้องเจาะรายละเอียดระดับใด แล้วจึงจับคู่ metric และหน่วยคิดเงินของแต่ละบริการ หากฝั่งหนึ่งเก็บรายละเอียดทุกเส้นทาง แต่อีกฝั่งเก็บเฉพาะภาพรวม ตัวเลขค่าบริการที่ต่างกันย่อมสะท้อนขอบเขตการมองเห็นที่ต่างกันด้วย
Logs และ traces มีต้นทุนซ่อนอยู่ตรงขั้นใด
คำอธิบายราคา logs ของ Grafana แยกข้อมูลที่รับมาประมวลผลออกจากข้อมูลที่เขียนเก็บหลังการลดข้อมูล สิทธิ์ข้อมูลฟรี 50 GB ใช้ก่อนคิดค่าปริมาณที่เขียนเก็บ ส่วนการเก็บนานกว่าระยะพื้นฐานคิดเพิ่มตามช่วงเวลา เอกสารยังระบุว่า logs มีเงื่อนไขปริมาณการค้น โดยให้ค้นได้ถึง 100 เท่าของปริมาณที่เขียนเก็บต่อเดือนก่อนคิดส่วนเกิน
ความต่างระหว่างข้อมูลที่รับเข้ากับข้อมูลที่เขียนเก็บทำให้การกรองมีผลต่อบิลคนละจุด หากส่ง logs ทั้งหมดเข้าบริการแล้วค่อยตัดทิ้ง ค่าประมวลผลยังผูกกับข้อมูลที่มาถึง แม้ค่าการเขียนเก็บจะลดลง หากกรองก่อนส่ง ปริมาณที่เข้าบริการย่อมลดลงด้วย แต่ทีมต้องรับผิดชอบกฎกรองและตรวจว่าข้อมูลสำคัญต่อการสืบหาปัญหายังอยู่ การประหยัดพื้นที่เก็บจึงอาจเพิ่มงานดูแลเส้นทางข้อมูล
สำหรับ traces ต้องแยก spans ที่รับเข้าจากส่วนที่เลือกเขียนเก็บ และกำหนดระยะเวลาที่ต้องการค้นย้อนหลัง การสุ่มเก็บช่วยลดปริมาณได้ แต่หากตัดเส้นทางคำขอที่ล้มเหลวหรือช้าผิดปกติออกไป ต้นทุนที่ลดลงจะมาพร้อมความสามารถสืบหาสาเหตุที่ลดลง การเทียบราคาให้ยุติธรรมต้องระบุทั้งสัดส่วนที่เก็บและช่วงเวลาที่ค้นได้ ไม่ใช่เทียบ GB ที่รับเข้าเพียงบรรทัดเดียว
เครื่องคำนวณตัวอย่าง: จากค่าบริการถึงค่าแรง
สมมติให้ทีมหนึ่งส่ง metrics 12,000 active series ที่ความถี่ 1 จุดต่อนาที ส่ง logs 200 GB และ traces 80 GB ต่อเดือน ไม่มีการกรองหลังรับเข้า และเก็บ logs กับ traces ตามระยะพื้นฐานของ Pro เท่านั้น ตัวเลข workload นี้เป็นตัวอย่างสมมติ ไม่ใช่ข้อมูลขององค์กรในงานศึกษาหรือใบเสนอราคาจากผู้ขาย เป้าหมายคือเห็นว่ารายการข้อมูลแต่ละชนิดและชั่วโมงทำงานส่งผลต่อคำตอบอย่างไร
เมื่อนำอัตรา Grafana Cloud ข้างต้นมาคิดแบบง่าย ส่วน metrics ที่เกินสิทธิ์คือ 2,000 series คิดเป็น 13 ดอลลาร์ต่อเดือน สำหรับ logs สมมติให้คิด process กับ 200 GB ที่รับเข้า และ write เฉพาะ 150 GB หลังหักสิทธิ์รวม จึงได้ 10 บวก 60 เท่ากับ 70 ดอลลาร์ สำหรับ traces ใช้วิธีเดียวกันกับ 80 GB ที่รับเข้าและ 30 GB ที่เขียนเกินสิทธิ์ ได้ 4 บวก 12 เท่ากับ 16 ดอลลาร์
รวมค่าบริการแพลตฟอร์ม 19 ดอลลาร์แล้ว ตัวอย่างเลขคณิตนี้ได้ 118 ดอลลาร์ต่อเดือน ภายใต้สมมติฐานที่ระบุไว้ ไม่มีค่าเก็บนานเกินระยะพื้นฐานและไม่มีค่า logs query ส่วนเกิน ตัวเลขจริงอาจต่างออกไปตามการลดข้อมูล สิทธิ์ที่ใช้ได้ เงื่อนไขปริมาณสูง และผลิตภัณฑ์อื่นที่เปิดใช้ จึงไม่ควรใช้ 118 ดอลลาร์เป็นใบเสนอราคาสำหรับระบบที่ยังไม่ทราบรูปแบบการใช้งาน
เพื่อทดสอบผลของค่าแรง สมมติอีกชั้นว่า Datadog สำหรับขอบเขตที่เทียบกันได้มีค่าบริการ 354 ดอลลาร์ต่อเดือน หรือสามเท่าของฐาน 118 ดอลลาร์ ตัวเลข 354 ดอลลาร์เป็นตัวแปรสมมติสำหรับเครื่องคำนวณ ไม่ใช่ราคาที่ Datadog เสนอให้ workload นี้ ส่วนต่างค่าบริการจึงเท่ากับ 236 ดอลลาร์ต่อเดือน
หากต้นทุนเวลาวิศวกรอยู่ที่ 25 ดอลลาร์ต่อชั่วโมง ส่วนต่าง 236 ดอลลาร์จะหมดไปเมื่อ Grafana Cloud ต้องใช้เวลาดูแลมากกว่า Datadog ราว 9.4 ชั่วโมงต่อเดือน สมมติว่า Grafana Cloud ใช้ 18 ชั่วโมงและ Datadog ใช้ 4 ชั่วโมง ต้นทุนรวมจะเป็น 568 ดอลลาร์เทียบกับ 454 ดอลลาร์ตามลำดับ กรณีนี้บริการที่มีค่าบริการต่ำกว่าจะมีต้นทุนรวมสูงกว่าเพราะชั่วโมงส่วนต่าง ไม่ใช่เพราะอัตราค่าแรงที่สูงขึ้นเอง
สำหรับทีมในไทย ให้แทนค่าแรงสมมติด้วยต้นทุนพนักงานต่อชั่วโมงที่องค์กรใช้จริง และแปลงค่าบริการดอลลาร์ด้วยอัตราแลกเปลี่ยนเดียวกันทั้งสองฝั่ง ชั่วโมงที่นำมาคิดควรเป็นเวลาที่เพิ่มขึ้นเพราะเลือกบริการนั้น เช่น งานแก้ collector หรือย้ายกฎแจ้งเตือน ไม่ใช่เวลาสืบหาปัญหาของแอปที่ต้องทำอยู่แล้วไม่ว่าเลือกบริการใด การแยกเช่นนี้ช่วยไม่ให้ค่าแรงถูกนับซ้ำและทำให้จุดคุ้มทุนมีความหมาย
ชั่วโมงดูแลเกิดจากอะไร และควรนับช่วงใด
Grafana Cloud ดูแลบริการจัดเก็บให้ แต่เส้นทางก่อนข้อมูลถึงบริการยังมีงานของทีม ตั้งแต่ติดตั้งตัวรับข้อมูล กำหนด label และกฎกรอง เลือกวิธีสุ่ม traces ไปจนถึงปรับ dashboard และการแจ้งเตือนเมื่อแอปเปลี่ยน ทีมที่คุ้นกับ OpenTelemetry อยู่แล้วอาจทำงานเหล่านี้ในรอบพัฒนาปกติ ส่วนทีมที่ไม่มีผู้รับผิดชอบชัดเจนอาจต้องดึงนักพัฒนาออกจากงานผลิตภัณฑ์ทุกครั้งที่ข้อมูลหายหรือความหมายของ metric เปลี่ยน
การเลือก Datadog ก็ยังต้องกำหนดจุดติดตั้ง agent เลือกหมวดบริการ และควบคุมว่าข้อมูลใดจะถูกทำดัชนีหรือเก็บเป็น trace ข้อได้เปรียบที่ต้องประเมินคือเครื่องมือที่ทีมเปิดใช้ช่วยลดเวลาตั้งค่า เชื่อมสัญญาณ และสืบหาปัญหาได้จริงเพียงใด หากเปิดหลายหมวดแต่ใช้งานเพียงเล็กน้อย ค่าแรงที่ประหยัดอาจไม่พอชดเชยค่าบริการ ในทางกลับกัน หากลดงานดูแลที่กินเวลาทุกเดือนได้มาก ส่วนต่างค่าบริการก็อาจเป็นเงินที่จ่ายแล้วคุ้ม
ควรแยกเวลาติดตั้งครั้งแรกจากเวลาประจำเดือน การย้าย dashboard การตั้งสิทธิ์ และการปรับกฎแจ้งเตือนเดิมเป็นต้นทุนช่วงเปลี่ยนผ่าน ส่วนการแก้เส้นทางส่งข้อมูล ทบทวนการกรอง และตรวจว่าการแจ้งเตือนยังใช้ได้เป็นต้นทุนต่อเนื่อง หากคาดว่าจะใช้ระบบหลายปี ต้นทุนติดตั้งควรถูกกระจายตามช่วงที่คาดว่าจะใช้งาน มิฉะนั้นการเทียบเดือนแรกกับเดือนปกติจะให้คำตอบคนละเรื่อง
ทีมแบบใดมีแนวโน้มคุ้มกับแต่ละทางเลือก
Grafana Cloud น่าสนใจเมื่อทีมควบคุมปริมาณ telemetry ได้ เข้าใจผลของ label และความถี่ metrics และมีคนดูแลเส้นทาง OpenTelemetry อยู่แล้ว ในสภาพเช่นนี้ค่าบริการที่ต่ำกว่าอาจแปลงเป็นเงินประหยัดได้จริง โดยยังคงข้อมูลที่ต้องใช้สืบหาปัญหา เงื่อนไขสำคัญคือทีมต้องมีเวลาทำให้ collector, dashboard และกฎแจ้งเตือนทำงานสอดคล้องกับระบบที่เปลี่ยนไป
Datadog น่าสนใจเมื่อผลิตภัณฑ์ที่ต้องเปิดใช้ตรงกับงานของทีม และเวลาที่ลดได้จากการตั้งค่าและดูแลมีมูลค่าสูงกว่าส่วนต่างค่าบริการ การเลือกจึงไม่ควรตัดสินจากราคาต่อ host หรือราคาต่อ GB เพียงอย่างเดียว ให้เทียบขอบเขตเดียวกันทั้งจำนวน series ความถี่ที่ส่ง logs ที่รับเข้าและทำดัชนี traces ที่เก็บ ระยะค้นย้อนหลัง และชั่วโมงงานของคนที่รับผิดชอบ เมื่อตัวเลขเหล่านี้อยู่ในสมการเดียวกัน ราคาที่ถูกกว่าจึงจะบอกได้ว่าประหยัดจริงหรือเพียงย้ายค่าใช้จ่ายจากบิลบริการมาเป็นเวลาของทีม
บทความที่เกี่ยวข้อง


สัปดาห์ทำงาน 4 วัน: ลดชั่วโมงให้ผลต่างจากอัด 40 ชั่วโมงใน 4 วัน

ปิด AI บน DeviantArt ให้ถูก: สองสวิตช์คุ้มครองคนละเรื่อง

LangChain หรือ LlamaIndex: งาน RAG ซับซ้อนกับงานค้นคืนเลือกคนละตัว

Flow Engineering ได้ทุน 50 ล้านดอลลาร์ มูลค่าบริษัทพุ่งแตะ 750 ล้าน

RescueTime หรือ Toggl Track: จับสมาธิกับคิดเงินลูกค้าใช้เวลาแบบเดียวกันไม่ได้
สมัครรับจดหมายข่าวของเรา
รับข่าวสารล่าสุดเกี่ยวกับ Web3, AI และคริปโตส่งตรงถึงกล่องจดหมายของคุณ