Selecting Tools (การเลือกเครื่องมือ)

อย่างที่ เราได้ครอบคลุมไปแล้ว มีเครื่องมือหลากหลายที่คุณอาจต้องนำมาใช้เพื่อช่วยปรับปรุง observability ของระบบของคุณ แต่อย่างที่ผมพูดถึงไปแล้ว นี่คือพื้นที่ที่กำลังเกิดขึ้นอย่างรวดเร็ว และมีความเป็นไปได้สูงมากที่ tooling ที่เราจะใช้ในอนาคตจะดูแตกต่างไปมากจากที่เรามีอยู่ตอนนี้ ด้วย platform อย่าง Honeycomb และ Lightstep ที่นำหน้าในแง่ของว่า observability tooling สำหรับ microservice หน้าตาเป็นอย่างไร และตลาดที่เหลือกำลังไล่ตามอยู่ในระดับหนึ่ง ผมคาดว่าพื้นที่นี้จะเห็นการเปลี่ยนแปลงมากมายในอนาคต

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

Democratic (เป็นประชาธิปไตย)

ถ้าคุณมีเครื่องมือที่ยากต่อการใช้งานจนมีแต่ operator ที่มีประสบการณ์เท่านั้นที่ใช้มันได้ คุณก็จำกัดจำนวนคนที่สามารถมีส่วนร่วมในกิจกรรม production ได้ เช่นเดียวกัน ถ้าคุณเลือกเครื่องมือที่แพงมากจนห้ามใช้ในสถานการณ์อื่นนอกจาก production environment ที่สำคัญ นักพัฒนาก็จะไม่มีโอกาสได้สัมผัสเครื่องมือเหล่านี้จนกว่าจะสายเกินไป

เลือกเครื่องมือที่คำนึงถึงความต้องการของคนทุกคนที่คุณอยากให้ใช้มัน ถ้าคุณอยากย้ายไปสู่ model ของ collective ownership ของซอฟต์แวร์ของคุณมากขึ้นจริง ๆ ซอฟต์แวร์ก็ต้องใช้งานได้โดยทุกคนในทีม การทำให้แน่ใจว่า tooling ที่คุณเลือกจะถูกใช้ใน development และ test environment ด้วย จะช่วยให้เป้าหมายนี้เป็นจริงได้มาก

Easy to Integrate (Integrate ได้ง่าย)

การดึงข้อมูลที่ถูกต้องออกมาจากสถาปัตยกรรมแอปพลิเคชันและระบบที่คุณรันอยู่นั้นสำคัญมาก และอย่างที่เราได้ครอบคลุมไปแล้ว คุณอาจต้องดึงข้อมูลมากกว่าเดิม และในรูปแบบที่ต่างออกไป การทำให้กระบวนการนี้ง่ายที่สุดเท่าที่จะทำได้เป็นเรื่องสำคัญมาก initiative อย่าง OpenTracing ได้ช่วยในแง่ของการมอบ standard API ที่ client library และ platform สามารถรองรับได้ ทำให้ integration และ portability ข้าม toolchain ง่ายขึ้น ที่น่าสนใจเป็นพิเศษ อย่างที่ผมได้พูดถึงไปแล้ว คือ initiative OpenTelemetry ใหม่ ซึ่งขับเคลื่อนโดยหลายฝ่ายจำนวนมาก

การเลือกเครื่องมือที่รองรับ open standard เหล่านี้จะช่วยลดความยากในการ integrate และอาจช่วยให้เปลี่ยน vendor ในภายหลังได้ง่ายขึ้นด้วย

Provide Context (ให้บริบท)

เมื่อ มองข้อมูลชิ้นหนึ่ง ผมต้องการให้เครื่องมือมอบบริบทให้มากที่สุดเท่าที่จะทำได้ เพื่อช่วยให้ผมเข้าใจว่าต้องทำอะไรต่อไป ผมชอบระบบการจัดหมวดหมู่ต่อไปนี้มากสำหรับบริบทประเภทต่าง ๆ ที่ผมพบผ่าน Lightstep blog post: 13

Temporal context

สิ่งนี้เทียบกับเมื่อหนึ่งนาที หนึ่งชั่วโมง หนึ่งวัน หรือหนึ่งเดือนที่แล้วเป็นอย่างไร?

Relative context

สิ่งนี้เปลี่ยนไปอย่างไรเมื่อเทียบกับสิ่งอื่นในระบบ?

Relational context

มีอะไรพึ่งพาสิ่งนี้ไหม? สิ่งนี้พึ่งพาสิ่งอื่นไหม?

Proportional context

สิ่งนี้แย่แค่ไหน? มันมี scope ใหญ่หรือเล็ก? ใครได้รับผลกระทบ?

Real-Time (แบบ Real-Time)

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

Suitable for Your Scale (เหมาะกับ Scale ของคุณ)

งานส่วนใหญ่ ในพื้นที่ observability ของระบบ distributed ได้รับแรงบันดาลใจจากงานที่ทำในระบบ distributed ขนาดใหญ่มาก น่าเสียดายที่สิ่งนี้อาจทำให้เราพยายามสร้างโซลูชันใหม่สำหรับระบบที่มี scale ใหญ่กว่าของเรามาก โดยไม่เข้าใจ trade-off

ระบบที่มี scale มหาศาลมักต้องทำ trade-off เฉพาะเพื่อลดฟังก์ชันการทำงานของระบบของพวกเขา เพื่อจัดการกับ scale ที่พวกเขาดำเนินการอยู่ Dapper ตัวอย่างเช่น ต้องใช้ random sampling ที่ aggressive มาก (ซึ่งก็คือ "ทิ้ง" ข้อมูลจำนวนมากอย่างมีประสิทธิภาพ) เพื่อให้รับมือกับ scale ระดับ Google ได้ อย่างที่ Ben Sigelman ผู้ก่อตั้ง LightStep และผู้สร้าง Dapper กล่าวไว้: 14

Microservice ของ Google สร้าง RPC ประมาณ 5 พันล้านครั้งต่อวินาที ดังนั้นการสร้าง observability tool ที่ scale ได้ถึง 5 พันล้าน RPC/วินาที จึงสรุปได้ว่าคือการสร้าง observability tool ที่ feature poor อย่างมาก ถ้าองค์กรของคุณทำประมาณ 5 ล้าน RPC/วินาที นั่นก็ยังน่าประทับใจอยู่ดี แต่คุณแทบจะไม่ควรใช้สิ่งที่ Google ใช้: ที่ 1/1000 ของ scale นั้น คุณสามารถมี feature ที่ทรงพลังกว่ามากได้

คุณยังต้องการเครื่องมือที่ สามารถ scale ได้ตามที่คุณ scale ในอุดมคติด้วย อีกครั้ง cost effectiveness สามารถเข้ามามีบทบาทตรงนี้ได้ แม้เครื่องมือที่คุณเลือกจะสามารถ scale ทางเทคนิคเพื่อรองรับการเติบโตที่คาดไว้ของระบบของคุณได้ คุณจะจ่ายเงินเพื่อมันต่อไปไหวไหม?