AI/ML – Як система прогнозує аварії в мереж
Як система прогнозує аварії в мережі ще до появи скарг абонентів
У сучасній мережі провайдера недостатньо просто збирати показники з обладнання. Значно важливіше – вчасно зрозуміти, коли вузол починає працювати нестабільно, навіть якщо він ще не перейшов у аварійний стан.
Саме для цього система використовує п'ять незалежних модулі аналізу:
- MetricPredictor – контролює сервери, комутатори, маршрутизатори, ДБЖ, кліматичне обладнання та інші інженерні системи.
- OnuPredictor – аналізує стан абонентських ONU в мережах GPON/EPON.
- SfpPredictor – відстежує роботу SFP/SFP+ модулів та магістральних оптичних ліній.
- OnuTrafficPredictor – аналізує трафік та пакетну статистику абонентських ONU.
- PortPredictor – контролює трафік, помилки та стан портів комутаторів.
На відміну від класичних систем моніторингу, алгоритми ML реагують не лише на перевищення порогів, а й аналізують тренди, швидкість зміни параметрів та взаємозв'язок між різними показниками. Завдяки цьому система здатна попереджати про проблеми ще до появи аварії або звернення абонентів.
Контроль інженерної інфраструктури
MetricPredictor - Перший модуль відповідає за моніторинг практично всіх системних параметрів обладнання.
Електроживлення та ДБЖ
Система контролює весь ланцюг живлення вузла.
Вона визначає:
- повне зникнення зовнішнього живлення;
- перехід обладнання на акумулятори;
- критичний розряд UPS;
- небезпечні просадки або перенапругу;
- різкі стрибки напруги;
- нестабільність частоти електромережі;
- перевантаження по струму;
- аномальне збільшення споживаної потужності.
Завдяки цьому оператор може заздалегідь побачити проблеми з електроживленням ще до відключення вузла.
Навантаження на обладнання
Система постійно аналізує використання процесора, оперативної пам'яті та накопичувачів.
Виявляються:
- тривале перевантаження CPU;
- різкі стрибки навантаження;
- швидке зростання завантаження процесора;
- нестача оперативної пам'яті;
- заповнення дискової підсистеми.
Важливо, що використовуються гістерезис та аналіз тенденцій, тому система не створює зайвих сповіщень через короткочасні пікові навантаження.
Температура та клімат
Перегрів – одна з найчастіших причин нестабільної роботи обладнання.
Система контролює:
- температуру компонентів;
- швидкість її зростання;
- роботу вентиляторів;
- небезпечну вологість у шафах або серверних.
Окремо визначається ризик термічного розгону, коли навантаження процесора поступово призводить до критичного нагрівання.
Мережеві показники
Для мережевого обладнання аналізуються:
- затримки;
- втрати пакетів;
- CRC-помилки;
- зростання кількості помилок;
- нестабільність бездротового сигналу.
Це дозволяє виявляти деградацію каналів ще до того, як вона стане помітною користувачам.
Контроль стану обладнання
Крім звичайних метрик система також реагує на:
- спрацювання апаратних датчиків;
- відкриття корпусів;
- аварійні сигнали обладнання;
- ситуації, коли обладнання перестало передавати телеметрію.
Навіть відсутність даних розглядається як окрема потенційна проблема.
Аналіз xPON мереж
OnuPredictor - Другий модуль спеціалізується виключно на роботі ONU. Його головна задача – знайти деградацію оптичної лінії ще до того, як абонент почне втрачати зв'язок.
Аналіз оптичного сигналу
Система відстежує:
- поступове погіршення рівня RX;
- нестабільний сигнал;
- сильні коливання потужності;
- різкі просідання RX або TX;
- критично низький рівень прийому.
Замість реакції лише на критичний поріг аналізується історія вимірювань, що дозволяє виявити повільне старіння лінії.
Втрати на оптичній трасі
Окремо розраховуються втрати:
- у напрямку OLT → ONU;
- у напрямку ONU → OLT.
Якщо загасання перевищує допустимі значення або між напрямками виникає значна різниця, система повідомляє про можливі проблеми з волокном, зварками або роз'ємами.
Також контролюється оптичний дисбаланс між показниками ONU та OLT.
Стан лазера ONU
Одним із найкорисніших механізмів є оцінка ресурсу лазера.
Система визначає:
- нестабільне живлення лазера;
- початок деградації;
- природне старіння;
- майже повне вичерпання ресурсу.
Це дозволяє планувати заміну обладнання до його фактичної відмови.
Температура та відстань
Додатково аналізуються:
- перегрів ONU;
- робота при критично низьких температурах;
- надто велика довжина оптичної лінії;
- раптові зміни виміряної дистанції, які можуть свідчити про перемикання або аварійні роботи на трасі.
Моніторинг SFP-модулів
SfpPredictor - Третій модуль призначений для контролю магістральної оптики.
Він підтримує як класичні Ethernet-з'єднання, так і PON-порти.
Система контролює:
- поступове погіршення RX;
- нестабільність сигналу;
- різкі просідання або стрибки потужності;
- критично низький рівень прийому;
- перевищення допустимої потужності передавача;
- температуру SFP;
- напругу живлення;
- деградацію або старіння лазера.
Окремо враховуються особливості PON-модулів, для яких використовуються інші допустимі рівні оптичної потужності.
Моніторинг трафіку та пакетів на ONU
OnuTrafficPredictor - Четвертий модуль контролює навантаження на абонентському порту та якість передачі даних на рівні пакетів, а не лише оптичного сигналу.
Пропускна здатність
Система аналізує вхідний та вихідний трафік абонента:
- аномальне зростання трафіку (можлива ознака компрометації обладнання або DDoS-активності);
- різке падіння трафіку при активному ONU;
- стійке перевищення тарифного навантаження;
- асиметрію між вхідним і вихідним потоком, нетипову для профілю абонента.
Пакетна статистика та помилки
Окремо відстежуються:
- помилки CRC/FCS на абонентському порту;
- колізії та фрагментовані пакети;
- різке зростання частки помилкових пакетів відносно загального трафіку.
Поєднання росту помилок із деградацією оптичного сигналу (дані з OnuPredictor) дозволяє відрізнити проблему лінії від проблеми на боці абонентського обладнання.
Моніторинг трафіку та помилок на портах комутаторів
PortPredictor - П'ятий модуль контролює навантаження та стабільність фізичних і агрегованих портів мережевого обладнання.
Навантаження порту
- наближення до утилізації каналу (насичення порту);
- різкі сплески трафіку (broadcast/multicast storm);
- нетипове для конкретного порту зростання навантаження в порівнянні з історичним профілем.
Помилки та стабільність лінку
- зростання CRC-помилок та колізій;
- втрати пакетів (input/output errors, discards);
- флапи порту (часті переходи up/down);
- нестабільність режиму дуплексу або швидкості з'єднання.
Такий контроль дозволяє виявляти деградацію магістральних та абонентських портів комутаторів ще до масових скарг абонентів на конкретному вузлі.
Інтелектуальні кореляції
Окрім аналізу окремих показників, система вміє зіставляти між собою різні події.
Наприклад:
- якщо одночасно росте температура та навантаження процесора – визначається ризик термічного розгону;
- якщо зникло зовнішнє живлення, а акумулятор UPS майже розрядився – система прогнозує неминуче вимкнення вузла;
- якщо одночасно спостерігається деградація напруги та перегрів – це може свідчити про несправність блоку живлення, а не про зовнішні проблеми з електромережею.
Подібні сценарії значно скорочують кількість хибних спрацювань і допомагають оператору швидше знайти реальну причину несправності.
У сукупності MetricPredictor, OnuPredictor та SfpPredictor формують систему раннього виявлення несправностей, орієнтовану на практичні потреби інтернет-провайдерів. Вона не обмежується контролем порогових значень, а аналізує динаміку показників, історію вимірювань і взаємозв'язок між різними метриками. Це дозволяє виявляти деградацію обладнання, проблеми з електроживленням, оптичними лініями, кліматичними умовами та мережевою інфраструктурою ще до того, як вони вплинуть на якість послуг або призведуть до аварійного відключення.
Спосіб запуску навчання та аналізу через CLI
sudo -u www-data php artisan ml:analyze-metrics
sudo -u www-data php artisan ml:analyze-onu
sudo -u www-data php artisan ml:analyze-sfp
sudo -u www-data php artisan ml:analyze-ports
sudo -u www-data php artisan ml:analyze-onu-traffic
sudo -u www-data php artisan ml:train-metrics
sudo -u www-data php artisan ml:train-onu
sudo -u www-data php artisan ml:train-sfp
sudo -u www-data php artisan ml:train-ports
sudo -u www-data php artisan ml:train-onu-traffic
Приклад CRON
- тренування раз в тиждень
- аналіз кожні 6 годин для ONU
- аналіз що дві години для SFP
- аналіз щогодини для метрик, для метрик ONU що 2 години
# === Analyze ===
15 * * * * /usr/bin/flock -n /tmp/ml-a-metrics.lock /usr/bin/php /var/www/html/artisan ml:analyze-metrics >> /tmp/analyze-metrics.log 2>&1
25 * * * * /usr/bin/flock -n /tmp/ml-a-ports.lock /usr/bin/php /var/www/html/artisan ml:analyze-ports >> /tmp/analyze-ports.log 2>&1
10 */2 * * * /usr/bin/flock -n /tmp/ml-a-sfp.lock /usr/bin/php /var/www/html/artisan ml:analyze-sfp >> /tmp/analyze-sfp.log 2>&1
50 */2 * * * /usr/bin/flock -n /tmp/ml-a-onutr.lock /usr/bin/php /var/www/html/artisan ml:analyze-onu-traffic >> /tmp/analyze-onu-traffic.log>
40 */6 * * * /usr/bin/flock -n /tmp/ml-a-onu.lock /usr/bin/php /var/www/html/artisan ml:analyze-onu >> /tmp/analyze-onu.log 2>&1
# === Train (рознесено по днях тижня о 01:00) ===
0 1 * * 1 /usr/bin/flock -n /tmp/ml-t-sfp.lock /usr/bin/php /var/www/html/artisan ml:train-sfp >> /tmp/train-sfp.log 2>&1
0 1 * * 2 /usr/bin/flock -n /tmp/ml-t-onu.lock /usr/bin/php /var/www/html/artisan ml:train-onu >> /tmp/train-onu.log 2>&1
0 1 * * 3 /usr/bin/flock -n /tmp/ml-t-metrics.lock /usr/bin/php /var/www/html/artisan ml:train-metrics >> /tmp/train-metrics.log 2>&1
0 1 * * 4 /usr/bin/flock -n /tmp/ml-t-ports.lock /usr/bin/php /var/www/html/artisan ml:train-ports >> /tmp/train-ports.log 2>&1
0 1 * * 5 /usr/bin/flock -n /tmp/ml-t-onutr.lock /usr/bin/php /var/www/html/artisan ml:train-onu-traffic >> /tmp/train-onu-traffic.log 2>&1
# === Прибирання рядів, що більше не звітують ===
0 3 * * 0 /usr/bin/php /var/www/html/artisan ml:purge --days=14 >> /tmp/ml-purge.log 2>&1
Тренування моделей та аналіз даних потребують відповідних обчислювальних ресурсів ЦП та RAM. Будь ласка, забезпечте достатній рівень продуктивності системи для коректного та ефективного виконання зазначених процесів.



No comments to display
No comments to display