การประชุม HighLoad++ ครั้งต่อไปจะจัดขึ้นในวันที่ 6 และ 7 เมษายน 2020 ในเซนต์ปีเตอร์สเบิร์ก รายละเอียดและตั๋ว . HighLoad++ มอสโก 2018 ฮอลล์ "มอสโก" วันที่ 9 พฤศจิกายน เวลา 15:00 น. วิทยานิพนธ์และ .
* การตรวจสอบ - ออนไลน์และการวิเคราะห์
* ข้อจำกัดพื้นฐานของแพลตฟอร์ม ZABBIX
* โซลูชันสำหรับปรับขนาดพื้นที่เก็บข้อมูลการวิเคราะห์
* การเพิ่มประสิทธิภาพเซิร์ฟเวอร์ ZABBIX
* การเพิ่มประสิทธิภาพ UI
* มีประสบการณ์ในการใช้งานระบบภายใต้โหลด NVPS มากกว่า 40 รายการ
* บทสรุปโดยย่อ
มิคาอิล มาคุรอฟ (ต่อไปนี้ – MM): - สวัสดีทุกคน!
Maxim Chernetsov (ต่อไปนี้ – MCH): - สวัสดีตอนบ่าย!
มม.: – ให้ฉันแนะนำแม็กซิม แม็กซ์เป็นวิศวกรที่มีพรสวรรค์ เป็นเครือข่ายที่ดีที่สุดที่ฉันรู้จัก Maxim มีส่วนร่วมในเครือข่ายและบริการ การพัฒนาและการดำเนินงาน
มช: – และฉันอยากจะบอกคุณเกี่ยวกับมิคาอิล มิคาอิลเป็นนักพัฒนาภาษา C เขาเขียนโซลูชันการประมวลผลการรับส่งข้อมูลปริมาณมากให้กับบริษัทของเรา เราอาศัยและทำงานใน Urals ในเมือง Chelyabinsk ผู้แข็งแกร่งใน บริษัท Intersvyaz บริษัทของเราเป็นผู้ให้บริการอินเทอร์เน็ตและเคเบิลทีวีแก่ผู้คนหนึ่งล้านคนใน 16 เมือง
มม.: – และมันก็คุ้มค่าที่จะบอกว่า Intersvyaz เป็นมากกว่าผู้ให้บริการ แต่ยังเป็นบริษัทไอทีอีกด้วย โซลูชันส่วนใหญ่ของเราจัดทำโดยแผนกไอทีของเรา
NS: จากเซิร์ฟเวอร์ที่ประมวลผลการรับส่งข้อมูลไปยังศูนย์บริการทางโทรศัพท์และแอปพลิเคชันมือถือ ปัจจุบันแผนกไอทีมีบุคลากรประมาณ 80 คนที่มีความสามารถหลากหลายมาก
เกี่ยวกับ Zabbix และสถาปัตยกรรมของมัน
มช: – และตอนนี้ฉันจะพยายามสร้างบันทึกส่วนตัวและพูดในหนึ่งนาทีว่า Zabbix คืออะไร (ต่อไปนี้จะเรียกว่า "Zabbix")
Zabbix วางตำแหน่งตัวเองในฐานะระบบตรวจสอบนอกกรอบระดับองค์กร มีฟีเจอร์มากมายที่ทำให้ชีวิตง่ายขึ้น: กฎการยกระดับขั้นสูง, API สำหรับการผสานรวม, การจัดกลุ่มและการตรวจหาโฮสต์และหน่วยวัดอัตโนมัติ Zabbix มีสิ่งที่เรียกว่าเครื่องมือปรับขนาด - พร็อกซี Zabbix เป็นระบบโอเพ่นซอร์ส
สั้น ๆ เกี่ยวกับสถาปัตยกรรม เราสามารถพูดได้ว่าประกอบด้วยสามองค์ประกอบ:
- เซิร์ฟเวอร์ เขียนใน C. ด้วยการประมวลผลและการถ่ายโอนข้อมูลที่ค่อนข้างซับซ้อนระหว่างเธรด การประมวลผลทั้งหมดเกิดขึ้นตั้งแต่การรับไปจนถึงการบันทึกลงในฐานข้อมูล
- ข้อมูลทั้งหมดจะถูกเก็บไว้ในฐานข้อมูล Zabbix รองรับ MySQL, PostreSQL และ Oracle
- เว็บอินเตอร์เฟสเขียนด้วย PHP ในระบบส่วนใหญ่จะมาพร้อมกับเซิร์ฟเวอร์ Apache แต่ทำงานได้อย่างมีประสิทธิภาพมากกว่าเมื่อใช้ร่วมกับ nginx + php
วันนี้เราขอเล่าเรื่องหนึ่งจากชีวิตของบริษัทเราที่เกี่ยวข้องกับแซบบิกซ์...
เรื่องราวจากชีวิตของ บริษัท Intersvyaz เรามีอะไรและเราต้องการอะไร?
5 หรือ 6 เดือนที่แล้ว วันหนึ่งหลังเลิกงาน...
มช: - มิชาสวัสดี! ฉันดีใจที่จับคุณได้ - มีการสนทนาอยู่ เราประสบปัญหาในการตรวจสอบอีกครั้ง ระหว่างเกิดอุบัติเหตุใหญ่ ทุกอย่างดำเนินไปอย่างช้าๆ และไม่มีข้อมูลเกี่ยวกับสถานะของเครือข่าย น่าเสียดายที่นี่ไม่ใช่ครั้งแรกที่เกิดเหตุการณ์เช่นนี้ ฉันต้องการความช่วยเหลือจากคุณ. มาทำให้การตรวจสอบของเราทำงานได้ในทุกสถานการณ์!
มม.: - แต่มาซิงโครไนซ์กันก่อน ฉันไม่ได้ดูที่นั่นมาสองสามปีแล้ว เท่าที่ฉันจำได้ เราละทิ้ง Nagios และเปลี่ยนมาใช้ Zabbix เมื่อประมาณ 8 ปีที่แล้ว และตอนนี้ดูเหมือนว่าเราจะมีเซิร์ฟเวอร์ที่ทรงพลัง 6 เครื่องและพรอกซีประมาณโหล ฉันสับสนอะไรหรือเปล่า?
มช: - เกือบ. เซิร์ฟเวอร์ 15 เครื่อง ซึ่งบางส่วนเป็นเครื่องเสมือน สิ่งที่สำคัญที่สุดคือมันไม่ได้ช่วยเราในเวลาที่เราต้องการมันมากที่สุด เหมือนอุบัติเหตุ - เซิร์ฟเวอร์ทำงานช้าลงและคุณมองไม่เห็นอะไรเลย เราพยายามปรับการกำหนดค่าให้เหมาะสม แต่ไม่ได้เพิ่มประสิทธิภาพสูงสุด
มม.: - ก็เป็นที่ชัดเจน. คุณดูอะไรบางอย่างคุณได้ขุดบางสิ่งจากการวินิจฉัยแล้วหรือยัง?
มช: – สิ่งแรกที่คุณต้องจัดการคือฐานข้อมูล MySQL มีการโหลดอย่างต่อเนื่อง โดยจัดเก็บตัวชี้วัดใหม่ และเมื่อ Zabbix เริ่มสร้างเหตุการณ์จำนวนมาก ฐานข้อมูลจะเข้าสู่ภาวะโอเวอร์ไดรฟ์เป็นเวลาสองสามชั่วโมงอย่างแท้จริง ฉันได้บอกคุณแล้วเกี่ยวกับการเพิ่มประสิทธิภาพการกำหนดค่า แต่ในปีนี้พวกเขาอัปเดตฮาร์ดแวร์: เซิร์ฟเวอร์มีหน่วยความจำและดิสก์อาร์เรย์มากกว่าร้อยกิกะไบต์บน SSD RAID - ไม่มีประโยชน์ที่จะขยายเป็นเส้นตรงในระยะยาว พวกเราทำอะไร?
มม.: - ก็เป็นที่ชัดเจน. โดยทั่วไป MySQL เป็นฐานข้อมูล LTP เห็นได้ชัดว่ามันไม่เหมาะสำหรับการจัดเก็บหน่วยเมตริกขนาดของเราอีกต่อไป ลองคิดดูสิ
มช: - เอาล่ะ!
การบูรณาการ Zabbix และ Clickhouse อันเป็นผลมาจากแฮ็กกาธอน
หลังจากนั้นไม่นาน เราก็ได้รับข้อมูลที่น่าสนใจ:
พื้นที่ส่วนใหญ่ในฐานข้อมูลของเราถูกครอบครองโดยไฟล์เก็บถาวรตัวชี้วัด และมีการใช้น้อยกว่า 1% สำหรับการกำหนดค่า เทมเพลต และการตั้งค่า เมื่อถึงเวลานั้น เราได้ใช้งานโซลูชัน Big Data ที่ใช้ Clickhouse มามากกว่าหนึ่งปีแล้ว ทิศทางการเคลื่อนไหวชัดเจนสำหรับเรา ที่ Hackathon ฤดูใบไม้ผลิของเรา ฉันได้เขียนการรวม Zabbix กับ Clickhouse สำหรับเซิร์ฟเวอร์และฟรอนต์เอนด์ ในเวลานั้น Zabbix ได้รับการรองรับ ElasticSearch แล้ว และเราตัดสินใจเปรียบเทียบมัน
การเปรียบเทียบ Clickhouse และ Elasticsearch
มม.: – สำหรับการเปรียบเทียบ เราสร้างโหลดเดียวกันกับที่เซิร์ฟเวอร์ Zabbix จัดเตรียมให้ และดูว่าระบบจะทำงานอย่างไร เราเขียนข้อมูลเป็นชุด 1000 บรรทัดโดยใช้ CURL เราสันนิษฐานล่วงหน้าว่า Clickhouse จะมีประสิทธิภาพมากกว่าสำหรับโปรไฟล์โหลดที่ Zabbix ทำ ผลลัพธ์เกินความคาดหมายของเราด้วยซ้ำ:
ภายใต้เงื่อนไขการทดสอบเดียวกัน Clickhouse เขียนข้อมูลได้มากกว่าสามเท่า ในเวลาเดียวกัน ทั้งสองระบบใช้ทรัพยากรอย่างมีประสิทธิภาพมาก (ทรัพยากรจำนวนเล็กน้อย) เมื่ออ่านข้อมูล แต่ Elastics ต้องใช้โปรเซสเซอร์จำนวนมากเมื่อบันทึก:
โดยรวมแล้ว Clickhouse เหนือกว่า Elastix อย่างมากในแง่ของการใช้โปรเซสเซอร์และความเร็ว ในเวลาเดียวกัน เนื่องจากการบีบอัดข้อมูล Clickhouse จึงใช้ฮาร์ดไดรฟ์น้อยลง 11 เท่า และดำเนินการกับดิสก์น้อยลงประมาณ 30 เท่า:
มช: – ใช่ การทำงานของ Clickhouse กับระบบย่อยของดิสก์ได้รับการปฏิบัติอย่างมีประสิทธิภาพมาก คุณสามารถใช้ดิสก์ SATA ขนาดใหญ่สำหรับฐานข้อมูลและรับความเร็วในการเขียนนับแสนบรรทัดต่อวินาที ระบบที่พร้อมใช้งานทันทีรองรับการแบ่งส่วน การจำลอง และกำหนดค่าได้ง่ายมาก เราพอใจกับการใช้งานตลอดทั้งปีมาก
เพื่อเพิ่มประสิทธิภาพทรัพยากร คุณสามารถติดตั้ง Clickhouse ถัดจากฐานข้อมูลหลักที่มีอยู่ และช่วยประหยัดเวลา CPU และการทำงานของดิสก์ได้มาก เราได้ย้ายที่เก็บถาวรของตัวชี้วัดไปยังคลัสเตอร์ Clickhouse ที่มีอยู่แล้ว:
เราลดทอนฐานข้อมูล MySQL หลักลงมากจนสามารถรวมไว้ในเครื่องเดียวกับเซิร์ฟเวอร์ Zabbix และละทิ้งเซิร์ฟเวอร์เฉพาะสำหรับ MySQL
การสำรวจความคิดเห็นใน Zabbix ทำงานอย่างไร
4 เดือนที่ผ่านมา
มม.: – เอาล่ะ เราจะลืมปัญหาเกี่ยวกับฐานได้ไหม?
มช: - นั่นแน่! ปัญหาอีกประการหนึ่งที่เราต้องแก้ไขคือการรวบรวมข้อมูลที่ช้า ขณะนี้พร็อกซีเซิร์ฟเวอร์ทั้ง 15 เครื่องของเรามี SNMP และกระบวนการโพลมากเกินไป และไม่มีทางอื่นนอกจากการติดตั้งเซิร์ฟเวอร์ใหม่และเซิร์ฟเวอร์ใหม่
มม.: - ยอดเยี่ยม. แต่ก่อนอื่น บอกเราว่าการสำรวจความคิดเห็นใน Zabbix ทำงานอย่างไร
มช: กล่าวโดยย่อ มีตัวชี้วัด 20 ประเภทและวิธีรับตัวชี้วัดมากมาย Zabbix สามารถรวบรวมข้อมูลในโหมด “ร้องขอ-ตอบกลับ” หรือรอข้อมูลใหม่ผ่าน “Trapper Interface”
เป็นที่น่าสังเกตว่าใน Zabbix ดั้งเดิมวิธีนี้ (Trapper) นั้นเร็วที่สุด
มีพร็อกซีเซิร์ฟเวอร์สำหรับการกระจายโหลด:
พร็อกซีสามารถทำหน้าที่รวบรวมเช่นเดียวกับเซิร์ฟเวอร์ Zabbix โดยรับงานจากนั้นและส่งตัวชี้วัดที่รวบรวมผ่านอินเทอร์เฟซ Trapper นี่เป็นวิธีที่แนะนำอย่างเป็นทางการในการกระจายโหลด พร็อกซียังมีประโยชน์สำหรับการตรวจสอบโครงสร้างพื้นฐานระยะไกลที่ทำงานผ่าน NAT หรือช่องทางที่ช้า:
มม.: – ทุกอย่างชัดเจนด้วยสถาปัตยกรรม เราต้องดูที่มา...
สองสามวันต่อมา
เรื่องราวของการที่ nmap fping ชนะ
มม.: “ฉันคิดว่าฉันขุดอะไรบางอย่างขึ้นมา”
มช: - บอกฉัน!
มม.: – ฉันค้นพบว่าเมื่อตรวจสอบความพร้อมใช้งาน Zabbix จะตรวจสอบโฮสต์สูงสุด 128 โฮสต์ในแต่ละครั้ง ฉันพยายามเพิ่มจำนวนนี้เป็น 500 และลบช่วงเวลาระหว่างแพ็กเก็ตในการ ping (ping) ซึ่งเพิ่มประสิทธิภาพเป็นสองเท่า แต่อยากได้จำนวนมากกว่านี้
มช: – ในทางปฏิบัติของฉัน บางครั้งฉันต้องตรวจสอบความพร้อมใช้งานของโฮสต์นับพัน และฉันไม่เคยเห็นสิ่งใดที่เร็วกว่า nmap สำหรับสิ่งนี้ ฉันแน่ใจว่านี่เป็นวิธีที่เร็วที่สุด มาลองดูกัน! เราจำเป็นต้องเพิ่มจำนวนโฮสต์ต่อการวนซ้ำอย่างมาก
มม.: – เช็คเกินห้าร้อย? 600?
มช: - อย่างน้อยสองพัน
มม.: - ตกลง. สิ่งที่สำคัญที่สุดที่ฉันอยากจะพูดคือฉันพบว่าการสำรวจความคิดเห็นใน Zabbix ส่วนใหญ่ทำพร้อมกัน เราจำเป็นต้องเปลี่ยนเป็นโหมดอะซิงโครนัสอย่างแน่นอน จากนั้นเราจะเพิ่มจำนวนตัววัดที่รวบรวมโดยผู้สำรวจความคิดเห็นได้อย่างมาก โดยเฉพาะอย่างยิ่งหากเราเพิ่มจำนวนตัววัดต่อการวนซ้ำ
มช: - ยอดเยี่ยม! และเมื่อ?
มม.: – ตามปกติเมื่อวานนี้
มช: – เราเปรียบเทียบ fping และ nmap ทั้งสองเวอร์ชัน:
บนโฮสต์จำนวนมาก nmap คาดว่าจะมีประสิทธิภาพมากกว่าถึงห้าเท่า เนื่องจาก nmap ตรวจสอบความพร้อมใช้งานและเวลาตอบสนองเท่านั้น เราจึงย้ายการคำนวณการสูญเสียไปยังทริกเกอร์ และลดช่วงเวลาการตรวจสอบความพร้อมใช้งานลงอย่างมาก เราพบว่าจำนวนโฮสต์ที่เหมาะสมที่สุดสำหรับ nmap จะอยู่ที่ประมาณ 4 ต่อการวนซ้ำ Nmap ช่วยให้เราสามารถลดต้นทุน CPU ในการตรวจสอบความพร้อมใช้งานได้สามครั้ง และลดช่วงเวลาจาก 120 วินาทีเหลือ 10 วินาที
การเพิ่มประสิทธิภาพการสำรวจ
มม.: “จากนั้นเราก็เริ่มทำการสำรวจความคิดเห็น เราสนใจการตรวจจับและเอเจนต์ SNMP เป็นหลัก ใน Zabbix การโพลจะดำเนินการพร้อมกันและมีมาตรการพิเศษเพื่อเพิ่มประสิทธิภาพของระบบ ในโหมดซิงโครนัส ความไม่พร้อมใช้งานของโฮสต์ทำให้การหยั่งเสียงลดลงอย่างมาก มีระบบของรัฐทั้งหมดมีกระบวนการพิเศษ - ที่เรียกว่าโพลเลอร์ที่ไม่สามารถเข้าถึงได้ซึ่งใช้งานได้กับโฮสต์ที่ไม่สามารถเข้าถึงได้เท่านั้น:
นี่คือคำอธิบายที่แสดงให้เห็นถึงเมทริกซ์สถานะ ความซับซ้อนทั้งหมดของระบบการเปลี่ยนภาพที่จำเป็นเพื่อให้ระบบยังคงมีประสิทธิภาพ นอกจากนี้ การโพลแบบซิงโครนัสเองก็ค่อนข้างช้า:
นั่นคือสาเหตุที่สตรีมโพลเลอร์หลายพันรายการบนพรอกซีหลายสิบรายการไม่สามารถรวบรวมข้อมูลตามจำนวนที่ต้องการสำหรับเราได้ การใช้งานแบบอะซิงโครนัสไม่เพียงช่วยแก้ปัญหาเกี่ยวกับจำนวนเธรดเท่านั้น แต่ยังทำให้ระบบสถานะของโฮสต์ที่ไม่พร้อมใช้งานง่ายขึ้นอย่างมาก เนื่องจากสำหรับหมายเลขใด ๆ ที่ตรวจสอบในการวนซ้ำการโพลครั้งเดียว เวลารอสูงสุดคือ 1 หมดเวลา:
นอกจากนี้ เรายังแก้ไขและปรับปรุงระบบการโพลสำหรับคำขอ SNMP ความจริงก็คือคนส่วนใหญ่ไม่สามารถตอบสนองต่อคำขอ SNMP หลายรายการพร้อมกันได้ ดังนั้นเราจึงสร้างโหมดไฮบริด เมื่อการโพล SNMP ของโฮสต์เดียวกันเสร็จสิ้นแบบอะซิงโครนัส:
ซึ่งทำเพื่อโฮสต์ทั้งหมด ในที่สุดโหมดนี้ก็ไม่ช้าไปกว่าโหมดอะซิงโครนัสโดยสมบูรณ์เนื่องจากการโพลค่า SNMP หนึ่งร้อยครึ่งยังคงเร็วกว่าการหมดเวลา 1 ครั้งมาก
การทดลองของเราแสดงให้เห็นว่าจำนวนคำขอที่เหมาะสมที่สุดในการวนซ้ำหนึ่งครั้งคือประมาณ 8 คำขอโดยใช้การสำรวจ SNMP โดยรวมแล้ว การเปลี่ยนไปใช้โหมดอะซิงโครนัสทำให้เราสามารถเร่งประสิทธิภาพการโพลได้ 200 เท่า หลายร้อยเท่า
มช: – ผลการเพิ่มประสิทธิภาพการสำรวจผลลัพธ์แสดงให้เห็นว่าเราไม่เพียงแต่สามารถกำจัดพร็อกซีทั้งหมดได้ แต่ยังลดช่วงเวลาในการตรวจสอบจำนวนมากอีกด้วย และไม่จำเป็นต้องใช้พรอกซีในการแบ่งปันโหลดอีกต่อไป
ประมาณสามเดือนก่อน
เปลี่ยนสถาปัตยกรรม - เพิ่มภาระ!
มม.: - แม็กซ์ ถึงเวลามีประสิทธิผลแล้วหรือยัง? ฉันต้องการเซิร์ฟเวอร์ที่ทรงพลังและวิศวกรที่ดี
มช: - เอาล่ะ เรามาวางแผนกัน ถึงเวลาแล้วที่จะต้องย้ายจากจุดตายที่ 5 เมตริกต่อวินาที
เช้าๆหลังอัพ
มช: - Misha เราอัปเดตตัวเอง แต่เมื่อถึงเช้าเราก็ย้อนกลับ... ลองทายดูสิว่าเราทำได้ความเร็วเท่าไหร่?
มม.: – สูงสุด 20.
มช: - ใช่ 25! น่าเสียดายที่เรามาถูกที่แล้ว
มม.: - ทำไม? คุณได้ทำการวินิจฉัยหรือไม่?
มช: - แน่นอน! ตัวอย่างเช่น นี่คืออันดับสูงสุดที่น่าสนใจ:
มม.: - มาดูกัน. ฉันเห็นว่าเราได้ลองใช้เธรดโพลจำนวนมาก:
แต่ในขณะเดียวกันพวกเขาก็ไม่สามารถรีไซเคิลระบบได้แม้แต่ครึ่งเดียว:
และประสิทธิภาพโดยรวมค่อนข้างน้อย ประมาณ 4 พันเมตริกต่อวินาที:
มีอะไรอีกไหม?
มช: – ใช่ ร่องรอยของหนึ่งในผู้สำรวจ:
มม.: – ที่นี่คุณจะเห็นได้อย่างชัดเจนว่ากระบวนการลงคะแนนกำลังรอ "สัญญาณ" นี่คือล็อค:
มช: - ไม่ชัดเจน
มม.: – ดูสิ สิ่งนี้คล้ายกับสถานการณ์ที่กลุ่มเธรดพยายามทำงานกับทรัพยากรที่มีเพียงเธรดเดียวเท่านั้นที่สามารถทำงานได้ในแต่ละครั้ง สิ่งที่พวกเขาทำได้คือแบ่งปันทรัพยากรนี้เมื่อเวลาผ่านไป:
และประสิทธิภาพโดยรวมของการทำงานกับทรัพยากรดังกล่าวถูกจำกัดด้วยความเร็วของหนึ่งคอร์:
มีสองวิธีในการแก้ปัญหานี้
อัพเกรดฮาร์ดแวร์ของเครื่อง เปลี่ยนไปใช้แกนประมวลผลที่เร็วขึ้น:
หรือเปลี่ยนสถาปัตยกรรมและในเวลาเดียวกันก็เปลี่ยนโหลด:
มช: – อย่างไรก็ตาม บนเครื่องทดสอบเราจะใช้คอร์น้อยกว่าในการต่อสู้ แต่มีความถี่ต่อคอร์ที่เร็วกว่าถึง 1,5 เท่า!
มม.: - ชัดเจน? คุณต้องดูรหัสเซิร์ฟเวอร์
เส้นทางข้อมูลในเซิร์ฟเวอร์ Zabbix
มช: – เพื่อทำความเข้าใจ เราได้เริ่มวิเคราะห์ว่าข้อมูลถูกถ่ายโอนภายในเซิร์ฟเวอร์ Zabbix อย่างไร:
ภาพเจ๋งใช่มั้ย? มาดูทีละขั้นตอนเพื่อให้ชัดเจนไม่มากก็น้อย มีเธรดและบริการที่รับผิดชอบในการรวบรวมข้อมูล:
โดยจะส่งตัววัดที่รวบรวมผ่านซ็อกเก็ตไปยังตัวจัดการตัวประมวลผลล่วงหน้า โดยที่ตัววัดจะถูกบันทึกไว้ในคิว:
“ตัวจัดการตัวประมวลผลล่วงหน้า” จะส่งข้อมูลไปยังผู้ปฏิบัติงาน ซึ่งดำเนินการตามคำสั่งในการประมวลผลล่วงหน้าและส่งคืนกลับผ่านซ็อกเก็ตเดียวกัน:
หลังจากนี้ ตัวจัดการตัวประมวลผลล่วงหน้าจะจัดเก็บไว้ในแคชประวัติ:
จากนั้นพวกเขาจะถูกยึดครองโดยผู้จมประวัติศาสตร์ซึ่งทำหน้าที่ค่อนข้างมาก: ตัวอย่างเช่นการคำนวณทริกเกอร์การเติมแคชค่าและที่สำคัญที่สุดคือการบันทึกการวัดในที่จัดเก็บประวัติ โดยทั่วไปกระบวนการนี้ซับซ้อนและสับสนมาก
มม.: – สิ่งแรกที่เราเห็นคือเธรดส่วนใหญ่แข่งขันกันเพื่อสิ่งที่เรียกว่า "แคชการกำหนดค่า" (พื้นที่หน่วยความจำที่จัดเก็บการกำหนดค่าเซิร์ฟเวอร์ทั้งหมด) เธรดที่รับผิดชอบในการรวบรวมข้อมูลทำการบล็อกโดยเฉพาะ:
...เนื่องจากการกำหนดค่าไม่เพียงแต่จัดเก็บตัวชี้วัดด้วยพารามิเตอร์เท่านั้น แต่ยังรวมถึงคิวที่ผู้สำรวจใช้ข้อมูลเกี่ยวกับสิ่งที่ต้องทำต่อไป เมื่อมีโพลจำนวนมากและตัวหนึ่งบล็อกการกำหนดค่า ตัวอื่นจะรอคำขอ:
นักสำรวจไม่ควรขัดแย้งกัน
ดังนั้น สิ่งแรกที่เราทำคือแบ่งคิวออกเป็น 4 ส่วน และอนุญาตให้ผู้สำรวจบล็อกคิวเหล่านี้ ส่วนเหล่านี้พร้อมกัน ภายใต้สภาวะที่ปลอดภัย:
สิ่งนี้ได้ลบการแข่งขันสำหรับแคชการกำหนดค่า และความเร็วของโพลเลอร์ก็เพิ่มขึ้นอย่างมาก แต่แล้วเราก็พบกับความจริงที่ว่าผู้จัดการพรีโปรเซสเซอร์เริ่มสะสมคิวงาน:
ผู้จัดการตัวประมวลผลล่วงหน้าต้องสามารถจัดลำดับความสำคัญได้
สิ่งนี้เกิดขึ้นในกรณีที่เขาขาดประสิทธิภาพ จากนั้นสิ่งที่เขาทำได้คือรวบรวมคำขอจากกระบวนการรวบรวมข้อมูลและเพิ่มบัฟเฟอร์จนกว่าคำขอจะใช้หน่วยความจำทั้งหมดและเกิดข้อขัดข้อง:
เพื่อแก้ไขปัญหานี้ เราได้เพิ่มซ็อกเก็ตที่สองที่มีไว้สำหรับผู้ปฏิบัติงานโดยเฉพาะ:
ดังนั้น ผู้จัดการตัวประมวลผลล่วงหน้ามีโอกาสที่จะจัดลำดับความสำคัญของงาน และหากบัฟเฟอร์เพิ่มขึ้น งานคือการชะลอการลบออก ทำให้ผู้ปฏิบัติงานมีโอกาสใช้บัฟเฟอร์นี้:
จากนั้นเราค้นพบว่าสาเหตุหนึ่งของการชะลอตัวก็คือตัวคนงานเอง เนื่องจากพวกเขากำลังแข่งขันกันแย่งชิงทรัพยากรที่ไม่สำคัญสำหรับงานของพวกเขาเลย เราบันทึกปัญหานี้ว่าเป็นการแก้ไขข้อบกพร่อง และได้รับการแก้ไขแล้วใน Zabbix เวอร์ชันใหม่:
เราเพิ่มจำนวนซ็อกเก็ต - เราได้ผลลัพธ์
นอกจากนี้ตัวจัดการพรีโปรเซสเซอร์เองก็กลายเป็นคอขวดเนื่องจากเป็นเธรดเดียว มันวางอยู่บนความเร็วคอร์ โดยให้ความเร็วสูงสุดประมาณ 70 เมตริกต่อวินาที:
ดังนั้นเราจึงสร้างฐานสี่อันพร้อมฐานสี่ชุด
และสิ่งนี้ทำให้เราสามารถเพิ่มความเร็วเป็นประมาณ 130 เมตริก:
ความไม่เชิงเส้นของการเติบโตอธิบายได้จากข้อเท็จจริงที่ว่าการแข่งขันสำหรับแคชประวัติปรากฏขึ้น ผู้จัดการตัวประมวลผลล่วงหน้า 4 คนและผู้จมประวัติศาสตร์แข่งขันกันเพื่อมัน ณ จุดนี้ เราได้รับประมาณ 130 เมตริกต่อวินาทีบนเครื่องทดสอบ โดยใช้โปรเซสเซอร์ประมาณ 95%:
ประมาณ 2,5 เดือนที่แล้ว
การปฏิเสธจากชุมชน snmp ทำให้ NVP เพิ่มขึ้นหนึ่งเท่าครึ่ง
มม.: – แม็กซ์ ฉันต้องการรถทดสอบใหม่! เราไม่เข้ากับปัจจุบันอีกต่อไป
มช: - ตอนนี้คุณมีอะไร?
มม.: – ขณะนี้ – NVP 130 ตัวและโปรเซสเซอร์ที่พร้อมใช้งานบนชั้นวาง
มช: - ว้าว! เย็น! เดี๋ยวก่อน ฉันมีสองคำถาม จากการคำนวณของฉัน ความต้องการของเราอยู่ที่ประมาณ 15-20 เมตริกต่อวินาที ทำไมเราถึงต้องการมากกว่านี้?
มม.: “ฉันอยากจะทำงานให้เสร็จ” ฉันอยากจะดูว่าเราสามารถบีบออกจากระบบนี้ได้มากแค่ไหน
มช: - แต่…
มม.: “แต่มันไม่มีประโยชน์สำหรับธุรกิจ”
มช: - ก็เป็นที่ชัดเจน. และคำถามที่สอง: เราสามารถสนับสนุนสิ่งที่เรามีตอนนี้ด้วยตัวเองได้หรือไม่ โดยไม่ได้รับความช่วยเหลือจากนักพัฒนา?
มม.: - ฉันไม่คิดว่า. การเปลี่ยนวิธีการทำงานของแคชการกำหนดค่าเป็นปัญหา ส่งผลต่อการเปลี่ยนแปลงในเธรดส่วนใหญ่ และดูแลรักษาค่อนข้างยาก เป็นไปได้มากว่าการบำรุงรักษาจะยากมาก
มช: “ถ้าอย่างนั้น เราจำเป็นต้องมีทางเลือกอื่น”
มม.: - มีตัวเลือกดังกล่าว เราสามารถเปลี่ยนมาใช้คอร์แบบเร็วได้ในขณะที่ละทิ้งระบบล็อคใหม่ เราจะยังคงได้รับประสิทธิภาพ 60-80 เมตริก ในขณะเดียวกันเราก็สามารถทิ้งโค้ดที่เหลือทั้งหมดไว้ได้ Clickhouse และการสำรวจแบบอะซิงโครนัสจะทำงาน และจะง่ายต่อการบำรุงรักษา
มช: - อัศจรรย์! ฉันขอแนะนำให้เราหยุดที่นี่
หลังจากปรับฝั่งเซิร์ฟเวอร์ให้เหมาะสมแล้ว ในที่สุดเราก็สามารถเปิดตัวโค้ดใหม่สู่การใช้งานจริงได้ เราละทิ้งการเปลี่ยนแปลงบางอย่างเพื่อเปลี่ยนไปใช้เครื่องที่มีแกนประมวลผลที่รวดเร็วและลดจำนวนการเปลี่ยนแปลงโค้ดให้เหลือน้อยที่สุด นอกจากนี้เรายังทำให้การกำหนดค่าง่ายขึ้นและกำจัดมาโครในรายการข้อมูลหากเป็นไปได้ เนื่องจากมาโครดังกล่าวแนะนำการล็อคเพิ่มเติม
ตัวอย่างเช่น การละทิ้งมาโครชุมชน snmp ซึ่งมักพบในเอกสารประกอบและตัวอย่าง ในกรณีของเรา ทำให้สามารถเร่งความเร็ว NVP ได้อีกประมาณ 1,5 เท่า
หลังจากผลิตได้สองวัน
การลบป๊อปอัปประวัติเหตุการณ์
มช: มิชา เราใช้ระบบนี้มาสองวันแล้ว และทุกอย่างก็ใช้งานได้ แต่เมื่อทุกอย่างได้ผลเท่านั้น! เราได้วางแผนงานด้วยการโอนส่วนเครือข่ายที่ค่อนข้างใหญ่ และเราตรวจสอบด้วยมือของเราอีกครั้งว่ามีอะไรเกิดขึ้นบ้างและอะไรบ้างที่ไม่ได้เกิดขึ้น
มม.: - เป็นไปไม่ได้! เราตรวจสอบทุกอย่าง 10 ครั้ง เซิร์ฟเวอร์จะจัดการกับความไม่พร้อมใช้งานของเครือข่ายที่สมบูรณ์ได้ในทันที
มช: - ใช่ ฉันเข้าใจทุกอย่าง: เซิร์ฟเวอร์, ฐานข้อมูล, ด้านบน, austat, บันทึก - ทุกอย่างรวดเร็ว... แต่เราดูที่เว็บอินเตอร์เฟส และมีโปรเซสเซอร์ "อยู่ในชั้นวาง" บนเซิร์ฟเวอร์และสิ่งนี้:
มม.: - ก็เป็นที่ชัดเจน. มาดูเว็บกันดีกว่า เราพบว่าในสถานการณ์ที่มีเหตุการณ์ที่ดำเนินอยู่จำนวนมาก วิดเจ็ตที่ใช้งานอยู่ส่วนใหญ่เริ่มทำงานช้ามาก:
เหตุผลก็คือการสร้างป๊อปอัปประวัติเหตุการณ์ที่สร้างขึ้นสำหรับแต่ละรายการในรายการ ดังนั้นเราจึงละทิ้งการสร้างหน้าต่างเหล่านี้ (ใส่เครื่องหมายความคิดเห็นไว้ 5 บรรทัดในโค้ด) และนี่จะช่วยแก้ไขปัญหาของเราได้
เวลาในการโหลดวิดเจ็ตแม้จะไม่พร้อมใช้งานอย่างสมบูรณ์ แต่ก็ลดลงจากหลายนาทีเหลือ 10-15 วินาทีที่ยอมรับได้สำหรับเรา และยังสามารถดูประวัติได้โดยคลิกที่เวลา:
หลังเลิกงาน. 2 เดือนที่แล้ว
มช: - มิชา คุณจะไปไหม? เราต้องคุยกัน.
มม.: - ฉันไม่ได้ตั้งใจ มีอะไรกับ Zabbix อีกแล้วเหรอ?
มช: - ไม่ผ่อนคลาย! ฉันแค่อยากจะบอกว่า: ทุกอย่างใช้งานได้ ขอบคุณ! ฉันมีเบียร์
Zabbix มีประสิทธิภาพ
Zabbix เป็นระบบและฟังก์ชั่นที่ค่อนข้างเป็นสากลและสมบูรณ์ สามารถใช้สำหรับการติดตั้งขนาดเล็กตั้งแต่แกะกล่อง แต่เมื่อความต้องการเพิ่มขึ้น ก็ต้องได้รับการปรับให้เหมาะสม หากต้องการจัดเก็บหน่วยเมตริกขนาดใหญ่ ให้ใช้พื้นที่จัดเก็บที่เหมาะสม:
- คุณสามารถใช้เครื่องมือในตัวในรูปแบบของการรวมเข้ากับ Elasticsearch หรือการอัพโหลดประวัติไปยังไฟล์ข้อความ (มีให้ตั้งแต่เวอร์ชัน XNUMX)
- คุณสามารถใช้ประโยชน์จากประสบการณ์และการผสานรวมกับ Clickhouse ของเราได้
หากต้องการเพิ่มความเร็วในการรวบรวมตัวชี้วัดอย่างมาก ให้รวบรวมโดยใช้วิธีอะซิงโครนัสและส่งผ่านอินเทอร์เฟซดักจับไปยังเซิร์ฟเวอร์ Zabbix หรือคุณสามารถใช้แพตช์เพื่อทำให้ Zabbix pollers แบบอะซิงโครนัสได้
Zabbix เขียนด้วยภาษา C และค่อนข้างมีประสิทธิภาพ การแก้ปัญหาคอขวดทางสถาปัตยกรรมหลายประการทำให้คุณสามารถเพิ่มประสิทธิภาพการทำงานได้มากขึ้น และจากประสบการณ์ของเรา สามารถรับเมตริกมากกว่า 100 เมตริกบนเครื่องที่ใช้โปรเซสเซอร์ตัวเดียว
แพทช์ Zabbix เดียวกัน
มม.: – ฉันต้องการเพิ่มสองสามจุด รายงานปัจจุบันทั้งหมด การทดสอบทั้งหมด หมายเลขจะได้รับสำหรับการกำหนดค่าที่เราใช้ ขณะนี้เราใช้ข้อมูลประมาณ 20 เมตริกต่อวินาทีจากนั้น หากคุณกำลังพยายามที่จะเข้าใจว่าวิธีนี้ใช้ได้ผลสำหรับคุณหรือไม่ คุณสามารถเปรียบเทียบได้ สิ่งที่พูดคุยกันในวันนี้ถูกโพสต์บน GitHub ในรูปแบบของแพตช์:
แพทช์ประกอบด้วย:
- บูรณาการอย่างสมบูรณ์กับ Clickhouse (ทั้งเซิร์ฟเวอร์ Zabbix และส่วนหน้า)
- การแก้ปัญหากับตัวจัดการพรีโปรเซสเซอร์
- การโพลแบบอะซิงโครนัส
แพทช์นี้เข้ากันได้กับทุกเวอร์ชัน 4 รวมถึง lts เป็นไปได้มากว่าหากมีการเปลี่ยนแปลงเพียงเล็กน้อยก็จะใช้งานได้กับเวอร์ชัน 3.4
ขอบคุณสำหรับความสนใจของคุณ
คำถาม
คำถามจากผู้ฟัง (ต่อไปนี้ – ก): – สวัสดีตอนบ่าย! โปรดบอกฉันว่าคุณมีแผนสำหรับการโต้ตอบอย่างเข้มข้นกับทีม Zabbix หรือกับพวกเขากับคุณ เพื่อที่นี่ไม่ใช่แพทช์ แต่เป็นพฤติกรรมปกติของ Zabbix
มม.: – ใช่ เราจะทำการเปลี่ยนแปลงบางอย่างอย่างแน่นอน บางสิ่งบางอย่างจะเกิดขึ้น บางสิ่งบางอย่างจะยังคงอยู่ในแพทช์
NS: – ขอบคุณมากสำหรับรายงานที่ยอดเยี่ยม! โปรดบอกฉันว่าหลังจากใช้แพตช์แล้ว การสนับสนุนจาก Zabbix จะยังคงอยู่ และจะอัปเดตเป็นเวอร์ชันที่สูงกว่าต่อไปได้อย่างไร เป็นไปได้ไหมที่จะอัปเดต Zabbix หลังจากแพตช์ของคุณเป็น 4.2, 5.0?
มม.: – ฉันไม่สามารถพูดอะไรเกี่ยวกับการสนับสนุนได้ ถ้าฉันเป็นฝ่ายสนับสนุนด้านเทคนิคของ Zabbix ฉันคงจะปฏิเสธ เพราะนี่คือโค้ดของคนอื่น สำหรับโค้ดเบส 4.2 จุดยืนของเราคือ: “เราจะก้าวไปตามเวลา และเราจะอัปเดตตัวเองในเวอร์ชันถัดไป” ดังนั้นเราจะโพสต์แพตช์สำหรับเวอร์ชันที่อัปเดตเป็นระยะเวลาหนึ่ง ฉันได้กล่าวไปแล้วในรายงาน: จำนวนการเปลี่ยนแปลงในเวอร์ชันยังค่อนข้างน้อย ฉันคิดว่าการเปลี่ยนจาก 3.4 เป็น 4 ใช้เวลาประมาณ 15 นาที มีบางอย่างเปลี่ยนแปลงไป แต่ก็ไม่ได้สำคัญมาก
NS: – คุณวางแผนที่จะสนับสนุนแพทช์ของคุณและคุณสามารถติดตั้งได้อย่างปลอดภัยในการใช้งานจริงและรับการอัปเดตในอนาคตหรือไม่
มม.: – เราขอแนะนำเป็นอย่างยิ่ง สิ่งนี้ช่วยแก้ปัญหาได้มากมายสำหรับเรา
มช: – อีกครั้งหนึ่ง ฉันอยากจะดึงความสนใจไปที่ความจริงที่ว่าการเปลี่ยนแปลงที่ไม่เกี่ยวข้องกับสถาปัตยกรรมและไม่เกี่ยวข้องกับการบล็อกหรือคิวนั้นเป็นแบบโมดูลาร์ โดยจะอยู่ในโมดูลที่แยกจากกัน แม้จะมีการเปลี่ยนแปลงเล็กน้อย คุณก็สามารถรักษามันไว้ได้อย่างง่ายดาย
มม.: – หากคุณสนใจในรายละเอียด “Clickhouse” จะใช้สิ่งที่เรียกว่าห้องสมุดประวัติศาสตร์ มันถูกผูกไว้ - เป็นสำเนาของการรองรับ Elastics นั่นคือสามารถกำหนดค่าได้ การโพลจะเปลี่ยนเฉพาะโพลเท่านั้น เราเชื่อว่าสิ่งนี้จะใช้ได้ผลเป็นเวลานาน
NS: - ขอบคุณมาก. บอกฉันว่ามีเอกสารเกี่ยวกับการเปลี่ยนแปลงที่เกิดขึ้นหรือไม่
มม.: – เอกสารเป็นแพทช์ แน่นอนว่าด้วยการเปิดตัว Clickhouse พร้อมกับการเปิดตัวโพลเลอร์ประเภทใหม่ ตัวเลือกการกำหนดค่าใหม่ก็เกิดขึ้น ลิงก์จากสไลด์สุดท้ายมีคำอธิบายวิธีใช้งานสั้นๆ
เกี่ยวกับการแทนที่ fping ด้วย nmap
NS: – ในที่สุดคุณก็นำสิ่งนี้ไปใช้อย่างไร? คุณช่วยยกตัวอย่างที่เฉพาะเจาะจงได้ไหม: คุณมีสายรัดและสคริปต์ภายนอกหรือไม่? อะไรจบลงด้วยการตรวจสอบโฮสต์จำนวนมากอย่างรวดเร็วเช่นนี้? คุณจะขุดโฮสต์เหล่านี้ได้อย่างไร? เราจำเป็นต้องให้อาหารพวกมันเพื่อ nmap รับพวกมันจากที่ไหนสักแห่ง ใส่พวกมันเข้าไป ใช้งานบางอย่างหรือไม่?..
มม.: - เย็น. คำถามที่ถูกต้องมาก! ประเด็นคือสิ่งนี้ เราแก้ไขไลบรารี (ICMP ping ซึ่งเป็นส่วนหนึ่งของ Zabbix) สำหรับการตรวจสอบ ICMP ซึ่งระบุจำนวนแพ็กเก็ต - หนึ่ง (1) และโค้ดพยายามใช้ nmap นั่นคือนี่คืองานภายในของ Zabbix ซึ่งกลายเป็นงานภายในของคนปิงเกอร์ ดังนั้นจึงไม่จำเป็นต้องมีการซิงโครไนซ์หรือใช้กับดัก นี่เป็นการกระทำโดยเจตนาเพื่อให้ระบบไม่เสียหายและไม่ต้องจัดการกับการซิงโครไนซ์ของระบบฐานข้อมูลทั้งสอง: สิ่งที่ต้องตรวจสอบ อัปโหลดผ่านโพลเลอร์ และการอัปโหลดของเราเสียหายหรือไม่.. ง่ายกว่ามาก
NS: – มันใช้ได้กับผู้รับมอบฉันทะด้วยหรือไม่?
มม.: – ใช่ แต่เราไม่ได้ตรวจสอบ รหัสการสำรวจจะเหมือนกันทั้งใน Zabbix และเซิร์ฟเวอร์ ควรทำงาน. ฉันขอย้ำอีกครั้ง: ประสิทธิภาพของระบบนั้นเราไม่จำเป็นต้องใช้พรอกซี
มช: – คำตอบที่ถูกต้องสำหรับคำถามคือ “ทำไมคุณถึงต้องการพร็อกซีกับระบบดังกล่าว” เพียงเพราะ NAT หรือการติดตามผ่านช่องทางที่ช้าบางประเภทเท่านั้น...
NS: – และคุณใช้ Zabbix เป็นตัวก่อภูมิแพ้ ถ้าฉันเข้าใจถูกต้อง หรือย้ายกราฟิกของคุณ (ที่เลเยอร์ไฟล์เก็บถาวร) ไปยังระบบอื่น เช่น Grafana? หรือคุณไม่ได้ใช้ฟังก์ชันนี้?
มม.: – ฉันจะเน้นย้ำอีกครั้ง: เราประสบความสำเร็จในการบูรณาการอย่างสมบูรณ์ เรากำลังเทประวัติศาสตร์ลงใน Clickhouse แต่ในขณะเดียวกัน เราก็ได้เปลี่ยนส่วนหน้าของ php ส่วนหน้าของ Php ไปที่ Clickhouse และทำกราฟิกทั้งหมดจากที่นั่น ในเวลาเดียวกัน พูดตามตรง เรามีส่วนที่สร้างข้อมูลในระบบการแสดงผลกราฟิกอื่นๆ จาก Clickhouse เดียวกัน จากข้อมูล Zabbix เดียวกัน
มช: – ใน “กราฟัน” ด้วยเช่นกัน
มีการตัดสินใจอย่างไรเกี่ยวกับการจัดสรรทรัพยากร?
NS: – แบ่งปันครัวภายในของคุณเล็กน้อย มีการตัดสินใจอย่างไรว่าจำเป็นต้องจัดสรรทรัพยากรเพื่อการประมวลผลผลิตภัณฑ์อย่างจริงจัง? โดยทั่วไปแล้วสิ่งเหล่านี้ถือเป็นความเสี่ยงบางประการ และโปรดบอกฉันในบริบทของความจริงที่ว่าคุณจะสนับสนุนเวอร์ชันใหม่: การตัดสินใจครั้งนี้มีเหตุผลอย่างไรจากมุมมองฝ่ายบริหาร?
มม.: – เห็นได้ชัดว่าเราเล่าเรื่องละครประวัติศาสตร์ได้ไม่ดีนัก เราพบว่าตัวเองอยู่ในสถานการณ์ที่ต้องทำอะไรสักอย่าง และโดยพื้นฐานแล้วเราไปกับสองทีมคู่ขนาน:
- ประการหนึ่งคือการเปิดตัวระบบการตรวจสอบโดยใช้วิธีการใหม่: การตรวจสอบเป็นบริการ ซึ่งเป็นชุดมาตรฐานของโซลูชันโอเพ่นซอร์สที่เรารวมเข้าด้วยกัน จากนั้นจึงพยายามเปลี่ยนกระบวนการทางธุรกิจเพื่อที่จะทำงานร่วมกับระบบการตรวจสอบใหม่
- ในเวลาเดียวกัน เรามีโปรแกรมเมอร์ผู้กระตือรือร้นคนหนึ่งที่ทำสิ่งนี้ (เกี่ยวกับตัวเขาเอง) มันเกิดขึ้นจนเขาชนะ
NS: – และทีมมีขนาดเท่าไร?
มช: - เธออยู่ตรงหน้าคุณ
NS: – เช่นเคย คุณต้องการคนที่หลงใหลใช่ไหม?
มม.: – ฉันไม่รู้ว่าความหลงใหลคืออะไร
NS: - ในกรณีนี้คือคุณ ขอบคุณมากครับ คุณเก่งมาก
มม.: - ขอบคุณ.
เกี่ยวกับแพตช์สำหรับ Zabbix
NS: – สำหรับระบบที่ใช้พรอกซี (เช่น ในระบบแบบกระจายบางระบบ) เป็นไปได้หรือไม่ที่จะปรับเปลี่ยนและแพตช์ เช่น โพลเลอร์ พร็อกซี และตัวประมวลผลล่วงหน้าของ Zabbix บางส่วนเอง และปฏิสัมพันธ์ของพวกเขา? เป็นไปได้หรือไม่ที่จะปรับการพัฒนาที่มีอยู่ให้เหมาะสมสำหรับระบบที่มีพรอกซีหลายตัว?
มม.: – ฉันรู้ว่าเซิร์ฟเวอร์ Zabbix ประกอบโดยใช้พรอกซี (โค้ดถูกคอมไพล์และรับ) เรายังไม่ได้ทดสอบสิ่งนี้ในการผลิต ฉันไม่แน่ใจเกี่ยวกับเรื่องนี้ แต่ฉันคิดว่าไม่ได้ใช้ตัวจัดการตัวประมวลผลล่วงหน้าในพร็อกซี งานของพร็อกซีคือนำชุดเมตริกจาก Zabbix มารวมเข้าด้วยกัน (มันยังบันทึกการกำหนดค่าฐานข้อมูลท้องถิ่น) และส่งคืนให้กับเซิร์ฟเวอร์ Zabbix เซิร์ฟเวอร์จะทำการประมวลผลล่วงหน้าเมื่อได้รับ
ความสนใจในผู้รับมอบฉันทะเป็นที่เข้าใจได้ เราจะตรวจสอบมัน นี่เป็นหัวข้อที่น่าสนใจ
NS: – แนวคิดก็คือ: หากคุณสามารถแพตช์ pollers ได้ คุณสามารถแพตช์พวกมันบนพร็อกซีและแพตช์การโต้ตอบกับเซิร์ฟเวอร์ และปรับตัวประมวลผลล่วงหน้าเพื่อวัตถุประสงค์เหล่านี้บนเซิร์ฟเวอร์เท่านั้น
มม.: – ฉันคิดว่ามันง่ายกว่านี้อีก คุณรับโค้ด ใช้แพตช์ จากนั้นกำหนดค่าตามที่คุณต้องการ - รวบรวมพร็อกซีเซิร์ฟเวอร์ (เช่น ด้วย ODBC) และแจกจ่ายโค้ดแพตช์ข้ามระบบ หากจำเป็น - รวบรวมพรอกซี หากจำเป็น - เซิร์ฟเวอร์
NS: – เป็นไปได้มากว่าคุณไม่จำเป็นต้องแพตช์การส่งพร็อกซีไปยังเซิร์ฟเวอร์เพิ่มเติมใช่ไหม
มช: - ไม่ มันเป็นมาตรฐาน
มม.: – อันที่จริง ความคิดข้อหนึ่งไม่ได้ฟัง เรารักษาสมดุลระหว่างความคิดที่แพร่หลายและปริมาณของการเปลี่ยนแปลงและความสะดวกในการสนับสนุนมาโดยตลอด
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com