Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

У документі Webitel Architecture описано всі можливі застосунки Webitel та взаємодію між ними. У поточному документі ми розглянемо основні рекомендації щодо моніторингу та підтримки інфраструктури Webitel.

Ресурси

Вимоги до апаратного комплексу можуть відрізнятися в залежності від застосунків, що запущені на сервері або VM, а також від інтенсивності використання застосунків. Правильна операційна система, що працює на інфраструктурі, має вирішальне значення для забезпечення стабільності всього комплексу застосунків. Раннє виявлення зросту рівня використання ресурсів дозволяє попередити можливі інциденти у майбутньому.

Нижче наведені ключові компоненти та рекомендації щодо моніторингу ресурсів.

База даних

Webitel використовує базу даних PostgreSQL, яка є єдиним сховищем для історичних та оперативних даних для всіх сервісів.

  • CPU - При виконанні складних запитів, база даних максимально використовує час процесора. Моніторинг має слідкувати за тим, щоб навантаження CPU не перевищувало 80% протягом 5 хвилин. Якщо дуже часто спостерігається навантаження 80% і більше, то необхідно залучитися до аналізу запитів або збільшити кількість ядер на сервері.
  • RAM - Великі та складні запити використовують оперативну пам'ять для формування відповіді. Тому необхідно моніторити обсяг зайнятої RAM, щоб він не перевищував 85%. Зверніть увагу, що існують такі поняття, як used memory та cached memory. Cached memory тимчасово використовується і автоматично звільняється. Вам потрібно моніторити саме used memory (це стосується інших сервісів, де йтиметься про моніторинг оперативної пам'яті).
  • Disk - Коли йдеться про диски під базою даних, важливою є затримка читання/запису на диск (disk latency). Повільний диск означає повільну роботу бази даних, і це впливає абсолютно на всі застосунки Webitel. Щодо вільного місця на диску, то більше 90% зайнятого місця є критичним сигналом.

Хорошою практикою є використання реплікації бази даних для роботи з аналітичними звітами (Grafana або іншого зовнішнього сервісу).

Consul и RabbitMQ

Для визначення сервісів та обміну повідомленнями сервіси Webitel використовують Consul та RabbitMQ. Основні критерії моніторингу ресурсів:

  • CPU - Завантаження на кожне ядро CPU не повинно перевищувати 80% довше 1 хвилини.
  • RAM - Об'єм зайнятої RAM не повинен перевищувати 80%.
  • Disk - Як і з базою даних - затримка читання/запису на диск (disk latency) впливає на швидкодію всього комплексу додатків. Важливо не забувати про моніторинг вільного місця на диску, яке ніколи не повинно опускатися нижче 5% від загального обсягу диска або менше 5 ГБ.

Телефонія 

Для роботи сервісів телефонії Webitel використовує кілька додатків, а саме: OpenSIPS, FreeSWITCH та rtpengine. Для всіх трьох додатків критично важливим є використання процесорного часу.

  • CPU - Якщо завантаження процесора перевищуватиме 60% протягом більше ніж 5 хвилин, то це може негативно відобразитись на якості голосу (металевий звук, спотворення, випадання слів).
  • RAM - Завантаження оперативної пам'яті не повинно перевищувати 80%.
  • Disk - Рівень вільного місця на диску не повинен опускатися нижче 10% від загального об'єму диска.

Записи розмов

Хорошою практикою є використання сховища, сумісного з S3, для запису розмов. Якщо ви використовуєте локальну файлову систему, рекомендується контролювати наявність вільного місця на диску для записів, яке не повинно опускатися нижче 10% від загального обсягу диска.

Сервіси Webitel

Нижче ми наводимо загальні рекомендації для інших сервісів Webitel:

  • CPU - Завантаження на кожне ядро CPU не повинно перевищувати 80% тривалістью більше 5 хвилин.
  • RAM - Завантаження оперативної пам'яті не повинно перевищувати 90%.
  • Disk - Рівень вільного місця на диску не повинен опускатися нижче 10% від загального об'єму диска.

Мережева доступність

Пропускна здатність

Пропускна здатність мережі між серверами, на яких розгорнуті всі сервіси Webitel, повинна бути менше 100 Мбіт/с з середнім значенням пінгу до 10 мс без втрат пакетів.

Для забезпечення стабільної роботи телефонії, між сервером телефонії та постачальником SIP ліній повинен бути забезпечений канал з параметрами, які не перевищують граничні значення:

  • Гарантована пропускна здатність каналу в бік провайдера телефонії не повинна бути менше 10 Мбіт/с (для 30 одночасних дзвінків з використанням G711 кодека);
  • Середнє значення параметра ping до сервера провайдера телефонії не повинно перевищувати 100 мс;
  • Значення параметра Packet Loss до сервера провайдера телефонії не повинно перевищувати 1%;
  • Значення параметра Jitter до сервера провайдера телефонії не повинно перевищувати 50 мс.

В бік користувачів телефонії вимог до гарантованого каналу не повинно бути:

  • не менше 512 кбіт/с на 1 користувача при використанні тільки чатів;
  • не менше 1 Мбіт/с на 1 користувача при використанні чатів і аудіодзвінків;
  • не менше 5 Мбіт/с на 1 користувача при використанні чатів, аудіо та відеодзвінків.

Значення параметра Packet Loss до сервера провайдера телефонії не повинно перевищувати 1%, а затримка не більше 50 мс. Якщо затримка перевищує 100 мс, можуть виникнути проблеми з якістю голосу (викривлення фраз або випадання слів).

Фільтрація трафіку

Усі сервіси Webitel мають вільно спілкуватися між собою. Рекомендується звернутися до документу Webitel Architecture, де описані деталі мережевої взаємодії.

Порти сервісів

У таблиці нижче наведені основні порти, які потрібно моніторити на доступність:

Застосунок

Порти

RabbitMQ5672/tcp

PostgreSQL

5432/tcp
Opensips5060/udp, 5060/tcp, 5061/tcp
Nginx443/tcp
FreeSWITCH5080/udp, 5080/tcp

Consul

8500/tcp

Доступність сервісів

Необхідно перевіряти актуальність SSL-сертифіката для nginx.

Всі сервіси Webitel повинні бути запущені і працювати:

webitel-app webitel-uac webitel-api engine messages-srv messages-bot flow_manager call_center storage freeswitch ngcp-rtpengine-daemon opensips grafana-server nginx\\

Моніторинг телефонії

Доброю практикою є моніторинг протоколів SIP та RTP з використанням Homer. Налаштування описані в статті Моніторинг протоколів SIP та RTP. Це дозволить швидше виявляти проблеми, пов'язані з якістю та доступністю телефонії.



  • No labels