สถาปัตยกรรมข้อมูลสำหรับการวัดบันทึกเหตุการณ์?

17

บริการของฉันมีกิจกรรมของผู้ใช้จำนวนมากอย่างต่อเนื่องและเราต้องการทำสิ่งต่าง ๆ เช่น "การนับเหตุการณ์ประเภทTตั้งแต่วันที่D "

เรากำลังพยายามตัดสินใจขั้นพื้นฐานสองประการ:

จะเก็บอะไรดี? การจัดเก็บทุกเหตุการณ์เทียบกับการจัดเก็บมวลรวมเท่านั้น
- (สไตล์บันทึกเหตุการณ์) บันทึกทุกเหตุการณ์และนับในภายหลังกับ
- (สไตล์อนุกรมเวลา) จัดเก็บ "การนับเหตุการณ์อีสำหรับวันที่D " ที่รวบรวมไว้ทุกวัน
จะเก็บข้อมูลที่ไหน
- ในฐานข้อมูลเชิงสัมพันธ์ (โดยเฉพาะ MySQL)
- ในฐานข้อมูลที่ไม่ใช่เชิงสัมพันธ์ (NoSQL)
- ในไฟล์บันทึกการทำงานแบบแบน (รวบรวมจากส่วนกลางผ่านเครือข่ายผ่านทางsyslog-ng)

มาตรฐานการปฏิบัติคืออะไรที่ฉันสามารถอ่านเพิ่มเติมเกี่ยวกับการเปรียบเทียบระบบประเภทต่าง ๆ ได้

รายละเอียดเพิ่มเติม:

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

IMHO "บันทึกเหตุการณ์ทั้งหมดไปยังไฟล์รวบรวมข้อมูลในภายหลังเพื่อกรองและรวมสตรีม" เป็นวิธีมาตรฐาน UNIX ที่สวยงาม แต่เพื่อนร่วมทาง Rails-y ของฉันดูเหมือนจะคิดว่าไม่มีอะไรจริงเว้นแต่ว่ามันจะอยู่ใน MySQL

architecture database metrics

— elliot42
แหล่งที่มา

1

มีโชคกับโปรเจ็กต์นี้ไหม?

— hiwaylon

2

@hiwaylon เราลงเอยด้วยระบบไฮบริด: 1) MySQL ถ้าเป็นไปได้ (มีปริมาณน้อย) (ทำให้การรวมใช้งานง่ายSELECT...GROUP BYสามารถจัดเก็บผลลัพธ์ของSELECT2) โดยใช้Graphiteสำหรับการรวมและการมองเห็นขนาดใหญ่แบบง่ายและ 3) การบันทึกเหตุการณ์เต็มรูปแบบสำหรับการอ้างอิงและดูรายละเอียดของการไหลของข้อมูลในเวลาจริง แต่ละอันมีคุณค่าแตกต่างกันไป

— elliot42

ฟังดูเป็นทางออกที่ยอดเยี่ยมคล้ายกับสิ่งที่เรากำลังทำอยู่

— hiwaylon

1

อัปเดตมากกว่าหนึ่งปีต่อมาเราสร้างระบบที่บันทึกทุกอย่างและวนซ้ำเป็นระยะ ๆ จากนั้นจึงจัดเก็บตัวเลขที่นับเหล่านั้นลงในฐานข้อมูล (อาจเป็นฐานข้อมูลอนุกรมเวลา แต่พอเพียงกับ MySQL) นี่คือการทำงานไม่กี่สัปดาห์ แต่สุดท้ายก็เป็นวิธีการที่มีประสิทธิภาพ / รวดเร็วอย่างน่าประหลาดใจเมื่อเป็นเพียงรหัสของคุณวนซ้ำ JSON ที่บันทึกไว้มันง่ายในการเพิ่มข้อมูลเมตาจำนวนมากและง่ายสำหรับรหัสของคุณที่จะมีกฎที่ยืดหยุ่น มันต้องการที่จะนับ

— elliot42

1

Update 2016: Kafka สามารถทำสิ่งต่าง ๆ เหล่านี้ได้อย่างน้อยวันนี้สำหรับการจัดเก็บแบบดิบ จากนั้นคุณสามารถติดเข้ากับ MapReduce หรืองาน Spark ขนาดใหญ่หรือคลังสินค้าขนาดใหญ่เช่น Vertica เป็นต้นหากคุณต้องการสืบค้น / รวมเข้าด้วยกัน

— elliot42

4

ขึ้นอยู่กับว่าฉันจะให้คำแนะนำเพื่อเสนอมุมมองใหม่ให้คุณ

จะเก็บอะไรดี? การจัดเก็บทุกเหตุการณ์เทียบกับการจัดเก็บมวลรวมเท่านั้น

(สไตล์บันทึกเหตุการณ์) บันทึกทุกเหตุการณ์และนับในภายหลังกับ

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

(สไตล์อนุกรมเวลา) จัดเก็บ "การนับเหตุการณ์อีสำหรับวันที่ D" ที่รวบรวมไว้ทุกวัน

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

จะเก็บข้อมูลที่ไหน

ในฐานข้อมูลเชิงสัมพันธ์ (โดยเฉพาะ MySQL)

ตัวเลือกแรกอาจเป็นเรื่องยากสำหรับ DB ถ้าคุณไปบันทึกเหตุการณ์ทั้งหมดดังนั้น MySQL ฉันกลัวว่ามันจะเล็กเกินไปและถ้าคุณต้องการใช้โซลูชั่น RDBMS คุณอาจคิดว่าตัวใหญ่กว่าเช่น PostgreSQL หรือกรรมสิทธิ์เช่น Oracle หรือ DB2 .

แต่สำหรับการรวมจะเป็นทางเลือกที่ดีขึ้นอยู่กับการโหลดที่สร้างขึ้นคุณสามารถรวมในโค้ดและแทรกการรวมเหล่านั้นใน DB

ในฐานข้อมูลที่ไม่ใช่เชิงสัมพันธ์ (NoSQL)

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

ในไฟล์บันทึกการทำงานแบบแบน (รวบรวมจากส่วนกลางผ่านเครือข่ายผ่าน syslog-ng)

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

หวังว่ามันจะช่วย!

1

ไฟล์บันทึกควรหมุนตามขนาดหรือความยาว ฉันไม่คิดว่าข้อกังวลสุดท้ายจะเป็นปัญหาแล้ว

— hiwaylon

1

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

เห็นด้วยกับ @ Thorbjørn Ravn Andersen เกี่ยวกับการย้าย "คำตอบความคิดเห็น" ของคุณไปยังคำถาม

— hiwaylon
แหล่งที่มา

1

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

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

— TMN
แหล่งที่มา

"รวบรวมข้อมูล แต่เก็บรายละเอียดไว้ในไฟล์ (บีบอัด)" โดยเฉพาะอย่างยิ่งความคิดที่ดีขอบคุณ!

— elliot42

มีความกังวลเกี่ยวกับปริมาณการบันทึก OP ที่กล่าวถึงและทำการกรอง + การรวมเมื่อเข้ามาหรือไม่ ดูเหมือนว่ามันอาจเป็นคอขวดอันตรายหากปริมาณการบันทึกสูงและ / หรือการรวมกันนั้นไม่สำคัญ

— hiwaylon

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

— TMN

1

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

ฉันขอแนะนำให้คุณดูแอปพลิเคชั่นบางอย่างที่คล้ายกับสิ่งที่คุณพยายามพัฒนา บางคนอาจมีประสิทธิภาพมากกว่าที่คุณทำเป็นเพื่อพัฒนา แต่จะไม่เจ็บถ้าคุณดูที่สถาปัตยกรรมและนโยบายการจัดเก็บตาม คุณมีแอปพลิเคชั่น SIEM เช่น RSA และ Arcsight และในด้านโอเพนซอร์ซคุณมีความคิดริเริ่มเช่น Kiwi หรือ OSSIM (ที่มีเวอร์ชันมืออาชีพของอุปกรณ์)

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

— Picarus
แหล่งที่มา