การบันทึกการปฏิบัติที่ดีสำหรับงานแบบกระจายคืออะไร

ฉันมีการตั้งค่าต่อไปนี้:

สร้างพนักงานหลายคนทำการคำนวณและยุติพวกเขาหลังจากการคำนวณเสร็จสิ้น

ดังนั้นทุกครั้งที่มันเป็นอินสแตนซ์ที่แตกต่างกันในการทำงานดังนั้นแต่ละโฮสต์จะมีล็อกไฟล์ของตัวเองซึ่งจะส่งผลให้มีรายการไฟล์จำนวนมาก

เป็นการปฏิบัติที่ดีหรือไม่? หากไม่เป็นเช่นนั้นจะมีวิธีใดที่ดีกว่าสำหรับการบันทึกการประมวลผลงานในกรณีใช้งานนี้โดยเฉพาะ

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

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

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

ล่าสุด แต่ที่นิยมมากคือการเข้าสู่ ElasticSearch สิ่งนี้มีประโยชน์ส่วนใหญ่เป็นเพราะแผงควบคุม Kibana และ Logstash tooklit (มักเรียกว่า ELK, ElasticSearch + Logstash + Kibana) Amazon ยังเสนอตัวเลือก ElasticSearch ที่โฮสต์ทำให้การเริ่มต้นใช้งานค่อนข้างง่ายขึ้น ES ใช้ REST API ค่อนข้างง่ายดังนั้นภาษาใดก็ตามที่มีไคลเอ็นต์ HTTP (อ่าน: ทุกคน) ควรใช้ได้กับการเข้าสู่ระบบ ES แต่ให้แน่ใจว่าคุณระมัดระวังในการปิดกั้นการทำงานของเครือข่ายในกรณีที่ระบบขัดข้องบางส่วน แอปจะไม่ติดขัดในการบันทึกการโทรที่จะไม่ประสบความสำเร็จและหยุดให้บริการคำขอของผู้ใช้)

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

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

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

ใช่การใช้ไฟล์บันทึกหลายไฟล์พร้อมกันเป็นวิธีปฏิบัติที่ดี

ความพยายามที่จะรวมกันเป็นล็อกไฟล์บันทึกเดียวจากคนงานหลายคนในเวลาจริงจะทำให้เกิดปัญหา:

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

Sharding logfiles (ใช้หลาย logfiles ที่ใช้งานในเวลาเดียวกัน) เป็นเทคนิคที่ใช้โดยผู้ให้บริการโฮสติ้งบางรายที่นำเสนอบริการการบันทึกรวมศูนย์ที่มีประสิทธิภาพสูงและปรับขนาดได้ ตัวอย่างเช่นเมื่อส่งออกบันทึกไปยังไฟล์การบันทึก StackDriverของ Google จะสร้างไฟล์บันทึกหลายรายการ จากรายการบันทึกใน Google Cloud Storage :

เมื่อคุณส่งออกบันทึกไปที่ฝากข้อมูล Cloud Storage, Stackdriver Logging จะเขียนชุดไฟล์ไปยังที่ฝากข้อมูล ไฟล์ถูกจัดระเบียบในลำดับชั้นไดเรกทอรีตามประเภทของบันทึกและวันที่ ประเภทบันทึกจะเป็นชื่อที่เรียบง่ายเหมือนหรือชื่อสารประกอบเช่นsyslog appengine.googleapis.com/request_logหากบันทึกเหล่านี้ถูกเก็บไว้ในที่ฝากข้อมูลชื่อmy-gcs-bucketไดเรกทอรีจะถูกตั้งชื่อตามตัวอย่างต่อไปนี้:

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

ที่ฝากข้อมูลเดียวสามารถมีบันทึกจากหลายประเภทบันทึก

ไดเร็กทอรี leaf ( DD/) มีหลายไฟล์แต่ละไฟล์เก็บรายการบันทึกที่เอ็กซ์พอร์ตสำหรับช่วงเวลาที่ระบุในชื่อไฟล์ ไฟล์จะถูกแบ่งส่วนและชื่อจะลงท้ายด้วยหมายเลขชาร์ด SnหรือAn(n = 0, 1, 2, ... ) ตัวอย่างเช่นต่อไปนี้เป็นไฟล์สองไฟล์ที่อาจเก็บไว้ภายในdirectory my-gcs-bucket/syslog/2015/01/13/:

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

สองไฟล์เหล่านี้รวมกันมีsyslogรายการบันทึกสำหรับอินสแตนซ์ทั้งหมดในระหว่างชั่วโมงเริ่มต้น 0800 UTC ในการรับรายการบันทึกทั้งหมดคุณต้องอ่านเศษทั้งหมดสำหรับแต่ละช่วงเวลาในกรณีนี้ส่วนไฟล์ 0 และ 1 จำนวนไฟล์ที่เขียนสามารถเปลี่ยนได้ทุกช่วงเวลาขึ้นอยู่กับปริมาณรายการบันทึก

บริการบันทึกประสิทธิภาพสูงเช่นนี้ยังสามารถเสนอทางเลือกอื่นในการบันทึกไฟล์การจัดการไฟล์บันทึกจึงสามารถหลีกเลี่ยงได้โดยสิ้นเชิงหากเป็นประโยชน์:

• การแทรกบันทึกลงในฐานข้อมูลโดยตรง ตัวอย่างเช่นการบันทึก Stackdriver สามารถผลักบันทึกลงใน Google BigQuery โดยตรง
• ผลักดันบันทึกโดยตรงในเครื่องมือประมวลผล ตัวอย่างเช่นการบันทึก Stackdriver สามารถผลักบันทึกลงในหัวข้อ Google Pub / ย่อย

สุดท้าย - หากการรวมล็อกไฟล์แบบเรียลไทม์ไม่ใช่ข้อกำหนดที่มีไฟล์บันทึกหลายไฟล์สามารถช่วยในการจัดการบันทึกออฟไลน์:

• ง่ายต่อการคิดค้นการสำรองข้อมูลบันทึกแบบก้าวหน้าการบีบอัดการเก็บถาวรและแผนการกำจัดในที่สุด
• การประมวลผลแบบขนานของบันทึกหลายชุด (logfiles) เป็นไปได้ลด / หลีกเลี่ยงผลกระทบของคอขวด
• ไม่มีการแยกไฟล์และจำเป็นต้องเขียนซ้ำ