Observability Pt. 1: ทำความรู้จักกับ Observability กันเถอะ
Observability คืออะไร
ผมไม่แน่ใจว่าเพื่อนๆ ที่ได้ยินคำว่า Observability ในครั้งแรกนึกถึงอะไร แต่สำหรับผมแล้ว สิ่งแรกที่ผมนึกถึงคือเจ้าตัวนี้ครับ
ใช่แล้วครับ มันคือ Observer ยูนิตล่องหนที่ใช้ “สอดแนม” ในเกม StarCraft นั่นเอง ในเกมวางแผน Real-Time Strategy ถ้าเรารู้ความเคลื่อนไหวของฝ่ายตรงข้ามว่าทำอะไรอยู่ มียูนิตอะไรบ้าง เราก็จะวางแผนและปรับเปลี่ยนแผนได้อย่างเหมาะสม
กลับเข้ามาที่โลกไอทีกัน อีกคำหนึ่งที่ผมนึกถึงก็คือ Observer Pattern เป็น Design Pattern ตัวหนึ่งที่ถูกจัดอยู่ในกลุ่ม Behavioral Pattern จากหนังสือชื่อดังของ Gang of Four ซึ่ง Design Pattern ตัวนี้เป็นการสร้าง Object ที่เรียกว่า Observer เข้าไปผูกหรือฝังเข้าไปกับ Object ที่เราต้องการมอนิเตอร์ หรือที่เรียกว่า Subject ในยามที่ Subject เกิดการเปลี่ยนแปลงใดๆ Observer ก็สามารถรับรู้ได้ในทันที
ฟังดูแล้วเพื่อน ๆ อาจจะพอนึกภาพออกว่า Observability ก็คงคล้ายๆ กับการ Monitoring นั่นแหละ ซึ่งก็ถูกต้องครับ แต่เราใช้คำว่า Observability ในการบอกคุณสมบัติของระบบว่ามีความสามารถในการรับรู้ เห็นสถานะ หรือเห็นความเป็นไปจาก Output ต่าง ๆ ของระบบหรือไม่ ถ้าเราสามารถเห็นการทำงานหรือสถานะภายในของระบบได้ตลอดเวลา เราก็จะสามารถป้องกันปัญหาได้ก่อนที่ปัญหานั้นจะเกิด หรือในกรณีที่เกิดปัญหาขึ้นมาจริงๆ แล้ว เราก็จะสามารถเห็น Root Cause และแก้ปัญหาได้อย่างตรงจุด เหมือนกับที่เราบอกว่า Scalability หรือความสามารถในการขยายเพื่อรองรับปริมาณงานที่มากขึ้นได้เป็นคุณสมบัติหนึ่งของระบบ ซึ่งการมอนิเตอร์นั้นก็เป็นหนึ่งในหลายๆ วิธีที่จะทำให้ระบบเรามี Observability ที่ดีได้
คำนี้เริ่มมีการนำมาใช้กับแอปพลิเคชันสมัยใหม่ที่เป็นสถาปัตยกรรมแบบกระจาย (Distributed) มากขึ้น มีการใช้ Microservice มากขึ้นในการใช้งานระบบ แต่ละ Request ที่เข้ามายัง แอปพลิเคชันอาจจะวิ่งผ่าน Component หรือ Microservice เยอะแยะมากมาย มีจุดเชื่อมต่อจำนวนมาก ถ้าระบบของเราไม่มี Observability ที่ดีก็จะทำให้การ Maintain ระบบของเรา ไม่ว่าจะเป็นการ Investigate Defect, Incident หรือการเก็บข้อมูลการทำงานของระบบเพื่อทำ Improvement ต่างๆ ทำได้ยากมาก
Background & De-facto Standard
ในทางทฤษฏี Observability จะประกอบไปด้วยเสา 3 ต้น หรือภาษาอังกฤษเรียกว่า Three Pillars of Observability นั่นก็คือ Logging, Metrics, และ Tracing ซึ่งถ้าแอปพลิเคชันไหนมีครบทั้ง 3 อย่างนี้ จะทำให้เราสามารถเข้าใจแอปพลิเคชันได้ครบทุกส่วนอย่างมีประสิทธิภาพ
เสา 3 ต้นของ Observability กล่าวโดยสรุปได้ดังนี้
- Logging การเขียนข้อมูล Log ในลักษณะของ Event Base ข้อมูลที่เขียนอาจอยู่ในรูปแบบของ Structure หรือ Non-Structure ก็ได้ เช่น Log File ที่แอปพลิเคชันเขียนขึ้น หรือ Log file ของ Web Server เช่น Apache, Nginx เป็นต้น วัตถุประสงค์ของ Log เช่น เพื่อใช้ในการ Investigate หรือ Debug ระบบ การทำ Logging นั้นเป็นเทคนิคที่ต้องใช้พื้นที่ในการเก็บข้อมูลเยอะที่สุด เนื่องจากต้อง Write ข้อมูลออกมาทุก Event ที่เราต้องการ
- Metrics ข้อมูลในลักษณะของ Aggregated Data อาจใช้ตอบคำถามทั้งในเชิงระบบและ Business เช่น Average Response Time ของ API ในช่วง 1 ชั่วโมงที่ผ่านมา จำนวนลูกค้าที่เปิดบัญชีแต่ละประเภทแยกตามสาขาใน 1 วัน เป็นต้น การทำ Metrics ถ้าทำอย่างถูกต้อง จะเป็นเทคนิคที่ใช้พื้นที่ในการเก็บข้อมูลอย่างมีประสิทธิภาพ เนื่องจากข้อมูลจะอยู่ในลักษณะ Time Series ที่ไม่จำเป็นต้องจับทุก Event เหมือนกับการทำ Logging ก็เพียงพอสำหรับการทำ Metrics แล้ว
- Tracing ในขณะที่ Logging และ Metrics เป็นข้อมูลของระบบใดระบบหนึ่งเท่านั้น Tracing จะเป็นข้อมูลในระดับ Request ว่าในแต่ละ Request นั้น แบบ End-to-End มีการเรียกไปถึงระบบไหนบ้าง และแต่ละระบบมี Behaviors อย่างไร เช่น Response Time ของแต่ละระบบ หรือ Error Message ที่เกิดจากแต่ละระบบ เป็นต้น
สมัยก่อนผู้สร้างเครื่องมือต่างๆ (หรือ Software Vendor) จะใช้หลักการออกแบบของใครของมัน ทำให้ลูกค้าที่ใช้เครื่องมือแต่ละอย่างไม่สามารถเปลี่ยนเครื่องมือหรือใช้หลายๆ เครื่องมือในเวลาเดียวกันได้ แต่หลังๆ มานี้ในอุตสาหกรรมซอร์ฟแวร์เราจะเห็นว่า Vendor ผู้สร้างเครื่องมือต่างๆ พยายามที่จะร่วมมือกันกำหนดมาตรฐานมากขึ้น ทำให้เวลาที่เราออกแบบระบบ เราสามารถออกแบบให้เข้ากับมาตรฐานเท่านั้น โดยยังไม่ต้องสนใจว่าเราจะใช้เครื่องมืออะไร ทำให้ลดต้นทุนและความซับซ้อนในการออกแบบระบบของผู้ใช้งานลงไปได้เยอะ โดยผมจะเล่าถึงหลักการ เครื่องมือ และมาตรฐานในเสาแต่ละต้นของ Observability ต่อไปครับ
Logging
ทุกคนที่เป็น Developer คงคุ้นเคยกับการทำ Logging อยู่แล้ว นั่นก็คือการเก็บ Event ต่างๆ ของแอปพลิเคชันไว้เพื่อ Investigate หรือ Debug ปัญหา ซึ่ง Log ที่ทำก็มีทั้งแบบ Structure และ Non-Structure ถ้าเราทำ Log เป็นแบบแรกก็จะช่วยให้ Investigate ได้ง่ายขึ้น ทั้งยังสามารถนำ Log เข้าเครื่องมือต่างๆ ที่ใช้ในการประมวลผลได้ง่ายขึ้นด้วย
จุดเด่นของ Logging
- สร้างได้ง่าย เนื่องจาก Log เป็น String เฉยๆ ซึ่งเราอาจะเขียน Log ในรูปแบบ JSON หรือเป็นคู่ Key-Value ก็ได้ ก็คือสามารถ Represent ข้อมูลได้หลากหลาย และในปัจจุบันยังมี Application Framework หรือ Library จำนวนมากในแต่ละภาษาที่ช่วยในการทำ Logging ซึ่งใช้งานค่อนข้างง่าย
- สามารถ Investigate ได้ละเอียดไปถึงระดับ Line of Code
- สามารถเห็น Error, Exception, Stack Trace ของปัญหาได้
- ถ้าทำ Structured Log สามารถ Search หรือ Filter หาจุดที่มีปัญหาได้ง่าย
จุดด้อยของ Logging
- I/O, Performance Incentives ในกรณีที่มีการ Log มากๆ
- ใช้ Disk มากในการเก็บข้อมูลย้อนหลังนานๆ
- ยากในการวิเคราะห์ภาพใหญ่หรือดูภาพรวมของระบบ
- การไล่ปัญหาต้องใช้คน และใช้เวลาในการ Query / Search / Investigate โดยมักต้องเทียบกับโค้ดถึงจะเข้าใจ
จะเห็นว่า Logging เป็น Pattern ที่ Powerful ระดับนึงในการมอนิเตอร์แอปพลิเคชัน แต่ก็มีจุดด้อยที่สำคัญเช่นกัน
Common Tools
สำหรับเครื่องมือทำ Logging ส่วนใหญ่ หลักการคือการส่ง (Ship) Log จาก Source ซึ่งก็คือแอปพลิเคชัน ไป Parse ให้อยู่ในฟอร์แมตที่ต้องการ จากนั้นนำไปเก็บที่ Database ตรงกลางที่เหมาะสำหรับการ Search ซึ่ง (น่าจะ) เป็น De-facto Standard แล้วที่จะใช้ ELK Stack (เดี๋ยวนี้จะเรียกว่า Elastic Stack) สำหรับ Logging Tools โดย ELK Stack ประกอบไปด้วยซอฟต์แวร์หลายๆ ตัวประกอบกัน ได้แก่
- Elasticsearch (E) เป็น NoSQL Database ที่เก่งในเรื่องการทำ Index และ Search ข้อมูลขนาดใหญ่ โดยข้อมูล Log ที่ถูกส่งมาจากแอปพลิเคชันจะถูกเก็บไว้ใน Database ตัวนี้ ถือว่าเป็นหัวใจสำคัญของ ELK Stack
- Logstash (L) เป็น Data Collection และ Log Parsing Engine ใช้ในการประมวลผลและแปลงรูปแบบข้อมูลที่รับมาจากแอปพลิเคชันให้อยู่ในรูปแบบที่เราต้องการ โดยจะนำไปเก็บใน Elasticsearch ถ้าเรามี Log File ที่เป็นฟอร์แมตเฉพาะ เราก็ต้องมาเขียน Configuration ที่ตัว Logstash ว่าใน Log File ของเรามีข้อมูลอะไรบ้าง
- Kibana (K) เป็น Web UI ใช้ในการค้นหาข้อมูลจาก Elasticsearch และทำ Visualize Data ในรูปแบบต่างๆ เช่น ตาราง กราฟ เป็นต้น
- Beats ตัวนี้ไม่มีตัวย่ออยู่ในชื่อ ELK Stack แต่ก็เป็นตัวสำคัญที่จะขาดไปไม่ได้ Beats นั้นทำหน้าที่ส่งข้อมูล (Ship) Log จากแอปพลิเคชันเพื่อไปประมวลผลที่ Logstash โดย Beats จะซัพพอร์ตข้อมูลหลายแบบจาก Source ต้นทาง เช่น File, Database หรือพวก Messsaging Middleware ต่างๆ เป็นต้น
ELK Stack จะมีอีก Variation หนึ่งเรียกว่า EFK เป็นการนำเครื่องมือ Fluentd มาใช้แทน Logstash ซึ่งทาง Fluentd เองเคลมว่ามี Performance ที่ดีกว่า Logstash เนื่องจาก Architecture เป็นแบบ De-centralize
สำหรับเครื่องมืออื่นๆ ที่อยู่ในกลุ่มนี้จะมี Splunk และ Graylog
Metrics
เป็นการวิเคราะห์ Data แบบ Time Series โดยดูจากตัวอ้างอิงหลายๆ แกน หรือ Metrics เช่น จำนวน Request, Average Response Time หรือค่าอื่นๆ ตามที่เราอยากเห็น ซึ่งเราสามารถใช้ Math Operation ในการช่วยวิเคราะห์ได้ เช่น Sum, Average, Mean เป็นต้น
เนื่องจากข้อมูล Metrics เป็นข้อมูลตัวเลขที่เก็บมาตามช่วงเวลาเป็นแบบ Time Series จุดเด่นของ Metrics จะเป็นการเห็นภาพรวมระบบได้ง่ายและรวดเร็ว โดยที่ยังไม่ได้ใช้ Disk มากเท่า Log เพราะเก็บข้อมูลเป็นชุด Time Series ตาม Point in Time และเราสามารถเห็น Trends over Time เมื่อเก็บข้อมูลเป็นระยะเวลานานระดับหนึ่งด้วย
การเก็บข้อมูลของเครื่องมือที่ทำ Metrics เหล่านี้ นอกจากชื่อของ Metrics แล้ว ยังสามารถใส่ข้อมูลในลักษณะ Key-Value เพิ่มเข้าไปได้ เรียกว่า Label ซึ่งสามารถนำไปใช้เป็นมิติ (Dimension) ในการหมุนข้อมูลให้ Flexible มากขึ้นตามที่เราต้องการ
นอกจากนี้เครื่องมือหลายตัวยังมีความสามารถ Automatic Instruments หรือการดึงข้อมูล Metrics จากแอปพลิเคชันโดยที่ไม่ต้องแก้โค้ดได้ (เช่น Response Time, Heap Size, No. Request, CPU Usage) ต่างจาก Logging ที่ต้องใช้การเขียนโค้ดเพื่อ Print Log มาเก็บ
ปล. เราสามารถทำ Metrics โดยใช้ข้อมูลจาก Logging ได้ด้วยเช่นกัน แต่ไม่ถือเป็น Best Practice เนื่องจากการทำ Metrics ด้วยข้อมูลจาก Logging ต้องเก็บข้อมูลเป็นจำนวนมาก ทำให้ Query ข้อมูลได้ช้า และต้องใช้เนื้อที่ในการเก็บ Log มาก ส่งผลให้สามารถดูข้อมูลย้อนหลังได้น้อย
จุดเด่นของ Metrics
- เห็นภาพรวมทั้งแอปพลิเคชันเป็น Dashboard ได้ง่าย
- เครื่องมือส่วนใหญ่มีความสามารถ Automatic Instruments ทำให้สามารถดึง Metrics ได้โดยไม่ต้องแก้โค้ด
- สามารถประมวล Time Series Data ด้วย Math Operation ได้ระดับหนึ่ง
- ประหยัด Disk ในการเก็บมากกว่า Logging และกระทบ Performance น้อยกว่า เพราะสามารถเก็บ Metrics ใน Memory ได้
จุดด้อยของ Metrics
- ในการทำ Custom Metrics ต้องมีการ Implement Exposition Format ออกมาให้เครื่องมือดึงไปเก็บ
- ไม่สามารถเห็น Detail เพื่อ Investigate ปัญหารายตัวได้
- ในกรณีใช้ Metrics แบบ Pull-Based เป็น Interval, จะมีโอกาสที่ไม่เห็น Outliner ที่มีโอกาสเกิดขึ้นมาได้
จะเห็นว่าการใช้ Logging และ Metrics คู่กันช่วยให้เราเห็นการทำงานของระบบหนึ่งๆ อย่างครบถ้วนและหาปัญหาได้ดีขึ้น แต่ก็ยังไม่ทำให้เราเห็นภาพการทำงานตลอดอายุของ Request หนึ่งๆ ที่เกี่ยวข้องกับหลายระบบ ซึ่ง Distributed Tracing จะช่วยแก้ปัญหาในจุดนั้น
Common Tools
เครื่องมือที่นิยมจะมีด้วยกันหลายตัว (ยังไม่มีตัวไหนที่ Dominate วงการได้เหมือน ELK Stack) เช่น Zabbix, InfluxDB, Prometheus ซึ่งแต่ละตัวจะมีข้อดีข้อเสียแตกต่างกัน เว็บ Prometheus เขียนบทความอธิบายค่อนข้างละเอียดทีเดียวครับ
สมัยก่อนการเลือกใช้เครื่องมือจะเป็นปัญหาระดับนึง เพราะแต่ละเครื่องมือมีวิธีในการเอาข้อมูลเข้าแตกต่างกัน ทำให้การเขียนโค้ดแตกต่างกันไปด้วย
OpenMetrics Standard
โครงการ CNCF ซึ่งเป็นศูนย์รวมของ Open Source Project ต่างๆ เกี่ยวกับ Cloud Native มีการพยายามสร้างมาตรฐาน Exposition Format เพื่อให้แอปพลิเคชันสามารถ Expose Metrics เป็นมาตรฐานเดียวกัน และสามารถไป Plug กับเครื่องมือไหนก็ได้ นอกจากนี้ยังมีโครงการ OpenTelemetry ที่มีวัตถุประสงค์ในการสร้างมาตรฐานของทั้งเรื่อง Logging, Metrics, และ Tracing ครับ
Tracing
Trace เป็นข้อมูล Event ต่างๆ ที่เกี่ยวข้องกับ Request หนึ่งๆ ที่วิ่งผ่านหลาย Component หรือระบบใน Distributed System ซึ่งข้อมูล Trace นี้จะช่วยให้เราเห็นทั้ง Path ก็คือในแต่ละ Request ผ่าน Component หรือ Service ไหนบ้าง กับ Structure หรือโครงสร้างการเชื่อมต่อของแต่ละ Component เช่น มีการทำงานแบบ Asynchronous ตรงไหน หรือมีการทำงานแบบ Parallel ตรงไหนบ้างรึเปล่า รวมถึงสามารถจับเวลาในจุดเชื่อมต่อต่างๆ ที่อยู่นอกเหนือจากตัวแอปพลิเคชันของเราได้ เช่น เวลาที่ใช้ไปกับ Network Communication เป็นต้น
ข้อมูล Trace จะถูกเก็บในรูปแบบของ Direct Acyclic Graph (DAG) ของการทำงานในแต่ละขั้นตอนที่เรียกว่า Span โดยแอปพลิเคชันสามารถกำหนดจุดเริ่มต้นและจุดสิ้นสุดของ Span ได้เอง นี่เป็นตัวอย่าง Request Flow Diagram ที่สร้างจากข้อมูล Trace ครับ
สำหรับหลักการของการทำ Tracing เมื่อ Component แรกของระบบรับ Request เข้ามาในแต่ละครั้ง ก็จะต้องสร้าง Unique ID ขึ้นมา ซึ่ง ID นี้จะถูกส่งต่อไปทอดๆ ทั้งสายของ Request พร้อมกับสร้าง Span ขึ้นมาเพื่อบันทึกการทำงานพร้อมจุดเริ่มต้นของการทำงานเอาไว้ เมื่อแต่ละ Component จบการทำงาน ก็จะบันทึกจุดสิ้นสุดการทำงานของ Span แล้วส่งข้อมูล Span ไปยังระบบที่ใช้เก็บข้อมูล Trace
ระหว่างที่ Span ยังไม่จบ ถ้าแต่ละ Component มีการส่งต่อการทำงานให้ Component อื่นๆ แต่ละ Component เหล่านั้นก็จะต้องสร้าง Span ใหม่ขึ้นมา ดังนั้น โครงสร้างของ Trace จะมี Span ซ้อนๆ กันตามรูปด้านล่างนี้
ภาพนี้เป็นตัวอย่าง Tracing จากเครื่องมือ Jaeger ที่มีการใช้งานกันภายใน KBTG จริงๆ จะเห็นว่าเราสามารถเห็น Flow แบบ End-to-End ว่าแต่ละ Request ที่เข้ามาหาแอปพลิเคชันวิ่งผ่าน Microservice อะไรบ้าง และแต่ละ Microservice ใช้เวลาในการประมวลผลเท่าไหร่ รวมถึงสามารถเห็นในระดับของ Http Request Header และ SQL Statement ได้อีกด้วย
Common Tools
เครื่องมือที่เกี่ยวข้องกับการทำ Tracing แบ่งได้เป็น 2 ส่วน คือส่วนที่เป็นซอฟต์แวร์กับส่วนที่เป็น Library หรือ API ที่เราต้องเอาไปใส่ในโค้ดของเราเพื่อให้ส่งข้อมูล Trace ออกมา ตัวอย่างของซอฟต์แวร์ในกลุ่มนี้ที่เป็นที่นิยมได้แก่ Jaeger, Zipkin, Datadog, NewRelic, Lightstep และ Dynatrace
เครื่องมือ Open Source ที่เป็นที่นิยมหนีไม่พ้น Jaeger เนื่องจากเป็นโปรเจคที่เคยอยู่ใน CNCF ที่ดูแลซอฟต์แวร์หรือเครื่องมือที่เกี่ยวข้องกับ Cloud Native Stack จำนวนมาก และสามารถนำมา Set up ใช้งานได้ง่าย ส่วนเครื่องมือที่เป็น Commercial ก็มีอยู่หลายตัวด้วยกัน ตัวที่ค่อนข้างได้รับความนิยมคือ Dynatrace ซึ่งมีฟีเจอร์ขั้นสูงเพิ่มขึ้นมา ไม่ว่าเป็นเรื่องของการมี AI หรือความสามารถในการมอนิเตอร์และตรวจจับสิ่งผิดปกติ และแจ้งเตือนอัตโนมัติ เป็นต้น แต่ก็จะมีค่าใช้จ่ายในการใช้งานตามมาด้วย
คุณสมบัติหนึ่งที่แตกต่างกันของเครื่องมือแต่ละตัว คือความยากง่ายในการ Set up หรือ Configure ระบบของเราให้ส่ง Trace ไปยังระบบหลังบ้าน หรือที่เรียกว่าการทำ Instrumentation เครื่องมือบางตัว โดยเฉพาะที่เป็น Commercial หลายตัวจะมีความสามารถ Auto Instrumentation คือสามารถไปมอนิเตอร์หรือจับแอปพลิเคชันของเราให้ส่ง Trace ออกมาได้เลยแบบอัตโนมัติ โดยไม่เป็นต้องแก้ไขโค้ดใดๆ ก็จะง่ายในการเริ่มต้นใช้งาน และรองรับกรณีที่เราไม่มี Source Code ของแอปพลิเคชันที่ต้องการทำ Tracing
ถ้าระบบของเรามีการ Implement Services Mesh ส่วนใหญ่จะมีฟีเจอร์ของการทำ Tracing มาให้ด้วย เนื่องจากใน Service Mesh การคุยกันระหว่าง Microservice แต่ละตัวจะผ่าน Proxy บางอย่าง ซึ่งฟีเจอร์ในเรื่องของ Observability เช่น การทำ Tracing หรือการบันทึก Metrics สามารถทำได้โดยอัตโนมัติ ยกตัวอย่างเช่น ถ้าเราใช้ Istio ก็จะซัพพอร์ต Observability ที่ Envoy Proxy เป็นต้น
มาตรฐานของ Observability Tools
จากที่ได้กล่าวมาข้างต้น คงเห็นแล้วว่าใน Area ของ Observability นั้นมีเครื่องมือ หรือ Vendor ที่ทำ Product ในกลุ่มนี้เป็นจำนวนมาก ในสมัยก่อนวิธีการ Implement เครื่องเหล่านี้มาใช้งานหรือการเขียนโปรแกรมให้รองรับเครื่องมือเหล่านี้จะขึ้นอยู่กับ Vendor แต่ละราย ซึ่งนอกจากจะทำให้ผู้ที่ต้องการใช้งานถูก Lock-in กับ Vendor แล้ว ทางฝั่ง Vendor เองก็ต้องมีการพัฒนา Library ขึ้นมาใหม่เป็นของตัวเองด้วย
แต่หลังๆ มานี้ทาง Community ได้เห็นความจำเป็นในการทำมาตรฐานในเรื่องของ Observabilty เพื่อลดความลำบากในการใช้งานของผู้ใช้ รวมถึงลดงานในการพัฒนา Programming Interface ของแต่ละเครื่องมือ เพื่อให้ Vendor ไปโฟกัสที่ฟีเจอร์ของเครื่องมือที่ตัวเองพัฒนามากกว่า ในระยะแรกก็จะมี OpenMetrics ที่พยายามทำมาตรฐานในเรื่องของ Metrics และ OpenCensus ครอบคลุมทั้งเรื่องของ Metrics และ Tracing ทั้งยังมีโครงการ OpenTracing ที่พัฒนามาตรฐาน Client Library ในเรื่องของ Tracing ซึ่งโครงการ OpenCensus และ OpenTracing ในภายหลังก็ได้ถูกจับรวมกัน เป็นโครงการ OpenTelemetry ที่ต้องการวางมาตรฐานทั้งในเรื่อง Logging, Metrics, และ Tracing ครบทั้ง 3 ด้าน และยังมี Reference Implementation ของ Tracing Collector สำหรับรับข้อมูล Trace จากแอปพลิเคชันเพื่อส่งต่อไปประมวลผลที่ระบบสำหรับเก็บข้อมูลโดยไม่เจาะจงกับ Vendor อีกด้วย (Vendor Agnostic)
การเก็บข้อมูล Trace โดยใช้ OpenTelemetry นั้นรองรับ Programming Language หลากหลาย ไม่ว่าจะเป็น Java, Go, .NET, Node.js, python เป็นต้น แต่มีเพียง Library สำหรับภาษา Java ที่สามารถทำ Automatic Instrumentation ได้โดยที่แอปพลิเคชันไม่ต้องแก้โค้ดใดๆ ส่วนภาษาอื่นอาจต้องมีการแก้ไขโค้ดเล็กน้อยเพื่อบันทึก Span ณ จุดที่เราต้องการเห็นการเชื่อมต่อ
ส่งท้าย
ในวันนี้เราก็ได้ทำความรู้จักกับ Observability กันไปแล้วว่าเกี่ยวข้องกับเรื่องอะไร ประกอบไปด้วยอะไรบ้าง และมีเครื่องมืออะไรบ้างในท้องตลาดที่ทำเรื่องนี้อยู่ รวมถึงมาตรฐานต่างๆ ที่เกี่ยวข้อง ในคราวหน้าเราจะมาลองลงลึกในแต่ละ Area ของ Logging, Metrics, Tracing ว่าเราสามารถนำเครื่องมือต่างๆ มาประยุกต์ใช้งานได้อย่างไรบ้างครับ
สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech
