วิธีการตรวจสอบเมตริกของ Jitsi Videobridge ด้วย Prometheus และ Grafana

เมื่อการประชุม Jitsi เริ่มติดขัด ผู้ดูแลระบบอาจเห็นข้อร้องเรียนเกี่ยวกับเสียงกระตุกหรือวิดีโอค้าง แต่ไม่มีวิธีตรวจสอบอย่างรวดเร็วว่าบริดจ์โอเวอร์โหลด เข้าถึงไม่ได้ หรือมีปริมาณการใช้งานมากกว่าปกติหรือไม่ Jitsi Videobridge (JVB) เปิดเผยเมตริกการทำงานที่ Prometheus สามารถรวบรวมและ Grafana สามารถแสดงผลได้ คู่มือนี้จะแนะนำการตั้งค่าที่ใช้งานได้จริง โดยเริ่มจากการตรวจสอบปลายทางในพื้นที่และจบลงด้วยแดชบอร์ดที่คุณสามารถตรวจสอบได้

ตัวอย่างสถานการณ์:ลองนึกภาพองค์กรขนาดเล็กที่ใช้งาน JVB หนึ่งตัวบนโฮสต์ Linux และใช้งาน Prometheus และ Grafana บนโฮสต์เดียวกันนั้น นี่เป็นเพียงตัวอย่างประกอบ ไม่ใช่รายงานการใช้งานจริงหรือการทดสอบ หากบริการของคุณทำงานในคอนเทนเนอร์ที่แยกจากกันหรือบนเซิร์ฟเวอร์ที่แตกต่างกัน ให้แทนที่ที่อยู่ภายในที่สามารถเข้าถึงได้และคงข้อจำกัดเครือข่ายเดิมไว้

สิ่งที่คุณจะติดตาม

เอกสารโครงการ JVB ปัจจุบันอธิบายถึงเอนด์พอยต์ Prometheus/OpenMetrics ในตัว/metricsบนอินเทอร์เฟซ HTTP ส่วนตัวของบริดจ์ โดยแสดงสถิติต่างๆ เช่น การประชุมที่ใช้งานอยู่ เอนด์พอยต์ อัตราบิตขาเข้าและขาออก อัตราแพ็กเก็ต และภาระของบริดจ์ ข้อมูลจาก Prometheus อาจไม่ได้แสดงสถิติทั้งหมดที่มีอยู่ในรูปแบบการรายงานอื่นๆ ของ JVB ดังนั้นให้ถือว่าเอนด์พอยต์ที่ให้บริการโดยเวอร์ชันที่ติดตั้งของคุณเป็นแหล่งข้อมูลที่ถูกต้องที่สุด การกำหนดค่าอ้างอิงในปัจจุบันเปิดใช้งานทรัพยากร REST ของ Prometheus และผูกอินเทอร์เฟซ HTTP ส่วนตัวเข้ากับลูปแบ็ก โดยพอร์ต HTTP ส่วนตัวเริ่มต้นที่ระบุไว้ในเอกสารคือ 8080 แพ็กเกจและเทมเพลตการปรับใช้เวอร์ชันเก่าอาจแตกต่างกันไป

Prometheus จะทำการรวบรวมและจัดเก็บข้อมูลอนุกรมเวลา Grafana จะเชื่อมต่อกับ Prometheus ในฐานะแหล่งข้อมูลและเรียกดูข้อมูลอนุกรมเวลาที่จัดเก็บไว้เหล่านั้น ไม่จำเป็นต้องใช้ Jitsi exporter แยกต่างหากสำหรับเส้นทางเมตริก JVB โดยตรงนี้ โปรดดูเอกสารประกอบเกี่ยวกับสถิติของ Jitsi และจุดเชื่อมต่อ Prometheus การกำหนดค่าอินเทอร์เฟซ HTTP ส่วนตัวและการกำหนดค่าอ้างอิงไฟล์ต้นทางเหล่านี้อาจมีการเปลี่ยนแปลง โปรดตรวจสอบการกำหนดค่าและเวอร์ชันที่ติดตั้งบนบริดจ์ของคุณก่อนที่จะนำค่าตัวอย่างไปใช้

ขั้นตอนที่ 1: ตรวจสอบว่า JVB ให้บริการข้อมูลเมตริกหรือไม่

บนเครื่อง JVB ขั้นแรกให้ระบุการกำหนดค่าที่ใช้งานอยู่ โดยทั่วไปแล้วแพ็กเกจ Debian หรือ Ubuntu จะใช้ไฟล์ `config.js` /etc/jitsi/videobridge/jvb.confแต่ Jitsi ระบุว่าไฟล์จริงคือเส้นทางใดก็ตามที่ส่งไปยังกระบวนการบริดจ์ การใช้งานคอนเทนเนอร์อาจติดตั้งการกำหนดค่าที่สร้างขึ้นแทน อย่าคิดว่าไฟล์ตัวอย่างคือไฟล์ที่บริการที่กำลังทำงานอ่าน

โดยใช้พอร์ตเริ่มต้นและการผูกลูปแบ็กตามตัวอย่าง ให้รันคำสั่งนี้บนโฮสต์ JVB:

curl -fsS http://127.0.0.1:8080/metrics | head

การตอบสนองที่สำเร็จคือข้อความธรรมดาที่มีตระกูลเมตริกของ Prometheus ซึ่งมักจะ มี # HELPบรรทัด# TYPEตามด้วยตัวอย่าง ภาพประกอบแสดงเฉพาะคำสั่งเท่านั้น ไม่ใช่หลักฐานการตอบสนองของเซิร์ฟเวอร์แบบเรียลไทม์ การปฏิเสธการเชื่อมต่อโดยทั่วไปหมายความว่า JVB หยุดทำงาน กำลังฟังอยู่ที่ที่อยู่หรือพอร์ตอื่น หรือการกำหนดค่าที่ติดตั้งไว้ปิดใช้งานตัวรับฟัง HTTP นั้น ข้อผิดพลาด HTTP 404 แสดงว่าเซิร์ฟเวอร์ตอบกลับแล้ว แต่เส้นทางนั้นไม่พร้อมใช้งานในการสร้างหรือการกำหนดค่า API นั้น ตรวจสอบบันทึกของ JVB และการกำหนดค่าของเวอร์ชันที่ติดตั้งไว้ แทนที่จะเปิดใช้งาน API ควบคุม Colibri ที่ไม่เกี่ยวข้องเพียงเพื่อให้เส้นทาง Prometheus ทำงานได้

คุณสามารถตรวจสอบชื่อและประเภทของตัวชี้วัดได้โดยตรงด้วย:

curl -fsS http://127.0.0.1:8080/metrics | grep -E '^(# HELP|# TYPE)' | head -n 40

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

ขั้นตอนที่ 2: รักษาความเป็นส่วนตัวของอินเทอร์เฟซส่วนตัว

เมื่อ Prometheus ทำงานบนโฮสต์เดียวกันกับ JVB ให้เปิดใช้งานอินเทอร์เฟซส่วนตัวไว้127.0.0.1วิธีนี้จะช่วยหลีกเลี่ยงการเปิดตัวรับฟังอีกตัวหนึ่งไปยังเครือข่ายของคุณ ในการตั้งค่าแบบโฮสต์เดียวกันตามสมมติฐานนี้ Prometheus สามารถเข้าถึงเป้าหมาย127.0.0.1:8080ได้โดยตรง

หาก Prometheus ทำงานอยู่ที่อื่น การผูกลูปแบ็กเริ่มต้นของ JVB จะไม่ยอมรับการเชื่อมต่อจากที่นั่น คุณอาจกำหนดค่าตัวรับฟังส่วนตัวให้ผูกกับอินเทอร์เฟซภายในที่ Prometheus สามารถเข้าถึงได้ จากนั้นจำกัดไฟร์วอลล์หรือเครือข่ายคอนเทนเนอร์เพื่อให้เฉพาะโฮสต์ Prometheus เท่านั้นที่สามารถเชื่อมต่อกับพอร์ตส่วนตัวได้ อย่าเปิดพอร์ต 8080 หรือ 8443 ให้กับอินเทอร์เน็ตสาธารณะ: Jitsi ระบุอย่างชัดเจนว่าอินเทอร์เฟซนี้เป็นส่วนตัวและระบุว่าปลายทางของอินเทอร์เฟซนี้ไม่ได้มีไว้สำหรับการเข้าถึงสาธารณะ หากสภาพแวดล้อมต้องการการเข้ารหัสระหว่างการส่ง อินเทอร์เฟซส่วนตัวจะรองรับ TLS เมื่อกำหนดค่าด้วยคีย์สโตร์ หรืออีกทางเลือกหนึ่ง ให้ใช้พร็อกซี TLS ภายในที่มีการควบคุมอย่างเข้มงวด หลีกเลี่ยงการคัดลอกการผูกสาธารณะแบบกว้างๆ เช่น โดย0.0.0.0ไม่มีข้อจำกัดการเข้าถึงที่เกี่ยวข้อง

หลังจากเปลี่ยนการตั้งค่า Listener แล้ว ให้ใช้กลไกการกำหนดค่าที่รองรับในระบบของคุณ และรีสตาร์ทหรือรีโหลด JVB เฉพาะเมื่อจำเป็นตามเวอร์ชันนั้นเท่านั้น การรีสตาร์ทอาจขัดจังหวะการเรียกใช้งานในระบบที่มีบริดจ์เดียว ดังนั้นควรวางแผนกำหนดเวลาให้เหมาะสม ใน Docker ให้แก้ไขไฟล์การกำหนดค่าฝั่งโฮสต์แบบถาวรหรือไฟล์สภาพแวดล้อมที่ใช้สร้าง ไม่ใช่ไฟล์คอนเทนเนอร์ชั่วคราว ตรวจสอบ Listener จากเครื่อง Prometheus curlก่อนดำเนินการต่อ

ขั้นตอนที่ 3: เพิ่มงานดึงข้อมูล (scrape job) ของ Prometheus

เพิ่มงานเก็บข้อมูล (scrape job) ลงในไฟล์การกำหนดค่า Prometheus สำหรับตัวอย่างบนโฮสต์เดียวกัน ส่วนที่เกี่ยวข้องคือ:

scrape_configs:
  - job_name: jitsi-videobridge
    metrics_path: /metrics
    static_configs:
      - targets:
          - 127.0.0.1:8080

การกำหนดค่า Prometheus ใช้scrape_configsและรองรับเป้าหมายแบบคงที่สำหรับการปรับใช้ขนาดเล็กที่กำหนดไว้ หาก JVB อยู่ในคอนเทนเนอร์อื่น127.0.0.1ให้ชี้ไปยังคอนเทนเนอร์ Prometheus เอง ให้ใช้ชื่อบริการและพอร์ตของ JVB บนเครือข่าย Docker ส่วนตัวที่ใช้ร่วมกันแทน สำหรับโฮสต์ระยะไกล ให้ใช้ชื่อหรือที่อยู่ DNS ส่วนตัว และตั้งค่ากฎไฟร์วอลล์ให้แคบลงเอกสารอ้างอิงการกำหนดค่า Prometheusจะอธิบายเกี่ยวกับงานการเก็บข้อมูล เป้าหมาย และการตั้งค่าช่วงเวลา

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

promtool check config /etc/prometheus/prometheus.yml

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

ขั้นตอนที่ 4: เชื่อมต่อ Grafana กับ Prometheus

ใน Grafana ให้เพิ่มแหล่งข้อมูล Prometheus ที่มีอยู่แล้ว และป้อน URL ที่ Grafana สามารถเข้าถึงได้ สำหรับโฮสต์เดียว อาจเป็นกรณีhttp://localhost:9090ที่ Grafana ทำงานโดยตรงบนโฮสต์นั้น แต่ถ้า Grafana ทำงานในคอนเทนเนอร์localhostหมายถึงคอนเทนเนอร์ของ Grafana ไม่ใช่โฮสต์หรือคอนเทนเนอร์ของ Prometheus ให้ใช้ชื่อบริการของ Prometheus บนเครือข่ายที่ใช้ร่วมกัน บันทึกและทดสอบแหล่งข้อมูล คู่มือแหล่งข้อมูล Prometheus ของ Grafana จะอธิบายการตั้งค่าการเชื่อมต่อ และเอกสารประกอบแหล่งข้อมูลจะอธิบายวิธีการที่ Grafana สอบถามข้อมูลจากแบ็กเอนด์เมตริก

เปิด Explore เลือก Prometheus แล้วเรียกใช้คำสั่งup{job="jitsi-videobridge"}นี้ นี่คือการตรวจสอบสถานะการดึงข้อมูลของ Prometheus ไม่ใช่เมตริกของ Jitsi ค่า 1 หมายความว่า Prometheus ดึงข้อมูลจากเป้าหมายได้สำเร็จสำหรับการประเมินปัจจุบัน ค่า 0 หมายความว่าเป้าหมายที่กำหนดค่าไว้ล้มเหลว หากการค้นหาไม่พบชุดข้อมูลใดๆ เลย ให้ยืนยันชื่องาน การโหลดการกำหนดค่าใหม่ การค้นหาเป้าหมาย และช่วงเวลาที่เลือกอย่างถูกต้อง

ขั้นตอนที่ 5: สร้างแดชบอร์ดที่มีประโยชน์และตรวจสอบข้อมูล

เมื่อupระบบทำงานได้อย่างสมบูรณ์แล้ว ให้ใช้ตัวเรียกดูเมตริกของ Grafana Explore หรือตัวเรียกดูนิพจน์ของ Prometheus เพื่อค้นหาซีรี่ส์ JVB ที่เปิดเผยโดยเวอร์ชันของคุณ เริ่มต้นด้วยชุดคำถามเชิงปฏิบัติการเล็กๆ น้อยๆ ก่อน:

• มีการประชุมและจุดเชื่อมต่อที่ใช้งานอยู่กี่แห่ง และจำนวนเหล่านั้นเปลี่ยนแปลงอย่างไรตลอดทั้งวัน?
• อัตราบิต RTP ขาเข้าและขาออก หรืออัตราแพ็กเก็ตมีการเปลี่ยนแปลงหรือไม่ เมื่อปริมาณการประชุมเพิ่มขึ้น?
• ค่าความเค้นของสะพานเพิ่มขึ้นตามจำนวนจุดปลายหรือไม่ หรือว่าค่าความเค้นสูงอยู่แล้วที่ระดับน้ำหนักบรรทุกปานกลาง?
• มีเมตริกเกี่ยวกับเธรด JVM และการเก็บขยะ (garbage collection) หรือไม่ และเมตริกเหล่านี้เปลี่ยนแปลงไปอย่างไรในรายงานการเรียกใช้ฟังก์ชันที่ช้า?

ใช้ชื่อเมตริกและหน่วยที่แสดงโดย/metricsเอนด์พอยต์ของคุณเอง เอกสารอ้างอิงสถิติของ Jitsi อธิบายตัวอย่างเช่นconferences, endpoints, bit_rate_download, bit_rate_upload, และstress_levelในรายการสถิติที่รองรับ แต่เตือนว่าสถิติบางอย่างอาจยังไม่แสดงในรูปแบบ Prometheus ในขณะนี้ อย่าคัดลอกชื่อเหล่านั้นลงในแบบสอบถามจนกว่าคุณจะยืนยันว่าตระกูล Prometheus มีอยู่ในบิลด์ของคุณ สำหรับตัวนับสะสม ให้ใช้ฟังก์ชัน PromQL เช่นrate()ในช่วง สำหรับมาตรวัดแบบทันที เช่น จำนวนการประชุมปัจจุบัน ให้แสดงค่าที่สุ่มมาโดยตรง รักษาหน่วยที่ระบุไว้เมื่อติดป้ายกำกับแผง เนื่องจากฟิลด์บิตเรตและอัตราแพ็กเก็ตใช้หน่วยที่แตกต่างกัน

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

ตรวจสอบการตั้งค่าที่เสร็จสมบูรณ์

ดำเนินการตามลำดับนี้จากง่ายที่สุดไปจนถึงซับซ้อนที่สุด:

1. บนโฮสต์ JVB ให้ร้องขอhttp://127.0.0.1:8080/metricsและยืนยันว่าการตอบกลับมีข้อความเมตริกอยู่ด้วย
2. จากโฮสต์หรือคอนเทนเนอร์ Prometheus ให้ร้องขอไปยังเอนด์พอยต์เดียวกันโดยใช้ที่อยู่ส่วนตัวที่กำหนดค่าไว้ การเข้าถึงสำเร็จในเครื่องไม่ได้หมายความว่าสามารถเข้าถึงได้จากระยะไกล
3. ในมุมมองเป้าหมายของ Prometheus ให้ตรวจสอบว่าjitsi-videobridgeเป้าหมายทำงานอยู่หรือไม่ และตรวจสอบข้อผิดพลาดในการสแกนครั้งล่าสุดหากเป้าหมายหยุดทำงาน
4. ใน Grafana Explore ให้ตรวจสอบว่าup{job="jitsi-videobridge"}ได้ผลลัพธ์เป็น 1 จากนั้นให้สอบถามชื่อเมตริก JVB หนึ่งชื่อที่คัดลอกมาจากเอนด์พอยต์จริง
5. เปิดแดชบอร์ดในช่วงเวลาที่ครอบคลุมช่วงเวลาการเก็บรวบรวมข้อมูลหลายช่วง และตรวจสอบว่าหน่วย ป้ายกำกับ และการประทับเวลาถูกต้องหรือไม่

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

การกำหนดค่านี้เป็นไปตามเอกสารต้นฉบับของ Jitsi, Prometheus และ Grafana ที่ตรวจสอบเมื่อวันที่ 6 ตุลาคม 2026 เนื่องจากรูปแบบการกำหนดค่าอ้างอิงของ Jitsi และหน้าจอ Grafana มีการเปลี่ยนแปลงอยู่เสมอ โปรดเปรียบเทียบตัวอย่างกับเอกสารและไฟล์สำหรับเวอร์ชันที่คุณใช้งานอยู่