Let’s Talk Observability : ฉบับคนไม่รู้ มารู้

ความสำคัญของ Observability สำหรับองค์กร

สวัสดีค่ะ ในบทความนี้ เราจะมาพูดถึงเรื่องเกี่ยวกับ Observability ฉบับเข้าใจง่าย ในส่วนของ Observability คืออะไร ทำไมองค์กรจึงควรใช้เครื่องมือ Observability และส่วนประกอบของ Observability รวมไปถึงข้อดีข้อเสีย

Photo by Whatap Laps

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

การที่เราจะพยายามทำให้ระบบเสถียร ไม่มีข้อผิดพลาดเลย เป็นสิ่งที่ดูเป็นไปได้ยากและถึงแม้จะเป็นไปได้ก็อาจมีค่าใช้จ่ายที่ค่อนข้างสูง

แต่ ถ้าเป็นการที่เราทำให้สามารถเห็นการทำงานของระบบได้ตลอดเวลา ที่นี่เราก็สามารถบริหารจัดการระบบของเราได้ อันนี้ดูเป็นไปได้มากกว่า

จึงเกิดแนวทางที่เรียกว่า “Observability” ซึ่งไม่ใช่คำที่ใหม่แต่มีรากฐานมาจาก “Control theory” โดยใช้คุณสมบัตินี้เพื่อดูค่าภายในระบบโดยการสำรวจผลลัพธ์ภายนอกระบบ

นิยาม “Observability” คือ ความสามารถในการเข้าใจสถานะภายในของระบบด้วยการวิเคราะห์ข้อมูลที่ระบบได้สร้างขึ้นมา ความสามารถของ Observability จะช่วยให้ทีมวิเคราะห์ได้ว่า เกิดอะไรขึ้นในสภาพแวดล้อมแบบ multi-cloud ซึ่งหากเราสามารถรู้ถึงสถานะของระบบได้ตลอดเวลา เราสามารถตรวจจับป้องกันปัญหา ก่อนที่ปัญหาจะเกิดขึ้น หรือในกรณีที่ปัญหาเกิดขึ้นแล้ว เราก็สามารถหาแนวทางในการแก้ปัญหาได้อย่างรวดเร็ว และมีประสิทธิภาพ

ทำไมองค์กรจึงควรใช้เครื่องมือ Observability?

ลองคิดง่ายๆ ว่าถ้าหากเรามีระบบที่ใหญ่ ตัวแอปพลิเคชันของเรามีหลาย server ทำให้มีการใช้ service มากขึ้น ในการใช้งานแต่ละครั้ง request ที่เข้ามายังแอปพลิเคชันอาจวิ่งผ่าน component หรือ service หลายตัว ซึ่งเราไม่รู้เลยว่าตัวไหนเข้าตัวไหนบ้าง หรือมีจุดเชื่อมกันตรงไหน และหากเกิด error ขึ้นมาที่ระบบใด ระบบหนึ่ง มันยากต่อการตรวจสอบต้นต่อของปัญหา

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

ถ้าระบบของเราไม่มี Observability ที่ดีก็จะทำให้การ maintain ระบบของเรา ไม่ว่าจะเป็น การ investigate defect, incident หรือการเก็บข้อมูลการทำงานของระบบเพื่อทำการ improvement ต่างๆ ทำได้ยากมาก

โดย Observability ประกอบด้วย 3 เสาหลัก ดังนี้

The three pillers of observability photo by TechTarget

• Logs — log ต่างๆ จากแอปพลิเคชันเพื่อใช้ในการ investigate หรือ Debug ระบบ
• Metrics — เป็นข้อมูลเชิงตัวเลข ตัวเลขต่างๆ ที่มีผลต่อแอปพลิเคชันเป็นข้อมูลในลักษณะของ Aggregated Data (ข้อมูลรวม) เช่น request average, response time และนำข้อมูลที่ได้มาวิเคราะห์เพื่อใช้ตอบคำถามเชิงระบบ / Business
• Traces — เป็นข้อมูลในระดับ request ว่าในแต่ละ request นั้น มีการเรียกไปถึงระบบไหนบ้าง และแต่ละระบบมี behaviors อย่างไร เช่น response time ของแต่ละระบบหรือ error massage ที่เกิดจากแต่ละระบบ เป็นต้น

โดยทั้ง 3 ส่วนนี้ จะขาดตัวใดตัวหนึ่งไปไม่ได้ เพราะแต่ละส่วนก็มีจุดประสงค์ของมัน มีจุดเด่นแต่ละด้านต่างกัน ถัดมาเราจะลง detail ในแต่ละส่วนกัน

Log

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

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

Example log photo by kubesimplify

ข้อดี

• สามารถ log ดูแอปพลิเคชันของเราว่ามี error เพราะอะไร และให้ print stack trace ของปัญหาได้ โดย stack trace เป็นการบันทึกเส้นทางการเรียก method จากอันล่าสุดย้อนกลับมาอันแรก ทำให้เราสามารถทราบลำดับการทำงาน ณ จุดเกิดเหตุได้

ข้อเสีย

• ใช้ disk มากในการเก็บข้อมูลย้อนหลังนานๆ
• การไล่หาปัญหาต้องใช้คน และใช้เวลาในการ query/search/investigate โดยมักต้องเปรียบเทียบไปถึง code ถึงจะสามารถเข้าใจได้

Metrics

เป็นการเก็บรวบรวมจากส่วนประกอบต่าง ๆ โดยเป็นชุดข้อมูลแบบ time series โดยดูจากตัวอ้างอิงหลายๆ แกน หรือหลายๆ matrics เช่น จำนวน request, average response time หรือค่าอื่นๆ ตามที่เราอยากเห็น ซึ่งเราสามารถใช้ Math operation ในการช่วยวิเคราะห์ข้อมูลเหล่านั้น เช่น sum, average, mean เป็นต้น โดยนำข้อมูลเหล่านี้มาเพื่อใช้ในการตรวจสอบประสิทธิภาพของระบบ เช่น การใช้ CPU, การใช้หน่วยความจำ และข้อมูลที่เกี่ยวข้องกับประสิทธิภาพอื่น ๆ

เนื่องจากข้อมูล matrics เป็นข้อมูลตัวเลขที่เก็บมาตามช่วงเวลาเป็นแบบ time series จุดเด่นของ matrics จะเป็นการที่ทำให้เราสามารถเห็นภาพรวมของระบบของเราได้ง่ายและรวดเร็วมากขึ้น โดยที่ยังไม่ได้ใช้งาน disk มากเท่า ตัว log เพราะเก็บข้อมูลเป็นชุด time series เช่น average response time ของ API ในช่วง 1 ชั่วโมงที่ผ่านมา หรือ จำนวนลูกค้าเปิดบัญชีแต่ละประเภท แยกเป็นแต่ละสาขาใน 1 วัน เป็นต้น

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

การใช้ matric สามารถ visibility ข้อมูลได้หลากหลาย ตั้งแต่ระดับ server, ตัวเครื่อง, ระดับ middleware, ระดับแอปพลิเคชัน เช่น แอปพลิเคชันเกิด out of memery quit ทำให้เรารู้ว่าตอนที่โดน quit ใช้ memory ไปกี่ GB ต้องเพิ่มอีกเท่าไหร่ จึงจะเหมาะสมกับการใช้งาน เป็นต้น

เครื่องมือที่ใช้ในการทำ matrics เช่น Prometheus, Dynatrace ซึ่งช่วยในการเรียกดูข้อมูลเมตริกซ์ ง่ายขึ้นผ่านการแสดงผลในรูปแบบแดชบอร์ด (dashboards) บน Grafana

Tool for matric photo by kubesimplify

ข้อดี

• matrics เป็นหนึ่งในปัจจัยที่ทำให้เห็นภาพรวมของระบบหรือแอปพลิเคชันมากขึ้น เช่น รู้ว่ามีการใช้งาน memory ไปสัดส่วนเท่าไหร่ ยังเหลืออีกเท่าไหร่ นำข้อมูลเหล่านั้นไปใช้สำหรับการประเมินระบบของเรา เพื่อที่เราสามารถไปปรับค่าให้เหมาะสมในการใช้งาน
• สามารถประมวลผล time series data ด้วย math operation ได้ระดับหนึ่ง
• ประหยัดพื้นที่ในการเก็บข้อมูลมากกว่า การเก็บ log และกระทบกับ performance น้อยกว่า

ข้อจำกัด

• เป็นเรื่องของความถี่ในเรื่องของการเก็บข้อมูล matric ซึ่งถ้าเราเก็บข้อมูลไม่ละเอียดพอ เราอาจพลาดสิ่งที่เกิดขึ้น ณ เวลานั้น แต่ถ้าเราเก็บข้อมูลถี่เกินไปก็อาจทำให้เกิด workload ได้ เช่น หากเราเก็บข้อมูล matric ทุกๆ 10 นาที แต่แอปพลิเคชันของเราทำงานมีช่วงเวลา ที่ CPU พีค ขึ้นมาสั้นๆ เพียง 2 นาที ก็อาจทำให้เรามีโอกาสพลาดข้อมูล ในช่วง 2 นาทีนั้น

จะเห็นว่าหากเราใช้ Logging และ Metrics คู่กันจะช่วยให้เราสามารถเห็นการทำงานของระบบหนึ่งๆ ได้อย่างครบถ้วนและหาปัญหาได้ดีขึ้น

แต่!! …

มันก็ยังไม่ทำให้เราเห็น การทำงานของระบบของเรา ตลอดอายุของ Request หนึ่งๆ ที่เกี่ยวข้องกับหลายระบบ ซึ่ง Tracing จะช่วยแก้ปัญหาในจุดนี้

Tracing

คำจำกัดความ “tracing” คือ “การติดตาม” เป็นการเก็บรวบรวมและวิเคราะห์ข้อมูลเกี่ยวกับ request ที่ผ่านในระบบของเราบ้าง เพื่อการติดตามและวินิจฉัยปัญหาที่เกี่ยวกับประสิทธิภาพและพฤติกรรมของแอปพลิเคชัน

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

ซึ่งการติดตามใน Kubernetes ช่วยให้เราสามารถหาคำตอบเกี่ยวกับสิ่งที่เกิดขึ้นโดยการตามเส้นทางของคำขอหรือเหตุการณ์ต่าง ๆ ที่เกิดขึ้นในระบบของเรา

Illustration of tracing operation photo by kubesimplify

ซึ่งข้อมูล tracing ช่วยให้เราเห็น path ใน แต่ละ request ว่าผ่าน component หรือ service ไหนบ้าง รวมถึงเห็น structure การเชื่อมต่อของแต่ละ component อีกทั้งยังสามารถจับเวลาในจุดเชื่อมต่อต่างๆ ที่เป็นความสามารถที่อยู่นอกเหนือจากที่แอปพลิเคชันเราทำได้

ข้อดี

• สามารถแสดงข้อมูลย้อนหลังการ call service ในรูปแบบ flow
• ทำให้เราสามารถหาต้นเหตุของปัญหาได้เจอ
• ทำให้รู้ perfomance ของแต่ละ component ว่าตรงไหนมีปัญหาหรือ error บ่อยๆ ที่เราต้องแก้ไข
• สามารถค้นหาข้อมูล เช่น response, error แล้วนำ time stamp มา link ในการค้นหา log, matrics

Conclusion

การทำ Observability ต้องประกอบด้วย 3 ส่วน ซึ่งแต่ละส่วน จะมีจุดเด่นในแต่ละด้าน

• log — ดูข้อมูลที่ทำให้เกิดปัญหา
• matric — ดูข้อมูลภาพรวม นำข้อมูลมาวิเคราะห์ ประกอบว่าเกิดอะไรขึ้น คาดการเหตุการณ์ที่อาจเกิดขึ้น
• tracing — แสดงจุดเชื่อมต่อของแต่ละ service หาต้นเหตุของปัญหา

หากเกิดปัญหา :

ขั้นแรก เราจะมาดูที่ tracing เพื่อดูต้นเหตุของปัญหา ทำให้เราเห็น root cause ของปัญหา ได้ time stamp (เวลาที่เกิดปัญหา) นำไป link ในการค้นหา log, matric

— หากนำ time stamp มา link เพื่อใช้ในการค้นหา log ทำให้ทราบ data ที่ทำให้เกิดปัญหา และ error ว่าพังอะไร

— หากนำ time stamp มา link เพื่อใช้ในการค้นหา matric ทำให้เห็น matric ที่แสดง error บน dashboard เพื่อนำข้อมูลมาประกอบว่าเกิดอะไรขึ้น

การทำ Observability หากเกิดปัญหา จะช่วยให้เราสามารถหาต้นเหตุของปัญหา และแก้ไขได้เร็ว นอกจากนี้ยังช่วยให้เราสามารถเห็น error, usecase, stage ที่เกิดขึ้นในระบบของเรา ซึ่งเราสามารถนำข้อมูลเหล่านั้นมาใช้ในการต่อยอด เขียน condition ให้ทำบางอย่างได้ เช่น ให้ส่งแจ้งเตือนไปยัง ms team, outlook, line, otcในกรณีแอปพลิเคชันมีปัญหา เป็นต้น

ส่งท้าย

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

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

References

Observability patterns for enterprise software systems