สวัสดีทุกคน. ด้านล่างนี้คือข้อความถอดเสียง .
– ระบบตรวจสอบระบบและบริการต่างๆ โดยผู้ดูแลระบบสามารถรวบรวมข้อมูลเกี่ยวกับพารามิเตอร์ปัจจุบันของระบบและตั้งค่าการแจ้งเตือนเพื่อรับการแจ้งเตือนเกี่ยวกับการเบี่ยงเบนในการทำงานของระบบ
รายงานจะมีการเปรียบเทียบ и — โครงการสำหรับการจัดเก็บตัวชี้วัด Prometheus ในระยะยาว
ก่อนอื่น ฉันจะบอกคุณเกี่ยวกับโพรมีธีอุส นี่คือระบบการตรวจสอบที่รวบรวมตัวชี้วัดจากเป้าหมายที่ระบุและบันทึกไว้ในที่จัดเก็บในตัวเครื่อง Prometheus สามารถบันทึกการวัดไปยังพื้นที่จัดเก็บข้อมูลระยะไกล และสามารถสร้างการแจ้งเตือนและกฎการบันทึกได้
ข้อจำกัดของโพรมีธีอุส:
- ไม่มีมุมมองแบบสอบถามส่วนกลาง นี่คือเมื่อคุณมีโพรมีธีอุสหลายอินสแตนซ์ที่เป็นอิสระ พวกเขารวบรวมตัวชี้วัด และคุณต้องการสืบค้นนอกเหนือจากตัววัดทั้งหมดที่รวบรวมจากอินสแตนซ์โพรมีธีอุสที่แตกต่างกัน โพรมีธีอุสไม่อนุญาต
- ด้วย Prometheus ประสิทธิภาพจะถูกจำกัดไว้ที่เซิร์ฟเวอร์เดียวเท่านั้น Prometheus จะไม่ปรับขนาดข้ามเซิร์ฟเวอร์หลายเครื่องโดยอัตโนมัติ คุณสามารถแบ่งเป้าหมายของคุณระหว่าง Prometheus หลายรายการได้ด้วยตนเองเท่านั้น
- ขอบเขตของตัววัดใน Prometheus ถูกจำกัดไว้เพียงเซิร์ฟเวอร์เดียวด้วยเหตุผลเดียวกับที่ไม่สามารถปรับขนาดข้ามเซิร์ฟเวอร์หลายเครื่องได้โดยอัตโนมัติ
- การจัดการความปลอดภัยของข้อมูลใน Prometheus ไม่ใช่เรื่องง่าย
วิธีแก้ไขปัญหา/ความท้าทายเหล่านี้?
แนวทางแก้ไขคือ:
โซลูชันทั้งหมดนี้มีไว้สำหรับการจัดเก็บข้อมูลระยะไกลที่รวบรวมโดย Prometheus พวกเขาแก้ไขปัญหาการจัดเก็บข้อมูลระยะไกลจากสไลด์ก่อนหน้าด้วยวิธีต่างๆ ในการนำเสนอนี้ ผมจะพูดถึงวิธีแก้ปัญหาสองข้อแรกเท่านั้น: и .
เป็นครั้งแรกที่มีข้อมูลเกี่ยวกับ ปรากฏโดย - มีการอธิบายสถาปัตยกรรมไว้ที่นั่น และวิธีการทำงาน
ธานอสนำข้อมูลที่ Prometheus บันทึกไว้ในดิสก์ในเครื่องและคัดลอกไปยัง S3 ไปยัง หรือไปยังที่เก็บวัตถุอื่น
ดังนั้นธานอสจึงมีมุมมองแบบสอบถามทั่วโลก คุณสามารถสืบค้นข้อมูลที่จัดเก็บไว้ในพื้นที่จัดเก็บอ็อบเจ็กต์จากอินสแตนซ์ Prometheus หลายอินสแตนซ์ได้
ธานอสรองรับ PromQL และ .
ธานอสใช้รหัสโพรเพื่อเก็บข้อมูล
ธานอสได้รับการพัฒนาโดยนักพัฒนากลุ่มเดียวกับโพรมีธีอุส
เกี่ยวกับ . ที่นี่ ที่เราคุยกันครั้งแรก .
VictoriaMetrics ได้รับข้อมูลจากโพรมีธีอุสหลายตัว โปรโตคอลที่สนับสนุนโดย Prometheus
VictoriaMetrics มอบมุมมองการสืบค้นทั่วโลก เนื่องจากอินสแตนซ์ Prometheus หลายอินสแตนซ์สามารถเขียนข้อมูลไปยัง VictoriaMetrics เดียวได้ ดังนั้น คุณจึงสามารถสอบถามข้อมูลทั้งหมดนี้ได้
VictoriaMetrics ยังรองรับ API การสืบค้นของ Thanos, PromQL และ Prometheus อีกด้วย
ซอร์สโค้ด VictoriaMetrics ต่างจากธานอสตรงที่เขียนตั้งแต่เริ่มต้น และได้รับการปรับให้เหมาะสมกับความเร็วและการใช้ทรัพยากร
VictoriaMetrics ต่างจากธานอสตรงที่ปรับขนาดทั้งแนวตั้งและแนวนอน กิน ซึ่งปรับขนาดในแนวตั้ง คุณสามารถเริ่มต้นด้วยโปรเซสเซอร์หนึ่งตัวและหน่วยความจำ 1 GB และค่อยๆ เพิ่มเป็นโปรเซสเซอร์หลายร้อยตัวและหน่วยความจำ 1 TB VictoriaMetrics สามารถใช้ทรัพยากรเหล่านี้ทั้งหมดได้ ประสิทธิภาพจะเพิ่มขึ้นประมาณ 100 เท่าเมื่อเทียบกับระบบ 1 คอร์
ประวัติศาสตร์ของธานอสเริ่มต้นขึ้นในเดือนพฤศจิกายน พ.ศ. 2017 เมื่อมีการเปิดเผยต่อสาธารณะครั้งแรก ก่อนหน้านี้ธานอสได้รับการพัฒนาภายใน .
ในเดือนมิถุนายน 2019 มีการเปิดตัวครั้งสำคัญ 0.5.0 ซึ่ง มาตรการ. เขาถูกถอดออกจากธานอสเพราะเขาทำผลงานได้ไม่ดี บ่อยครั้งที่คลัสเตอร์ธานอสทำงานไม่ถูกต้อง โหนดที่เชื่อมต่อไม่ถูกต้องเนื่องจากโปรโตคอลการนินทา ดังนั้นเราจึงตัดสินใจลบเขาออกจากที่นั่น ฉันคิดว่านี่เป็นการตัดสินใจที่ถูกต้อง
ในเดือนมิถุนายน 2019 เดียวกันก็ส่งหมายเลขใบสมัคร в .
และหลังจากนั้นไม่กี่เดือนธานอสก็ได้รับการยอมรับ ซึ่งรวมถึง Prometheus, Kubernetes และโปรเจ็กต์ยอดนิยมอื่นๆ
ในเดือนมกราคม 2018 การพัฒนา VictoriaMetrics ได้เริ่มขึ้น
ในเดือนกันยายน 2018 ฉันพูดถึง VictoriaMetrics ต่อสาธารณะเป็นครั้งแรก
ในเดือนธันวาคม 2018 มีการเผยแพร่เวอร์ชันโหนดเดียว
ในเดือนพฤษภาคม 2019 แหล่งที่มาของทั้งเวอร์ชันโหนดเดียวและคลัสเตอร์
ในเดือนมิถุนายน 2019 เช่นเดียวกับธานอส เราได้ส่งใบสมัครไปยังมูลนิธิ CNCF ตามหมายเลข - เราสมัครหนึ่งวันก่อนที่ธานอสจะสมัคร
แต่น่าเสียดายที่เรายังไม่ได้รับการตอบรับจากที่นั่น ต้องการความช่วยเหลือจากชุมชน
มาดูสไลด์ที่สำคัญที่สุดที่แสดงสถาปัตยกรรมของ Thanos และ VictoriaMetrics
มาเริ่มกันที่ธานอส ส่วนประกอบสีเหลืองคือส่วนประกอบของโพรมีธีอุส อย่างอื่นเป็นส่วนประกอบของธานอส เริ่มจากองค์ประกอบที่สำคัญที่สุดกันก่อน Thanos Sidecar เป็นส่วนประกอบที่ติดตั้งอยู่ข้างๆ Prometheus ทุกตัว โดยจะโหลดข้อมูล Prometheus จากพื้นที่จัดเก็บภายในเครื่องไปยัง S3 หรือ Object Storage อื่น
นอกจากนี้ยังมีส่วนประกอบที่เรียกว่า Thanos Store Gateway ซึ่งสามารถอ่านข้อมูลนี้จาก Object Storage ตามคำขอที่เข้ามาจาก Thanos Query Thanos Query ใช้ PromQL และ Prometheus API นั่นคือจากภายนอกดูเหมือนโพรมีธีอุส รับการสอบถาม PromQL ส่งไปยัง Thanos Store Gateway, Thanos Store Gateway ดึงข้อมูลที่จำเป็นจาก Object Storage แล้วส่งกลับ
แต่เราจัดเก็บข้อมูลไว้ใน Object Storage โดยไม่มีสองชั่วโมงล่าสุด เนื่องจากคุณสมบัติของการใช้งาน Thanos Sidecar ซึ่งไม่สามารถอัปโหลดสองชั่วโมงล่าสุดไปยัง Object Storage S3 ได้ เนื่องจาก Prometheus ยังไม่ได้สร้างไฟล์สำหรับสองชั่วโมงนี้ในที่จัดเก็บในตัวเครื่อง
คุณตัดสินใจที่จะแก้ไขปัญหานี้อย่างไร? นอกเหนือจากการร้องขอไปยัง Thanos Store Gateway แล้ว Thanos Query ยังส่งคำขอแบบขนานไปยัง Thanos Sidecar แต่ละคันที่อยู่ถัดจาก Prometheus
และในทางกลับกัน ธานอส ไซด์คาร์ ก็ส่งคำขอไปยังโพรมีธีอุสเพิ่มเติม และดึงข้อมูลในช่วงสองชั่วโมงที่ผ่านมา
นอกจากส่วนประกอบเหล่านี้แล้ว ยังมีส่วนประกอบเสริมที่ไม่มีธานอสจะทำงานได้ดี นี่คือ Thanos Compact ซึ่งมีหน้าที่ในการรวมไฟล์ขนาดเล็กบน Object Storage ให้เป็นไฟล์ขนาดใหญ่ที่ Thanos Sidecars อัปโหลดไว้ที่นี่ Thanos Sidecar อัพโหลดไฟล์ข้อมูลที่นั่นภายในสองชั่วโมง ไฟล์เหล่านี้หากไม่ถูกรวมเป็นไฟล์ขนาดใหญ่ จำนวนไฟล์ก็จะเพิ่มมากขึ้นอย่างมาก ยิ่งไฟล์ดังกล่าวมีหน่วยความจำมากขึ้นสำหรับ Thanos Store Gateway ก็ยิ่งต้องการทรัพยากรมากขึ้นในการถ่ายโอนข้อมูลผ่านเครือข่ายและข้อมูลเมตา Thanos Store Gateway ไม่มีประสิทธิภาพ ดังนั้นจึงจำเป็นต้องรัน Thanos Compact ซึ่งจะรวมไฟล์ขนาดเล็กให้เป็นไฟล์ขนาดใหญ่ เพื่อให้มีไฟล์ดังกล่าวน้อยลง และเพื่อลดค่าใช้จ่ายบน Thanos Store Gateway
นอกจากนี้ยังมีส่วนประกอบเช่น Thanos Ruler โดยดำเนินการตามกฎการแจ้งเตือนของ Prometheus และสามารถประเมินกฎการบันทึกของ Prometheus เพื่อเขียนข้อมูลกลับไปยัง Object Storage แต่ไม่แนะนำให้ใช้ส่วนประกอบนี้เนื่องจาก... เขา .
นี่คือแผนการง่ายๆ ของธานอส
ทีนี้มาเปรียบเทียบกับโครงการ VictoriaMetrics กันดีกว่า
VictoriaMetrics มี 2 เวอร์ชัน: เวอร์ชันโหนดเดียวและคลัสเตอร์ โหนดเดียวทำงานบนคอมพิวเตอร์เครื่องเดียว โหนดเดียวไม่มีส่วนประกอบเหล่านี้ มีเพียงไบนารีเดียวเท่านั้น ไบนารีบนสไลด์นี้ดูเหมือนสี่เหลี่ยมจัตุรัสนี้ ทุกสิ่งที่อยู่ภายในสี่เหลี่ยมจัตุรัสคือเนื้อหาของไฟล์ไบนารีสำหรับเวอร์ชันโหนดเดียว คุณไม่จำเป็นต้องรู้เกี่ยวกับเขา คุณเพียงแค่เรียกใช้ไบนารี่และทุกอย่างก็ใช้ได้ผลสำหรับเรา
เวอร์ชันคลัสเตอร์มีความซับซ้อนมากขึ้น ภายในมีส่วนประกอบที่แตกต่างกันสามส่วน: vmselect, vminsert และ vmstorage จากชื่อของพวกเขาควรจะชัดเจนว่าแต่ละคนทำอะไร ส่วนประกอบ Insert ยอมรับข้อมูลในรูปแบบที่แตกต่างกัน: จาก API การเขียนระยะไกลของ Prometheus, โปรโตคอล Influx line, โปรโตคอล Graphite และโปรโตคอล OpenTSDB ส่วนประกอบแทรกยอมรับ แยกวิเคราะห์ และกระจายระหว่างส่วนประกอบการจัดเก็บข้อมูลที่มีอยู่ ซึ่งเป็นที่ที่ข้อมูลถูกเก็บไว้แล้ว ในทางกลับกัน องค์ประกอบ Select จะยอมรับคำสั่ง PromQL เขาปฏิบัติ เช่นเดียวกับ API การสืบค้น Prometheus และสามารถใช้แทน Prometheus ใน Grafana หรือไคลเอ็นต์ Prometheus API อื่นๆ ได้ เลือกยอมรับคำขอ Promql แยกวิเคราะห์ อ่านข้อมูลที่จำเป็นสำหรับการดำเนินการคำขอนี้จากโหนดที่เก็บข้อมูล ประมวลผลข้อมูลนี้ และส่งคืนการตอบกลับ
มาเปรียบเทียบความซับซ้อนของการติดตั้ง Thanos และ VictoriaMetrics กัน
เริ่มกันที่ธานอส ก่อนที่คุณจะเริ่มทำงานกับ Thanos คุณต้องสร้างบัคเก็ตใน Object Storage เช่น S3 หรือ GCS เพื่อให้ Thanos Sidecar สามารถเขียนข้อมูลลงไปได้
จากนั้นสำหรับ Prometheus แต่ละตัว คุณจะต้องติดตั้ง Thanos Sidecar ก่อนหน้านี้ คุณต้องไม่ลืมปิดการใช้งานการบีบอัดข้อมูลใน Prometheus การบีบอัดข้อมูลจะบีบอัดข้อมูลในพื้นที่จัดเก็บข้อมูล Prometheus ในเครื่องเป็นระยะๆ เพื่อลดการใช้ทรัพยากร
เมื่อคุณติดตั้ง Thanos Sidecar บน Prometheus คุณต้องปิดใช้งานการบีบอัดข้อมูลนี้ เนื่องจาก Thanos Sidecar ทำงานไม่ถูกต้องเมื่อเปิดใช้งานการบีบอัดข้อมูล ซึ่งหมายความว่า Prometheus ของคุณจะเริ่มบันทึกข้อมูลเป็นบล็อกสองชั่วโมงและหยุดรวมบล็อกเหล่านั้นเป็นบล็อกที่ใหญ่ขึ้น ดังนั้น หากคุณสร้างการสืบค้นที่เกินระยะเวลาสองชั่วโมงที่ผ่านมา การสืบค้นเหล่านั้นจะไม่ทำงานอย่างมีประสิทธิภาพเท่าที่ควรหากเปิดใช้งานการบีบอัดข้อมูล
ดังนั้นธานอสจึงแนะนำให้ลดเวลาการเก็บรักษาข้อมูลในที่จัดเก็บในตัวเครื่องลงเหลือ 6-8 ชั่วโมง เพื่อลดค่าใช้จ่ายของบล็อกขนาดเล็กจำนวนมาก
เมื่อคุณติดตั้ง Thanos Sidecar แล้ว คุณต้องติดตั้งสององค์ประกอบสำหรับแต่ละ Object Storage Bucket เหล่านี้คือ Thanos Compactor และ Thanos Store Gateway
หลังจากนั้น คุณจะต้องติดตั้ง Thanos Query และกำหนดค่าเพื่อให้สามารถเชื่อมต่อกับ Thanos Store Gateways ทั้งหมดที่คุณมี และยังสามารถเชื่อมต่อกับ Thanos Sidecars ทั้งหมดได้อีกด้วย
อาจมีปัญหาเล็กน้อยที่นี่
คุณต้องกำหนดค่าการเชื่อมต่อที่เชื่อถือได้และปลอดภัยจาก Thanos Query ไปยังส่วนประกอบเหล่านี้ และหาก Prometheus ของคุณตั้งอยู่ในศูนย์ข้อมูลที่แตกต่างกันหรือใน VPC ที่แตกต่างกัน การเชื่อมต่อกับศูนย์เหล่านั้นจากภายนอกก็เป็นสิ่งต้องห้าม แต่เพื่อให้ Thanos Query ทำงานได้ คุณต้องกำหนดค่าการเชื่อมต่อที่นั่น และต้องหาทาง
หากคุณมีศูนย์ข้อมูลดังกล่าวจำนวนมาก ความน่าเชื่อถือของทั้งระบบก็จะลดลงตามไปด้วย เนื่องจาก Thanos Query ต้องรักษาการเชื่อมต่อกับ Thanos Sidecars ทั้งหมดที่อยู่ในศูนย์ข้อมูลต่างๆ อย่างต่อเนื่อง สำหรับทุกคำขอที่เข้ามา มันจะส่งคำขอไปยัง Thanos Sidecars ทั้งหมด หากการเชื่อมต่อถูกขัดจังหวะ คุณจะได้รับชุดข้อมูลที่ไม่สมบูรณ์ หรือคุณจะได้รับคำตอบว่า "คลัสเตอร์ไม่ทำงาน"
ใน VictoriaMetrics ทุกอย่างจะง่ายขึ้นเล็กน้อย สำหรับเวอร์ชัน Single-node คุณเพียงแค่ต้องรันไบนารี่เดียวและทุกอย่างทำงานได้
ในเวอร์ชันคลัสเตอร์ การรันส่วนประกอบทั้งสามประเภทข้างต้นในปริมาณเท่าที่คุณต้องการหรือใช้ก็เพียงพอแล้ว เพื่อทำให้การเปิดตัวส่วนประกอบใน Kubernetes เป็นแบบอัตโนมัติ เรากำลังวางแผนที่จะสร้างตัวดำเนินการ Kubernetes ด้วย แผนภูมิ Helm ไม่ครอบคลุมในบางกรณี และให้คุณยิงตัวเองด้วยเท้าได้ ตัวอย่างเช่น ช่วยให้คุณสามารถลดจำนวนโหนดการจัดเก็บข้อมูล ซึ่งจะทำให้ข้อมูลสูญหายได้
หลังจากที่คุณเปิดใช้งานไบนารี่หรือเวอร์ชันคลัสเตอร์แล้ว คุณเพียงแค่ต้องเพิ่ม Prometheus ลงในการกำหนดค่า เพื่อเริ่มเขียนข้อมูลแบบขนานกับที่จัดเก็บในตัวเครื่องและที่เก็บข้อมูลระยะไกล อย่างที่คุณเห็น การกำหนดค่านี้ควรทำงานได้อย่างน่าเชื่อถือมากกว่าเมื่อเปรียบเทียบกับการกำหนดค่าของธานอส เราไม่จำเป็นต้องรักษาการเชื่อมต่อจาก VictoriaMetrics ไปยัง Prometheus ทั้งหมด เนื่องจาก Prometheus เชื่อมต่อกับ VictoriaMetrics และส่งข้อมูลเอง
ลองพิจารณาการสนับสนุนของ Thanos และ VictoriaMetrics
ธานอสจำเป็นต้องตรวจสอบ Sidecar เพื่อให้แน่ใจว่าจะไม่หยุดโหลดข้อมูลลงใน Object Storage พวกเขาอาจหยุดการดาวน์โหลดข้อมูลนี้เนื่องจากข้อผิดพลาดในการดาวน์โหลด เช่น การเชื่อมต่อเครือข่ายของคุณกับ Object Storage ถูกขัดจังหวะชั่วคราว หรือ Object Storage ไม่พร้อมใช้งานชั่วคราว Thanos Sidecar จะสังเกตเห็นสิ่งนี้ในขณะนี้ รายงานข้อผิดพลาด อาจขัดข้องและหยุดทำงาน หากคุณไม่ตรวจสอบ คุณจะหยุดการถ่ายโอนข้อมูลไปยัง Object Storage หากเลยเวลาเก็บรักษา (แนะนำ 6-8 ชั่วโมง) คุณจะสูญเสียข้อมูลที่ไม่ได้อยู่ใน Object Storage
เครื่องอัดธานอสอาจหยุดทำงานเนื่องจาก - เครื่องอัดนำข้อมูลจาก Object Storage และรวมเข้ากับข้อมูลชิ้นใหญ่ เนื่องจากเครื่องอัดไม่ได้รับการซิงโครไนซ์กับ Sidecars สิ่งต่อไปนี้สามารถเกิดขึ้นได้: Sidecar ยังไม่มีเวลาในการทำบล็อกให้เสร็จสมบูรณ์ Compactor ตัดสินใจว่าบล็อกนี้ได้ถูกเขียนเสร็จสมบูรณ์แล้ว รถบดเริ่มอ่านมัน มันไม่ได้อ่านบล็อกทั้งหมดและหยุดทำงาน ดูรายละเอียด .
Store Gateway อาจส่งคืนข้อมูลที่ไม่สอดคล้องกันเนื่องจากการแข่งระหว่าง Compactor และ Sidecars สิ่งเดียวกันนี้เกิดขึ้นที่นี่ เนื่องจาก Store Gateway ไม่ได้ซิงโครไนซ์กับ Compactors และ Sidecars แต่อย่างใด ดังนั้น สภาพการแข่งขันอาจเกิดขึ้นเมื่อ Store Gateway ไม่เห็นข้อมูลบางส่วนหรือเห็นข้อมูลที่ไม่จำเป็น
องค์ประกอบการสืบค้นในธานอสโดยค่าเริ่มต้นจะส่งกลับผลลัพธ์บางส่วนหากรถไซด์คาร์หรือเกตเวย์ร้านค้าบางตัวไม่พร้อมใช้งานในขณะนี้ คุณจะได้รับข้อมูลบางส่วน และคุณจะไม่รู้ด้วยซ้ำว่าคุณไม่ได้รับข้อมูลทั้งหมด นี่คือวิธีการทำงานตามค่าเริ่มต้น ในสถานการณ์ที่คล้ายกัน VictoriaMetrics จะส่งคืนข้อมูลที่ทำเครื่องหมายว่าเป็นบางส่วน
VictoriaMetrics ต่างจากธานอสตรงที่ข้อมูลแทบจะไม่สูญเสียเลย แม้ว่าการเชื่อมต่อจาก Prometheus ไปยัง VictoriaMetrics จะถูกขัดจังหวะ แต่ก็ไม่เป็นปัญหา เนื่องจาก Prometheus ยังคงบันทึกข้อมูลใหม่ขาเข้าใน Write Ahead Log ซึ่งมีขนาด 2 ชั่วโมง หากคุณคืนค่าการเชื่อมต่อกับ VictoriaMetrics ภายในสองชั่วโมง ข้อมูลของคุณจะไม่สูญหาย โพรมีธีอุส .
ต่างจากธานอสซึ่งเขียนข้อมูลลงในพื้นที่เก็บข้อมูลอ็อบเจ็กต์หลังจากผ่านไปสองชั่วโมงเท่านั้น Prometheus จะจำลองข้อมูลโดยอัตโนมัติโดยใช้โปรโตคอลการเขียนระยะไกลไปยังพื้นที่เก็บข้อมูลระยะไกล เช่น VictoriaMetrics คุณไม่กลัวที่จะสูญเสียที่เก็บข้อมูลในเครื่องใน Prometheus หากเขาสูญเสียที่เก็บข้อมูลในเครื่องกะทันหัน ในกรณีที่เลวร้ายที่สุด คุณจะสูญเสียข้อมูลวินาทีสุดท้ายที่ไม่มีเวลาบันทึกในที่จัดเก็บข้อมูลระยะไกล
Kubernetes จัดการคลัสเตอร์โดยอัตโนมัติ ไม่เหมือนธานอส เป็นการยากที่จะวางส่วนประกอบของ Thanos ทั้งหมดไว้ในคลัสเตอร์ Kubernetes เดียว ซึ่งแตกต่างจากส่วนประกอบของคลัสเตอร์ VictoriaMetrics
VictoriaMetrics มีการอัปเดตเวอร์ชันใหม่ที่เรียบง่ายมาก เพียงหยุด VictoriaMetrics อัปเดตไบนารีแล้วเปิดใช้งาน เมื่อหยุดผ่านสัญญาณ SIGINT ไบนารี VictoriaMetrics ทั้งหมดจะปิดระบบอย่างสง่างาม พวกเขาบันทึกข้อมูลที่จำเป็นอย่างถูกต้องปิดการเชื่อมต่อขาเข้าอย่างถูกต้องเพื่อไม่ให้สูญเสียสิ่งใด ดังนั้นคุณจะไม่สูญเสียอะไรเลยเมื่ออัปเกรด
VictoriaMetrics ทำให้การขยายคลัสเตอร์เป็นเรื่องง่ายมาก เพียงเพิ่มส่วนประกอบที่จำเป็นแล้วทำงานต่อ
เกี่ยวกับข้อผิดพลาดใน Thanos และ VictoriaMetrics
ธานอสมีข้อผิดพลาดดังต่อไปนี้ โพรต้องจัดเก็บข้อมูลในช่วงสองชั่วโมงที่ผ่านมา หากพวกมันสูญหาย คุณจะสูญเสียมันไปโดยสิ้นเชิง เนื่องจากยังไม่ได้เขียนลงใน Object Storage เช่น S3
ส่วนประกอบ Store Gateway และส่วนประกอบเครื่องอัดอาจต้องใช้หน่วยความจำจำนวนมากในการทำงานกับ Object Storage ขนาดใหญ่ หากมีไฟล์ขนาดเล็กจำนวนมากจัดเก็บอยู่ที่นั่น ยิ่งจำนวนและขนาดของไฟล์มากเท่าใด Store Gateway และ RAM ของการบีบอัดก็จะยิ่งมากขึ้นเท่านั้นในการจัดเก็บข้อมูลเมตา ธานอสมีปัญหามากมายเกี่ยวกับความจริงที่ว่า .
ธานอสถูกโฆษณาให้ขยายขนาดไปเรื่อยๆ ตามจำนวนโพรมีธีอุสที่คุณมี นี้เป็นจริงไม่เป็นความจริง เนื่องจากคำขอทั้งหมดต้องผ่านองค์ประกอบ Query ซึ่งจะต้องสำรวจส่วนประกอบ Store Gateway ทั้งหมดและส่วนประกอบ Sidecar ทั้งหมดพร้อมกัน ให้ดึงข้อมูลจากที่นั่นแล้วประมวลผลล่วงหน้า แน่นอนว่าความเร็วในการร้องขอนั้นถูกจำกัดด้วยลิงก์ที่อ่อนแอที่สุด เกตเวย์ร้านค้าที่ช้าที่สุด หรือไซด์คาร์ที่ช้าที่สุด
ส่วนประกอบเหล่านี้อาจถูกโหลดไม่สม่ำเสมอ ตัวอย่างเช่น คุณมี Prometheus ซึ่งรวบรวมเมตริกนับล้านต่อวินาที และมี Prometheus ซึ่งรวบรวมเมตริกนับพันต่อวินาที Prometheus ซึ่งรวบรวมตัวชี้วัดนับล้านต่อวินาที ทำให้เซิร์ฟเวอร์ที่ทำงานอยู่มีภาระงานสูงกว่ามาก ด้วยเหตุนี้ Sidecar จึงทำงานช้าลงที่นั่น และโดยทั่วไปทุกอย่างทำงานช้าที่นั่น และองค์ประกอบแบบสอบถามจะดึงข้อมูลจากที่นั่นช้ามาก ดังนั้น ประสิทธิภาพของคลัสเตอร์ทั้งหมดของคุณจะถูกจำกัดโดย Sidecar ที่ช้านี้
ตามค่าเริ่มต้น ธานอสจะให้ข้อมูลบางส่วนหากรถไซด์คาร์บางตัวและเกตเวย์ร้านค้าไม่พร้อมใช้งาน ตัวอย่างเช่น หาก Sidecars ของคุณกระจัดกระจายไปทั่วโลกในศูนย์ข้อมูลต่างๆ โอกาสที่จะเกิดความล้มเหลวในการเชื่อมต่อและความไม่พร้อมใช้งานของส่วนประกอบก็จะเพิ่มขึ้นอย่างมาก ดังนั้น ในกรณีส่วนใหญ่ คุณจะได้รับข้อมูลบางส่วนโดยไม่รู้ตัวด้วยซ้ำ
VictoriaMetrics ก็มีข้อผิดพลาดเช่นกัน ข้อผิดพลาดประการแรกคือตัวเลือกที่จำกัดจำนวน RAM ที่ใช้สำหรับแคช VictoriaMetrics ตามค่าเริ่มต้น จะเท่ากับ 60% ของ RAM บนเครื่องที่ VictoriaMetrics กำลังทำงานอยู่ หรือ 60% ของ RAM ของพ็อด VictoriaMetrics ใน Kubernetes
หากคุณเปลี่ยนค่านี้ไม่ถูกต้อง คุณสามารถทำลายประสิทธิภาพของ VictoriaMetrics ได้ ตัวอย่างเช่น หากคุณตั้งค่าต่ำเกินไป ข้อมูลอาจไม่พอดีกับแคช VictoriaMetrics อีกต่อไป ด้วยเหตุนี้เธอจะต้องทำงานพิเศษและโหลดโปรเซสเซอร์และดิสก์ หากคุณทำให้ตัวเลือกนี้ใหญ่เกินไป ประการแรกโอกาสที่ VictoriaMetrics จะล้มเหลวโดยมีข้อผิดพลาดหน่วยความจำไม่เพียงพอจะเพิ่มขึ้นประการแรกและประการที่สองจะนำไปสู่ความจริงที่ว่าจะมี RAM เหลือน้อยมากในหน่วยความจำระบบปฏิบัติการสำหรับ แคชไฟล์ และ VictoriaMetrics อาศัยแคชของไฟล์เพื่อประสิทธิภาพ หากยังไม่เพียงพอ ภาระบนดิสก์อาจเพิ่มขึ้นอย่างมาก ดังนั้นคำแนะนำ: อย่าเปลี่ยนพารามิเตอร์เว้นแต่จำเป็นจริงๆ
ตัวเลือกที่สอง นี่คือระยะเวลาการเก็บรักษา - ระยะเวลาที่กำหนดเป็น 1 เดือนตามค่าเริ่มต้น นี่คือระยะเวลาที่ VictoriaMetrics จัดเก็บข้อมูล หลังจากช่วงเวลานี้ VictoriaMetrics จะลบข้อมูล
หลายๆ คนใช้งาน VictoriaMetrics โดยไม่มีพารามิเตอร์นี้และบันทึกข้อมูลเป็นเวลาหนึ่งเดือน แล้วพวกเขาก็ถามว่า: ทำไมข้อมูลของเดือนที่แล้วถึงหายไป? เนื่องจากระยะเวลาการเก็บรักษาเริ่มต้นคือ 1 เดือน ดังนั้นจึงต้องทราบและกำหนด RetentionPeriod ที่ถูกต้อง
มาดูคุณสมบัติพิเศษกันดีกว่า
ธานอสมีคุณลักษณะที่เรียกว่าการลดขนาดตัวอย่าง: ช่วงเวลา 5 นาทีและรายชั่วโมง ซึ่งบ่อยครั้ง - หากคุณค้นหาใน Google และดูปัญหาของพวกเขาบน GitHub มีปัญหามากมายที่เกี่ยวข้องกับการลดขนาดตัวอย่างนี้ ซึ่งบางครั้งอาจทำงานไม่ถูกต้อง หรือไม่ทำงานตามที่ผู้ใช้คาดหวัง
ธานอสมีการขจัดข้อมูลซ้ำซ้อนสำหรับคู่ Prometheus HA เมื่อ Prometheus สองตัวรวบรวมหน่วยเมตริกเดียวกันจากเป้าหมายเดียวกัน และธานอสก็จัดเก็บไว้ใน Object Storage ธานอสสามารถขจัดข้อมูลซ้ำซ้อนได้อย่างเหมาะสม ซึ่งต่างจาก VictoriaMetrics
ธานอสมีองค์ประกอบการแจ้งเตือนที่อยู่ในแผนผังธานอส แต่เขา .
ธานอสมีข้อได้เปรียบตรงที่ธานอสและโพรมีธีอุสใช้รหัสเดียวกัน Thanos และ Prometheus ได้รับการพัฒนาโดยนักพัฒนาคนเดียวกัน ด้วยการปรับปรุงธานอสหรือโพรมีธีอุส อีกด้านหนึ่งก็ชนะ
คุณสมบัติหลักของ VictoriaMetrics คือ MetricsQL สิ่งเหล่านี้คือส่วนขยาย VictoriaMetrics สำหรับ PromQL ซึ่งฉันได้พูดถึงในงานติดตามตรวจสอบครั้งใหญ่ครั้งก่อน
VictoriaMetrics รองรับการโหลดข้อมูลโดยใช้โปรโตคอลที่แตกต่างกันมากมาย VictoriaMetrics ไม่เพียงแต่สามารถรับข้อมูลจาก Prometheus เท่านั้น แต่ยังผ่านทางโปรโตคอล Influx, OpenTSDB และ Graphite อีกด้วย
ข้อมูล VictoriaMetrics ใช้พื้นที่น้อยกว่ามากเมื่อเทียบกับ Thanos และ Prometheus
หากคุณบันทึกข้อมูลจริง ผู้ใช้จะพูดถึงขนาดข้อมูลบนดิสก์ที่ลดลง 2-5 เท่า เมื่อเทียบกับ Prometheus และ Thanos
ข้อดีอีกประการหนึ่งของ VictoriaMetrics ก็คือได้รับการปรับให้เหมาะสมกับความเร็ว
ลองดูที่ต้นทุนของโครงสร้างพื้นฐาน
ข้อดีอย่างหนึ่งของธานอสก็คือสามารถเก็บข้อมูลไว้ในที่เก็บข้อมูลอ็อบเจ็กต์ซึ่งมีราคาค่อนข้างถูก
เมื่อจัดเก็บข้อมูลในพื้นที่จัดเก็บอ็อบเจ็กต์ คุณต้องชำระค่าดำเนินการเขียนและอ่านข้อมูล ($10 ต่อการดำเนินการล้านครั้ง) เมื่อคุณเขียนข้อมูลไปยังพื้นที่จัดเก็บอ็อบเจ็กต์ คุณจะต้องชำระค่าใช้จ่ายโฮสติ้งสำหรับการอัปโหลดข้อมูลไปยังอินเทอร์เน็ต หากคลัสเตอร์ของคุณไม่ได้อยู่ใน AWS ก็จะไม่มีค่าใช้จ่ายที่นั่น เมื่อคุณอ่านข้อมูล คุณจะต้องจ่ายระหว่าง 10 ถึง 230 เหรียญสหรัฐฯ ต่อ 1TB สิ่งนี้อาจมีนัยสำคัญหากคุณค้นหาข้อมูลประวัติจากคลัสเตอร์ Thanos บ่อยครั้ง
สำหรับคลัสเตอร์ Thanos คุณจะต้องจ่ายค่าเซิร์ฟเวอร์สำหรับ Compact, Store Gateway, ส่วนประกอบการสืบค้นที่ต้องใช้หน่วยความจำจำนวนมาก และ CPU สำหรับข้อมูลจำนวนมาก
VictoriaMetrics มีค่าใช้จ่ายดังต่อไปนี้ หากคุณเก็บข้อมูลไว้ในไดรฟ์ GCE HDD จะมีราคาอยู่ที่ 40 เหรียญสหรัฐสำหรับ 1TB สำหรับ VictoriaMetrics ไดรฟ์ HDD ธรรมดาก็เพียงพอแล้ว ไม่จำเป็นต้องใช้ SSD ซึ่งมีราคาสูงกว่าถึงห้าเท่า VictoriaMetrics ได้รับการปรับให้เหมาะสมสำหรับ HDD
VictoriaMetrics ต้องการเซิร์ฟเวอร์สำหรับส่วนประกอบ: ส่วนประกอบแบบ Single-nod หรือแบบคลัสเตอร์ ซึ่งแตกต่างจากส่วนประกอบของ Thanos ที่ต้องการ CPU และ RAM น้อยกว่ามากและจะมีราคาถูกกว่าตามนั้น
ตัวอย่างของการนำไปปฏิบัติ
Thanos มีตัวอย่างการใช้งานใน Gitlab Gitlab ทำงานบนธานอสทั้งหมด แต่ไม่ใช่ทุกอย่างจะราบรื่นนัก หากมองดูพวกเขา แล้วคุณจะเห็นว่ามีบางส่วนอยู่เรื่อยๆ : มีหน่วยความจำไม่เพียงพอสำหรับ Store Gateway หรือส่วนประกอบ Query พวกเขาต้องเพิ่มจำนวนหน่วยความจำอย่างต่อเนื่อง
ด้วยเหตุนี้ค่าใช้จ่ายในการแก้ไขปัญหาเหล่านี้จึงเพิ่มขึ้น
การดำเนินการครั้งที่สองซึ่งอาจประสบความสำเร็จมากกว่าคือบริษัท Improbable ซึ่งเริ่มพัฒนาธานอส พวกเขาเผยแพร่ซอร์สโค้ดธานอส Improbable เป็นบริษัทที่พัฒนาเอ็นจิ้นเกม
VictoriaMetrics มีตัวอย่างการใช้งานสาธารณะ:
- เครื่องมือสร้างเว็บไซต์ wix.com
- Adidas กำลังนำ VictoriaMetrics ไปใช้ และยังได้นำเสนอในงาน PromCon 2019 ครั้งล่าสุดด้วย
- TrafficStars - เครือข่ายโฆษณา
- Seznam.cz เป็นเครื่องมือค้นหายอดนิยมของเช็ก
จากนั้นก็มีบริษัทที่ไม่มีชื่อซึ่งฉันไม่สามารถตั้งชื่อได้ในขณะนี้ พวกเขาไม่ยินยอม
- ผู้พัฒนาเกมรายใหญ่รายหนึ่ง ใหญ่กว่าฉันไม่น่าเป็นไปได้
- นักพัฒนาซอฟต์แวร์กราฟิกรายใหญ่
- ธนาคารรัสเซียขนาดใหญ่
- ผู้ผลิตกังหันลมในยุโรปที่ประสบความสำเร็จในการทดสอบ VictoriaMetrics ผู้ผลิตรายนี้กำลังใช้ VictoriaMetrics เพื่อติดตามข้อมูลที่รวบรวมจากกังหันลมในอัตรา 50 ตัวอย่างต่อวินาทีต่อเซ็นเซอร์ กังหันลมแต่ละตัวมีเซ็นเซอร์หลายร้อยตัว พวกเขามีกังหันลมหลายร้อยตัว
- สายการบินรัสเซียที่ต้องการใช้ VictoriaMetrics แต่ก็ยังทำไม่ได้ เราอยู่ในขั้นตอนสัญญากับพวกเขา
สรุปผลการวิจัย
VictoriaMetrics และ Thanos แก้ปัญหาที่คล้ายกัน แต่ด้วยวิธีที่ต่างกัน:
- มุมมองแบบสอบถามทั่วโลก
- มาตราส่วนแนวนอน
- การเก็บรักษาโดยพลการ
ขอบคุณ
เรากำลังรอคุณอยู่ที่ของเรา .
เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ , โปรด.
คุณใช้อะไรเป็นที่จัดเก็บข้อมูลระยะยาวสำหรับ Prometheus
35,3% Thanos6
0,0% คอร์เทกซ์0
0,0% M3DB0
41,2% วิกตอเรียเมตริก7
23,5% อื่นๆ4
ผู้ใช้ 17 คนโหวต ผู้ใช้ 16 รายงดออกเสียง
ที่มา: will.com
