Building Blocks for Observability (Building Block สำหรับ Observability)

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

ในส่วนที่เหลือของบทนี้ เราจะมาดูว่าจะทำสิ่งนี้ทั้งหมดให้เกิดขึ้นได้อย่างไร เราจะครอบคลุม building block หลายอย่างที่ช่วยปรับปรุง observability ของสถาปัตยกรรมระบบของคุณ:

Log aggregation

การเก็บรวบรวมข้อมูลข้าม microservice หลายตัว ซึ่งเป็น building block สำคัญของโซลูชัน monitoring หรือ observability ใด ๆ

Metrics aggregation

การจับตัวเลขดิบจาก microservice และ infrastructure ของเรา เพื่อช่วยตรวจจับปัญหา ขับเคลื่อน capacity planning และบางทีก็ scale แอปพลิเคชันของเราด้วยซ้ำ

Distributed tracing

การติดตาม flow ของการเรียกข้าม microservice boundary หลายตัว เพื่อหาว่าอะไรผิดพลาดและดึง latency information ที่แม่นยำออกมา

Are you doing OK?

การดู error budget, SLA, SLO และอื่น ๆ เพื่อดูว่าสิ่งเหล่านี้ถูกใช้เป็นส่วนหนึ่งของการทำให้แน่ใจว่า microservice ของเราตอบสนองความต้องการของผู้บริโภคได้อย่างไร

Alerting

คุณควร alert เรื่องอะไร? alert ที่ดีหน้าตาเป็นอย่างไร?

Semantic monitoring

คิดแตกต่างออกไปเกี่ยวกับสุขภาพของระบบของเรา และเกี่ยวกับสิ่งที่ควรปลุกเราตื่นตอนตีสาม

Testing in production

สรุปเทคนิค testing in production หลากหลายรูปแบบ

มาเริ่มกันที่สิ่งที่อาจจะง่ายที่สุดในการเริ่มต้นใช้งาน แต่เป็นสิ่งที่จะคุ้มค่ากลับมาหลายเท่า: log aggregation

Log Aggregation

ด้วย จำนวน server และ microservice instance ที่มากมาย แม้แต่ในสถาปัตยกรรม microservice ขนาดพอประมาณ การ login เข้าเครื่องหรือ SSH-multiplexing เพื่อดึง log ก็ไม่เพียงพออีกต่อไป แทนที่จะทำแบบนั้น เราต้องใช้ subsystem เฉพาะทางเพื่อดึง log ของเราและทำให้มันพร้อมใช้งานได้จากศูนย์กลาง

Log จะกลายเป็นหนึ่งในกลไกสำคัญที่สุดอย่างรวดเร็ว ที่ช่วยให้คุณเข้าใจว่าเกิดอะไรขึ้นใน production system ของคุณ ด้วยสถาปัตยกรรม deployment ที่เรียบง่ายกว่า logfile ของเรา สิ่งที่เราใส่เข้าไปในนั้น และวิธีที่เราจัดการมัน มักเป็นสิ่งที่เราไม่ค่อยได้ใส่ใจ แต่กับระบบที่ distributed มากขึ้นเรื่อย ๆ log จะกลายเป็นเครื่องมือสำคัญ ไม่เพียงช่วยให้คุณวินิจฉัยว่าอะไรผิดพลาดเมื่อคุณพบว่ามีปัญหาเท่านั้น แต่ยังบอกคุณด้วยว่ามีปัญหาที่ต้องการความสนใจของคุณตั้งแต่แรกแล้ว

อย่างที่เราจะพูดถึงในไม่ช้า มีเครื่องมือหลากหลายในพื้นที่นี้ แต่ทั้งหมดล้วนทำงานในรูปแบบคล้าย ๆ กัน ตามที่แสดงใน Figure 10-4 Process ต่าง ๆ (เช่น microservice instance ของเรา) log ลงใน local filesystem ของมัน Daemon process ในเครื่องจะเก็บรวบรวมและส่งต่อ log นี้เป็นระยะไปยัง store บางแห่งที่ operator สามารถ query ได้ หนึ่งในแง่มุมที่ดีของระบบเหล่านี้คือสถาปัตยกรรม microservice ของคุณสามารถแทบไม่รู้ตัวถึงการมีอยู่ของมันเลยก็ได้ คุณไม่จำเป็นต้องเปลี่ยนโค้ดของคุณเพื่อใช้ API พิเศษอะไร คุณแค่ log ลงใน local filesystem คุณจำเป็นต้องเข้าใจ failure mode รอบ ๆ กระบวนการ log shipping นี้ด้วย โดยเฉพาะถ้าคุณอยากเข้าใจสถานการณ์ที่ log อาจสูญหายไปได้

Figure 10-4. ภาพรวมว่า log ถูกเก็บรวบรวมอย่างไรในกระบวนการ log aggregation

ทีนี้ ผมหวังว่าคุณคงสังเกตเห็นแล้วว่าผมพยายามหลีกเลี่ยงการเป็นคนหัวรั้นตายตัวเกี่ยวกับเรื่องต่าง ๆ แทนที่จะบอกแค่ว่าคุณ ต้อง ทำ X หรือ Y ผมพยายามให้บริบทและคำแนะนำ และอธิบาย nuance ของการตัดสินใจบางอย่าง—นั่นคือ ผมพยายามมอบเครื่องมือให้คุณตัดสินใจเลือกสิ่งที่ถูกต้องสำหรับบริบทของคุณเอง แต่ในเรื่องของ log aggregation ผมจะให้คำแนะนำที่ใกล้เคียงกับ one-size-fits-all ที่สุดเท่าที่ผมจะทำได้: คุณควรมองว่าการ implement เครื่องมือ log aggregation เป็น prerequisite สำหรับการ implement สถาปัตยกรรม microservice

เหตุผลของผมสำหรับมุมมองนี้มีสองอย่าง อย่างแรก log aggregation มีประโยชน์อย่างเหลือเชื่อ สำหรับคนที่มองว่า logfile ของตัวเองเป็นที่ทิ้งข้อมูลมั่ว ๆ นี่อาจเป็นเรื่องน่าประหลาดใจ แต่เชื่อผมเถอะ—เมื่อทำถูกต้อง log aggregation มีค่ามหาศาล โดยเฉพาะเมื่อใช้ร่วมกับอีก concept หนึ่งที่เราจะพูดถึงในไม่ช้า นั่นคือ correlation ID

อย่างที่สอง การ implement log aggregation เมื่อเทียบกับแหล่งความเจ็บปวดและความทุกข์ทรมานอื่น ๆ ที่สถาปัตยกรรม microservice นำมาให้ ไม่ได้ยากขนาดนั้น ถ้าองค์กรของคุณไม่สามารถ implement โซลูชัน log aggregation ง่าย ๆ ได้สำเร็จ มันก็มีแนวโน้มว่าองค์กรของคุณจะรับมือกับแง่มุมอื่น ๆ ของสถาปัตยกรรม microservice ไม่ไหว ดังนั้นให้มองการ implement โซลูชันแบบนี้เป็นวิธีทดสอบความพร้อมขององค์กรของคุณสำหรับความน่ากลัวที่เหลือที่จะตามมา