มารู้จัก 3 Pillars of Observability กัน
Observability ถือเป็นสิ่งที่ขาดไม่ได้เลย ในการออกแบบระบบที่ดี เพื่อที่จะให้มันสามารถ monitor ระบบของเราบน production ว่าทำงานได้ตามสิ่งที่มันควรจะเป็น ได้ทุกประการอยู่หรือไม่
ทุกครั้ง เมื่อระบบของเรามีอะไรที่ผิดปกติคุณจะต้องเข้าไปหาสาเหตุของปัญหานั้น ว่าเกิดอะไรขึ้นกับระบบ แน่นอนว่า การตรวจสอบสาเหตุของปัญหานั้นบน production โดยมากมักจะทำการตรวจสอบแบบ Whitebox ซึ่งเมื่อเรามีการทำ monitoring ก็ยิ่งทำให้เราล่วงรู้อนาคตล่วงหน้าเกี่ยวกับปัญหาที่อาจจะเกิดขึ้นใน Application ของเราได้ ทำให้เราสามารถป้องกัน หรือแก้ไขได้ก่อนที่หายนะจะมา… Logging, Metrics และ Distributed tracing หรือเรียกอีกทางหนึ่งว่า Whitebox monitoring นั่นเอง
จาก SRE (Site Reliability Engineering)
ถ้าเราไม่ทำ Monitoring ก็เท่ากับว่าเรานั้นได้เหมือนคนตาบอด เราไม่สามารถบอกได้ว่า Service นั้นทำงานได้เป็นปกติ หรือไม่ และ ใน SRE ก็ได้บอกว่าการ Monitoring ถือเป็นรากฐานที่สำคัญที่สุด refer จาก Service Reliability Hierarchy ซึ่งจากข้อมูลนี้ทำให้เราสามารถนำข้อมูลกลับไป improve service ให้ดียิ่งขึ้นได้
3 Pillars of Observability
วันนี้ผมจะมาเขียนเกี่ยวกับ 3 Pillars of Observability ใน scope whitebox monitoring อะไรคือความแตกต่าง ระหว่าง Logging, Metrics และ Distributed tracing
Logging
Logging น่าจะเป็นอะไรที่ผู้อ่านทุกท่านคุ้นเคยกันมากที่สุดแล้วครับ การที่เราทำการเก็บ Log event ต่าง ๆ ที่เกิดขึ้นในระบบของเรานั้น มันเป็นสิ่งที่ถูกที่ควร แต่ก็อย่าลืมเก็บให้ดีเก็บให้ถูก คุยเรื่อง Pattern ให้ชัดเจน
ถ้าหากคุณมีปัญหาเกี่ยวกับการรับส่งข้อมูล Log จำนวนมาก บางทีคุณอาจจะต้องกลับมานั่งทบทวนบ้างว่า อะไรควรส่ง อะไรไม่ควรส่ง แนะนำให้แบ่ง Log level นอกจากนี้ก็ยังต้องมาดูเรื่องของการ scale ของ log โดยมากแนะนำให้ใช้ elasticsearch
Libraries เช่น log4j, log4net หรือ Libraries อื่น ๆ ขึ้นอยู่กับ stack ที่คุณใช้อยู่
ในตอนนี้ที่นิยมมาก ๆ ก็คือ write ลง disk แล้วส่งไปหา ELK หรืออาจจะส่งข้อมูลไปที่ kafka, rabbitMq แล้วก็เอา logstash เพื่อรับของจาก queue ใส่ลงไปใน elasticsearch แล้วก็นำมาแสดงผลด้วย Kibana
Metrics
Metrics เป็นตัวชี้วัดที่สามารถปรับ และ ตรวจสอบข้อมูลได้ตามความต้องการ เนื่องจากเป็นเพียงการทำ intervals of time as time series data
ข้อดีอย่างหนึ่งของการ Monitoring โดยใช้ metrics คือเรื่องของ storage มันค่อนข้างที่จะคงที่ ไม่ได้ขยายบึ้ม ๆ เหมือน logs นั่นหมายความว่าการใช้งาน disk storage หรือการ process ไม่เปลี่ยนแปลงตามการเพิ่มขึ้นของปริมาณการใช้งาน รวมถึง disk storage จะเพิ่มขึ้นเพียงแค่ตาม data on time series ที่เราต้องการ capture เท่านั้น
Metric นั้นมีประสิทธิภาพมากกว่าการที่เราต้องมานั่งหา log data แต่ว่า log data จะสามารถให้ข้อมูลที่แน่นอนแก่คุณได้ดีกว่า ถ้าหากคุณต้องการใช้ประโยชน์ของ average of response times จาก metrics คุณสามารถบันทึก log แล้วนำมันมา queries ใน elasticsearch ได้
ปัจจุบันมี metrics หลายตัวที่เป็นที่นิยม อาทิเช่น Promethus, influxdb, zabbix โดยที่แต่ละตัวก็จะมีความดีความเด่นที่แตกต่างกันออกไป แต่ที่ผมใช้ปัจจุบันก็คือ Promethus ก็ใช้ดีไม่มีปัญหาอะไร
เมื่อคุณรวบรวมตัว metrics ทั้งหมดของคุณใน Prometheus คุณสามารถใช้ Grafana เพื่อให้เห็นค่าเหล่านั้นเป็น Graph ได้
Metrics จากประสบการณ์
- Health check: ตรวจสอบว่าระบบยังอยู่ดี ไม่หนีไปไหน
- Number of Requests: ตรวจสอบว่ามีจำนวน Request เข้ามาเท่าไหร่ /api/tps
- Service Response Time: ตรวจสอบว่าในแต่ละ service แต่ละ api มี response time เป็นค่าเท่าไหร่
- Error Rates: ตรวจสอบ error rates ถ้าหากสูงผิดปกติ ให้มี alarm แจ้งทีมที่ดูแลต่อไป
Distributed Tracing
ในยุคที่มองไปทางไหนก็จะเห็นแต่ Microservices… 1 request จาก user บางทีอาจจะวิ่งไปถึง 2–10 service วิ่งกันไปกันมา ใน application ของคุณก็เป็นได้ มันสร้างขึ้นมาเพื่อดู event ordering latency… Logs อาจจะช่วยคุณในข้อมูลเบื้องลึกได้ว่ามันเกิดอะไรขึ้นจากเคสต้นทาง แต่กว่าที่คุณจะตามตัวเจอ ว่าเกิดจากอะไรกันแน่ ก็อาจจะต้องใช้เวลาอย่างมากในการค้นหา เนื่องจากมันมีการยิงกันไปกันมาหลายจุด… ในเมื่อมันมีปัญหา ก็ต้องมีคนแก้
Google เลยตีพิมพ์ Dapper, a Large-Scale Distributed Systems Tracing Infrastructure ขึ้นในปี 2010 ซึ่งพวกเค้าให้ชื่อมันว่า trace distributed
แล้วต่อมาในเดือน June 2012 Twitter ก็ได้สร้าง open source internal distributed tracing project หรือที่เป็นที่รู้จักกันในนาม Zipkin และ พื้นฐานก็มาจาก Google Dapper paper
ปัจจุบันก็มี libraries หลายเจ้าที่นำมาทำ distributed tracing เช่น Zipkin, Jaeger, LightStep, Instane แต่ที่นิยมสุดจะเป็น Zipkin นั่นเอง
Zipkin จะเข้ามาช่วยคุณในการจัดการกับปัญหาข้างต้นที่ผมได้กล่าวไป โดยมันมี Web UI ที่ทำให้คุณ เห็นได้เลยว่า 1 request นั้นมันวิ่งไปที่ใด ใช้เวลาในแต่ละ request ภายใน service แต่ละ service ของเรานานแค่ไหน สามารถ search เพื่อ filter ข้อมูลที่เราต้องการได้ และ ที่สำคัญมันรู้ด้วยว่า ไปจอดที่ไหน พอรู้ว่าจอดที่ไหนก็ง่ายแล้วครับ
Conclusion
อย่างที่ได้กล่าวไปในตอนแรกเลยว่า 3 Pillars of Observability มีความสำคัญอย่างมากในการที่จะช่วยเรา ในการ monitoring ระบบ โดยถ้าจะให้เขียนสรุปในแบบของผมเอง ผมจะมองว่า
- Logging: ทำให้เรารู้ข้อมูลเฉพาะเจาะจง หยั่งลึกถึงราก แต่แลกมาด้วยการใช้เวลานานในการค้นหา แก้ได้โดยการใช้ Correlation ID ปัญหาหลักของ Logging ก็คือการที่เก็บ Log บวม, Log เต็ม, Log pattern ไม่ตรง, Log ไม่ซิ้ง บลา ๆ
- Metrics: เมื่อผนวกกับ tools ในการทำ dashboard จะช่วยเราให้เราสามารถคาดการณ์ได้ล่วงหน้าว่าระบบอาจจะเกิดปัญหาได้ ด้วยการใช้ intervals of time as time series data นำมา predix สิ่งที่อาจจะเกิดขึ้น รวมถึงมองภาพรวมของ Service ต่าง ๆ ได้ อันนี้มี request มาเยอะเวลาไหน เวลาใดควร scale out-in, scale up-down สามารถวาดให้เป็น Graph ได้หลายรูปแบบตามต้องการ
- Distributed Tracing: ทำให้เราทราบถึง request ต่าง ๆ ที่ถูก request เข้ามา ช่วยเราในเรื่องของการดู latency สามารถช่วยเรา investigate ปัญหาต่าง ๆ ได้รวดเร็วกว่าได้นั่งหา log data จากลม
สรุปของสรุป: Metrics ดูภาพกว้าง predix เหตุการณ์ > Distributed Tracing หาปัญหา > Logging ทำให้เราถึงบางอ้อ
ก็หวังว่าผู้อ่านจะได้นำความรู้ตรงนี้ไปปรับใช้ต่อยอด หรือเกิด ideas ได้บ้างนะครับ
ผิดพลาดประการใด ขออภัยมา ณ ที่นี้
