Dashboard นี้ช่วยตอบคำถามอะไรให้คนดู

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

ปัญหาจึงอาจไม่ได้อยู่ที่ไม่มีข้อมูลครับ แต่อยู่ที่การจัดลำดับคำถาม ถ้าเอาทุก metric ที่เก็บได้มาวางต่อกัน คนดูยังต้องเป็นผู้รู้ระบบทั้งหมดเองเพื่อแปลว่ากราฟเหล่านั้นเกี่ยวข้องกันอย่างไร

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

หน้าแรกควรตอบว่ากำลังเกิดอะไรกับงาน

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

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

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

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

เลือก panel จากความหมายของข้อมูล

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

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

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

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

ตัวกรองกับช่วงเวลาต้องตามคนดูไปด้วย

ตัวแปรอย่าง environment, service หรือ instance ช่วยใช้หน้าเดียวกับหลายชุดได้ แต่ต้องตรวจว่า panel ทุกอันรับตัวกรองนั้นตามที่ตั้งใจ หากบางช่องยังดู production ขณะที่ส่วนอื่นเป็น UAT คนดูอาจนำข้อมูลคนละระบบมาสรุปร่วมกันโดยไม่รู้ตัว

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

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

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

ข้อมูลหายควรถูกแยกจากค่าที่เป็นศูนย์

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

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

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

ทำทางไล่ให้จบมากกว่าหน้าเดียว

จากภาพรวม อาจมีลิงก์ไปกราฟรายบริการ log หรือรายการ deploy ที่เกี่ยวข้องตามข้อมูลที่เก็บไว้ การเชื่อมเหล่านี้ควรอิงชื่อและเวลาเดียวกัน เพื่อให้คนตามจากอาการไปยังหลักฐานที่ละเอียดขึ้นได้โดยไม่ต้องเดารหัสภายในเอง

แต่ไม่จำเป็นต้องวางทุก panel ไว้หน้าเดียว การแยกหน้าเฉพาะงานช่วยลดทั้งภาระการอ่านและ query ที่ทำพร้อมกัน โดยยังให้คนที่ต้องใช้รายละเอียดเปิดต่อได้ตามเส้นทางที่ตั้งใจ

สิทธิ์เข้าถึงแหล่งข้อมูลก็ควรถูกตรวจตามบทบาทจริง ไม่คิดว่าการซ่อน panel หนึ่งจากหน้าแรกเป็นวิธีจำกัดข้อมูลทั้งหมด หาก Dashboard เชื่อมไป log ที่มีรายละเอียดต่างระดับ ก็ควรมีสิทธิ์ของปลายทางรองรับด้วย

ลองให้คนใช้ทำโจทย์จริงจากหน้าเดียวกัน

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

เก็บ query และการตั้งค่าที่ดูแลต่อได้ตาม workflow ของทีม หากต้องเปลี่ยน metric ก็จะตาม panel กับ alert ที่พึ่งอยู่ได้ และควรทบทวนหน้าเมื่อบริการหรือคนรับผิดชอบเปลี่ยน ไม่ให้ Dashboard ที่เคยตอบโจทย์กลายเป็นหน้ารวมของเก่าที่ไม่มีใครกล้าแก้

สรุป

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