მონიტორინგი და დაკვირვებადობა
მონიტორინგის სისტემა, რომელიც პასუხობს კითხვას „რატომ“
ვაშენებთ მონიტორინგის პლატფორმას ნულიდან ან ვასწორებთ არსებულს: მეტრიკები, streaming telemetry და flow ანალიტიკა ერთ სურათში, დაშბორდებითა და alert-ებით, რომლებსაც ენდობით.
პრობლემა
დაშბორდები ბევრია, პასუხი — არა
ტიპური სურათი: ათეული გრაფიკი, ასეული alert და მაინც უცნობია, რომელი ლინკი გადაიტვირთა და რომელი კლიენტი დაზარალდა. მიზეზი თითქმის ყოველთვის ერთია — შეგროვების ფენა არასწორ დონეზეა აწყობილი.
- SNMP polling-ის ინტერვალი მოვლენაზე ნელია
- Flow მონაცემები საერთოდ არ გროვდება
- Alert-ები ზღვრებზეა, არა სიმპტომებზე
- დაშბორდი არავის სამუშაო პროცესს არ ემთხვევა
რას ვაწვდით
მონიტორინგის სისტემა, რომელიც პასუხობს კითხვას „რატომ“
შეგროვების არქიტექტურა
SNMP, gNMI და flow — თითოეული იმ ფენაზე, სადაც ის ნამდვილად მუშაობს.
მეტრიკების ბაზა
შენახვის ვადა, cardinality და მასშტაბირება წინასწარ გათვლილი.
დაშბორდები როლების მიხედვით
NOC, ინჟინერი და მენეჯმენტი — სამი განსხვავებული ხედი.
alert-ების წესები
სიმპტომზე დაფუძნებული alert-ები, ესკალაციის მარშრუტიზაციით.
სინთეტიკური შემოწმებები
მომხმარებლის გზის იმიტაცია — HTTP, DNS, ხმა, სტრიმი.
დოკუმენტაცია
რა იზომება, რატომ, და ვინ რეაგირებს.
არქიტექტურა
არქიტექტურა
- 01შეგროვებაpolling + streaming + flow
- SNMP
- gNMI
- NetFlow/IPFIX
- 02დამუშავება
- Telegraf
- Akvorado
- Vector
- 03შენახვადროითი სერიები და flow
- Prometheus
- InfluxDB
- ClickHouse
- 04ვიზუალიზაცია
- Grafana
- Zabbix
- 05Alertმარშრუტიზაცია და ესკალაცია
- Alertmanager
- Telegram
- PagerDuty
საოპერაციო ეკრანები
საოპერაციო ეკრანები
ეს კონკრეტული სისტემები ჯგუფის რეალურ ინფრასტრუქტურაზე მუშაობს — სქრინშოტები დამუშავებულია გამოქვეყნებამდე.
გამტარუნარიანობა და peering რეალურ დროში
თითოეული upstream და თითოეული peering ცალკე იზომება, გლობალური და ლოკალური მიმართულებების გაყოფით. capacity-ისა და peering-ის გადაწყვეტილება სწორედ ამ ხედვიდან მოდის — არა შეგრძნებიდან.
ტრაფიკი წყაროების მიხედვით — flow ანალიტიკა
flow მონაცემები დაჯგუფებულია ASN-ების კატეგორიებად: CDN/OTT, ქართული ISP-ები, ჯგუფის საკუთარი ქსელები და საერთაშორისო ტრანზიტი. ეს არის ის სურათი, რომლითაც წყდება — რომელი cache უნდა შემოვიდეს ქსელში, სად ღირს peering და რა უნდა დარჩეს ფასიან ტრანზიტზე. ეს ერთადერთი ეკრანია, რომელიც განზრახ იკითხება: აქ მხოლოდ აგრეგირებული წილებია, არც ერთი კლიენტი და არც ერთი მისამართი.
ვინ აგზავნის ტრაფიკს — ASN-ების დონეზე
იგივე flow მონაცემები, ოღონდ სახელებით: რომელი CDN და რომელი პლატფორმა აგზავნის ყველაზე მეტს, სად მიდის და რომელი როუტერი ატარებს. სწორედ ეს სია ხდება peering-ისა და cache-ის განთავსების არგუმენტი მოლაპარაკებაზე — Akamai, Fastly, Meta, Google. მოცულობები დაბუნდოვნებულია, სახელები და პროპორციები — არა.
ერთი რუკა — MikroTik, Ubiquiti და Cambium ერთად
მცირე და საშუალო ოპერატორის ქსელი იშვიათად ერთვენდორიანია: MikroTik ბირთვში, Ubiquiti უსადენო ხაზებზე, Cambium წვდომაზე. ეს რუკა თითოეულ ხაზზე იმას აჩვენებს, რაზეც ოპერირება დგას — რამდენი უსადენო კლიენტია სექტორზე, CCQ, ხმაურის ფონი, airMAX ხარისხი და ტევადობა, მანძილი, სიხშირე, Rx/Tx და uptime. ანძის კვების კვანძები იმავე რუკაზეა: აკუმულატორის ძაბვა ჩვენთვის ისეთივე მეტრიკაა, როგორც ტრაფიკი — ღამის ჩავარდნების ნახევარი სწორედ იქ იხსნება.
ქსელის ინვენტარი და მდგომარეობა
130-ზე მეტი მოწყობილობა და ათასობით პორტი ერთ სისტემაში: ხელმისაწვდომობის რუკა, alert-ების ისტორია და შეცდომების მქონე ინტერფეისების ტოპი — GPON/EPON წვდომის ქსელის ჩათვლით, სადაც პრობლემა ჯერ პორტზე ჩანს და მერე აბონენტთან.
ერთი ჩართვა, ერთი გრაფიკი — QoS რეალურ დროში
ასე გამოიყურება კონკრეტული კორპორატიული ჩართვა Zabbix-ში: შემომავალი და გამავალი ტრაფიკი, პიკები, გამოყოფილი სიჩქარის რეალური გამოყენება და ისტორია. სწორედ ეს გრაფიკი პასუხობს კითხვას „არხი ნამდვილად გვიწევს თუ არა“ — და ეს პასუხი კლიენტსაც შეუძლია ნახოს, არა მხოლოდ ჩვენ.
შესაძლებლობები
შესაძლებლობები
თითოეული პუნქტი აღნიშნულია: დადასტურებული პროდაქშენ გამოცდილება თუ საინჟინრო შესაძლებლობა.
ანძის კვება და აკუმულატორები
Provenაკუმულატორის ძაბვა, დენის ხაზი და ტემპერატურა იმავე რუკაზე, სადაც ტრაფიკია. ძაბვის კლება ავარიაზე ადრე ჩანს — და ღამის ჩავარდნების ის ნაწილი, რომელიც სხვაგვარად „აუხსნელია“, სწორედ აქ იხსნება.
- SNMP
- Battery voltage
- Temperature
SNMP polling მასშტაბში
Provenpolling რჩება საბაზისო მექანიზმად პარკის უმეტესობაზე — მრიცხველები, ხელმისაწვდომობა და ინტერფეისების მდგომარეობა.
- SNMP
- Zabbix
- LibreNMS
gNMI streaming telemetry
CapabilityStreaming telemetry ცვლის polling-ს მხოლოდ იქ, სადაც სიხშირე ამას მოითხოვს — დანარჩენში ისინი ერთმანეთს ავსებენ.
- gNMI
- gnmic
- Telegraf
Flow ანალიტიკა
CapabilityNetFlow/IPFIX/sFlow ClickHouse-ზე, peering-ისა და ტრაფიკის ანალიზისთვის.
- Akvorado
- ClickHouse
- IPFIX
Grafana დაშბორდები
Proven- Grafana
- Prometheus
- InfluxDB
Zabbix ინფრასტრუქტურული მონიტორინგი
Proven- Zabbix
- SNMP traps
- Agents
მოწყობილობების ინვენტარი და პორტების მონიტორინგი
Provenქსელის მთელი პარკი და მისი პორტები ერთ სისტემაში — ავტომატური აღმოჩენით, ხელმისაწვდომობის რუკითა და შეცდომების მქონე ინტერფეისების რანჟირებით, GPON/EPON წვდომის ქსელის ჩათვლით.
- LibreNMS
- SNMP
- GPON/EPON
SLO და error budget
CapabilityCapacity პროგნოზირება
Capabilityზრდის ტენდენციები და გაჯერების პროგნოზი ლინკებზე და საცავზე.
ტექნოლოგიური სტეკი
ტექნოლოგიური სტეკი
- მეტრიკები
- PrometheusInfluxDBZabbixLibreNMSVictoriaMetrics
- ტელემეტრია
- gNMIIOS XR telemetryTelegraf
- Flow
- AkvoradoClickHouseNetFlow v9IPFIXsFlow
- ვიზუალიზაცია
- GrafanaZabbix UI
- alerting
- AlertmanagerGrafana AlertsTelegram
თანამშრომლობის მოდელი
თანამშრომლობის მოდელი
პროექტი
ერთჯერადი scope: აუდიტი, მიგრაცია ან დანერგვა ფიქსირებული შედეგით.
რეტეინერი
ყოველთვიური საინჟინრო საათები — სპეციალისტზე წვდომა მოთხოვნისამებრ.
Co-Managed
NetWizard და თქვენი შიდა გუნდი ერთად, გაყოფილი პასუხისმგებლობით.
ხშირი კითხვები
ხშირი კითხვები
Zabbix თუ Prometheus?
ორივე — სხვადასხვა ამოცანისთვის. Zabbix ძლიერია აღჭურვილობის და agent-ული მონიტორინგისთვის, Prometheus — დინამიური, კონტეინერიზებული გარემოსთვის. ხშირად ორივე ერთად დგას Grafana-ს ქვეშ.
რამდენ ხანს ინახება მონაცემები?
შენახვის ვადა განისაზღვრება ბიუჯეტისა და მოთხოვნის მიხედვით — მაღალი გარჩევადობა მოკლე ვადით, აგრეგირებული მონაცემები გრძელვადიანად.