container ยังรันอยู่ แต่ผู้ใช้เปิดเว็บได้จริงไหม

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

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

Blackbox Exporter เป็นเครื่องมือหนึ่งที่ใช้ probe ปลายทางแล้วให้ metric กลับมา แต่ก่อนตั้งเป้าเป็นรายการ URL ยาวๆ ควรเลือกว่าต้องการยืนยันการใช้งานส่วนใด และกำหนดว่าผลผ่านของแต่ละเป้าหมายหมายถึงอะไรจริงๆ

จุดที่ใช้ตรวจมีผลกับสิ่งที่มองเห็น

ถ้าตรวจจากเครื่องเดียวกับแอป เราอาจยืนยันได้ว่าบริการตอบในเส้นทางภายใน แต่ยังไม่ครอบคลุม DNS หรือการเข้าจากนอกบ้าน หากต้องการดูทางเข้าของผู้ใช้ภายนอก ก็ควรมีจุดตรวจที่ใช้เส้นทางนั้นตามขอบเขตที่เราดูแลได้

ในทางกลับกัน ปลายทางที่ตั้งใจให้ใช้เฉพาะเครือข่ายส่วนตัวก็ต้องตรวจจากจุดที่มีสิทธิ์และเส้นทางถูก ไม่ตีความว่าการเข้าจากอินเทอร์เน็ตไม่ผ่านเป็นเหตุเสียของบริการที่ไม่ได้ออกแบบให้เปิดจากจุดนั้นตั้งแต่แรก

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

ถ้าชื่อมีทั้ง IPv4 กับ IPv6 ก็ควรรู้ว่ากฎ probe เลือกทดสอบแบบใด การมีทางหนึ่งผ่านไม่ยืนยันว่าอีกทางผ่านด้วย หากงานต้องรองรับทั้งคู่ การแยกตรวจอย่างตั้งใจจะอธิบายผลได้มากกว่าปล่อย fallback แล้วอ่านว่าสำเร็จทั้งหมด

exporter พร้อมกับเป้าหมายพร้อมเป็นคนละข้อมูล

Prometheus อาจ scrape ตัว Blackbox Exporter ได้ตามปกติ แต่ผล probe ของบริการปลายทางยังล้มเหลวได้ จึงต้องแยกสถานะของเครื่องมือเก็บข้อมูลออกจากผลของเป้าหมายที่กำลังตรวจ

metric อย่าง probe_success ใช้บอกผลตาม module ที่เลือก ส่วน metric ของ exporter เองช่วยดูการทำงานของตัวมัน การตั้ง alert ควรอ้างถึงสิ่งที่ต้องการยืนยันจริง ไม่ใช้แค่การเก็บ metric ได้แทนว่าหน้าเว็บเปิดผ่าน

ชื่อ target กับ labels ควรสื่อปลายทางและจุดตรวจให้ตรง เพื่อให้ข้อความที่ส่งออกมาบอกได้ว่ากำลังล้มเหลวจากมุมไหน ไม่ใช้ชื่อ instance ที่ซ่อน URL จริงจนคนดูต้องย้อนเปิด configuration ทุกครั้ง

timeout และรอบตรวจต้องถูกออกแบบร่วมกับการ scrape ตามข้อจำกัดของเครื่องมือ โดยมีพื้นที่ให้คืนผล ไม่ตั้งรอเป้าหมายนานจนขั้นเก็บข้อมูลหมดเวลาก่อนเป็นปกติ และไม่เพิ่มความถี่จนตัวตรวจสร้างภาระให้บริการเกินที่งานต้องการ

สถานะ HTTP ต้องแปลตามหน้าที่ของหน้า

การได้ HTTP ที่อยู่ในช่วงยอมรับเป็นหลักฐานว่าปลายทางตอบตามเงื่อนไขหนึ่ง แต่หน้า error ที่แอปตอบเป็น 200 หรือหน้า login หลัง redirect ก็อาจยังผ่านกติกากว้างที่ไม่ได้ดูเนื้อหา

ถ้าต้องยืนยันหน้าประเภทหนึ่ง อาจกำหนดเงื่อนไขสถานะ header หรือข้อความที่ควรพบตามความสามารถของ module แต่ต้องเลือกข้อความที่มีความหมายและไม่เปลี่ยนตามการจัดหน้าเล็กๆ จน alert เกิดเพียงเพราะแก้ถ้อยคำ

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

สำหรับ HTTPS ควรรักษาการตรวจชื่อและใบรับรองตามที่ client ควรใช้ ไม่ปิดการตรวจเพียงเพื่อให้ probe ผ่านแล้วนำผลไปแทนประสบการณ์ของเบราว์เซอร์ที่ยังตรวจอยู่ ส่วนข้อมูลวันหมดอายุช่วยวางแผนดูแลได้ แต่ก็ต้องแยกจากผลว่าแอปตอบเนื้อหาถูกต้องหรือไม่

การเปิดหน้าได้ยังไม่เท่ากับทุกฟังก์ชันทำงาน

เว็บที่ใช้ JavaScript ดึงข้อมูลภายหลังอาจส่งโครง HTML กลับมาได้ แม้ API ที่ผู้ใช้ต้องใช้มีปัญหา การ probe HTTP ทั่วไปไม่ได้เปิดหน้าและใช้งานเหมือนเบราว์เซอร์ทุกขั้น จึงควรเลือก endpoint ประกอบหรือวิธีตรวจอีกแบบตามสิ่งที่ต้องยืนยัน

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

สิ่งที่ผ่านจึงควรถูกอธิบายตรง เช่น ทางเข้ารับ HTTP ได้กับ API ตอบข้อมูลพื้นฐานได้ เป็นคนละหลักฐาน การมีหลายจุดที่หน้าที่ชัดดีกว่าตั้งชื่อ probe เดียวว่าสุขภาพทั้งหมดแล้วทำให้คนเข้าใจเกินสิ่งที่ตรวจ

ผลล้มเหลวควรมีรายละเอียดให้ไล่ต่อ

ข้อมูลเวลาของขั้น DNS การเชื่อมต่อ และ TLS ที่เครื่องมือให้ได้ช่วยเลือกจุดตรวจต่อ แต่ยังต้องอ่านตาม protocol กับ module ที่ใช้ ไม่ตีความทุก metric เป็นเวลาของการเปิดหน้าเต็มแบบเครื่องมือวัดประสบการณ์ผู้ใช้

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

ส่วน endpoint ที่ให้สั่ง probe ก็ควรจำกัดการเข้าถึงกับขอบเขตเป้าหมายตามการติดตั้ง ไม่เปิดให้ใครสั่งเครื่องภายในไปติดต่อปลายทางใดก็ได้โดยไม่ดูสิทธิ์ เพราะตัวตรวจเองมีเส้นทางเครือข่ายที่ต้องได้รับการดูแลเหมือนบริการอื่น

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

สรุป

Blackbox Exporter ช่วยเพิ่มมุมมองจากทางเข้าที่ผู้ใช้ต้องผ่าน แต่ผลจะมีความหมายเมื่อเลือกจุดตรวจ protocol และเงื่อนไขผ่านให้ตรงงาน เมื่อแยกสุขภาพของ exporter ออกจาก target และใช้ข้อมูลภายในประกอบ เราจะรู้ว่ากำลังยืนยันส่วนใดของประสบการณ์จริง โดยไม่ใช้สถานะ container หรือ HTTP หนึ่งตัวแทนทั้งระบบครับ