โมเดลและแพลตฟอร์ม AI
VictoriaMetrics เปิดตัว VictoriaStack สำหรับเมตริก บันทึก ร่องรอย และการแก้ไขปัญหาด้วย AI

VictoriaMetrics เปิดตัว VictoriaStack แพลตฟอร์มการสังเกตการณ์ระบบแบบโอเพนซอร์สที่นำผลิตภัณฑ์ด้านเมตริก บันทึก และการติดตามแบบกระจายของบริษัทมาไว้ในรูปแบบการทำงานที่ประสานกัน การเปิดตัวนี้มีเป้าหมายเพื่อให้ทีมวิศวกรรมขยายขอบเขตการเก็บข้อมูลเทเลเมทรีได้ โดยไม่ต้องเปลี่ยนสภาพแวดล้อมการตรวจสอบทั้งหมด หรือบังคับให้จัดเก็บสัญญาณทุกชนิดไว้ในฐานข้อมูลเดียวกัน
VictoriaStack ผสาน VictoriaMetrics สำหรับเมตริก, VictoriaLogs สำหรับบันทึก และ VictoriaTraces สำหรับร่องรอยเข้าด้วยกัน ทีมต่าง ๆ เลือกใช้สัญญาณที่ต้องการและเพิ่มสัญญาณอื่นในภายหลังได้ โดยมีเครื่องมือสำหรับการติดตั้งใช้งานร่วมกันและการรองรับ OpenTelemetry ช่วยเชื่อมองค์ประกอบต่าง ๆ เข้าด้วยกัน
ประกาศนี้ยังขยายแนวทางดังกล่าวไปสู่การดำเนินงานที่มี AI ช่วยเหลือด้วย เซิร์ฟเวอร์ Model Context Protocol อย่างเป็นทางการและทักษะสำหรับเอเจนต์ช่วยให้ผู้ช่วย AI ตรวจสอบข้อมูลเทเลเมทรีทั่วทั้งแพลตฟอร์มได้ ขณะที่วิศวกรยังคงรับผิดชอบในการตัดสินใจว่าจะนำการเปลี่ยนแปลงใดไปใช้
สัญญาณสามประเภท ฐานข้อมูลเฉพาะทางสามระบบ
เมตริก บันทึก และร่องรอยช่วยตอบคำถามด้านการปฏิบัติงานที่แตกต่างกัน เมตริกสรุปพฤติกรรมในช่วงเวลาหนึ่ง เช่น อัตราคำขอ จำนวนข้อผิดพลาด หรือการใช้หน่วยความจำ บันทึกเก็บรายละเอียดของเหตุการณ์ ส่วนร่องรอยแบบกระจายติดตามคำขอที่ผ่านบริการหลายรายการ ทำให้เห็นว่าใช้เวลาไปกับส่วนใดและเกิดความล้มเหลวขึ้นที่ใด
เมื่อเกิดเหตุขัดข้อง วิศวกรอาจเริ่มจากสังเกตเห็นเวลาแฝงที่พุ่งสูงขึ้นในเมตริก จากนั้นใช้ร่องรอยจำกัดวงปัญหาให้เหลือบริการหนึ่ง แล้วตรวจสอบบันทึกเพื่อหาข้อผิดพลาดที่เป็นต้นเหตุ การนำสัญญาณเหล่านี้มาใช้ในเวิร์กโฟลว์ที่สอดคล้องกันอาจช่วยให้ตรวจสอบปัญหาได้เร็วขึ้น โดยไม่จำเป็นต้องทำให้ข้อกำหนดด้านการจัดเก็บข้อมูลของแต่ละสัญญาณเหมือนกัน
เอกสารสถาปัตยกรรมของ VictoriaStack อธิบายถึงฐานข้อมูลที่ทำงานแยกจากกันแต่ใช้รูปแบบองค์ประกอบร่วมกัน ฐานข้อมูลแต่ละระบบทำงานได้ทั้งในรูปแบบไบนารีเดี่ยวหรือคลัสเตอร์ที่แยกส่วนรับข้อมูลเข้า การจัดเก็บ และการสืบค้นออกจากกัน แพลตฟอร์มนี้ใช้ vmauth เป็นจุดเข้าใช้งานสำหรับกำหนดเส้นทางและกระจายโหลดได้
อินเทอร์เฟซสำหรับสืบค้นข้อมูลยังคงออกแบบเฉพาะทางเช่นกัน โดย VictoriaMetrics ใช้ MetricsQL ซึ่งเข้ากันได้กับ PromQL, VictoriaLogs ใช้ LogsQL และ VictoriaTraces รองรับ LogsQL ควบคู่กับ API ที่เข้ากันได้กับ Jaeger และ Tempo ดังนั้น การทำงานร่วมกันจึงไม่ได้หมายถึงการใช้ฐานข้อมูลเดียวหรือภาษาสำหรับสืบค้นแบบครอบจักรวาลเพียงภาษาเดียว
ฐานข้อมูลหลักทั้งสามระบบเผยแพร่ภายใต้สัญญาอนุญาต Apache 2.0 นอกจากนี้ บริษัทยังมีความสามารถระดับองค์กรและบริการสนับสนุนเชิงพาณิชย์ รวมถึง VictoriaMetrics Cloud ซึ่งเป็นบริการที่มีการจัดการเต็มรูปแบบและรองรับสัญญาณทั้งสามประเภท
OpenTelemetry เชื่อมโยงชั้นการเก็บข้อมูล
OpenTelemetry เป็นแนวทางร่วมสำหรับการเพิ่มเครื่องมือตรวจวัดให้แอปพลิเคชันและส่งออกข้อมูลเทเลเมทรี โปรโตคอล OTLP รองรับเมตริก บันทึก และร่องรอยของ VictoriaStack จึงช่วยให้ทีมมีช่องทางรับข้อมูลเข้าที่สอดคล้องกัน แม้ข้อมูลจะถูกส่งไปจัดเก็บในระบบแบ็กเอนด์ที่แตกต่างกัน
ความแตกต่างนี้สำคัญเมื่อแอปพลิเคชันเติบโตจากบริการเพียงไม่กี่รายการเป็นระบบแบบกระจาย เครื่องมือตรวจวัดควรช่วยอธิบายพฤติกรรมของแอปพลิเคชัน ส่วนการเปลี่ยนปลายทางของข้อมูลเทเลเมทรีไม่ควรทำให้ต้องออกแบบโค้ดตรวจสอบของแต่ละบริการใหม่ทั้งหมด
แพลตฟอร์มนี้ยังรองรับรูปแบบการรับข้อมูลเข้าอื่น ๆ ตามความเหมาะสมด้วย ตัวอย่างเช่น ทีมที่มีระบบเก็บเมตริกซึ่งอิงกับ Prometheus อยู่แล้ว สามารถใช้ระบบนิเวศเดิมต่อไป พร้อมเพิ่มบันทึกหรือการติดตามควบคู่กันได้ ความเข้ากันได้ของโปรโตคอลช่วยลดภาระในการย้ายระบบ แต่การเลือกช่วงเวลาการเก็บรักษาข้อมูล ความจุ และรูปแบบการสืบค้นยังคงเป็นการตัดสินใจทางวิศวกรรม
สำหรับการติดตั้งใช้งานบน Kubernetes ทาง VictoriaMetrics แนะนำให้ใช้ Operator และแผนภูมิ Helmเป็นเครื่องมือจัดการทั่วไป เป้าหมายคือทำให้การติดตั้งใช้งานและการอัปเกรดมีความสม่ำเสมอยิ่งขึ้น พร้อมคงความสามารถในการปรับขนาดของสัญญาณแต่ละประเภทให้เหมาะกับภาระงานของตน
เอเจนต์ AI ตรวจสอบข้อมูลเทเลเมทรีได้ทั่วทั้งระบบ
VictoriaStack นำแนวทางด้าน AI มาใช้สองด้าน ได้แก่ ระบบการสังเกตการณ์ต้องรองรับข้อมูลเทเลเมทรีที่เกิดจากแอปพลิเคชันแบบเอเจนต์ และผู้ช่วย AI สามารถช่วยวิศวกรตรวจสอบข้อมูลเทเลเมทรีดังกล่าวได้
เอกสารเครื่องมือ AIของบริษัทอธิบายถึงเซิร์ฟเวอร์ MCP แยกสำหรับเมตริก บันทึก และร่องรอย เซิร์ฟเวอร์เหล่านี้มีความสามารถแบบมีโครงสร้าง เช่น การสืบค้นอนุกรมเวลา การสำรวจฟิลด์ในบันทึก การค้นหาบริการและการดำเนินงาน และการดึงข้อมูลร่องรอย การเชื่อมต่อกับเมตริกยังรองรับการตรวจสอบเรื่องคาร์ดินาลิตี พฤติกรรมการสืบค้น และการกำหนดค่าการแจ้งเตือนด้วย
คลังทักษะสำหรับเอเจนต์ของบริษัทยังมีเวิร์กโฟลว์ที่นำกลับมาใช้ซ้ำได้สำหรับการตรวจสอบข้อมูลจากหลายสัญญาณและงานปฏิบัติการที่เกี่ยวข้อง ผู้ช่วยสามารถทำตามขั้นตอนการแก้ไขปัญหาที่เชื่อมโยงหลายสัญญาณ แทนที่จะพึ่งแดชบอร์ดเพียงหน้าเดียวหรือข้อความแสดงข้อผิดพลาดที่คัดลอกมา
ประกาศระบุว่าผู้ช่วยอย่าง Claude Code, Codex, Cursor และเอเจนต์ที่พัฒนาขึ้นภายในองค์กรสามารถเข้าถึงข้อมูลได้แบบอ่านอย่างเดียว รูปแบบการทำงานที่มุ่งหมายไว้จึงเป็นการตรวจสอบ กล่าวคือ รวบรวมหลักฐาน เชื่อมโยงอาการ และเสนอคำอธิบาย โดยให้วิศวกรเป็นผู้ตัดสินใจว่าจะนำสิ่งใดไปใช้ การเชื่อมต่อแหล่งข้อมูลเทเลเมทรีกับเอเจนต์ไม่ได้ยืนยันด้วยตัวเองว่าเอเจนต์ระบุสาเหตุที่แท้จริงได้ถูกต้อง
ปรับขนาดการรับข้อมูลเข้าและการสืบค้นแยกจากกัน
คู่มือเริ่มต้นใช้งาน VictoriaStack แสดงให้เห็นทั้งการกำหนดค่าแบบโหนดเดี่ยวและแบบคลัสเตอร์ ตัวอย่างสาธิต Docker Compose ประกอบด้วยแอปพลิเคชันและตัวเก็บรวบรวมข้อมูล OpenTelemetry, ฐานข้อมูลทั้งสาม, Grafana, vmalert และ vmauth เอกสารระบุชัดเจนว่าสภาพแวดล้อมในเครื่องนี้มีไว้เพื่อสาธิต ไม่ใช่สำหรับนำไปใช้งานจริงในระบบผลิต
ในรูปแบบคลัสเตอร์ คอมโพเนนต์สำหรับรับข้อมูลเข้าและสืบค้นข้อมูลเป็นแบบไร้สถานะ จึงสามารถปรับขนาดแยกจากกันได้ ส่วนคอมโพเนนต์สำหรับจัดเก็บข้อมูลจะเก็บรักษาข้อมูลไว้ การแยกเช่นนี้ช่วยรองรับความต้องการที่แตกต่างกัน กล่าวคือ เมื่อมีข้อมูลเทเลเมทรีขาเข้าเพิ่มขึ้น อาจจำเป็นต้องเพิ่มขีดความสามารถในการรับข้อมูล ขณะที่การมีวิศวกรหรือเอเจนต์ทำการสืบสวนมากขึ้นอาจเพิ่มความต้องการในการสืบค้นข้อมูล
การวางแผนพื้นที่จัดเก็บข้อมูลยังคงเป็นเรื่องสำคัญ เอกสารระบุว่าฐานข้อมูลจัดเก็บข้อมูลเทเลเมทรีไว้ในระบบไฟล์ภายในเครื่อง โดยใช้ S3 หรือ Google Cloud Storage สำหรับสำรองข้อมูล ไม่ใช่เป็นชั้นจัดเก็บข้อมูลบนออบเจ็กต์สตอเรจสำหรับการสืบค้น นอกจากนี้ยังระบุด้วยว่า การลดจำนวนชาร์ดสำหรับจัดเก็บข้อมูลเป็นการดำเนินการที่ซับซ้อน คุณลักษณะเหล่านี้มีความสำคัญต่อการเลือกโทโพโลยีและการคาดการณ์การเติบโต
สแตกที่ประสานการทำงานกัน โดยไม่ต้องย้ายระบบทั้งหมดในคราวเดียว
VictoriaMetrics นำเสนอ VictoriaStack ที่งาน KubeCon + CloudNativeCon North America 2026 พร้อมสาธิตแอปพลิเคชัน Kubernetes ที่ติดตั้งเครื่องมือวัดและเก็บข้อมูลด้วย OTLP ซึ่งส่งสัญญาณเทเลเมทรีทั้งสามประเภทไปยังแบ็กเอนด์ที่เกี่ยวข้อง จากนั้นจึงแสดงขั้นตอนการแก้ไขปัญหาที่เชื่อมโยงข้อมูลจากสัญญาณต่าง ๆ เข้าด้วยกัน
“ยุคของเอเจนต์จะนำมาซึ่งข้อมูลเทเลเมทรีที่เพิ่มขึ้น และความต้องการที่สูงขึ้นในการประมวลผลข้อมูลเหล่านั้น” Roman Khavronenko ผู้ร่วมก่อตั้งและผู้จัดการฝ่ายวิศวกรรมของ VictoriaMetrics กล่าวในประกาศ เขากล่าวว่า VictoriaStack ออกแบบมาให้รองรับการเติบโตของความต้องการดังกล่าวได้อย่างปรับขนาดได้และมีประสิทธิภาพ
แนวทางที่นำไปใช้ได้จริงคือการทยอยปรับใช้ โดยยังคงใช้ระบบนิเวศการรวบรวมข้อมูลที่มีประโยชน์ไว้ เพิ่มสัญญาณที่ยังขาด และจัดการบริการที่เกิดขึ้นผ่านรูปแบบการทำงานที่สอดคล้องกันยิ่งขึ้น คุณค่าของ VictoriaStack อยู่ที่การทำให้ส่วนประกอบต่าง ๆ ทำงานร่วมกันได้ดีเพียงใด เมื่อปริมาณข้อมูลเทเลเมทรีและความต้องการในการสืบสวนเพิ่มขึ้น ขณะเดียวกันก็ยังให้ทีมควบคุมได้ว่าข้อมูลจะอยู่ที่ใด และจะปรับขนาดสัญญาณแต่ละประเภทอย่างไร












