SNMP polling თუ streaming telemetry (gNMI) — რომელი, როდის

ორივე მექანიზმი ერთსა და იმავე კითხვას პასუხობს — რას აკეთებს ეს მოწყობილობა ამ წუთში — და ამას საპირისპირო მიმართულებით აკეთებს. SNMP-ის შემთხვევაში კითხვას სვამს კოლექტორი; gNMI-ის შემთხვევაში მოწყობილობა თავად ყვება. არასწორი არჩევანი კონკრეტულად ჯდება: ან access დონეს ახრჩობთ poll ტრაფიკით და მაინც ვერ იჭერთ იმ მოვლენას, რისთვისაც მონიტორინგი აიგო, ან gRPC პაიპლაინს აშენებთ იმ აპარატურისთვის, რომელსაც გამოსადეგი YANG მოდელი საერთოდ არ აქვს.

ქვემოთ აღწერილია ის ლოგიკა, რომლითაც მონიტორინგის ფენას ვგეგმავთ. ეს კომპრომისები ღირს გასაგები იყოს მანამ, სანამ ვინმე შესყიდვას გახსნის.

რას აკეთებს SNMP რეალურად#

SNMP არის request/response პროტოკოლი UDP პორტ 161-ზე. კოლექტორი ითხოვს, აგენტი პასუხობს, და ამ ორს შორის მოწყობილობა თავისით მხოლოდ შეტყობინებას აგზავნის. პრაქტიკულად ოთხი ოპერაცია გვჭირდება:

• GET — ერთი OID, ერთი მნიშვნელობა, ერთი round trip.
• GETNEXT — გადადის ლექსიკოგრაფიულად შემდეგ OID-ზე. თითო მნიშვნელობაზე თითო round trip, სწორედ ამიტომ არის „გულუბრყვილო“ walk ნელი.
• GETBULK (v2c და შემდეგ) — ითხოვს max-repetitions რაოდენობის თანმიმდევრულ მნიშვნელობას ერთ response PDU-ში.
• TRAP / INFORM — აგენტი თავისით უგზავნის შეტყობინებას UDP 162-ს, კითხვის გარეშე: linkDown, bgpBackwardTransition და ყველაფერი, რასაც MIB განსაზღვრავს. trap არის fire-and-forget UDP, რომლის ხელახლა გამოთხოვაც შეუძლებელია; inform კი დასტურდება. ორივე ჩვეულებრივ rate-ლიმიტირებულია მოწყობილობაზე და არცერთი მრიცხველების სერიას არ ატარებს.

რეალური ინტერფეისების walk ასე გამოიყურება:

# 64-ბიტიანი მრიცხველები ifXTable-შია; ifTable-ის 32-ბიტიანი ძალიან სწრაფად გადაივსება
snmpbulkwalk -v2c -c "$COMMUNITY" -Cr25 10.0.0.1 IF-MIB::ifXTable

# ერთი მაღალსიჩქარიანი მრიცხველი — გამოსადეგია, როცა კონკრეტულ პორტს დებაგავთ
snmpget -v3 -l authPriv -u nocpoll -a SHA -A "$AUTHPASS" \
        -x AES -X "$PRIVPASS" 10.0.0.1 IF-MIB::ifHCInOctets.436

ორი დეტალი სისტემატურად კბენს. პირველი: ifIndex არ არის სტაბილური. ბევრ პლატფორმაზე ის ხელახლა ინიშნება ბარათის გადადგმის ან subinterface-ის წაშლის შემდეგ, ანუ ნედლ ინდექსზე მიბმული გრაფიკი უხმაუროდ იწყებს სულ სხვა პორტის ჩვენებას. გასაღებად აიღეთ ifName ან ifAlias და ინდექსი ყოველ discovery-ზე თავიდან ამოხსენით. მეორე: ifTable-ის მრიცხველები 32-ბიტიანია; 10 Gbit/s-ზე 32-ბიტიანი octet მრიცხველი რამდენიმე წამში გადაივსება, ამიტომ Fast Ethernet-ზე მაღლა ifXTable და მისი ifHC* ვარიანტები ერთადერთი გონივრული არჩევანია.

მეორე ნახევარი უსაფრთხოებაა. SNMPv2c არის community string ღია ტექსტით — დასაშვებია მართვის VRF-ში, რომელზეც სხვას წვდომა არ აქვს, და დაუცველია ნებისმიერ სხვა ადგილას. SNMPv3 authPriv რეჟიმში აგენტის ცოტა CPU-ს ჭამს და ამ კამათს საერთოდ ხურავს.

სად წყვეტს polling მასშტაბირებას#

polling-ს სტრუქტურული ზღვარი აქვს: poll ციკლი უნდა დასრულდეს მანამ, სანამ შემდეგი დაიწყება. თუ 400 მოწყობილობას ჰკითხავთ, თითოს 48 პორტით და ათეულამდე სისტემური OID-ით, 60-წამიან ინტერვალზე, კოლექტორს აქვს 60 წამი, რომ დაასრულოს ყველა მოთხოვნა, გაიმეოროს ყველა timeout და ჩაწეროს ყველა მნიშვნელობა. როცა ციკლი გადაფარავს ინტერვალს, თქვენ არ იღებთ შეტყობინებას — იღებთ ხვრელებს გრაფიკში, და ეს ხვრელები ზუსტად ისე გამოიყურება, როგორც ავარია.

აქედან სამი შედეგი გამომდინარეობს:

• დეტალიზაციას აქვს ქვედა ზღვარი. წუთზე ნაკლები ინტერვალი მცირე პარკზე შესაძლებელია და დიდზე — არარეალური. ყველაფერი, რაც ინტერვალზე ხანმოკლეა — microburst, რომელიც egress რიგს ავსებს, ან BGP სესია, რომელიც ჩავარდა და დაბრუნდა — თქვენს მონაცემებში უბრალოდ არ არსებობს.
• დროის ნიშნული კოლექტორისაა, არა მოწყობილობის. ორი ინტერფეისი, რომელიც „12:00:30-ზე გაიზომა“, სინამდვილეში წამებით სხვადასხვა დროს წაიკითხა. მოწყობილობებს შორის rate გამოთვლა ამ jitter-ს მემკვიდრეობით იღებს.
• მდგომარეობის ცვლილება ჩანს მხოლოდ მაშინ, თუ მოწყობილობა trap-ს გამოგზავნის. მეზობელი, რომელიც ერთი ინტერვალის შიგნით ჩავარდა და დაბრუნდა, polling-ის მონაცემებში მხოლოდ მრიცხველის წყვეტას ტოვებს. trap ამ გადასვლას ფარავს, მაგრამ ეს არის ერთი დაუდასტურებელი UDP დატაგრამა სწორედ იმ მომენტში, როცა control plane ყველაზე დატვირთულია — ამიტომ მნიშვნელოვანი გადასვლები ON_CHANGE-ს ეკუთვნის.

რას ცვლის gNMI#

gNMI არის gRPC სერვისი HTTP/2-სა და TLS-ზე, ჩვეულებრივ ვენდორის მიერ არჩეულ პორტზე — მაგალითად 57400 ან 6030. იმის ნაცვლად, რომ განმეორებით იკითხოს, კოლექტორი ხსნის ერთ ხანგრძლივ Subscribe RPC-ს და მოწყობილობა თავად აგზავნის განახლებებს იმ YANG გზებისთვის, რომლებიც მოთხოვნილია.

პრაქტიკული განსხვავებები:

• დროის ნიშნულს მოწყობილობა სვამს. ყოველი განახლება მოდის მოწყობილობის საკუთარი ნანოწამური timestamp-ით, ამიტომ პარკის მასშტაბით კორელაცია აზრიანი ხდება.
• ერთი კავშირი, მრავალი გზა. HTTP/2 მულტიპლექსირების წყალობით ახალი subscription ახალ TCP სესიას არ ამატებს.
• გზები, არა OID-ები. /interfaces/interface[name=Ethernet1]/state/counters/in-octets თავად ხსნის საკუთარ თავს; 1.3.6.1.2.1.31.1.1.1.6.436 — არა.
• on-change შესაძლებელია. მდგომარეობისთვის — BGP სესიის სტატუსი, ინტერფეისის oper-status, ოპტიკის ზღვრები — მოწყობილობა თავად აცნობებს გადასვლას, ნაცვლად იმისა, რომ ორი გაზომვიდან გამოიტანოთ დასკვნა.

Subscription რეჟიმები და მათი ფასი#

Subscribe RPC-ს სამი ზედა დონის რეჟიმი აქვს — ONCE, POLL და STREAM. პრაქტიკულად სასარგებლო STREAM-ია, და მის შიგნით თითოეულ გზას თავისი რეჟიმი აქვს:

სწორედ ON_CHANGE-ის მხარდაჭერაშია იმპლემენტაციები ყველაზე მეტად განსხვავებული. ზოგი პლატფორმა subscription-ს იღებს და შემდეგ ჩუმად შიდა sample სიხშირით აგზავნის; ზოგი გზას პირდაპირ უარყოფს. შეამოწმეთ თითო პლატფორმაზე და თითო პროგრამული ვერსიაზე — არასოდეს ენდოთ datasheet-ს.

მუშა gnmic subscription#

gnmic ყველაზე სწრაფი გზაა იმის დასამტკიცებლად, რომ მოწყობილობა ნამდვილად აკეთებს იმას, რასაც დოკუმენტაცია ჰპირდება:

# ჯერ capabilities: მოდელები, კოდირებები, ვერსიები
gnmic -a 10.0.0.1:57400 -u telemetry -p "$PASS" --skip-verify capabilities

# sample რეჟიმის მრიცხველების ნაკადი, json_ietf კოდირებით
gnmic -a 10.0.0.1:57400 -u telemetry -p "$PASS" --skip-verify \
      -e json_ietf subscribe \
      --path "/interfaces/interface/state/counters" \
      --stream-mode sample --sample-interval 10s

# სესიის მდგომარეობა, მხოლოდ ცვლილებაზე
gnmic -a 10.0.0.1:57400 -u telemetry -p "$PASS" --skip-verify \
      subscribe --path "/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/state/session-state" \
      --stream-mode on-change

--skip-verify ლაბორატორიის ადგილია და სხვაგან არსად; პროდაქშენში კოლექტორი ამოწმებს მოწყობილობის სერტიფიკატს ზუსტად ისე, როგორც ნებისმიერი სხვა TLS კლიენტი.

მუდმივი პაიპლაინისთვის იგივე ინსტრუმენტი მუშაობს დემონად კონფიგურაციის ფაილით და აგზავნის Prometheus-ში, NATS-ში ან Kafka-ში, საიდანაც time series ბაზა კითხულობს. ამისთვის არქიტექტურას ასე ვაწყობთ: gnmic კოლექტორები მოწყობილობებთან ახლოს, შეტყობინებების რიგი ბუფერისთვის, ერთი writer ბაზაში, Grafana ზემოდან. სწორედ რიგი გაძლევთ საშუალებას, ბაზა გადატვირთოთ ფანჯრის დაკარგვის გარეშე.

რომელი სიგნალი სად ეკუთვნის#

გულწრფელი პასუხი ისაა, რომ ქსელების უმეტესობას ორივე სჭირდება, და გაყოფა ბუნებრივად გამოდის:

დატოვეთ SNMP-ზე: გარემოს და ინფრასტრუქტურის აღჭურვილობა (UPS, PDU, კონდიცირება, კარის სენსორები), ოპტიკური მოდულების პარამეტრები ENTITY-SENSOR-MIB-ით იმ პლატფორმებზე, სადაც ტელემეტრიის სტეკი არ არის, ძველი access სვიჩები, მოწყობილობები, რომლებიც მხოლოდ საკუთარ private MIB-ს გასცემენ, და ყველაფერი, სადაც ხუთწუთიანი გაზომვა მართლაც საკმარისია.

გადაიტანეთ gNMI-ზე: BGP და IGP მეზობლების მდგომარეობა, რიგის სიღრმე და drop მრიცხველები, მაღალსიჩქარიანი ინტერფეისების მრიცხველები core-სა და edge-ზე, LSP-ების მდგომარეობა, control-plane CPU დატვირთვის ქვეშ, და ყველაფერი, სადაც საშუალო მნიშვნელობის ნაცვლად თავად გადასვლა გჭირდებათ.

გადამწყვეტი კითხვა არ არის „რომელია თანამედროვე“, არამედ „რა არის ყველაზე მოკლე მოვლენა, რომელიც უნდა დავინახო“. თუ პასუხი თქვენს poll ციკლზე გრძელია, SNMP სავსებით საკმარისია და ოპერირებაშიც იაფია.

მიგრაცია მონიტორინგის ხვრელის გარეშე#

მიგრაცია, რომელიც მუშაობს, მოსაწყენი და გადაფარვითია:

1. აწყობთ gNMI პაიპლაინს არსებული poller-ის გვერდით. არაფერი ითიშება.
2. ჯერ სახელებს ანორმალიზებთ. თანხმდებით, რომ interface_in_octets_total ერთსა და იმავეს ნიშნავს წყაროს მიუხედავად, და ორივეს — SNMP-საც და gNMI-საც — ამ სახელში ასახავთ. დაშბორდები და alert-ის წესები გადართვას ხელუხლებლად გადაიტანენ.
3. ორივეს ერთდროულად ატარებთ სულ მცირე ერთი სრული ცვლილებების ციკლის განმავლობაში და ადარებთ. სადაც სხვაობაა, ტიპური მიზეზებია: მრიცხველის განულების სემანტიკა ბარათის გადატვირთვის შემდეგ, SAMPLE ინტერვალი, რომელიც poll ინტერვალზე მთლიანად არ იყოფა, და ერთეულების შეუსაბამობა.
4. alert-ებს ახალ წყაროზე გადაიტანთ თითო წესით, ძველს კი დადუმებულ სარეზერვოდ ტოვებთ, სანამ ახალს არ ენდობით.
5. მხოლოდ ამის შემდეგ შლით OID-ებს poller-იდან — და მხოლოდ იმათ, რომლებიც ახალმა პაიპლაინმა ნამდვილად ჩაანაცვლა.

რა შეიძლება გატყდეს#

• Cardinality-ის აფეთქება. დიდი შასიდან სრული ინტერფეისების subtree-ის სტრიმინგი გაცილებით მეტ სერიას წარმოქმნის, ვიდრე poller-ს ოდესმე შეექმნა. გაფილტრეთ კოლექტორზე, არა ბაზაში.
• გაწყვეტილი კავშირები. Subscribe RPC ხანგრძლივია, ამიტომ gRPC keepalive და გარკვევით აღწერილი reconnect და re-sync ქცევა უფრო მნიშვნელოვანია, ვიდრე უმდგომარეობო polling-ისთვის.
• Control-plane დატვირთვა. ტელემეტრია უფასო არ არის. ერთწამიანი sample ინტერვალი აგრესიული subtree-ის ყველა leaf-ზე იმავე CPU-ს ეხება, რომელზეც თქვენი მარშრუტიზაციის პროტოკოლები მუშაობს.
• სქემის უხმაურო ცვლილება. პროგრამული განახლება YANG გზას გადაარქმევს ან გადაანაცვლებს და სერია უბრალოდ ჩერდება. გქონდეთ alert მონაცემის არარსებობაზე, არა მხოლოდ ზღვრებზე.
• ნახევრად გადატანილი alert-ები. ყველაზე ცუდი შედეგია alert-ის წესი, რომელიც კითხულობს მეტრიკას, რომელსაც აღარც ერთი პაიპლაინი აღარ წერს. სწორედ ამიტომ არის ზემოთ მე-5 ნაბიჯი ბოლო.

თუ flow მონაცემებს უკვე აგროვებთ, ბუნებრივი შემდეგი ნაბიჯია ამ მრიცხველების პრეფიქსების მიხედვით მოცულობებთან კორელაცია — ეს აღწერილია სტატიაში NetFlow/IPFIX პაიპლაინი Akvorado-სა და ClickHouse-ზე, ხოლო აქედან გამომდინარე ტრაფიკის გადაწყვეტილებები — სტატიაში BGP traffic engineering flow მონაცემებით.