Observability Versus Monitoring (Observability กับ Monitoring)

เรา กำลังจะเริ่มเจาะลึกว่าเราจะเริ่มแก้ปัญหาที่เราเพิ่งพูดถึงไปได้อย่างไร แต่ก่อนที่เราจะทำ ผมคิดว่ามันสำคัญที่เราจะสำรวจคำศัพท์คำหนึ่งที่ได้รับความนิยมมากขึ้นมากนับตั้งแต่ผมเขียนหนังสือฉบับพิมพ์ครั้งแรก— observability .

เหมือนที่มักเป็นเสมอ แนวคิดของ observability มีมานานหลายทศวรรษแล้ว แต่เพิ่งจะเข้ามาสู่วงการพัฒนาซอฟต์แวร์เมื่อไม่นานมานี้ Observability ของระบบคือขอบเขตที่คุณสามารถเข้าใจ internal state ของระบบได้จาก external output โดยทั่วไปมันต้องการความเข้าใจแบบองค์รวมมากขึ้นเกี่ยวกับซอฟต์แวร์ของคุณ—มองมันในฐานะ ระบบ มากกว่าที่จะมองเป็นกลุ่มของ entity ที่แยกจากกัน

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

ในทางกลับกัน Monitoring คือสิ่งที่เรา ทำ เรา monitor ระบบ เรามองมัน สิ่งต่าง ๆ จะเริ่มผิดพลาดถ้าคุณโฟกัสแค่ที่ตัว monitoring—กิจกรรมนั้น—โดยไม่คิดว่าคุณคาดหวังให้กิจกรรมนั้นบรรลุอะไร

แนวทาง monitoring แบบดั้งเดิมกว่านั้นจะให้คุณคิดล่วงหน้าว่าอะไรอาจผิดพลาดได้บ้าง แล้วกำหนดกลไก alerting เพื่อบอกคุณเมื่อสิ่งเหล่านั้นเกิดขึ้น แต่เมื่อระบบยิ่ง distributed มากขึ้น คุณจะเจอปัญหาที่ไม่เคยผุดขึ้นในหัวคุณมาก่อน ด้วยระบบที่มี observability สูง คุณจะมีชุดของ external output ที่คุณสามารถซักถามได้หลายวิธี—ผลลัพธ์ที่เป็นรูปธรรมของการมีระบบที่ observable ได้ก็คือคุณสามารถตั้งคำถามกับระบบ production ของคุณที่คุณไม่เคยคิดจะถามมาก่อนได้

ดังนั้นเราจึงสามารถมอง monitoring เป็นกิจกรรม—สิ่งที่เราทำ—ในขณะที่ observability เป็นคุณสมบัติของระบบ

The Pillars of Observability? Not So Fast (เสาหลักของ Observability? ยังก่อน)

บาง คนพยายามกลั่นแนวคิดของ observability ให้เหลือแค่ concept หลักไม่กี่อย่าง บางคนโฟกัสไปที่ "three pillars" ของ observability ในรูปของ metrics, logging และ distributed tracing New Relic ถึงกับบัญญัติศัพท์ MELT (metrics, event, logs, and traces) ขึ้นมา ซึ่งก็ไม่ได้ติดตลาดจริงจังนัก แต่อย่างน้อย New Relic ก็พยายามแล้ว แม้ model ง่าย ๆ นี้จะดึงดูดผมมากในตอนแรก (และผมก็เป็นคนคลั่งไคล้ acronym!) แต่เมื่อเวลาผ่านไปผมก็เริ่มถอยห่างจากความคิดนี้ เพราะมันดู reductive เกินไป และอาจพลาดประเด็นสำคัญไปด้วย

ประการแรก การลดทอนคุณสมบัติของระบบให้เหลือแค่รายละเอียด implementation แบบนี้ ดูย้อนแย้งสำหรับผม Observability เป็นคุณสมบัติ (property) และมีหลายวิธีที่ผมอาจบรรลุคุณสมบัตินั้นได้ การโฟกัสมากเกินไปที่รายละเอียด implementation เฉพาะเจาะจง มีความเสี่ยงที่จะไปโฟกัสที่กิจกรรมแทนที่จะเป็นผลลัพธ์ มันคล้ายกับโลกของ IT ในปัจจุบัน ที่องค์กรนับร้อยนับพันตกหลุมรักการสร้างระบบที่ใช้ microservice โดยไม่เข้าใจจริง ๆ ว่าพวกเขากำลังพยายามบรรลุอะไรกันแน่!

ประการที่สอง มีเส้นแบ่งที่ชัดเจนระหว่าง concept เหล่านี้เสมอไปหรือเปล่า? ผมขอเถียงว่าหลายอย่างในนั้นซ้อนทับกัน ผมสามารถใส่ metric ลงใน logfile ได้ถ้าอยากทำ ในทางกลับกัน ผมก็สามารถสร้าง distributed trace ขึ้นจากชุดของ log line ได้เช่นกัน ซึ่งเป็นสิ่งที่ทำกันเป็นปกติ

Note (หมายเหตุ)

Observability คือขอบเขตที่คุณสามารถเข้าใจได้ว่าระบบกำลังทำอะไรอยู่ โดยอิงจาก external output Logs, events และ metrics อาจช่วยให้สิ่งต่าง ๆ observable ได้ แต่จงแน่ใจว่าคุณโฟกัสที่การทำให้ระบบเข้าใจได้ มากกว่าการโยนเครื่องมือมากมายเข้าไป

พูดแบบขี้ระแวงหน่อย ผมอาจจะบอกว่าการผลักดัน narrative ง่าย ๆ แบบนี้เป็นวิธีขายเครื่องมือให้คุณ คุณต้องการเครื่องมือหนึ่งสำหรับ metrics เครื่องมืออีกตัวสำหรับ logs และอีกตัวสำหรับ traces! และคุณต้องส่งข้อมูลเหล่านั้นแยกกันด้วย! มันง่ายกว่ามากที่จะขาย feature ด้วยวิธี box-ticking เวลาพยายาม market ผลิตภัณฑ์ แทนที่จะพูดถึงผลลัพธ์ อย่างที่ผมบอก ผม อาจจะ เสนอมุมมองแบบขี้ระแวงนี้ได้ แต่นี่ปี 2021 แล้ว และผมก็พยายามคิดในแง่บวกมากขึ้นสักหน่อย 3

เป็นไปได้ว่าทั้งสาม (หรือสี่!) concept นี้เป็นเพียงตัวอย่างเฉพาะของ concept ที่กว้างกว่ามากกว่า โดยพื้นฐานแล้ว เราสามารถมองข้อมูลชิ้นไหนก็ตามที่เราได้จากระบบของเรา—external output เหล่านี้—ในเชิงทั่วไปว่าเป็น event ได้ event หนึ่ง ๆ อาจมีข้อมูลมากหรือน้อยก็ได้ มันอาจมี CPU rate ข้อมูลเกี่ยวกับการชำระเงินที่ล้มเหลว ข้อเท็จจริงที่ว่าลูกค้าล็อกอินเข้ามา หรืออะไรก็ได้อีกมากมาย เราสามารถ project จาก event stream นี้ให้เป็น trace (โดยสมมติว่าเรา correlate event เหล่านี้ได้) เป็น searchable index หรือเป็น aggregation ของตัวเลขก็ได้ แม้ว่าปัจจุบันเราจะเลือกเก็บข้อมูลนี้ด้วยวิธีที่ต่างกัน โดยใช้เครื่องมือและ protocol ที่ต่างกัน แต่ toolchain ปัจจุบันของเราไม่ควรจำกัดวิธีคิดของเราว่าเราจะได้ข้อมูลที่เราต้องการมาได้ดีที่สุดอย่างไร

เมื่อพูดถึงการทำให้ระบบของคุณ observable ให้คิดถึง output ที่คุณต้องการจากระบบของคุณในแง่ของ event ที่คุณสามารถเก็บและซักถามได้ คุณอาจต้องใช้ tooling ที่ต่างกันเพื่อเปิดเผย event ประเภทต่าง ๆ ในตอนนี้ แต่นั่นอาจไม่ใช่กรณีในอนาคต