Network Streaming Telemetry คืออะไร? ทำไมถึงดีกว่า SNMP?

What is Network Streaming Telemetry? Why It is Better Than SNMP?

— — — — — — — — — — — — — — —
สารบัญเนื้อหาทั้งหมด (My Contents)
— — — — — — — — — — — — — — —

กว่า 30 ปีแล้วที่เราใช้ SNMP ในการ monitor อุปกรณ์ network วันนี้อาจถึงเวลาทำความรู้จักกับสิ่งที่เรียกว่า Streaming Telemetry หรือบางทีเรียก Model-Driven Telemetry ซึ่งอาจพูดได้ว่าเป็นท่าใหม่ของการ monitor network ในยุคใหม่ก็คงจะไม่ผิด แน่นอนว่ามันมาพร้อมกับยุค cloud และ IoT นั่นเอง

โดย Streaming Telemetry หรือ Model-Driven Telemetry คือวิธีการ monitor network ที่ฝั่งอุปกรณ์เป็นฝ่ายส่ง telemetry data แบบ push model ให้กับ NMS แบบใกล้เคียง real-time โดยเราสามารถกำหนดสิ่งที่เราต้องการจะ monitor ได้โดยการ subscribe โดยใช้ YANG model

ฝากคอร์ส Python for Network Automation ผมด้วยครับ

คอร์ส Python for Network Automation (3 วัน)

รู้จักกับ Push/Pull Model ก่อน

ตัวอย่าง Pull Model (SNMP, Syslog หรือ CLI)

→ ใช้ SNMP เพื่อเช็ค Interface Status

NMS: Interface เป็นยังไงบ้าง?
Router: ยังอยู่ดี (Up)
(30 วินาทีผ่านไป)
NMS: Interface เป็นยังไงบ้าง?
Router: ยังอยู่ดี (Up)
(30 วินาทีผ่านไป)
NMS: Interface เป็นยังไงบ้าง?
Router: บินไปแล้ว (Down)
…
…

รูปแบบก็คือ NMS จะคอยถาม ส่วน router ก็จะคอยตอบเป็นช่วง ๆ ไป

ตัวอย่าง Push Model (Telemetry)

→ ใช้ Streaming Telemetry เพื่อเช็ค Memory Usage

Router: ตอนนี้ใช้ memory usage ไป 20%
(30 วินาทีผ่านไป)
Router: ตอนนี้ใช้ memory usage ไป 27%
(30 วินาทีผ่านไป)
Router: ตอนนี้ใช้ memory usage ไป 23%
(30 วินาทีผ่านไป)
…
…

รูปแบบก็คือ router ก็จะคอยบอกสถานะออกมาเป็นช่วง ๆ โดยที่ NMS ไม่ต้องคอยถาม

→ ใช้ Streaming Telemetry เพื่อเช็ค Interface Status

…
Router: ตอนนี้ใช้ interface บินไปแล้ว (Down)
…
…

รูปแบบก็คือ router ก็จะคอยสถานะออกมาก็ต่อเมื่อเกิดเหตุการณ์ใด ๆ ขึ้นโดยที่ NMS ไม่ต้องคอยถาม

Streaming Telemetry ดีกว่า SNMP ยังไง?

รูปจาก Presentation Slide ของ Cisco ในเรื่อง Machine Learning Based Network Fault Management with Streaming Telemetry Data

1. ลดการใช้ CPU บนอุปกรณ์ที่ถูก Monitor ได้เยอะ

สมมุติว่าเรามี monitoring tool หลายตัว เช่น ที่บริษัทเรามีทั้ง Nagios, Zabbix และ SolarWinds ปัญหาก็คือที่ router จะยิ่งมีการใช้ CPU load มากขึ้นเพราะ NMS แต่ละตัวต่างก็พากัน polling เข้ามาตาม interval ของตัวเอง (หากต้องการได้ข้อมูลที่ใกล้เคียงกับคำว่า real-time ยิ่งต้องเพิ่มความถี่ในการ polling มากขึ้น) ซึ่งกระทบกับ performance ของอุปกรณ์มาก

กลับกันถ้าหากเราใช้ streaming telemetry นั้น จำนวนของ monitoring tool ที่มากขึ้นแทบไม่ได้เพิ่ม CPU load บนอุปกรณ์อย่างมีนัยยะเลย เพราะอุปกรณ์เป็นฝ่ายสตรีม data ออกไปให้เอง

2. ใช้เวลาในการ Collect Data น้อย

ข้อนี้ถ้าให้อธิบายอย่างละเอียดคงต้องแยกออกไปอีกบทความเลย เอาเป็นว่าลองดูรูปนี้นะครับ ซึ่งเป็น ifTable ของ OID: .1.3.6.1.2.1.2 (ผมตัด column ส่วนใหญ่ออกไปนะ)

http://www.net-snmp.org/docs/mibs/interfaces.html

ข้อมูลของ interface ถูกจัดอยู่ในรูปของตารางแบบนี้ และ GetBulk request (SNMP polling) ที่ถูกส่งมาจาก monitoring tool จะทำให้ router ต้อง traverse ข้อมูลในตารางทีละ column เพื่อส่งข้อมูลกลับไป (ใครเคยเขียน code ให้นึกถึงการ query ข้อมูลในตาราง)

แต่กับ streaming telemetry มีวิธีการที่เร็วกว่านั้น และจากตัวอย่างที่เค้าทดสอบมาบน Cisco NCS5516 ที่มี interface ทั้งหมด 576 interface

การ collect statistics อย่างพวก interface counter ต่าง ๆ นั้นใช้เวลาไม่ถึง 5 วินาที กลับกันถ้าใช้เป็น SNMP นี่โดนไปราว 22–23 วินาทีเลยทีเดียว

วิธีการสตรีม Telemetry Data จาก Router ออกไป

จากรูปด้านซ้ายคือ Cadence-Driven Telemetry ส่วนด้านขวาคือ Event-Driven Telemetry

1. Cadence-Driven Telemetry (หรือบน subscription เรียก periodic) คือการ stream data ออกไปเป็นจังหวะอย่างต่อเนื่อง ยิ่งเรา set ความถี่มากเท่าไรจะทำให้เราสามารถเห็น pattern (data visualization) ของความเปลี่ยนแปลงได้ใกล้เคียงกับความเป็นจริงมากเท่านั้น
2. Event-Driven Telemetry (หรือบน subscription เรียก on-change) คือถ้ามี event เกิดขึ้นคุณค่อยรายงาน ไม่ต้องมารายงานทุก ๆ 60 วินาที ข้อดีคือเมื่อมี event เกิดขึ้น device จะแจ้งเราทันทีโดยไม่ต้องรอให้ถึงรอบ interval ก่อน ซึ่งเราสามารถเอาไปใช้เป็น trigger ใน automation system ได้ว่าถ้าหากมี interface down ให้ทำอะไรต่อได้ทันที

Transport และการสร้าง Session

ในการสตรีม telemetry data ออกไปนั้น ทางอุปกรณ์ network เองจะสตรีมผ่าน transport protocol ทั้งหมด 3 ตัว ได้แก่

1. TCP (เฉพาะ dial-out mode) โดย router จะทำการสร้าง TCP session ไปยัง collector และสตรีม data ที่ถูกกำหนดบน sensor-group ออกไป
2. gRPC (เฉพาะ dial-in mode) โดย collector จะทำการสร้าง gRPC session ไปยัง router จากนั้น router จะสตรีม data ที่ถูกกำหนดบน sensor-group มาให้ ข้อดีของตัวนี้คือมันรองรับ TLS สำหรับ protect data ด้วยผ่านทาง HTTP version 2
3. UDP (เฉพาะ dial-out mode) เห็นบางแหล่งข้อมูลบอกว่ามี UDP ด้วย แต่ผมยังไม่มีข้อมูลและยังไม่ได้ test นะครับ ถ้ามีโอกาสจะกลับมาแก้ไขให้อีกที

ขยายความ Dial-In และ Dial-Out อีกนิดนึงละกัน ให้นึกภาพว่าคุณ(เป็นอุปกรณ์ network) มีนัดให้สัมภาษณ์สดกับรายการทีวีสักช่องหนึ่ง(เป็น collector/NMS)

• Dial-In คือ รายการทีวีเป็นฝ่ายโทรมาหาคุณ
• Dial-Out คือคุณเป็นฝ่ายโทรไปหารายการทีวี

แต่ทั้งสองแบบก็คือคุณเป็นคนเล่าเรื่องราว(ส่งข้อมูล)ให้กับรายการทีวีเหมือนกัน

Encoding สำหรับ Data Telemetry

อุปกรณ์ network สามารถส่ง telemetry data ด้วย encoding หลัก ๆ คือ

1. GPB (Google Protocol Buffers)

สำหรับ encoding แบบนี้คือ data ทั้งหมดหรือบางส่วนจะอยู่ในรูปของ binary ทำให้ต้องใช้ไฟล์ .proto ในการ decode ข้อมูลด้วย ทีนี้ไอ้ GPB เนี่ยมี 2 แบบ

1.1 Compact GPB encoding = ข้อมูลทั้งหมดเป็น binary ทำให้ต้องใช้ไฟล์ .proto จำนวน 1 ไฟล์สำหรับแต่ละ YANG model ในการ map ข้อมูล แน่นอนว่าอันนี้มีประสิทธิภาพที่สุดในทุกตัว แต่ก็ไม่ human friendly เลย
1.2 Key-value (KV-GPB) encoding = ข้อมูลเป็นลักษณะ key value pair นั่นเอง โดยส่วน key เป็น string แต่ value เป็น binary บางครั้งเรียก self-describing ซึ่งมนุษย์พออ่านแล้วเข้าใจบ้าง เพราะมีการส่ง key ไปด้วย แต่ยังคงต้องใช้ .proto ในการ decode ส่วน value เหมือนเดิมนะ

2. JSON encoding

ข้อมูลทุกอย่างเก็บในรูป JSON นั่นแหละ ทั้ง key และ value เป็น string เลย แน่นอนว่ามัน human friendly ที่สุดแล้ว แต่ก็มีขนาดใหญ่และส่งช้าที่สุด ไม่ต้อง decode อะไรทั้งนั้น

— — — — — — — — — — — — — — —
สารบัญเนื้อหาทั้งหมด (My Contents)
— — — — — — — — — — — — — — —