Dzmitry Lazerka, ผู้ร่วมก่อตั้ง VictoriaMetrics – ซีรีส์สัมภาษณ์

Dzmitry Lazerka, ผู้ร่วมก่อตั้ง VictoriaMetrics เป็นวิศวกรซอฟต์แวร์ที่มีประสบการณ์และผู้นำด้านเทคโนโลยีที่เชี่ยวชาญลึกซึ้งในแมชชีนเลิร์นนิง, ระบบข้อมูลขนาดใหญ่, การมองเห็นระบบ, และโครงสร้างพื้นฐาน ก่อนที่จะร่วมก่อตั้ง VictoriaMetrics ในปี 2018 เขาเคยทำงานเป็น Machine Learning Engineer ที่แผนกยานยนต์อัตโนมัติ Level 5 ของ Lyft, ซึ่งช่วยพัฒนาระบบสำหรับการจดจำและวิเคราะห์สถานการณ์การขับขี่ในโลกจริง ก่อนหน้านั้น เขาเป็นหัวหน้าโครงการแมชชีนเลิร์นนิงและโครงสร้างพื้นฐานข้อมูลที่ Spire Global, ทำหน้าที่เป็นผู้ร่วมก่อตั้งด้านวิศวกรรมที่ Bellgram, และทำงานด้านระบบข้อมูลและการวิเคราะห์ที่ Duetto Research และ Google ผ่าน EPAM Systems ตลอดเส้นทางอาชีพของ Lazerka เขาได้สร้างและนำโครงการต่าง ๆ ที่ครอบคลุมการขับขี่อัตโนมัติ, การพยากรณ์ทางทะเล, การค้นหา, การวิเคราะห์, การประมวลผลข้อมูลแบบกระจาย, และระบบแบ็กเอนด์ที่ขยายได้สูง

VictoriaMetrics เป็นบริษัทด้านการมองเห็นระบบแบบโอเพ่นซอร์สที่สร้างเครื่องมือสำหรับการเก็บรวบรวม, เก็บ, สืบค้น, และวิเคราะห์ข้อมูลการดำเนินงานในปริมาณมาก เทคโนโลยีของบริษัทเริ่มต้นด้วย VictoriaMetrics, ฐานข้อมูลซีรีส์เวลาแบบประสิทธิภาพสูงและโซลูชันการเฝ้าระวังที่ออกแบบมาสำหรับการขยายตัว, การสืบค้นที่รวดเร็ว, การจัดเก็บที่มีประสิทธิภาพ, และภาระการดำเนินงานต่ำ, และต่อมาขยายเป็นสแตกการมองเห็นระบบที่ครอบคลุมเมตริก, ล็อก, และเทรซแบบกระจายผ่าน VictoriaMetrics, VictoriaLogs, และ VictoriaTraces บริษัทยังให้บริการการปรับใช้บนคลาวด์แบบองค์กรและแบบจัดการเต็มรูปแบบ, พร้อมกับความสามารถในการตรวจจับความผิดปกติที่ใช้แมชชีนเลิร์นนิงกับข้อมูลซีรีส์เวลา แพลตฟอร์มของบริษัทรองรับเทคโนโลยีรวมถึง OpenTelemetry, กระบวนการทำงานที่เข้ากันได้กับ Prometheus, Grafana, และ Kubernetes, ให้ความยืดหยุ่นแก่องค์กรในการผสานรวม VictoriaMetrics เข้ากับสภาพแวดล้อมการมองเห็นระบบที่มีอยู่

ก่อนที่คุณจะร่วมก่อตั้ง VictoriaMetrics คุณเคยทำงานกับระบบข้อมูลขนาดใหญ่, การวิเคราะห์, และแมชชีนเลิร์นนิงที่ Google, Spire Global, แผนกยานยนต์อัตโนมัติของ Lyft, และสตาร์ทอัพอื่น ๆ สิ่งใดเป็นแรงผลักดันสุดท้ายให้คุณก่อตั้ง VictoriaMetrics, และปัญหาใดจากบทบาทก่อนหน้านั้นทำให้คุณเชื่อว่าการเฝ้าระวังและการมองเห็นระบบต้องการแนวทางที่แตกต่างอย่างสิ้นเชิง?

ฉันใช้เวลาทำงานตลอดอาชีพกับข้อมูลจำนวนมาก ที่ Google, Spire, Lyft และบริษัทอื่น ๆ คุณจะได้เรียนรู้อย่างรวดเร็วว่าบางสิ่งที่ทำงานได้ดีในระดับหนึ่งอาจกลายเป็นค่าใช้จ่ายสูงหรือยากต่อการดำเนินการในระดับอื่น การเฝ้าระวังมีปัญหาเช่นเดียวกัน

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

นี่คือสิ่งที่ผู้ร่วมก่อตั้งของฉัน Aliaksandr Valialkin และ Roman Khavronenko เห็นโดยตรง พวกเขามีประสบการณ์ในการดำเนินการ Prometheus และเจอข้อจำกัดเรื่องหน่วยความจำ การเพิ่มระบบเช่น Thanos ช่วยแก้ปัญหาการขยายบางประการ, แต่ก็ทำให้มีส่วนประกอบและความซับซ้อนในการดำเนินงานเพิ่มขึ้น และกับ InfluxDB เราได้เห็นว่าการเปลี่ยนแปลงลิขสิทธิ์สามารถส่งผลต่อการตัดสินใจด้านวิศวกรรมหลังจากทีมได้ลงทุนในเทคโนโลยีนั้นแล้ว

ดังนั้นแนวคิดเบื้องหลัง VictoriaMetrics จึงเป็นเรื่องปฏิบัติ: เราสามารถสร้างฐานข้อมูลซีรีส์เวลาที่ทำงานเดียวกันโดยใช้ทรัพยากรน้อยกว่ามากและง่ายต่อการดำเนินงานได้หรือไม่?

เราไม่ได้เริ่มต้นด้วยแผนที่จะสร้างบริษัทการมองเห็นระบบขนาดใหญ่ เราเริ่มจากการแก้ปัญหาวิศวกรรม

การทำให้เป็นโอเพ่นซอร์สเป็นส่วนหนึ่งของสิ่งนั้น วิศวกรสามารถดาวน์โหลด VictoriaMetrics, นำงานจริงในสภาพการผลิตมาทดสอบและเปรียบเทียบผลลัพธ์ด้วยตนเอง เราไม่จำเป็นต้องบอกว่ามันเร็วหรือมีประสิทธิภาพมากกว่า พวกเขาสามารถวัดได้เอง

นี่เป็นวิธีที่ดีที่สุดในการสร้างซอฟต์แวร์โครงสร้างพื้นฐาน หากเทคโนโลยีดี วิศวกรควรสามารถพิสูจน์ด้วยตนเองได้

ค่าใช้จ่ายในการมองเห็นระบบอาจค่อย ๆ กลายเป็นส่วนสำคัญของบิลคลาวด์ของบริษัท ค่าใช้จ่ายเหล่านี้มักจะบานปลายที่จุดใด, และการตัดสินใจด้านสถาปัตยกรรมหรือการซื้อที่ทีมวิศวกรรมมักทำผิดบ่อยที่สุดคืออะไร?

ฉันจะมองที่ cardinality ก่อน

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

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

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

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

นี่คือเหตุผลที่บางบริษัทมองการมองเห็นระบบเป็นปัญหาการซื้อ, ถามว่าแพลตฟอร์มใดง่ายต่อการปรับใช้ที่สุดในวันนี้ ฉันถามคำถามเช่น “จะเกิดอะไรขึ้นเมื่อปริมาณ telemetry เพิ่มขึ้น 10 เท่า? จะเกิดอะไรกับ cardinality? เรากำลังเก็บอะไร? เก็บไว้กี่ระยะเวลา? แล้วค่าใช้จ่ายจะเป็นอย่างไร?”

มีวิธีแก้ปัญหาด้านวิศวกรรมสำหรับปัญหาเหล่านี้ ตัวอย่างเช่น ด้วยการรวมข้อมูลแบบสตรีมมิ่ง คุณสามารถรวมเมตริกก่อนที่มันจะถึงการจัดเก็บแทนการเก็บซีรีส์เวลาทั้งหมดแบบดิบแล้วรวมภายหลัง คุณสามารถแยกงานที่มี cardinality สูงออกจากการเฝ้าระวังที่สำคัญต่อธุรกิจ คุณยังสามารถใช้นโยบายการเก็บรักษาและความละเอียดที่แตกต่างกันตามคุณค่าของข้อมูล

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

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

การมองเห็นระบบเป็นระบบวิศวกรรม ค่าใช้จ่ายของมันควรได้รับการออกแบบเช่นกัน

Grammarly ได้กล่าวว่าการพิสูจน์แนวคิดกับ VictoriaMetrics ทำให้บิล AWS ลดลง 10 เท่า เมื่อบริษัทบรรลุการประหยัดในระดับนี้ สิ่งที่เปลี่ยนแปลงอยู่ภายใต้ฝาเครื่องจริง ๆ คืออะไร: การบีบอัดข้อมูล, ความต้องการการประมวลผล, สถาปัตยกรรมการจัดเก็บ, ความซับซ้อนในการดำเนินงาน, หรือการผสมผสานของปัจจัยเหล่านี้?

เป็นการผสมผสานกัน, แต่การบีบอัดและรอยเท้าทรัพยากรทำงานส่วนใหญ่ VictoriaMetrics ใช้การบีบอัดที่ออกแบบมาสำหรับข้อมูลซีรีส์เวลา, ดังนั้นเมตริกเดียวกันใช้พื้นที่ดิสก์เพียงส่วนเล็กของที่ฐานข้อมูลทั่วไปจะใช้ เรายังทำงานบน RAM ที่เบากว่า Prometheus สี่ถึงห้าครั้งที่อัตราการรับเข้าที่เท่ากัน, และเบากว่าบนดิสก์ถึง 10 เท่า เมื่อ Grammarly ทำการพิสูจน์แนวคิดของพวกเขา สิ่งนั้นปรากฏโดยตรงในบิล AWS ของพวกเขา เพราะพวกเขาไม่ได้แค่เก็บข้อมูลน้อยลง; พวกเขาใช้อินสแตนซ์ที่น้อยกว่าและขนาดเล็กกว่าเพื่อทำงานนั้น

ส่วนความซับซ้อนในการดำเนินงานก็สำคัญเช่นกัน, แต่เป็นผลโดยอ้อม ทีมหลายทีมที่คำนวณค่าใช้จ่ายการมองเห็นระบบมักมองเฉพาะรายการจัดเก็บและการประมวลผลและมองข้ามชั่วโมงวิศวกรรมที่ใช้ในการดำเนินการสแตก Thanos ที่มีห้าส่วนประกอบเทียบกับไบนารีเดียว นั่นคือเงินที่แท้จริง; แต่ยากที่จะกำหนดตัวเลขให้ชัดเจน

Prometheus ได้กลายเป็นพื้นฐานของการเฝ้าระวังแบบคลาวด์เนทีฟ, แต่บางองค์กรในที่สุดก็เจอข้อจำกัดด้านการขยายตัวหรือการดำเนินงาน สิ่งใดโดยทั่วไปทำให้บริษัทเริ่มมองหาแนวทางนอกเหนือจากการปรับใช้ Prometheus แบบดั้งเดิม, และเมื่อใดที่ VictoriaMetrics กลายเป็นทางเลือกที่มีเหตุผล?

Prometheus ทำได้ยอดเยี่ยมในสิ่งที่มันถูกสร้างมา: เป็นเอนจินการเก็บข้อมูลและแจ้งเตือนแบบโหนดเดียว ทีมงานมักเจออุปสรรคสองแบบ: หรือจำนวนข้อมูลเพิ่มขึ้นเกินขีดจำกัดที่อินสแตนซ์ Prometheus เดียวสามารถเก็บในหน่วยความจำได้, หรือพวกเขาต้องการการเก็บรักษาระยะยาวและการสืบค้นทั่วโลกในหลายคลัสเตอร์ ซึ่ง Prometheus ไม่ได้ถูกออกแบบมาให้ทำได้ด้วยตนเอง นั่นคือช่วงที่ผู้ใช้เริ่มติดตั้ง Thanos หรือ Cortex ซึ่งมักเป็นจุดเริ่มต้นของความเจ็บปวดด้านการดำเนินงาน คุณจะเปลี่ยนจากการรันไบนารีเดียวเป็นการรันระบบกระจายที่มีคอมแพคเตอร์, ควอรีเออร์, เกตเวย์สตอร์ และอื่น ๆ อีกมากที่อาจพังในเวลา 3 นาฬิกาตอนเช้า.

VictoriaMetrics จึงเป็นขั้นตอนต่อไปที่สมเหตุสมผลเนื่องจากเป็นการแทนที่แบบ drop‑in ไม่ใช่การออกแบบใหม่ ทีมงานสามารถชี้การตั้งค่า scrape ของ Prometheus ที่มีอยู่ไปยัง VictoriaMetrics และยังคงใช้แดชบอร์ด Grafana, การแจ้งเตือนและกฎการบันทึกทั้งหมดที่เคยสร้างไว้ การย้ายเป็นเพียงการเปลี่ยนแปลงการตั้งค่า ไม่ใช่โครงการใด ๆ และพวกเขาจะได้ขนาดที่ต้องการโดยไม่ต้องเพิ่มส่วนประกอบใหม่อีกห้าตัวเพื่อดำเนินการ.

เรากำลังเห็นทีมวิศวกรรมพิจารณาใหม่ว่า พวกเขาต้องการแพลตฟอร์มการสังเกตการณ์ขนาดใหญ่ที่จัดการเต็มรูปแบบหรือสามารถสร้างสแตกที่มีประสิทธิภาพมากขึ้นจากส่วนประกอบโอเพนซอร์สหรือไม่ คุณมองว่านี่เป็นการเปลี่ยนแปลงเชิงโครงสร้างที่กว้างขวางในตลาดการสังเกตการณ์หรือไม่, และโอเพนซอร์สกดดันโมเดลการกำหนดราคาดั้งเดิมมากแค่ไหน?

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

สิ่งนี้ทำให้เกิดแรงกดดันจริงต่อการกำหนดราคาของผู้ให้บริการเดิม เมื่อทีมสามารถชี้การตั้งค่า scrape ที่มีอยู่ไปยังทางเลือกโอเพนซอร์สและลดค่าใช้จ่ายลง 60 ถึง 80% โดยไม่สูญเสียฟังก์ชันการทำงาน นั่นไม่ใช่การสนทนาที่ยากภายในองค์กร ผู้ให้บริการที่ยังคงเรียกเก็บค่าใช้จ่ายต่อโฮสต์หรือเมตริกที่กำหนดเองจะยังคงทำให้ลูกค้าที่ไม่ทำการคำนวณนี้เสียเปรียบต่อเนื่อง

โครงสร้างพื้นฐาน AI นำทรัพยากรใหม่ที่มีค่าใช้จ่ายสูงเป็นพิเศษเข้ามาในสมการ: GPU บริษัทที่ดำเนินการฝึกหรือสรุปผล AI ควรติดตามอะไรบ้างนอกเหนือจากการใช้งาน GPU เบื้องต้น, และการสังเกตการณ์ที่ดียิ่งขึ้นสามารถแปลเป็นการลดค่าใช้จ่ายโครงสร้างพื้นฐาน AI ได้โดยตรงอย่างไร?

การใช้งาน GPU อย่างเดียวไม่ให้ข้อมูลเพียงพอ

คุณอาจเห็นการใช้งาน 90% บนแดชบอร์ดและสันนิษฐานว่าทุกอย่างดี แต่สิ่งที่คุณต้องการรู้อย่างแท้จริงคือ: GPU ทำอะไรอยู่?

คุณต้องมองลึกลงไปว่า เคอร์เนล CUDA ใดกำลังทำงาน? หน่วยความจำ GPU ถูกจัดสรรอย่างไร? ใช้เวลาเท่าไหร่ในการย้ายหน่วยความจำแทนที่จะทำการคำนวณ? งานนั้นใช้ Tensor Cores หรือไม่เมื่อควรใช้? GPU เป็นคอขวดจริงหรือแค่รอข้อมูลจากที่อื่น?

นี่คือคำถามสำคัญเพราะ GPU มีราคาแพง ความไม่มีประสิทธิภาพเล็กน้อยที่เกิดซ้ำบนหลายร้อยหรือหลายพัน GPU จะกลายเป็นค่าใช้จ่ายจำนวนมหาศาล

ตัวอย่างเช่น หาก GPU รอคอยเนื่องจากสายข้อมูลไม่สามารถส่งข้อมูลได้เร็วพอ การซื้อ GPU เพิ่มจะไม่แก้ปัญหา คุณต้องหาคอขวด สิ่งเดียวกันก็ใช้กับหน่วยความจำ หากงานจัดสรรหน่วยความจำอย่างไม่มีประสิทธิภาพ การมองเห็นที่ดียิ่งขึ้นจะช่วยวิศวกรปรับขนาดแบตช์หรือรันงานมากขึ้นบนฮาร์ดแวร์เดียวกัน

นี่คือจุดที่การสังเกตการณ์ทำให้โครงสร้างพื้นฐาน AI น่าสนใจ ไม่ได้เพียงแค่ตรวจจับว่ามีบางอย่างขัดข้อง แต่ยังบอกคุณว่าคุณกำลังเสียการคำนวณที่ไหน

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

ด้วย OpenTelemetry และโครงการเช่น OpenLIT เราสามารถได้รับการมองเห็นที่ลึกขึ้นมากในงานของ GPU จากนั้นด้วย VictoriaMetrics เราสามารถรวมข้อมูล, กำจัดมิติที่ไม่จำเป็น และเก็บรักษาข้อมูลที่วิศวกรต้องการอย่างมีประสิทธิภาพ

คำถามที่มีประโยชน์ไม่ได้คือ “GPU ของฉันถูกใช้เท่าไหร่?”

แต่เป็น “งานที่มีประโยชน์ที่ฉันได้รับจาก GPU ที่ฉันจ่ายเงินไปคืออะไร?”

เมื่อคุณตอบคำถามนั้นได้แล้ว คุณจะเริ่มทำการตัดสินใจด้านวิศวกรรมและต้นทุนได้ดียิ่งขึ้น

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

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

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

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

VictoriaMetrics ยังได้นำการเรียนรู้ของเครื่องและกระบวนการทำงานที่ช่วยโดย AI ไปใช้ในการตรวจจับความผิดปกติ คุณเชื่อว่า AI สามารถปรับปรุงการมอนิเตอร์และการตอบสนองต่อเหตุการณ์ได้จริงในวันนี้ที่ไหน, และการตัดสินใจของมนุษย์ยังคงยากต่อการทดแทนที่ไหน?

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

AI ช่วยจริง ๆ คือการเปิดเผยสิ่งที่คนอาจพลาดในความสับสน เช่น จุดเบี่ยงเบนและแนวโน้มที่ไม่ทำให้เกณฑ์มือจับได้ ที่ VictoriaMetrics เรามีนโยบาย AI ภายในที่ง่าย: พนักงานสามารถอัตโนมัติกระบวนการทำงานของตนได้ตามต้องการ แต่ยังคงรับผิดชอบต่อผลลัพธ์สุดท้าย นั่นเป็นมาตรฐานเดียวกันที่เราจะใช้กับการตรวจจับความผิดปกติในสภาพแวดล้อมการผลิตของลูกค้า โมเดลอาจทำเครื่องหมายให้เห็น, แต่คนยังต้องตัดสินใจว่ามันหมายถึงอะไรและต้องทำอย่างไรต่อ

VictoriaMetrics ยังคงเป็นโอเพนซอร์สและใช้แนวทางการระดมทุนด้วยตนเองและจากลูกค้าแทนที่จะตามโมเดลสตาร์ทอัพโครงสร้างพื้นฐานที่ได้รับการสนับสนุนจากเงินทุนร่วมทุนแบบดั้งเดิม การที่เป็นเช่นนี้มีผลต่อวิธีที่คุณสร้างผลิตภัณฑ์, ตั้งราคา, และตัดสินใจว่าเทคโนโลยีใดจะยังคงเป็นโอเพนซอร์ส?

การระดมทุนด้วยตนเองเปลี่ยนโครงสร้างแรงจูงใจมากกว่าที่คนคาดคิด ด้วยไม่มีคณะกรรมการที่บังคับให้เราต้องบรรลุตัวเลข ARR ในไตรมาสที่กำหนด เราไม่ได้ต้องทำการแลกเปลี่ยนที่มักมาพร้อมกับแรงกดดันนั้น เช่น ทำให้เวอร์ชันโอเพนซอร์สอ่อนแอเพื่อบังคับให้ผู้ใช้ย้ายไปสู่ระดับชำระเงิน, หรือเปลี่ยนไลเซนส์เช่นที่ InfluxDB หรือ HashiCorp ทำเมื่อพวกเขาต้องปกป้องรายได้จากผู้ให้บริการคลาวด์ VictoriaMetrics OSS ใช้ Apache 2.0 ในปัจจุบันและเราไม่มีแผนที่จะเปลี่ยนแปลง

วิธีที่เราตัดสินใจว่าอะไรจะเปิดเป็นซอร์สโค้ดนั้นง่ายมาก: เครื่องยนต์หลัก ซึ่งเป็นสิ่งที่วิศวกรต้องไว้วางใจให้จัดการข้อมูลการผลิตของพวกเขา จะยังคงเปิดอยู่ เราจะเรียกเก็บค่าใช้จ่ายสำหรับสิ่งที่บริษัทต้องการเมื่อระบบทำงานในระดับใหญ่และต้องการผู้รับผิดชอบ: การรองรับหลายผู้ใช้, การตรวจสอบสิทธิ์ระดับองค์กร, การสนับสนุนการปฏิบัติตามกฎระเบียบ, SLA สำหรับ CVE และการเข้าถึงโดยตรงกับวิศวกรผู้เขียนโค้ดแทนคิวสนับสนุน การได้รับเงินทุนจากลูกค้าก็หมายความว่าแผนงานจะถูกกำหนดโดยสิ่งที่ผู้ใช้จริงๆ พบในการผลิต ไม่ใช่โดยสิ่งที่สามารถระดมทุนได้ในสไลด์พรีเซนเทชัน

เมื่อเมตริก, ล็อก, แทรซ, เทเลเมทรีของแอปพลิเคชัน AI, การตรวจสอบ GPU, และการตรวจจับความผิดปกติอัตโนมัติเข้ากันมากขึ้น คุณคิดว่า stack การสังเกตการณ์จะเป็นอย่างไรในไม่กี่ปีข้างหน้า และทีมวิศวกรรมจะคาดหวังอะไรจากแพลตฟอร์มที่ต้องการคงความเกี่ยวข้อง?

Stack จะบรรจบกันในเชิงปฏิบัติการก่อนที่จะบรรจบเป็นผลิตภัณฑ์เดียว และความแตกต่างนี้สำคัญ ทีมส่วนใหญ่ไม่ต้องการแพลตฟอร์มโมโนลิธิกที่มี UI เดียวล็อกทุกอย่างเข้าด้วยกัน สิ่งที่พวกเขาต้องการคือเมตริก, ล็อกและแทรซที่ทำงานบนโมเดลการดำเนินงานเดียว, ผู้ขายเดียวและเรื่องลิขสิทธิ์เดียว โดยไม่ต้องสละความสามารถในการรันสัญญาณแต่ละอย่างแยกกันหากทีมใดทีมหนึ่งต้องการ นั่นคือทิศทางที่ VictoriaMetrics กำลังสร้าง เราไม่ได้พยายามบรรจุทุกอย่างเข้าไปในไบนารีเดียว เรากำลังพยายามทำให้สัญญาณทั้งสามใช้เครื่องยนต์เดียวและมีลักษณะประสิทธิภาพเดียวกัน ดังนั้นการเพิ่มสัญญาณที่สองหรือสามจะไม่หมายถึงการรับภาระการดำเนินงานที่สองหรือสาม

แพลตฟอร์มที่คงความเกี่ยวข้องคือแพลตฟอร์มที่สามารถดูดซับเทเลเมทรี AI และการตรวจสอบ GPU เข้าไปในโมเดลเดียวกันโดยไม่ทำให้เส้นโค้งต้นทุนแตกหัก งานโหลด AI สร้างเทเลเมทรีในปริมาณที่โมเดลการกำหนดราคาต่อเมตริกหรือต่อโฮสต์แบบเดิมไม่เคยรองรับ ทีมงานจะต้องหยุดเก็บข้อมูลที่ต้องการหรือค่าใช้จ่ายการสังเกตการณ์จะเติบโตเร็วกว่าเงินลงทุน AI ที่ควรจะเฝ้าติดตาม ทีมวิศวกรรมจะคาดหวังให้แพลตฟอร์มจัดการปริมาณนั้นในลักษณะเดียวกับที่พวกเขาคาดหวังให้โครงสร้างพื้นฐานใดๆ ขยายตัวได้โดยไม่ต้องให้พวกเขาต้องออกแบบใหม่หรือเจรจาใหม่ทุกครั้งที่งานโหลดเพิ่มขึ้น

ขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม, ผู้อ่านที่ต้องการเรียนรู้เพิ่มเติมควรเยี่ยมชม VictoriaMetrics.