นี่มันปี 2019 และเรายังไม่มีโซลูชันมาตรฐานสำหรับการรวมบันทึกใน Kubernetes ในบทความนี้ เราต้องการใช้ตัวอย่างจากการปฏิบัติจริง เพื่อแบ่งปันการค้นหา ปัญหาที่พบ และวิธีแก้ไข
อย่างไรก็ตาม ก่อนอื่น ฉันจะจองโดยให้ลูกค้าแต่ละรายเข้าใจสิ่งต่าง ๆ กันมากโดยการรวบรวมบันทึก:
- มีคนต้องการดูบันทึกความปลอดภัยและการตรวจสอบ
- ใครบางคน - การบันทึกแบบรวมศูนย์ของโครงสร้างพื้นฐานทั้งหมด
- และสำหรับบางคน การรวบรวมเฉพาะบันทึกแอปพลิเคชันก็เพียงพอแล้ว ไม่รวม ตัวอย่างเช่น บาลานเซอร์
ด้านล่างนี้คือบทสรุปเกี่ยวกับวิธีการใช้ "รายการความปรารถนา" ต่างๆ และเราพบปัญหาอะไรบ้าง
ทฤษฎี: เกี่ยวกับเครื่องมือบันทึก
ความเป็นมาเกี่ยวกับส่วนประกอบของระบบบันทึก
การบันทึกมีการพัฒนาไปมาก โดยเป็นผลมาจากวิธีการรวบรวมและวิเคราะห์บันทึกที่ได้รับการพัฒนา ซึ่งเป็นสิ่งที่เราใช้อยู่ในปัจจุบัน ย้อนกลับไปในทศวรรษ 1950 Fortran ได้เปิดตัวอะนาล็อกของสตรีมอินพุต/เอาท์พุตมาตรฐาน ซึ่งช่วยให้โปรแกรมเมอร์สามารถดีบักโปรแกรมของเขาได้ นี่เป็นบันทึกคอมพิวเตอร์ชุดแรกที่ทำให้ชีวิตของโปรแกรมเมอร์ในสมัยนั้นง่ายขึ้น วันนี้เราเห็นองค์ประกอบแรกของระบบการบันทึกในตัวพวกเขาแล้ว - แหล่งที่มาหรือ “ผู้ผลิต” ของบันทึก.
วิทยาการคอมพิวเตอร์ไม่หยุดนิ่ง: เครือข่ายคอมพิวเตอร์ปรากฏขึ้น กลุ่มแรก... ระบบที่ซับซ้อนซึ่งประกอบด้วยคอมพิวเตอร์หลายเครื่องเริ่มทำงาน ขณะนี้ผู้ดูแลระบบถูกบังคับให้รวบรวมบันทึกจากเครื่องหลายเครื่อง และในกรณีพิเศษ พวกเขาสามารถเพิ่มข้อความเคอร์เนลระบบปฏิบัติการได้ ในกรณีที่จำเป็นต้องตรวจสอบความล้มเหลวของระบบ เพื่ออธิบายระบบการรวบรวมบันทึกแบบรวมศูนย์ ในช่วงต้นทศวรรษ 2000 จึงมีการเผยแพร่ ซึ่งทำให้ remote_syslog เป็นมาตรฐาน นี่คือลักษณะที่ปรากฏขององค์ประกอบสำคัญอื่น: นักสะสมบันทึก และที่เก็บข้อมูลของพวกเขา
ด้วยปริมาณบันทึกที่เพิ่มขึ้นและการนำเทคโนโลยีเว็บมาใช้อย่างแพร่หลาย คำถามก็เกิดขึ้นว่าบันทึกใดบ้างที่ต้องแสดงให้ผู้ใช้เห็นได้อย่างสะดวก เครื่องมือคอนโซลแบบธรรมดา (awk/sed/grep) ถูกแทนที่ด้วยเครื่องมือขั้นสูงกว่า ผู้ดูบันทึก - องค์ประกอบที่สาม
เนื่องจากปริมาณบันทึกเพิ่มขึ้น จึงมีบางสิ่งที่ชัดเจน: จำเป็นต้องมีบันทึก แต่ไม่ใช่ทั้งหมด และบันทึกที่แตกต่างกันต้องการระดับการเก็บรักษาที่แตกต่างกัน: บ้างก็หายไปในหนึ่งวัน ในขณะที่บ้างต้องเก็บไว้เป็นเวลา 5 ปี ดังนั้น ส่วนประกอบสำหรับการกรองและกำหนดเส้นทางกระแสข้อมูลจึงถูกเพิ่มเข้าไปในระบบการบันทึก เรามาเรียกมันกันดีกว่า กรอง.
พื้นที่จัดเก็บข้อมูลยังก้าวกระโดดครั้งใหญ่อีกด้วย จากไฟล์ปกติไปจนถึงฐานข้อมูลเชิงสัมพันธ์ และจากนั้นก็ไปสู่พื้นที่จัดเก็บข้อมูลเชิงเอกสาร (เช่น Elasticsearch) ดังนั้นที่เก็บของจึงถูกแยกออกจากตัวสะสม
ท้ายที่สุดแล้ว แนวคิดเรื่องบันทึกได้ขยายไปสู่กระแสนามธรรมของเหตุการณ์ที่เราต้องการเก็บรักษาไว้เป็นประวัติศาสตร์ หรือในกรณีที่คุณจำเป็นต้องดำเนินการสอบสวนหรือจัดทำรายงานการวิเคราะห์...
เป็นผลให้ในระยะเวลาอันสั้น การรวบรวมบันทึกได้พัฒนาเป็นระบบย่อยที่สำคัญ ซึ่งสามารถเรียกได้ว่าเป็นหนึ่งในส่วนย่อยใน Big Data อย่างถูกต้อง
หากกาลครั้งหนึ่งการพิมพ์ธรรมดาอาจเพียงพอสำหรับ "ระบบบันทึก" ตอนนี้สถานการณ์เปลี่ยนไปมาก
Kubernetes และบันทึก
เมื่อ Kubernetes มาถึงโครงสร้างพื้นฐาน ปัญหาที่มีอยู่แล้วในการรวบรวมบันทึกก็ไม่ได้ข้ามไปเช่นกัน ในบางแง่ มันยิ่งเจ็บปวดมากขึ้นอีก: การจัดการแพลตฟอร์มโครงสร้างพื้นฐานไม่เพียงทำให้ง่ายขึ้น แต่ยังซับซ้อนในเวลาเดียวกันอีกด้วย บริการเก่าๆ จำนวนมากได้เริ่มโยกย้ายไปยังไมโครเซอร์วิสแล้ว ในบริบทของบันทึก สิ่งนี้สะท้อนให้เห็นในจำนวนแหล่งบันทึกที่เพิ่มขึ้น วงจรชีวิตพิเศษ และความจำเป็นในการติดตามความสัมพันธ์ของส่วนประกอบของระบบทั้งหมดผ่านบันทึก...
เมื่อมองไปข้างหน้า ฉันสามารถระบุได้ว่าตอนนี้น่าเสียดายที่ไม่มีตัวเลือกการบันทึกที่เป็นมาตรฐานสำหรับ Kubernetes ที่จะเปรียบเทียบได้ดีกับตัวเลือกอื่นๆ ทั้งหมด แผนการที่ได้รับความนิยมมากที่สุดในชุมชนมีดังนี้:
- มีคนคลี่สแต็กออก เอฟเค (Elasticsearch, Fluentd, Kibana);
- มีคนกำลังลองใช้ที่เพิ่งเปิดตัว หรือใช้ ;
- เรา (และอาจจะไม่ใช่แค่เราเท่านั้น?..) ฉันพอใจกับพัฒนาการของตัวเองมาก - ...
ตามกฎแล้ว เราใช้บันเดิลต่อไปนี้ในคลัสเตอร์ K8 (สำหรับโซลูชันที่โฮสต์เอง):
- ;
- .
อย่างไรก็ตาม ฉันจะไม่อาศัยคำแนะนำในการติดตั้งและการกำหนดค่า แต่ฉันจะมุ่งเน้นไปที่ข้อบกพร่องและข้อสรุประดับโลกเพิ่มเติมเกี่ยวกับสถานการณ์ของบันทึกโดยทั่วไป
ฝึกฝนกับบันทึกใน K8
“บันทึกประจำวัน” มีกี่คนกันนะ?..
การรวบรวมบันทึกแบบรวมศูนย์จากโครงสร้างพื้นฐานที่ค่อนข้างใหญ่ต้องใช้ทรัพยากรจำนวนมาก ซึ่งจะใช้ในการรวบรวม จัดเก็บ และประมวลผลบันทึก ในระหว่างการดำเนินโครงการต่างๆ เราต้องเผชิญกับข้อกำหนดและปัญหาการดำเนินงานต่างๆ ที่เกิดขึ้น
มาลอง ClickHouse กันดีกว่า
มาดูที่จัดเก็บข้อมูลแบบรวมศูนย์ในโปรเจ็กต์ที่มีแอปพลิเคชันที่สร้างบันทึกค่อนข้างมาก: มากกว่า 5000 บรรทัดต่อวินาที มาเริ่มทำงานกับบันทึกของเขาโดยเพิ่มลงใน ClickHouse กัน
ทันทีที่ต้องการเรียลไทม์สูงสุด เซิร์ฟเวอร์ 4 คอร์ที่มี ClickHouse จะถูกโอเวอร์โหลดบนระบบย่อยของดิสก์แล้ว:
การโหลดประเภทนี้เกิดจากการที่เราพยายามเขียนใน ClickHouse โดยเร็วที่สุด และฐานข้อมูลตอบสนองต่อสิ่งนี้ด้วยโหลดดิสก์ที่เพิ่มขึ้นซึ่งอาจทำให้เกิดข้อผิดพลาดต่อไปนี้:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
ความจริงที่เป็น ใน ClickHouse (มีข้อมูลบันทึก) มีปัญหาระหว่างการเขียน ข้อมูลที่แทรกเข้าไปจะสร้างพาร์ติชันชั่วคราว ซึ่งจากนั้นจะรวมเข้ากับตารางหลัก เป็นผลให้การบันทึกกลายเป็นความต้องการอย่างมากบนดิสก์และยังอยู่ภายใต้ข้อ จำกัด ที่เราได้รับการแจ้งเตือนด้านบน: สามารถรวมพาร์ติชั่นย่อยได้ไม่เกิน 1 พาร์ติชั่นใน 300 วินาที (อันที่จริงนี่คือ 300 ส่วนแทรก ต่อวินาที).
เพื่อหลีกเลี่ยงพฤติกรรมนี้ как можно более большими кусками и не чаще 1 раза в 2 секунды. Однако запись большими пачками предполагает, что мы должны реже писать в ClickHouse. Это, в свою очередь, может привести к переполнению буфера и к потере логов. Решение — увеличить буфер Fluentd, но тогда увеличится и потребление памяти.
หมายเหตุ: ปัญหาอีกประการหนึ่งของโซลูชันของเรากับ ClickHouse นั้นเกี่ยวข้องกับความจริงที่ว่าการแบ่งพาร์ติชันในกรณีของเรา (ล็อกเฮาส์) นั้นถูกนำไปใช้ผ่านตารางภายนอกที่เชื่อมต่อ . สิ่งนี้นำไปสู่ความจริงที่ว่าเมื่อสุ่มตัวอย่างช่วงเวลาขนาดใหญ่ จำเป็นต้องใช้ RAM มากเกินไป เนื่องจากเมตาเทเบิลจะวนซ้ำผ่านพาร์ติชั่นทั้งหมด แม้แต่พาร์ติชั่นที่เห็นได้ชัดว่าไม่มีข้อมูลที่จำเป็นก็ตาม อย่างไรก็ตาม ขณะนี้แนวทางนี้สามารถประกาศให้ล้าสมัยได้อย่างปลอดภัยสำหรับ ClickHouse เวอร์ชันปัจจุบัน (ค ).
เป็นผลให้เห็นได้ชัดว่าไม่ใช่ทุกโครงการที่มีทรัพยากรเพียงพอที่จะรวบรวมบันทึกแบบเรียลไทม์ใน ClickHouse (แม่นยำยิ่งขึ้นการแจกจ่ายจะไม่เหมาะสม) นอกจากนี้คุณจะต้องใช้ аккумуляторซึ่งเราจะกลับมาในภายหลัง กรณีที่อธิบายข้างต้นเป็นเรื่องจริง และในขณะนั้น เราไม่สามารถนำเสนอโซลูชันที่เชื่อถือได้และมีเสถียรภาพที่เหมาะกับลูกค้าได้ และช่วยให้เรารวบรวมบันทึกโดยมีความล่าช้าน้อยที่สุด...
แล้ว Elasticsearch ล่ะ?
เป็นที่รู้กันว่า Elasticsearch สามารถรองรับเวิร์กโหลดจำนวนมากได้ มาลองกันในโปรเจ็กต์เดียวกันครับ ตอนนี้โหลดมีลักษณะดังนี้:
Elasticsearch สามารถแยกแยะสตรีมข้อมูลได้ อย่างไรก็ตาม การเขียนวอลุ่มดังกล่าวลงไปจะใช้ประโยชน์จาก CPU อย่างมาก ตัดสินใจได้โดยการจัดคลัสเตอร์ ในทางเทคนิคแล้ว นี่ไม่ใช่ปัญหา แต่ปรากฎว่าเพียงเพื่อใช้งานระบบรวบรวมบันทึก เราใช้อยู่แล้วประมาณ 8 คอร์ และมีส่วนประกอบที่มีการโหลดสูงเพิ่มเติมในระบบ...
บรรทัดล่าง: ตัวเลือกนี้สามารถพิสูจน์ได้ แต่เฉพาะในกรณีที่โครงการมีขนาดใหญ่และฝ่ายจัดการพร้อมที่จะใช้ทรัพยากรจำนวนมากในระบบการบันทึกแบบรวมศูนย์
จากนั้นคำถามธรรมชาติก็เกิดขึ้น:
บันทึกอะไรที่จำเป็นจริงๆ?
เรามาลองเปลี่ยนแนวทางกัน: บันทึกควรให้ข้อมูลไปพร้อมๆ กันและไม่ครอบคลุม แต่ละ เหตุการณ์ในระบบ
สมมติว่าเรามีร้านค้าออนไลน์ที่ประสบความสำเร็จ บันทึกใดมีความสำคัญ? การรวบรวมข้อมูลให้ได้มากที่สุด เช่น จากเกตเวย์การชำระเงิน ถือเป็นแนวคิดที่ดี แต่ไม่ใช่ว่าบันทึกทั้งหมดจากบริการแบ่งส่วนรูปภาพในแค็ตตาล็อกผลิตภัณฑ์จะมีความสำคัญสำหรับเรา มีเพียงข้อผิดพลาดและการตรวจสอบขั้นสูงเท่านั้นที่เพียงพอ (เช่น เปอร์เซ็นต์ของข้อผิดพลาด 500 ข้อที่คอมโพเนนต์นี้สร้างขึ้น)
เราก็เลยได้ข้อสรุปว่า การบันทึกแบบรวมศูนย์ไม่ได้เป็นสิ่งที่สมเหตุสมผลเสมอไป. บ่อยครั้งที่ลูกค้าต้องการรวบรวมบันทึกทั้งหมดในที่เดียว แม้ว่าในความเป็นจริงแล้ว จากบันทึกทั้งหมด จำเป็นต้องมีข้อความเพียง 5% ที่มีเงื่อนไขซึ่งมีความสำคัญต่อธุรกิจเท่านั้น:
- บางครั้งการกำหนดค่าเฉพาะขนาดของบันทึกคอนเทนเนอร์และตัวรวบรวมข้อผิดพลาดก็เพียงพอแล้ว (เช่น Sentry)
- การแจ้งเตือนข้อผิดพลาดและบันทึกในเครื่องขนาดใหญ่มักจะเพียงพอที่จะตรวจสอบเหตุการณ์ได้
- เรามีโครงการที่ทำขึ้นโดยใช้การทดสอบการทำงานและระบบรวบรวมข้อผิดพลาดโดยเฉพาะ นักพัฒนาซอฟต์แวร์ไม่ต้องการบันทึกเช่นนี้ - พวกเขาเห็นทุกอย่างจากการติดตามข้อผิดพลาด
ภาพประกอบจากชีวิต
เรื่องอื่นสามารถใช้เป็นตัวอย่างที่ดีได้ เราได้รับคำขอจากทีมรักษาความปลอดภัยของลูกค้าของเรารายหนึ่งซึ่งใช้โซลูชันเชิงพาณิชย์ที่พัฒนาขึ้นมานานก่อนที่จะมีการเปิดตัว Kubernetes
จำเป็นต้อง "ผูกมิตร" กับระบบรวบรวมบันทึกแบบรวมศูนย์ด้วยเซ็นเซอร์ตรวจจับปัญหาขององค์กร - QRadar ระบบนี้สามารถรับบันทึกผ่านโปรโตคอล syslog และดึงข้อมูลจาก FTP อย่างไรก็ตาม ไม่สามารถรวมเข้ากับปลั๊กอิน remote_syslog สำหรับ fluentd ได้ในทันที (ปรากฏว่า ). ปัญหาในการตั้งค่า QRadar กลายเป็นปัญหาจากทีมรักษาความปลอดภัยของลูกค้า
เป็นผลให้ส่วนหนึ่งของบันทึกทางธุรกิจที่สำคัญถูกอัพโหลดไปยัง FTP QRadar และอีกส่วนหนึ่งถูกเปลี่ยนเส้นทางผ่าน syslog ระยะไกลจากโหนดโดยตรง สำหรับสิ่งนี้เรายังเขียนด้วยซ้ำ - บางทีมันอาจช่วยใครบางคนแก้ปัญหาที่คล้ายกัน... ด้วยรูปแบบผลลัพธ์ ลูกค้าเองก็ได้รับและวิเคราะห์บันทึกที่สำคัญ (โดยใช้เครื่องมือที่เขาชื่นชอบ) และเราสามารถลดต้นทุนของระบบบันทึกได้ โดยประหยัดเพียง เดือนที่แล้ว.
อีกตัวอย่างหนึ่งค่อนข้างบ่งบอกถึงสิ่งที่ไม่ควรทำ หนึ่งในลูกค้าของเราสำหรับการประมวลผล แต่ละ события, поступающего от пользователя, делал многострочный เอาต์พุตที่ไม่มีโครงสร้าง ข้อมูลในบันทึก ดังที่คุณอาจเดาได้ว่าบันทึกดังกล่าวไม่สะดวกอย่างยิ่งในการอ่านและจัดเก็บ
เกณฑ์สำหรับบันทึก
ตัวอย่างดังกล่าวนำไปสู่ข้อสรุปว่านอกเหนือจากการเลือกระบบรวบรวมบันทึกแล้ว คุณยังต้องเลือกอีกด้วย ออกแบบท่อนไม้เองด้วย! ข้อกำหนดที่นี่มีอะไรบ้าง?
- บันทึกต้องอยู่ในรูปแบบที่เครื่องอ่านได้ (เช่น JSON)
- บันทึกควรมีขนาดกะทัดรัดและสามารถเปลี่ยนแปลงระดับของการบันทึกเพื่อแก้ไขปัญหาที่อาจเกิดขึ้นได้ ในเวลาเดียวกัน ในสภาพแวดล้อมการผลิต คุณควรรันระบบที่มีระดับการบันทึกเช่น การเตือน หรือ ความผิดพลาด.
- บันทึกจะต้องได้รับการทำให้เป็นมาตรฐาน กล่าวคือ ในออบเจ็กต์บันทึก บรรทัดทั้งหมดต้องมีประเภทฟิลด์เดียวกัน
บันทึกที่ไม่มีโครงสร้างอาจทำให้เกิดปัญหากับการโหลดบันทึกลงในพื้นที่จัดเก็บและทำให้การประมวลผลหยุดชะงักโดยสิ้นเชิง เพื่อเป็นตัวอย่าง นี่คือตัวอย่างที่มีข้อผิดพลาด 400 ซึ่งหลายคนพบอย่างแน่นอนในบันทึกที่คล่อง:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
ข้อผิดพลาดหมายความว่าคุณกำลังส่งฟิลด์ที่มีประเภทไม่เสถียรไปยังดัชนีด้วยการแมปสำเร็จรูป ตัวอย่างที่ง่ายที่สุดคือฟิลด์ในบันทึก nginx ที่มีตัวแปร $upstream_status. อาจมีตัวเลขหรือสตริงก็ได้ ตัวอย่างเช่น:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
บันทึกแสดงว่าเซิร์ฟเวอร์ 10.100.0.10 ตอบกลับด้วยข้อผิดพลาด 404 และคำขอถูกส่งไปยังที่จัดเก็บเนื้อหาอื่น เป็นผลให้ค่าในบันทึกกลายเป็นดังนี้:
"upstream_response_time": "0.001, 0.007"
สถานการณ์นี้เป็นเรื่องปกติมากจนสมควรได้รับการแยกจากกัน .
แล้วความน่าเชื่อถือล่ะ?
มีหลายครั้งที่บันทึกทั้งหมดโดยไม่มีข้อยกเว้นมีความสำคัญ และด้วยเหตุนี้ รูปแบบการรวบรวมบันทึกทั่วไปสำหรับ K8 ที่เสนอ/กล่าวถึงข้างต้นจึงมีปัญหา
ตัวอย่างเช่น fluentd ไม่สามารถรวบรวมบันทึกจากคอนเทนเนอร์ที่มีอายุสั้นได้ ในโปรเจ็กต์หนึ่งของเรา คอนเทนเนอร์การย้ายฐานข้อมูลใช้เวลาน้อยกว่า 4 วินาทีแล้วถูกลบ - ตามคำอธิบายประกอบที่เกี่ยวข้อง:
"helm.sh/hook-delete-policy": hook-succeeded
ด้วยเหตุนี้ บันทึกการดำเนินการย้ายจึงไม่รวมอยู่ในที่เก็บข้อมูล การเมืองสามารถช่วยได้ในกรณีนี้ before-hook-creation.
อีกตัวอย่างหนึ่งคือการหมุนเวียนบันทึกนักเทียบท่า สมมติว่ามีแอปพลิเคชันที่เขียนลงในบันทึกอย่างแข็งขัน ภายใต้สภาวะปกติ เราจะจัดการเพื่อประมวลผลบันทึกทั้งหมด แต่ทันทีที่เกิดปัญหา - ตัวอย่างเช่น ตามที่อธิบายไว้ข้างต้นด้วยรูปแบบที่ไม่ถูกต้อง - การประมวลผลจะหยุดลง และ Docker จะหมุนไฟล์ ผลลัพธ์ก็คือบันทึกที่มีความสำคัญทางธุรกิจอาจสูญหายได้
นั่นเป็นเหตุผลที่ สิ่งสำคัญคือต้องแยกสตรีมบันทึกออกจากกันฝังการส่งสิ่งที่มีค่าที่สุดลงในแอปพลิเคชันโดยตรงเพื่อความปลอดภัย นอกจากนี้การสร้างบางอย่างก็คงไม่ฟุ่มเฟือย “ตัวสะสม” ของบันทึกซึ่งสามารถรอดพ้นจากพื้นที่จัดเก็บที่ไม่เพียงพอในขณะที่บันทึกข้อความสำคัญ
สุดท้ายนี้เราจะต้องไม่ลืมสิ่งนั้น สิ่งสำคัญคือต้องตรวจสอบระบบย่อยอย่างเหมาะสม. มิฉะนั้น มันง่ายที่จะเจอสถานการณ์ที่ fluentd อยู่ในสถานะ CrashLoopBackOff และไม่ส่งสิ่งใดเลยและสิ่งนี้สัญญาว่าจะสูญเสียข้อมูลสำคัญ
ผลการวิจัย
ในบทความนี้ เราไม่ได้ดูโซลูชัน SaaS เช่น Datadog ปัญหาหลายประการที่อธิบายไว้ที่นี่ได้รับการแก้ไขไม่ทางใดก็ทางหนึ่งโดยบริษัทการค้าที่เชี่ยวชาญในการรวบรวมบันทึก แต่ไม่ใช่ทุกคนที่สามารถใช้ SaaS ได้ด้วยเหตุผลหลายประการ (หลักคือต้นทุนและการปฏิบัติตาม 152-FZ).
การรวบรวมบันทึกแบบรวมศูนย์ในตอนแรกดูเหมือนเป็นงานง่ายๆ แต่ก็ไม่ใช่เลย สิ่งสำคัญคือต้องจำไว้ว่า:
- จำเป็นต้องบันทึกรายละเอียดเฉพาะส่วนประกอบที่สำคัญเท่านั้น ในขณะที่สามารถกำหนดค่าการตรวจสอบและการรวบรวมข้อผิดพลาดสำหรับระบบอื่นได้
- บันทึกในการผลิตควรเก็บไว้ให้น้อยที่สุดเพื่อไม่ให้เพิ่มภาระที่ไม่จำเป็น
- บันทึกจะต้องสามารถอ่านได้ด้วยเครื่อง ทำให้เป็นมาตรฐาน และมีรูปแบบที่เข้มงวด
- บันทึกที่สำคัญจริงๆ ควรส่งในสตรีมแยกต่างหาก ซึ่งควรแยกออกจากสตรีมหลัก
- การพิจารณาตัวสะสมบันทึกเป็นสิ่งที่ควรค่าแก่การพิจารณาซึ่งสามารถช่วยคุณประหยัดจากการระเบิดของภาระสูงและทำให้ภาระในการจัดเก็บมีความสม่ำเสมอมากขึ้น
กฎง่ายๆ เหล่านี้หากใช้ทุกที่ จะทำให้วงจรที่อธิบายไว้ข้างต้นทำงานได้ แม้ว่าส่วนประกอบสำคัญจะหายไป (แบตเตอรี่) หากคุณไม่ปฏิบัติตามหลักการดังกล่าว งานจะนำคุณและโครงสร้างพื้นฐานไปสู่ส่วนประกอบอื่นที่มีภาระงานสูง (และในเวลาเดียวกันก็ไม่มีประสิทธิภาพ) ของระบบได้อย่างง่ายดาย
PS
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «'
ที่มา: will.com