การแปลบทความจัดทำขึ้นเฉพาะสำหรับนักศึกษาของหลักสูตร .
เป็นนักพัฒนาซอฟต์แวร์ ผู้คลั่งไคล้ Go และนักแก้ปัญหา เขายังเป็นผู้ดูแล Prometheus และผู้ร่วมก่อตั้งเครื่องมือ Kubernetes SIG อีกด้วย ในอดีต เขาเป็นวิศวกรฝ่ายผลิตที่ SoundCloud และเป็นผู้นำทีมตรวจสอบที่ CoreOS ปัจจุบันทำงานที่ Google
- วิศวกรโครงสร้างพื้นฐานที่ Improbable เขามีความสนใจในเทคโนโลยีใหม่และปัญหาของระบบแบบกระจาย เขามีประสบการณ์การเขียนโปรแกรมระดับต่ำที่ Intel, ประสบการณ์ผู้สนับสนุนที่ Mesos และประสบการณ์การผลิต SRE ระดับโลกที่ Improbable ทุ่มเทให้กับการปรับปรุงโลกแห่งไมโครเซอร์วิส ความรักสามประการของเขา: Golang, โอเพ่นซอร์สและวอลเลย์บอล
เมื่อดูผลิตภัณฑ์เรือธง SpatialOS ของเรา คุณจะเดาได้เลยว่า Improbable ต้องการโครงสร้างพื้นฐานระบบคลาวด์ระดับโลกที่มีไดนามิกสูง พร้อมด้วยคลัสเตอร์ Kubernetes หลายสิบรายการ เราเป็นคนแรกๆ ที่ใช้ระบบตรวจสอบ . Prometheus สามารถติดตามตัววัดนับล้านแบบเรียลไทม์ และมาพร้อมกับภาษาการสืบค้นอันทรงพลังที่ช่วยให้คุณสามารถดึงข้อมูลที่คุณต้องการได้
ความเรียบง่ายและความน่าเชื่อถือของ Prometheus เป็นหนึ่งในข้อได้เปรียบหลัก อย่างไรก็ตาม เมื่อเราผ่านระดับหนึ่งไปแล้ว เราก็พบข้อเสียหลายประการ เพื่อแก้ไขปัญหาเหล่านี้เราได้พัฒนา เป็นโปรเจ็กต์โอเพ่นซอร์สที่สร้างขึ้นโดย Improbable เพื่อแปลงคลัสเตอร์ Prometheus ที่มีอยู่ให้กลายเป็นระบบตรวจสอบเดียวพร้อมพื้นที่จัดเก็บข้อมูลประวัติแบบไม่จำกัด ธานอสมีอยู่บน Github .
เป้าหมายของเรากับธานอส
ในระดับหนึ่งปัญหาเกิดขึ้นซึ่งเกินความสามารถของวานิลลาโพรมีธีอุส จะจัดเก็บข้อมูลประวัติขนาดเพตะไบต์ได้อย่างน่าเชื่อถือและประหยัดได้อย่างไร สามารถทำได้โดยไม่กระทบต่อเวลาตอบสนองหรือไม่ เป็นไปได้ไหมที่จะเข้าถึงตัววัดทั้งหมดที่อยู่ในเซิร์ฟเวอร์ Prometheus ที่แตกต่างกันด้วยคำขอ API เดียว มีวิธีใดบ้างที่จะรวมข้อมูลที่จำลองแบบซึ่งรวบรวมโดยใช้ Prometheus HA เข้าด้วยกัน
เพื่อแก้ไขปัญหาเหล่านี้ เราจึงสร้างธานอสขึ้นมา ส่วนต่อไปนี้จะอธิบายวิธีที่เราจัดการกับปัญหาเหล่านี้และอธิบายเป้าหมายของเรา
การสืบค้นข้อมูลจากอินสแตนซ์ Prometheus หลายรายการ (การสืบค้นส่วนกลาง)
Prometheus นำเสนอแนวทางการทำงานในการแบ่งส่วน แม้แต่เซิร์ฟเวอร์ Prometheus ตัวเดียวก็ยังมีความสามารถในการปรับขนาดที่เพียงพอเพื่อช่วยให้ผู้ใช้ไม่ต้องยุ่งยากกับการแบ่งส่วนแนวนอนในกรณีการใช้งานเกือบทั้งหมด
แม้ว่านี่จะเป็นโมเดลการปรับใช้ที่ยอดเยี่ยม แต่บ่อยครั้งก็จำเป็นต้องเข้าถึงข้อมูลบนเซิร์ฟเวอร์ Prometheus ที่แตกต่างกันผ่าน API หรือ UI เดียว ซึ่งเป็นมุมมองโดยรวม แน่นอนว่า เป็นไปได้ที่จะแสดงหลายคำค้นหาในแผง Grafana เดียว แต่แต่ละคำค้นหาสามารถดำเนินการได้บนเซิร์ฟเวอร์ Prometheus เดียวเท่านั้น ในทางกลับกัน ด้วย Thanos คุณสามารถสืบค้นและรวบรวมข้อมูลจากเซิร์ฟเวอร์ Prometheus หลายเครื่องได้ เนื่องจากเซิร์ฟเวอร์เหล่านี้ทั้งหมดสามารถเข้าถึงได้จากจุดสิ้นสุดเดียว
ก่อนหน้านี้ เพื่อให้ได้รับมุมมองทั่วโลกใน Improbable เราได้จัดอินสแตนซ์ Prometheus ออกเป็นหลายระดับ . นี่หมายถึงการสร้างเซิร์ฟเวอร์เมตา Prometheus หนึ่งเครื่องที่รวบรวมตัววัดบางส่วนจากเซิร์ฟเวอร์ลีฟแต่ละเครื่อง
วิธีการนี้พิสูจน์แล้วว่าเป็นปัญหา สิ่งนี้ส่งผลให้เกิดการกำหนดค่าที่ซับซ้อนมากขึ้น การเพิ่มจุดที่อาจเกิดความล้มเหลวเพิ่มเติม และการใช้กฎที่ซับซ้อนเพื่อให้แน่ใจว่าปลายทางแบบรวมศูนย์จะได้รับเฉพาะข้อมูลที่ต้องการเท่านั้น นอกจากนี้ สหพันธรัฐประเภทนี้ไม่อนุญาตให้คุณรับมุมมองทั่วโลกที่แท้จริง เนื่องจากข้อมูลบางส่วนไม่สามารถใช้งานได้จากคำขอ API เดียว
ที่เกี่ยวข้องอย่างใกล้ชิดกับสิ่งนี้คือมุมมองแบบรวมของข้อมูลที่รวบรวมบนเซิร์ฟเวอร์ Prometheus ความพร้อมใช้งานสูง (HA) โมเดล HA ของ Prometheus รวบรวมข้อมูลสองครั้งอย่างอิสระ ซึ่งง่ายมากจนไม่มีอะไรง่ายไปกว่านี้อีกแล้ว อย่างไรก็ตาม การใช้มุมมองแบบรวมและกรองข้อมูลซ้ำของทั้งสองสตรีมจะสะดวกกว่ามาก
แน่นอนว่าจำเป็นต้องมีเซิร์ฟเวอร์ Prometheus ที่พร้อมใช้งานสูง ที่ Improbable เราให้ความสำคัญกับการตรวจสอบข้อมูลแบบนาทีต่อนาทีอย่างจริงจัง แต่การมีอินสแตนซ์ Prometheus หนึ่งรายการต่อคลัสเตอร์ถือเป็นความล้มเหลวเพียงจุดเดียว ข้อผิดพลาดในการกำหนดค่าหรือความล้มเหลวของฮาร์ดแวร์อาจทำให้ข้อมูลสำคัญสูญหายได้ แม้แต่การปรับใช้งานแบบธรรมดาก็อาจทำให้เกิดการหยุดชะงักเล็กน้อยในการรวบรวมเมทริก เนื่องจากการรีสตาร์ทอาจใช้เวลานานกว่าช่วงเวลาการคัดลอกอย่างมาก
การจัดเก็บข้อมูลประวัติที่เชื่อถือได้
พื้นที่จัดเก็บตัววัดราคาถูก รวดเร็ว และระยะยาวคือความฝันของเรา (แบ่งปันโดยผู้ใช้ Prometheus ส่วนใหญ่) ใน Improbable เราถูกบังคับให้กำหนดค่าระยะเวลาการเก็บรักษาตัววัดเป็นเก้าวัน (สำหรับ Prometheus 1.8) นี่เป็นการเพิ่มข้อจำกัดที่ชัดเจนว่าเราจะมองย้อนกลับไปได้ไกลแค่ไหน
Prometheus 2.0 ได้รับการปรับปรุงในเรื่องนี้ เนื่องจากจำนวนอนุกรมเวลาไม่ส่งผลกระทบต่อประสิทธิภาพโดยรวมของเซิร์ฟเวอร์อีกต่อไป (ดู ). อย่างไรก็ตาม Prometheus จะเก็บข้อมูลไว้ในดิสก์ภายในเครื่อง แม้ว่าการบีบอัดข้อมูลที่มีประสิทธิภาพสูงสามารถลดการใช้งาน SSD ภายในได้อย่างมาก แต่ท้ายที่สุดแล้ว ยังคงมีข้อจำกัดเกี่ยวกับจำนวนข้อมูลประวัติที่สามารถจัดเก็บได้
นอกจากนี้ ที่ Improbable เราให้ความสำคัญกับความน่าเชื่อถือ ความเรียบง่าย และต้นทุน ดิสก์ในเครื่องขนาดใหญ่ใช้งานและสำรองข้อมูลได้ยากกว่า มีค่าใช้จ่ายสูงกว่าและต้องการเครื่องมือสำรองข้อมูลเพิ่มเติม ส่งผลให้เกิดความซับซ้อนที่ไม่จำเป็น
การสุ่มตัวอย่าง
เมื่อเราเริ่มทำงานกับข้อมูลในอดีต เราพบว่ามีปัญหาพื้นฐานกับ big-O ที่ทำให้การสืบค้นช้าลงและช้าลงในขณะที่เราทำงานกับข้อมูลเป็นสัปดาห์ เดือน และปี
วิธีแก้ปัญหามาตรฐานสำหรับปัญหานี้คือ (downsampling) - ลดความถี่ในการสุ่มตัวอย่างสัญญาณ ด้วยการสุ่มตัวอย่างต่ำ เราสามารถ “ลดขนาด” ลงในช่วงเวลาที่กว้างขึ้น และรักษาจำนวนตัวอย่างให้เท่าเดิม และทำให้การสืบค้นตอบสนอง
การสุ่มตัวอย่างข้อมูลเก่าเป็นข้อกำหนดที่หลีกเลี่ยงไม่ได้สำหรับโซลูชันการจัดเก็บข้อมูลระยะยาว และอยู่นอกเหนือขอบเขตของ Vanilla Prometheus
เป้าหมายเพิ่มเติม
เป้าหมายเดิมประการหนึ่งของโครงการธานอสคือการบูรณาการเข้ากับการติดตั้ง Prometheus ที่มีอยู่ได้อย่างราบรื่น เป้าหมายที่สองคือความสะดวกในการใช้งานโดยมีอุปสรรคในการเข้าน้อยที่สุด การขึ้นต่อกันใดๆ ควรจะตอบสนองได้อย่างง่ายดายสำหรับผู้ใช้ทั้งผู้ใช้รายเล็กและรายใหญ่ ซึ่งหมายถึงต้นทุนพื้นฐานที่ต่ำด้วย
สถาปัตยกรรมธานอส
หลังจากระบุเป้าหมายของเราไว้ในส่วนที่แล้ว เรามาดูกันว่าธานอสแก้ไขปัญหาเหล่านี้อย่างไร
มุมมองทั่วโลก
หากต้องการรับมุมมองโดยรวมนอกเหนือจากอินสแตนซ์ Prometheus ที่มีอยู่ เราจำเป็นต้องเชื่อมโยงจุดเข้าคำขอเดียวกับเซิร์ฟเวอร์ทั้งหมด นี่คือสิ่งที่ส่วนประกอบธานอสทำ . มีการปรับใช้ถัดจากเซิร์ฟเวอร์ Prometheus แต่ละเซิร์ฟเวอร์และทำหน้าที่เป็นพร็อกซี โดยให้บริการข้อมูล Prometheus ในเครื่องผ่าน gRPC Store API ทำให้สามารถดึงข้อมูลอนุกรมเวลาด้วยแท็กและช่วงเวลา
อีกด้านหนึ่งคือส่วนประกอบ Querier ที่ไม่มีสถานะซึ่งขยายขนาดออก ซึ่งทำมากกว่าแค่ตอบคำถาม PromQL ผ่าน Prometheus HTTP API มาตรฐานเพียงเล็กน้อย Querier, Sidecar และส่วนประกอบอื่นๆ ของ Thanos สื่อสารผ่าน .
- เมื่อได้รับคำขอ Querier จะเชื่อมต่อกับเซิร์ฟเวอร์ Store API ที่เกี่ยวข้อง ซึ่งก็คือ Sidecar ของเรา และรับข้อมูลอนุกรมเวลาจากเซิร์ฟเวอร์ Prometheus ที่เกี่ยวข้อง
- หลังจากนั้นจะรวมการตอบกลับและดำเนินการแบบสอบถาม PromQL กับสิ่งเหล่านั้น Querier สามารถผสานทั้งข้อมูลที่แยกจากกันและข้อมูลซ้ำจากเซิร์ฟเวอร์ Prometheus HA
วิธีนี้จะไขปริศนาชิ้นสำคัญของเรา - รวมข้อมูลจากเซิร์ฟเวอร์ Prometheus ที่แยกออกมาไว้ในมุมมองเดียว ที่จริงแล้วธานอสสามารถใช้ได้กับฟีเจอร์นี้เท่านั้น ไม่จำเป็นต้องทำการเปลี่ยนแปลงกับเซิร์ฟเวอร์ Prometheus ที่มีอยู่!
อายุการเก็บรักษาไม่จำกัด!
อย่างไรก็ตาม ไม่ช้าก็เร็วเราจะต้องจัดเก็บข้อมูลเกินกว่าเวลาเก็บรักษา Prometheus ปกติ เราเลือกพื้นที่เก็บข้อมูลอ็อบเจ็กต์เพื่อจัดเก็บข้อมูลประวัติ มีให้บริการอย่างกว้างขวางในระบบคลาวด์และศูนย์ข้อมูลภายในองค์กร และคุ้มค่าคุ้มราคามาก นอกจากนี้ พื้นที่จัดเก็บอ็อบเจ็กต์เกือบทั้งหมดยังมีให้ใช้งานได้ผ่าน S3 API ที่รู้จักกันดี
Prometheus เขียนข้อมูลจาก RAM ไปยังดิสก์ทุกๆ สองชั่วโมงโดยประมาณ บล็อกข้อมูลที่เก็บไว้ประกอบด้วยข้อมูลทั้งหมดในช่วงเวลาที่กำหนดและไม่เปลี่ยนรูป วิธีนี้จะสะดวกมากเพราะ Thanos Sidecar สามารถดูไดเร็กทอรีข้อมูลของ Prometheus และเมื่อมีบล็อกใหม่ให้โหลดลงในที่เก็บข้อมูลออบเจ็กต์
การโหลดลงในที่เก็บข้อมูลอ็อบเจ็กต์ทันทีหลังจากเขียนลงดิสก์ยังช่วยให้คุณรักษาความเรียบง่ายของสแครปเปอร์ (Prometheus และ Thanos Sidecar) ซึ่งทำให้การสนับสนุน ต้นทุน และการออกแบบระบบง่ายขึ้น
อย่างที่คุณเห็นการสำรองข้อมูลนั้นง่ายมาก แต่การสืบค้นข้อมูลในที่เก็บข้อมูลอ็อบเจ็กต์ล่ะ?
ส่วนประกอบ Thanos Store ทำหน้าที่เป็นพร็อกซีในการดึงข้อมูลจากที่เก็บข้อมูลอ็อบเจ็กต์ เช่นเดียวกับ Thanos Sidecar มันมีส่วนร่วมในกลุ่มซุบซิบและใช้ Store API ด้วยวิธีนี้ Querier ที่มีอยู่สามารถปฏิบัติต่อมันได้เหมือนกับ Sidecar ซึ่งเป็นแหล่งข้อมูลอนุกรมเวลาอีกแหล่งหนึ่ง โดยไม่จำเป็นต้องกำหนดค่าพิเศษ
บล็อกข้อมูลอนุกรมเวลาประกอบด้วยไฟล์ขนาดใหญ่หลายไฟล์ การโหลดตามความต้องการจะไม่มีประสิทธิภาพมากนัก และการแคชไว้ในเครื่องจะต้องใช้หน่วยความจำและพื้นที่ดิสก์จำนวนมาก
Store Gateway รู้วิธีจัดการรูปแบบพื้นที่จัดเก็บข้อมูล Prometheus แทน ด้วยตัวกำหนดเวลาการสืบค้นอัจฉริยะและการแคชเฉพาะส่วนดัชนีที่จำเป็นของบล็อก ทำให้สามารถลดการสืบค้นที่ซับซ้อนให้เหลือจำนวนคำขอ HTTP ขั้นต่ำไปยังไฟล์พื้นที่จัดเก็บออบเจ็กต์ได้ ด้วยวิธีนี้ คุณสามารถลดจำนวนคำขอลงได้สี่ถึงหกลำดับขนาด และได้รับเวลาตอบสนองที่โดยทั่วไปยากต่อการแยกแยะจากคำขอไปยังข้อมูลบน SSD ภายในเครื่อง
ดังที่แสดงในแผนภาพด้านบน Thanos Querier ลดต้นทุนต่อการสืบค้นข้อมูลพื้นที่จัดเก็บอ็อบเจ็กต์ได้อย่างมาก โดยใช้ประโยชน์จากรูปแบบพื้นที่จัดเก็บ Prometheus และการวางข้อมูลที่เกี่ยวข้องไว้เคียงข้างกัน เมื่อใช้วิธีการนี้ เราสามารถรวมคำขอเดียวจำนวนมากให้เป็นการดำเนินการจำนวนมากขั้นต่ำได้
การบดอัดและการสุ่มตัวอย่าง
เมื่อบล็อกใหม่ของข้อมูลอนุกรมเวลาถูกโหลดลงในพื้นที่จัดเก็บอ็อบเจ็กต์ได้สำเร็จ เราจะถือว่าข้อมูลดังกล่าวเป็นข้อมูล "ในอดีต" ซึ่งพร้อมใช้งานทันทีผ่าน Store Gateway
อย่างไรก็ตาม หลังจากผ่านไประยะหนึ่ง บล็อกจากแหล่งเดียว (Prometheus ที่มี Sidecar) จะสะสมและไม่ใช้ศักยภาพในการจัดทำดัชนีเต็มรูปแบบอีกต่อไป เพื่อแก้ไขปัญหานี้ เราได้แนะนำส่วนประกอบอื่นที่เรียกว่า Compactor เพียงใช้กลไกการบดอัดในเครื่องของ Prometheus กับข้อมูลประวัติในพื้นที่จัดเก็บอ็อบเจ็กต์ และสามารถรันเป็นงานแบทช์ตามระยะเวลาธรรมดาได้
ด้วยการบีบอัดที่มีประสิทธิภาพ การสืบค้นพื้นที่จัดเก็บข้อมูลเป็นระยะเวลานานไม่ก่อให้เกิดปัญหาในแง่ของขนาดข้อมูล อย่างไรก็ตาม ต้นทุนที่อาจเกิดขึ้นในการคลายแพ็กค่านับพันล้านค่าและเรียกใช้ผ่านตัวประมวลผลคิวรีจะส่งผลให้เวลาดำเนินการคิวรีเพิ่มขึ้นอย่างมากอย่างหลีกเลี่ยงไม่ได้ ในทางกลับกัน เนื่องจากมีจุดข้อมูลหลายร้อยจุดต่อพิกเซลบนหน้าจอ จึงเป็นไปไม่ได้เลยที่จะแสดงข้อมูลด้วยความละเอียดสูงสุด ดังนั้นการลดขนาดตัวอย่างจึงไม่เพียงแต่เป็นไปได้เท่านั้น แต่ยังจะไม่ทำให้สูญเสียความแม่นยำอย่างเห็นได้ชัดอีกด้วย
หากต้องการลดขนาดข้อมูล Compactor จะรวบรวมข้อมูลอย่างต่อเนื่องที่ความละเอียดห้านาทีและหนึ่งชั่วโมง สำหรับข้อมูลดิบแต่ละชิ้นที่เข้ารหัสโดยใช้การบีบอัด TSDB XOR ข้อมูลรวมประเภทต่างๆ จะถูกจัดเก็บ เช่น ค่าต่ำสุด ค่าสูงสุด หรือผลรวมสำหรับหนึ่งบล็อก ซึ่งช่วยให้ Querier สามารถเลือกการรวมที่เหมาะสมกับการสืบค้น PromQL ที่กำหนดได้โดยอัตโนมัติ
ผู้ใช้ไม่จำเป็นต้องกำหนดค่าพิเศษเพื่อใช้ข้อมูลที่มีความแม่นยำลดลง Querier สลับระหว่างความละเอียดและข้อมูลดิบที่แตกต่างกันโดยอัตโนมัติเมื่อผู้ใช้ซูมเข้าและออก หากต้องการ ผู้ใช้สามารถควบคุมสิ่งนี้ได้โดยตรงผ่านพารามิเตอร์ "ขั้นตอน" ในคำขอ
เนื่องจากค่าใช้จ่ายในการจัดเก็บหนึ่ง GB นั้นต่ำ ตามค่าเริ่มต้น Thanos จะจัดเก็บข้อมูลดิบ ข้อมูลความละเอียดห้านาทีและหนึ่งชั่วโมง ไม่จำเป็นต้องลบข้อมูลเดิม
กฎการบันทึก
แม้ว่าธานอสจะใช้กฎการบันทึกก็เป็นส่วนสำคัญของสแต็กการตรวจสอบ ลดความซับซ้อน เวลาแฝง และต้นทุนของการสืบค้น นอกจากนี้ยังสะดวกสำหรับผู้ใช้ในการรับข้อมูลที่รวบรวมตามหน่วยเมตริก ธานอสใช้อินสแตนซ์วานิลลาของ Prometheus ดังนั้นจึงเป็นที่ยอมรับอย่างสมบูรณ์ในการจัดเก็บกฎการบันทึกและกฎการแจ้งเตือนบนเซิร์ฟเวอร์ Prometheus ที่มีอยู่ อย่างไรก็ตาม ในบางกรณี ขั้นตอนนี้อาจไม่เพียงพอ:
- การแจ้งเตือนและกฎส่วนกลาง (เช่น การแจ้งเตือนเมื่อบริการไม่ทำงานบนคลัสเตอร์มากกว่าสองในสามคลัสเตอร์)
- กฎสำหรับข้อมูลนอกที่จัดเก็บในเครื่อง
- ความปรารถนาที่จะจัดเก็บกฎและการแจ้งเตือนทั้งหมดไว้ในที่เดียว
ในกรณีทั้งหมดเหล่านี้ ธานอสมีส่วนประกอบแยกต่างหากที่เรียกว่าไม้บรรทัด ซึ่งคำนวณกฎและการแจ้งเตือนผ่าน Thanos Queries ด้วยการจัดเตรียม StoreAPI ที่รู้จักกันดี โหนด Query จึงสามารถเข้าถึงตัววัดที่คำนวณใหม่ได้ หลังจากนั้นยังถูกจัดเก็บไว้ในที่เก็บข้อมูลออบเจ็กต์และเผยแพร่ผ่าน Store Gateway
พลังแห่งธานอส
ธานอสมีความยืดหยุ่นพอที่จะปรับแต่งให้เหมาะกับความต้องการของคุณ สิ่งนี้มีประโยชน์อย่างยิ่งเมื่อย้ายจากโพรมีธีอุสธรรมดา มาสรุปสิ่งที่เราได้เรียนรู้เกี่ยวกับส่วนประกอบของธานอสด้วยตัวอย่างสั้นๆ กัน ต่อไปนี้คือวิธีนำวานิลลา Prometheus ของคุณเข้าสู่โลกแห่ง “พื้นที่จัดเก็บตัวชี้วัดที่ไม่จำกัด”:
- เพิ่ม Thanos Sidecar ไปยังเซิร์ฟเวอร์ Prometheus ของคุณ - ตัวอย่างเช่น คอนเทนเนอร์ sidecar ในพ็อด Kubernetes
- ปรับใช้แบบจำลอง Thanos Querier หลายตัวเพื่อให้สามารถดูข้อมูลได้ ในขั้นตอนนี้ เป็นเรื่องง่ายที่จะตั้งค่าการนินทาระหว่าง Scraper และ Querier หากต้องการตรวจสอบการโต้ตอบของส่วนประกอบ ให้ใช้ตัวชี้วัด 'thanos_cluster_members'
เพียงสองขั้นตอนนี้เพียงพอที่จะมอบมุมมองทั่วโลกและการขจัดข้อมูลซ้ำซ้อนที่ราบรื่นจากแบบจำลอง Prometheus HA ที่อาจเกิดขึ้น! เพียงเชื่อมต่อแดชบอร์ดของคุณกับตำแหน่งข้อมูล Querier HTTP หรือใช้ Thanos UI โดยตรง
อย่างไรก็ตาม หากคุณต้องการสำรองข้อมูลตัววัดและพื้นที่เก็บข้อมูลระยะยาว คุณจะต้องดำเนินการอีกสามขั้นตอนให้เสร็จสิ้น:
- สร้างบัคเก็ต AWS S3 หรือ GCS กำหนดค่า Sidecar เพื่อคัดลอกข้อมูลไปยังที่เก็บข้อมูลเหล่านี้ การจัดเก็บข้อมูลในเครื่องสามารถย่อให้เล็กสุดได้แล้ว
- ปรับใช้ Store Gateway และเชื่อมต่อกับคลัสเตอร์ซุบซิบที่มีอยู่ของคุณ ตอนนี้คุณสามารถสืบค้นข้อมูลที่สำรองไว้ได้แล้ว!
- ปรับใช้ Compactor เพื่อปรับปรุงประสิทธิภาพการสืบค้นในระยะเวลาอันยาวนานโดยใช้การบีบอัดและการลดขนาดตัวอย่าง
หากคุณต้องการทราบข้อมูลเพิ่มเติม อย่าลังเลที่จะดูของเรา и !
ในเวลาเพียงห้าขั้นตอน เราได้เปลี่ยน Prometheus ให้กลายเป็นระบบตรวจสอบที่เชื่อถือได้พร้อมมุมมองทั่วโลก เวลาจัดเก็บข้อมูลที่ไม่จำกัด และตัววัดที่มีความพร้อมใช้งานสูง
ดึงคำขอ: เราต้องการคุณ!
เป็นโครงการโอเพ่นซอร์สตั้งแต่เริ่มต้น การบูรณาการอย่างราบรื่นกับ Prometheus และความสามารถในการใช้ Thanos เพียงบางส่วน ทำให้เป็นตัวเลือกที่ยอดเยี่ยมสำหรับการปรับขนาดระบบการตรวจสอบของคุณได้อย่างง่ายดาย
เรายินดีรับคำขอและปัญหาการดึง GitHub เสมอ ในระหว่างนี้ โปรดติดต่อเราผ่านทาง Github Issues หรือ slackหากคุณมีคำถามหรือข้อเสนอแนะ หรือต้องการแบ่งปันประสบการณ์ของคุณในการใช้งาน! หากคุณชอบสิ่งที่เราทำที่ Improbable อย่าลังเลที่จะติดต่อเรา - !
ที่มา: will.com