การตรวจสอบฐานข้อมูลที่ The Grid ตอนที่ 2: การสังเกตหลังปรับใช้

ในโพสต์ก่อนหน้าของซีรีส์นี้ ฉันได้พูดถึงวิธีที่เราดำเนินการเกี่ยวกับการรวบรวมข้อกำหนดสำหรับโครงการนี้ เราตัดสินใจอย่างไรเกี่ยวกับเครื่องมือที่จะใช้ และวิธีที่เราวางแผนการปรับใช้เพื่อหลีกเลี่ยงการหยุดชะงักของบริการ ตามที่สัญญาไว้ โพสต์ติดตามผลนี้จะเน้นที่การสังเกตหลังการปรับใช้และปัจจัยอะไรที่ทำให้เรื่องราวนี้ประสบความสำเร็จสำหรับเรา

คำสั่งที่เตรียมไว้และการกรองคลาสคำสั่ง

การออกแบบเริ่มต้นของเราสำหรับโครงการนี้มีวัตถุประสงค์เพื่อใช้ประโยชน์จากคุณลักษณะในปลั๊กอิน percona ที่ให้คุณกรองเหตุการณ์ที่ปล่อยออกมาเพื่อใช้รายการคำสั่งที่รวมหรือคำสั่งที่แยกออกเพื่อจำกัดขอบเขตเฉพาะสิ่งที่เราจำเป็นต้องตรวจสอบจริงๆ

คุณลักษณะนี้อาศัยปลั๊กอินที่ทำเครื่องหมายทุกคำสั่ง sql ที่ตรวจพบพร้อมกับคลาสตามรายการที่มีอยู่ใน mysql และจากที่นั่นการตัดสินใจในเลเยอร์เอาต์พุตหากตรวจพบคลาสคำสั่งควรถูกระงับหรือปล่อยออกมา

ดังนั้นเราจึงเขียนพิมพ์เขียวเริ่มต้นเพื่อใช้ คุณลักษณะ audit_log_exclude_commands เพื่อแยกคำสั่ง sql ใดๆ ที่ไม่ก่อให้เกิดการเขียนหรือการเปลี่ยนแปลงข้อมูลแถว เราไปทำรายการยกเว้นเพราะเรารู้สึกว่ารายการที่รวมมีความเสี่ยงที่จะขาดคลาสคำสั่งในขอบเขตและอาจกลายเป็นเหตุผลให้มีช่องว่างในบันทึกการตรวจสอบของเรา

อย่างไรก็ตาม ในคลัสเตอร์แรกที่เราทดสอบ เราเห็นว่าคำสั่งทั้งหมดที่ได้รับการตรวจสอบถูกจัดประเภทเป็น ข้อผิดพลาด แม้ว่าจะเห็นได้ชัดว่าคำสั่งเหล่านี้ทำงานสำเร็จและในกรณีที่มีการเปลี่ยนแปลงข้อมูลก็ทำได้เช่นกัน นอกจากนี้เรายังพบว่ามีการส่งข้อความค้นหาทั้งหมดไปยังเซิร์ฟเวอร์ syslog ส่วนกลางโดยไม่คำนึงถึงรายการยกเว้นซึ่งดูเหมือนว่าจะสัมพันธ์กับการจัดประเภทข้อผิดพลาดนั้น

ซึ่งหมายความว่าเราจัดเก็บเหตุการณ์ใน elasticsearch มากกว่าที่เราต้องการจริงๆ ซึ่งจะส่งผลต่อความสามารถของเราในการวิเคราะห์และตรวจจับพฤติกรรมที่ผิดพลาดอย่างทันท่วงทีอย่างแน่นอน ด้วยความร่วมมือกับทีมรักษาความปลอดภัย เราจึงตัดสินใจแจ้งปัญหาให้ Percona ทราบผ่านตัวติดตามจุดบกพร่อง แต่จะย้ายการกรองตามคำสั่งไปยังเลเยอร์ syslog ส่วนกลางด้วย

เช่นเดียวกับทุกอย่างในด้านวิศวกรรม ข้อเสียเปรียบที่นี่คือการส่งข้อมูลมากขึ้นผ่านเลเยอร์เครือข่าย DB และทำให้การกรองในเลเยอร์ syslog แบบรวมศูนย์ซับซ้อนยิ่งขึ้น และทำให้การปรับขนาดการค้นหาแบบยืดหยุ่นของเราต้องการการจัดการมากขึ้นและการกำหนดค่าบนฝั่งฐานข้อมูลง่ายขึ้น

ผลงาน

การตัดสินใจที่สำคัญที่สุดอย่างหนึ่งในโปรเจ็กต์นี้ที่ช่วยเราได้มากคือการตัดสินใจใช้สิ่งอำนวยความสะดวก rsyslog เพื่อดักจับและจัดส่งบันทึกเหล่านี้ไปยังเซิร์ฟเวอร์ syslog ส่วนกลาง

แต่ไม่มีอะไรที่ปราศจากข้อดีและข้อเสีย

การตัดสินใจนี้หมายความว่าช่วงเวลาทำงานของระบบที่แยกจากกันและความน่าเชื่อถือของสแต็กเครือข่ายระหว่างนั้นมีความสำคัญต่อการจัดหา SLA ที่เราต้องการเพื่อให้ทีมตรวจสอบมีความมั่นใจในโซลูชันการตรวจสอบนี้

สำหรับผู้ที่ไม่ต้องการประนีประนอมและต้องการรักษาความรับผิดชอบของการคงอยู่ของบันทึกการตรวจสอบภายใน DB stack ฉันขอแนะนำให้ใช้ ตัวจัดการ ไฟล์ ในปลั๊กอินการตรวจสอบ จากนั้นใช้ logstash ในเครื่องเพื่อนำบันทึกและส่งต่อไปยังระบบวิเคราะห์ของ ทางเลือก.

ตัวเลือกหลังนั้นหมายถึง IOP ของดิสก์จำนวนมากที่ใช้ไปจากกระบวนการฐานข้อมูลและใช้งานโดยปลั๊กอินการตรวจสอบและ logstash และหมายความว่าคุณต้องปรับสมดุลพื้นที่ดิสก์บนอินสแตนซ์ของคุณอย่างระมัดระวังระหว่างไฟล์ตารางฐานข้อมูล บันทึกการทำงาน และการตรวจสอบ บันทึกปลั๊กอิน การชั่งน้ำหนักตัวเลือกของคุณต้องพึ่งพาเพียงอย่างเดียวซึ่งการดำเนินการ/ยอมรับได้ง่ายขึ้นโดยธุรกิจ แต่คุณมีตัวเลือก

ในกรณีของเรา ตัวเลือก rsyslog พิสูจน์แล้วว่าส่งผลกระทบน้อยที่สุดต่อฐานข้อมูลที่ยุ่งของเรา โดยสูงสุดที่ประมาณ 5400 ธุรกรรม/วินาที ในระหว่างการทำงานปกติ เราไม่มีผลกระทบต่อประสิทธิภาพการทำงาน ปลั๊กอินการตรวจสอบทำงานอย่างต่อเนื่อง โดยส่งเหตุการณ์โดยไม่กระทบต่อประสิทธิภาพของฐานข้อมูล ทั้งหมดเป็นเพราะเราได้เลือกสถาปัตยกรรมที่หลีกเลี่ยงการใช้งานดิสก์บนฝั่งฐานข้อมูล

การตัดสินใจในอดีตได้ผลดี

หนึ่งในข้อกังวลแรกที่เรามีเมื่อเราเริ่มดำเนินการในโครงการนี้คือผลกระทบต่อประสิทธิภาพ คลัสเตอร์ฐานข้อมูลกลุ่มหนึ่งที่อยู่ในขอบเขตมีเวลาว่างมากและแอปพลิเคชันมีความอ่อนไหวต่อความล่าช้า ดังนั้นเราจึงต้องแน่ใจว่าเราติดตามตัวชี้วัดประสิทธิภาพ เช่น ธุรกรรมต่อวินาที การใช้งานดิสก์และ CPU เพื่อเปรียบเทียบตัวเลขหลังจากปรับใช้ปลั๊กอินและ ดูว่าบทลงโทษสำหรับสิ่งนั้นคืออะไร

เป็นเรื่องน่าประหลาดใจที่เห็นว่าเราไม่ได้ถูกลงโทษมากนักในการปฏิบัติงานตามปกติ ดังที่กล่าวไว้ก่อนหน้านี้ เนื่องจากเราตัดสินใจใช้ตัวจัดการ SYSLOG หมายความว่าโดยปกติเราไม่จำเป็นต้องใช้ความจุดิสก์ในเครื่องใดๆ เพื่อติดตามเหตุการณ์การตรวจสอบเหล่านี้

แต่เราไม่ต้องการวางแผนตามเวลา 'การทำงานปกติ' เท่านั้น

เรายังจำเป็นต้องทราบด้วยว่าเมื่อ rsyslog ต้องการทางเลือกสำรองไปยังไฟล์สปูลในเครื่อง เหตุการณ์เหล่านี้จะไม่รวมเข้ากับบริการที่ส่งผลกระทบต่อการหยุดทำงานของคลัสเตอร์ DB ที่มีความสำคัญมากกว่า โดยการทดสอบพฤติกรรมการสพูล rsyslog ภายใต้การดูแลอย่างใกล้ชิดในการผลิต เราตระหนักดีว่าการทำงานในการแบ่งส่วนข้อมูลฐานข้อมูลของเราในไม่กี่ปีที่ผ่านมาทำให้เราได้รับประโยชน์โดยไม่ได้วางแผนจากความจุของดิสก์ IOP จำนวนมากในการดูดซับเหตุการณ์ เช่น การสพูล rsyslog ไปยังดิสก์ จากนั้นจึงจำเป็นต้องส่งอีกครั้ง เหตุการณ์ทั้งหมดนี้

เราสังเกตเห็นการเพิ่มขึ้นของการใช้ดิสก์ระหว่างเหตุการณ์เหล่านี้ แต่ไม่เคยทำให้อินสแตนซ์ db อยู่ในสถานะวิกฤติหรือกิจกรรมที่ต้องเผชิญกับลูกค้าได้รับผลกระทบ

การแลกเปลี่ยน

เช่นเดียวกับทุกอย่างในด้านวิศวกรรมซอฟต์แวร์ มักมีข้อแลกเปลี่ยนเสมอ ในโครงการนี้ เราพิจารณาวิธีการส่งบันทึกที่มีความน่าเชื่อถือมากกว่าและมีศักยภาพน้อยกว่าสำหรับบันทึกที่สูญหาย ซึ่งจะเกี่ยวข้องกับการเขียนบันทึกลงดิสก์ จากนั้นใช้บางอย่างเช่น logstash เพื่อนำเข้าและส่งไปยังปลายทางการวิเคราะห์เพื่อให้ทีมรักษาความปลอดภัยใช้

แต่นั่นจะหมายถึงการใช้ดิสก์ IOPs ที่มีนัยสำคัญในด้านฐานข้อมูล ซึ่งเรารู้ว่าอาจส่งผลกระทบต่อคุณภาพการบริการของการเรียกลูกค้าไปยังฐานข้อมูลเหล่านี้

เราตัดสินใจว่าจะตอบสนองความต้องการทางธุรกิจของเราได้อย่างเพียงพอโดยใช้การบันทึกที่ยืดหยุ่นใน rsyslog โดยใช้สปูลที่มีขนาดเหมาะสม และใช้ TCP เพื่อส่งเหตุการณ์ไปยังสแต็กการตรวจสอบบันทึกของเรา เช่นเดียวกับทุกสิ่งในชีวิต ไม่มีอะไรที่คงอยู่ตลอดไป และเราทราบดีว่าการตัดสินใจครั้งนี้อาจต้องมีการทบทวนอีกครั้งในอนาคต

ในที่สุด

โครงการนี้แม้จะครอบคลุมคลัสเตอร์ครึ่งโหลและอินสแตนซ์จำนวนมาก แต่ก็เสร็จสิ้นภายในไตรมาสเดียวในขณะที่ทีมปฏิบัติการ DB ยังคงจุดไฟในธุรกิจที่เติบโตอย่างรวดเร็วและยังคงเติบโตอย่างรวดเร็ว สิ่งนี้จะเกิดขึ้นไม่ได้หากปราศจากความร่วมมืออย่างใกล้ชิดระหว่าง DBE และทีมรักษาความปลอดภัย และหากไม่มีการจัดการผลิตภัณฑ์ที่แข็งแกร่งซึ่งรักษาขอบเขตที่จำกัดและเป็นที่ทราบกันดีอยู่แล้ว เพื่อให้แน่ใจว่าเราทุกคนจับตาดูเป้าหมายสุดท้ายในการทำให้ธุรกิจของเราปลอดภัยยิ่งขึ้น