30 ข้อควรปฏิบัติในการทำ Logging

30 best practices for logging at scale
โดยคุณ JASON SKOWRONSKI จาก loggly

30 best practices for logging at scale

ผมมีความเชื่อว่าเหล่านักพัฒนาซอฟแวร์ทุกท่านคงทำการ Write log กันทุกคนนะครับ ถ้าใครที่ยังพัฒนาซอฟแวร์แล้วไม่มี Logs รบกวนให้ไปทำมาก่อน แล้วค่อยมาอ่านก็ยังไม่สาย ฮ่า ๆ ผมล้อเล่น… ถ้ายังไม่เคยเขียน Logs ก็แนะนำให้อ่าน แล้วนำไปประยุกต์ใช้ได้เลยครับ

Logging นั้นก็ถือเป็น 1 ใน 3 Pillars of Observability ในการ Monitoring ระบบของเรา ถ้าหากอยากดูเพิ่มเติมเกี่ยวกับ 3 Pillars of Observability สามารถดูได้จาก Link ได้เลยครับ

มารู้จัก 3 Pillars of Observability กัน

มาเกริ่นกันนิดนึง ปัจจุบันในการ Logging ของเรา เราทำงานกับมันกันอย่างไรครับ?
เริ่มต้นจาก Service เดียว รัน 1 เครื่อง ดังนั้น Logging ของเราก็ไม่มีปัญหาอะไร แต่ว่า… ชีวิตจริงตอนเรา Dev กับตอนขึ้นไปบน Production เจ้า 1 Service ของเรา มันดันไปอยู่บนหลาย ๆ เครื่อง Server ยกตัวอย่างเช่น 1 Service รันอยู่บน Server 4 ตัว แปลว่า Log จะออกทั้งหมด 4 เครื่องเลย เวลามีปัญหาก็ต้องเข้าไปดูตั้ง 4 เครื่องแหนะ เขาจึงมีคนคิดการทำ “centralized” ขึ้นมา เอาไว้ให้เรา Investigate ปัญหา อะจบไปอีก 1 เปราะ ทีนี้มาต่อกันอีกนิด พอเราเริ่มเก็บข้อมูลเข้าที่เข้าทาง ก็จะมีปัญหาตามมาก็คือ ข้อมูลปริมาณมหาศาล ทำให้ค้นหายาก ก็อาจจะมีการนำ Tools เข้ามาเพื่อช่วยในการค้นหา… ก็ดูเหมือนจะไปได้สวย แต่ว่าเมื่อ Service ของเรามันโตขึ้นเรื่อย ๆ เราก็จะค้นพบสัจธรรมทั้งเรื่อง Scalability, Reliable Delivery, Security, Performance, ease of use และเรื่องอื่น ๆ อีกมากมาย….

วันนี้ผมจะพาทุกท่านไปดูว่าคุณ​ JASON SKOWRONSKI จาก loggly เขามีวิธีการจัดการกับ Logging at scale อย่างไรจากประสบการณ์ของเขา

เขาสร้าง 30 best practices ขึ้นมา โดยเขาแบ่งออกเป็น 3 หมวดหลัก ๆ นั่นคือ Best practices for creating logs, Best practices for transmitting logs และ Best practices for managing logs

Best practices for creating logs

1. ใช้พวก Standard logging framework
   เช่น log4j, log4net หรือ อื่น ๆ เพื่อความไวในการปรับเปลี่ยน Config ที่ดีมากกว่าการ hard code
2. เลือกใช้ Logging framework ที่ให้ผลลัพท์ที่ยืดหยุ่น
   View console logs in development and centralize prod logs without extra plugins or agents.
3. เลือกใช้รูปแบบโครงสร้างมาตรฐาน เช่น JSON
   กำหนดรูปแบบของ logs เพื่อเอาไว้ทำการแยก และวิเคราะห์ข้อมูล
4. สร้าง Standard schema ในแต่ละฟิลด์
   ระบุฟิลด์เฉพาะเจาะจง มันจะช่วยให้ทุกคนรู้ว่าควรดูที่ไหน
5. อย่าให้ Logs มา Block application ของเรา
   เขียน Logs เป็น Asynchronously ด้วย Buffer หรือ Queue เพื่อให้ Application ของคุณทำงานต่อไปได้โดยไม่ Block
6. หลีกเลี่ยง vendor lock-in. ให้ใช้ Standard library หรือ Wrapper ที่มีความเบา
7. ระวังข้อจำกัดในการใช้งาน Platform as a Service (PaaS) หรือ พวก Container based environmentsใน Environments เช่น Heroku และ Docker เซ็ทข้อจำกัด host access, syslog daemons และ อื่น ๆ
8. กำหนด Standard logging config ให้กับทุกทีม เพื่อหลีกเลี่ยงความสับสนวุ่นวายในการเก็บข้อมูล logs เราควรเริ่มด้วยการมีแนวทางปฏิบัติให้ไปในทิศทางเดียวกัน และให้แต่ละทีมปรับเปลี่ยนตามความเหมาะสม
9. อย่าลืม Legacy application logs ให้หาทางส่ง Logs จากพวก Legacy application ซึ่งเป็นสาเหตุของปัญหาการทำงานบ่อย

Best practices for transmitting logs

1. ใช้ Fault-tolerant protocols
   ใช้ TCP หรือ RELP เพื่อส่งบันทึกแทนที่จะเป็น UDP ซึ่งอาจจะมาไม่ถึง หรือ ศูนย์หายได้
2. Retry อัตโนมัตถ้ามีการส่งผิดพลาด
3. Configure local storage สำหรับป้องกันเวลาระบบ Network ขัดข้อง
4. อย่าเก็บข้อมูลใน local storage จนมันใช้ Memory หรือ Disk เต็ม ถ้าคุณไม่ Configure limit หรือ Rotation เอาไว้บางครั้ง Logs อาจจะทำให้ Server คุณ Crash ได้ (อันนี้ผมเจอบ่อยสมัยก่อน)
5. Monitor backlogs และ outages ตัว Backlogs สามารถระบุปัญหาต่าง ๆ ของ Server หรือ Network ที่นำไปสู่การเสียหายของข้อมูลได้
6. Prevent bursting your logs when sending files.
   อย่าลืม Rotate logs ก่อนที่จะทำการ Configuring new servers
7. Filter sensitive data ก่อนส่ง logs อย่าลืม Filter sensitive data ก่อนที่จะส่ง logs เช่น รหัสบัตรประชาชน, วัน เดือน ปี เกิดของลูกค้าอะไรอย่างนี้
8. Encrypt data in transit. ใช้ HTTPS หรือติดตั้ง TLS certificates เพื่อที่จะทำให้ข้อมูลของเรามีความปลอดภัยมากขึ้น
9. Configure proxy and firewall อย่าลืมตรวจสอบ Firewall ports สำหรับ Syslog
10. Use your configuration management system to set up logging.
    ใช้ Automate large deployments ของ logging configuration เช่น Ansible, Puppet, หรืออื่น ๆ

Best practices for managing logs

1. ตรวจสอบข้อกำหนดด้านความปลอดภัยจากหน่วยงาน IT security ของคุณก่อน เนื่องจากหน่วยงาน IT secutiry มัก หรือ อาจจะมีข้อคิดเห็นต่าง ๆ หรือมีข้อกำหนดต่าง ๆ ให้เราต้องปฏิบัติตามก่อนจะเขียน logs
2. เก็บ logs ให้อยู่นอก Data center ของคุณ เนื่องจากคุณจำเป็นที่จะต้องมี logs เอาไว้ดู ในระหว่างที่ไฟดับ หรือไฟไหม้ ดังนั้นจึงควรเก็บ logs เอาไว้ใน Zone ที่พร้อมใช้งาน
3. เปรียบเทียบการเลือกใช้ Self-hosting, Cloud-hosting หรือ SaaS ให้พิจารณาการจัดเก็บข้อมูล, การประมวณผล, ค่าแบนด์วิดธ์, ค่าการดำเนินการ เนื่องจากสิ่งเหล่านี้มี “ต้นทุน”
4. รับข้อมูลจากผู้ใช้งานระบบก่อนที่จะตัดสินใจ ให้ผู้ใช้ปลายทางลองใช้ตัวเลือกแทนการตัดสินใจจาก top-down purchase
5. โปรดจำไว้ว่า User experience เป็นสิ่งสำคัญมาก หากผู้ใช้พบว่าเครื่องมือที่ใช้งานนั้น ใช้งานยากพวกเขาก็จะหลีกเลี่ยงการใช้งาน
6. Low latency เป็นสิ่งสำคัญอย่างมากในการ Monitoring และแก้ไขปัญหาแบบสด ๆ อย่าลืมทดสอบเวลาในการใช้งานว่าใช้เวลามากเกินไปหรือไม่
7. การทดสอบ Performance การค้นหา ให้ทำให้เต็มความซับซ้อนของงาน การทดสอบขนาดเล็กนั้นไม่มีความหมาย ดังนั้นให้ส่งปริมาณที่เหมือนจริง และทดสอบข้อความค้นหาที่แท้จริง หรือใกล้เคียงที่สุด
8. ไม่ว่าคุณจะใช้ Self-hosting หรือ Cloud-hosting ไม่มีใครต้องการ Performace ที่ต่ำ อย่าลืมทำ Shard หรือ Index เพื่อ Performance ด้วย
9. Automatically parse your logs at ingestion.
   Parsing logs at search time is slower, and automatic rules save time over custom ones.
10. Onboard users and integrate into workflow. Availability != Effective use
    แค่การที่ทำให้ Log ใช้งานได้นั้น “ไม่เท่ากับ” การใช้งานได้อย่างมีประสิทธิภาพ ผู้ใช้จำเป็นต้องเข้าใจ และปรับเปลี่ยน Log ให้เข้ากับการทำงาน หรือเนื้องานของตนเอง
11. Set up common
    ทำให้ Logs search ง่าย เพิ่ม Dashboards ทำ Alerts logs ให้กับทีม จะทำให้ Logs ของทีมดูมีคุณค่า น่าใช้ คนภายในทีมซื้อ และสามารถต่อยอดได้

Summary

สรุป บวกกับประสบการณ์ของผม
- อย่า Write Log มากจนเกินความจำเป็น Write ที่มันต้องใช้จริง ๆ ดีกว่า
- อย่าให้ Log มาเป็นตัว Dependency กับ Service เรา เช่น Service down เพราะ Centralized Log ที่เรา Write นั้นมีปัญหา จริง ๆ ถ้าใช้พวก Library ปัจจุบัน เค้าก็มักจะทำเป็น Asynchronously กันอยู่แล้ว ถ้าทำเองก็อย่าลืมใส่ใจจุดนี้ด้วย
- การ Write Logs ที่ดีนั้นก็ควรจะเป็นห่วงเรื่องความ Sensitive ของข้อมูลที่จะ Write ลงไปด้วย ไม่ใช่ว่า กังวลเรื่อง Security แทบตาย สุดท้ายโดนเจาะเพราะ Logs หลุด
- Logs ที่ Write ควรจะค้นหาได้ง่าย มี Pattern มีการตกลงกันภายใน หลายครั้งตามหา Logs กันวุ่นวายในหลาย ๆ ทีม เนื่องจากไม่ตกลงกันให้ดี ว่าจะเขียน Pattern กันอย่างไร เพราะในชีวิตจริงของเรานั้น มันไม่ใช่เรา ที่เป็นคนแรกที่มาดู Logs อาจจะเป็นทีม Noc, Support, TechOps หรือ SRE มาดูก่อนเพื่อทำการ Solve problem เบื่องต้น
- การ Write Logs ควรมีการทำ Shard หรือ Index ให้พร้อมสรรพ เพื่อให้ว่องไวในการค้นหา

ทิ้งท้าย เก็บ Logs แล้วก็ควรมี Process มา Analyze log บ้าง เพราะหลายครั้งมีสิ่งผิดปกติที่ User มองไม่เห็น เช่น Get profile เบิ้ลเนื่องจากเขียนโค้ดผิดพลาด หรือมี Error ที่เราไม่เคยเห็นเกิดขึ้นมา ก็จะได้วิเคราะห์แก้ไข “ไม่ใช่ User ทุกคนที่จะแจ้ง Bug เรา เขามีทางเลือกที่จะเลิกใช้ระบบเราได้เช่นกัน” ดังนั้นวิเคราะห์ Log กันด้วยนะครับ

นอกจากนี้ท่านผู้อ่านยังสามารถอ่านบทความเกี่ยวกับ Log Level ได้จาก Link
สุดท้ายนี้ก็ต้องขอขอบคุณ คุณ JASON SKOWRONSKI จาก loggly ที่เขียนบทความดี ๆ มาให้เราไดอ่านกัน

ถ้าหากผมเข้าใจสิ่งที่อ่าน แล้วแปลผิดพลาดประการใดก็ขออภัยมา ณ ที่นี้ด้วยครับ

References

30 best practices for logging at scale | Log Analysis | Log Monitoring by Loggly

มารู้จัก 3 Pillars of Observability กัน

Log Level สำคัญไฉน