ทำไมเราจึงมีความผันผวนสูงในการวัดแบนด์วิดธ์ Cacti กราฟ?

เราทำการทดสอบความซ้ำซ้อนของ Etherchannel และ Routing บนเครือข่ายของเรา ในระหว่างการแทรกแซงนี้เราทำการวัด เครื่องมือตรวจสอบของเราคือ Cacti สำหรับกราฟ อุปกรณ์ที่ตรวจสอบคือ 4500-X บน VSS แต่ละลิงก์อยู่บนโครงเครื่องจริง

สคีมา:

ทดสอบลำดับเหตุการณ์:
[t0] ลิงก์บนพอร์ต te1 / 1/14 ถูกลบออกทางร่างกาย Te2 / 1/14 เปิดใช้งานอยู่ Po1 ทำงานอยู่
[t0 + 15] ลิงก์บนพอร์ต Te1 / 1/14 กลับสู่บริการและตรวจสอบว่าพอร์ตนั้นกลับมาใน etherchannel Po1
[t0 + 20] ลิงก์ในพอร์ต te1 / 1/14 ถูกลบออกทางร่างกาย Te2 / 1/14 เปิดใช้งานอยู่ Po1 ทำงานอยู่
[t0 + 35] ลิงก์บนพอร์ต Te1 / 1/14 กลับสู่บริการและตรวจสอบว่าพอร์ตนั้นกลับมาใน etherchannel Po1

ในการทดสอบของเราเราตรวจสอบปริมาณการใช้ etherchannel Po1 ผ่าน Cacti (กราฟด้านล่าง) และสังเกตเห็นการเปลี่ยนแปลงที่สำคัญในมูลค่าของการไหลเมื่อเราปิดการใช้งานลิงก์ te1 / 1/14 (ลิงค์สินทรัพย์ te2 / 1/14) ค่อนข้างเสถียรในช่วงย้อนกลับ . เราตรวจสอบเคาน์เตอร์ของ int Po1 มากเกินไปและสิ่งเหล่านี้ก็ค่อนข้างคงที่

สองอินเตอร์เฟสของ 10G รวมอยู่ใน Etherchannels ด้วย LACP ที่ตั้งค่าไว้ ข้างใน etherchannel พวกมันคือ vlans 2 อัน หนึ่งสำหรับการรับส่งข้อมูลแบบหลายผู้รับและอีกหนึ่งสำหรับอินเทอร์เน็ต / การรับส่งข้อมูลทั้งหมด

คุณรู้สาเหตุที่เป็นไปได้ของพฤติกรรมนี้หรือไม่?

เพื่อขยายความคิดเห็นของ ytti

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

ด้านอุปกรณ์:

• ตัวเลือกที่ไม่ถูกต้องของเคาน์เตอร์ถ้าคุณใช้เคาน์เตอร์ 32- บิตพวกเขาสามารถพลิกทุก ๆ 3.4 วินาทีหากคุณใช้อินเตอร์เฟส 10g ที่อัตราสาย
• การอัพเดตตัวนับอุปกรณ์ขนาดใหญ่จำนวนมากจะอัพเดตตัวนับเพียงสองหรือสามครั้งต่อนาทีเท่านั้นและไม่สามารถเชื่อใจได้ว่าจะซิงค์ ทุก ๆ 30 วินาทีนั้นน้อยเท่าที่ฉันจะรบกวนการเลือกตั้งและถึงอย่างนั้นฉันก็อยากได้อย่างน้อยสองจุดก่อนที่จะเริ่มการแจ้งเตือนหรือดำเนินการใด ๆ
• อาจมี gotcha เนื่องจากแพ็กเก็ตที่ส่งสำหรับการประมวลผล CPU (อาจเป็น netflow) อาจถูกนับทันทีเมื่อเทียบกับที่ไม่ได้รับแบตช์ RE (ถูกเห็นบน Juniper MX)

ด้าน Poller:

• โพลเป็นหน่วยเลือกตั้งอย่างถูกต้องในช่วงเวลาหรือไม่และถ้าไม่ฉีดผลลัพธ์ด้วยเวลาหน่วยเลือกตั้งจริง (เช่น x บิตในหน่วย yz วินาที) เพื่อให้สามารถคำนวณอัตราที่เหมาะสมได้
• จะเกิดอะไรขึ้นเมื่อรีเซ็ตตัวนับหรือ SNMP GET ไม่ตอบสนองเครื่องมือต่าง ๆ ตอบสนองสิ่งเหล่านี้ในวิธีที่ต่างกัน

ปัญหาของคุณเป็นเช่นนั้นการสุ่มตัวอย่างเราเตอร์ของคุณและการลงคะแนนเลือกตั้งของคุณเองไม่ได้กระทบกับช่วงเวลาเดียวกัน นั่นคือแม้ว่าช่วงเวลาการสำรวจเป็นแบบคงที่ แต่ช่วงเวลาการสำรวจมีจำนวนตัวอย่างที่แตกต่างกันซึ่งคณิตศาสตร์ของคุณไม่ได้คำนึงถึง
พิจารณาว่าคุณได้สำรวจถึง t1, t2, t3 แล้ว แต่เราเตอร์ไม่ได้ทดลองอะไรเลยที่ช่วงเวลา t1, t2 ดังนั้นการรับส่งข้อมูลทั้งหมดระหว่าง t1, t3 จึงสิ้นสุดที่ t2, t3 ทำให้อัตราของคุณเป็น 0 ที่ t1, t2 และมากกว่า linerate ที่ t2, t3

ตอนนี้ฉันจะแนะนำวิธีแก้ปัญหาหนึ่ง แต่โปรดยืนยันกับคนที่มีความเข้าใจคร่าวๆของคณิตศาสตร์

หาอินเทอร์เฟซที่คุณสนใจก่อน (ถ้า ge-1/1/1):

snmpbulkwalk SWITCH ifDescr | grep ge-1/1/1

จากนั้นคุณจะเห็นหมายเลข ifIndex ของมันสมมติว่าเป็น '42'

จากนั้นทำสิ่งที่ชอบ:

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

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

จากนั้นส่วนที่เราต้องการคณิตศาสตร์ แต่ฉันขอแนะนำวิธีแก้ปัญหาไร้เดียงสาอย่างหนึ่ง

หากช่วงเวลาการอัปเดตของคุณคือ 10 วินาทีให้ทำโพลสำรวจความคิดเห็นทุก 5 วินาทีนั่นคือสองครั้งบ่อยเท่าที่มีการอัพเดท จากนั้นตัวอย่างของคุณจะเป็น

t0, t5, t10, t15, t20, t25, t30

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

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

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

จากนั้นคุณจะพล็อต s1, s2, s3 และคุณควรได้ผลลัพธ์ที่ราบรื่น / แม่นยำมากกว่าสิ่งที่คุณเห็นในตอนนี้

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

เนื่องจากคุณกำลังโพลในอัตราเดียวกับตัวนับที่อัปเดตคุณจึงไม่น่าจะซิงค์กัน

โดยการกำหนดค่า

snmp-server hc poll <<hundredths of a second>>

คุณสามารถลดช่วงเวลาที่ตัวนับ SNMP ได้รับการอัปเดตเป็น 1 วินาที สิ่งนี้จะทำให้ได้ค่าที่ถูกต้องมากขึ้นสำหรับปริมาณงานเมื่อคุณทำการสำรวจทุก ๆ 10 วินาที

FYI นี่เป็นคำสั่งที่ซ่อนอยู่