🥇DIY: як ми автоматизуємо моніторинг складу ProHoster

Під управлінням Х5 знаходиться 43 розподільні центри та 4 029 власних вантажних автомобілів, вони забезпечують безперебійне постачання продуктів до 15 752 магазинів. У статті поділюсь досвідом створення з нуля інтерактивної системи моніторингу подій складу. Інформація буде корисна логістам торгових компаній із кількома десятками розподільчих центрів, які керують широким товарним асортиментом.

Як правило, побудова систем моніторингу та управління бізнес-процесами починають із обробки повідомлень та інцидентів. При цьому упускається важливий технологічний момент, пов'язаний із можливістю автоматизації самого факту виникнення бізнес-подій та реєстрації інцидентів. Більшість бізнес-систем класу WMS, TMS та ін. мають вбудовані засоби моніторингу власних процесів. Але якщо це системи різних виробників або функціонал моніторингу недостатньо розвинений, доводиться замовляти дорогі доопрацювання або залучати спеціалізованих консультантів для додаткових налаштувань.

Розглянемо підхід, у якому нам знадобиться лише невелика частина консалтингу, що з визначенням джерел (таблиць) щоб одержати показників із системи.

Специфіка наших складів у тому, що у одному логістичному комплексі працює кілька систем управління складом (WMS Exceed). Склади розділені відповідно до категорій зберігання товарів (сухий, алкоголь, заморожування та ін.) не лише логічно. Усередині одного логістичного комплексу розташовано кілька окремих складських будівель, операції на кожному з них управляються своєю WMS.

Для формування загальної картини процесів, що відбуваються на складі, менеджери по кілька разів на день аналізують звітність кожної WMS, обробляють повідомлення операторів складу (приймачі, комплектувальники, штабелери) і зводять фактичні операційні показники для відображення на інформаційній дошці.

Щоб заощадити час менеджерів, ми вирішили розробити недорогу систему оперативного контролю подій складу. Нова система, крім відображення «гарячих» показників оперативної роботи складських процесів, має також допомогти менеджерам у фіксації інцидентів та контролі виконання завдань щодо усунення причин, що впливають на задані показники. Провівши загальний аудит ІТ-архітектури компанії, ми зрозуміли, що окремі частини необхідної системи вже так чи інакше існують у нашому ландшафті і для них є експертиза налаштувань, так і необхідні служби підтримки. Залишилося лише звести весь концепт у єдине архітектурне рішення та оцінити обсяг розробок.

Після оцінки обсягу робіт, який необхідно виконати для побудови нової системи, було вирішено розбити проект на кілька етапів:

Збір показників за процесами складу, візуалізація та контроль показників та відхилень
Автоматизація нормативів щодо процесів та реєстрація заявок у службі бізнес-сервісів щодо відхилень
Проактивний моніторинг з прогнозуванням навантаження та створення рекомендацій менеджерам.

На першому етапі система має збирати з усіх WMS комплексу підготовлені зрізи оперативних даних. Читання відбувається у режимі реального часу (інтервали менше 5 хвилин). Фішка в тому, що дані необхідно отримувати із СУБД кількох десятків складів при розгортанні системи на всю мережу. Отримані оперативні дані обробляються логікою ядра системи обчислення відхилень від запланованих показників і підрахунку статистики. Оброблені в такий спосіб дані необхідно відобразити на планшеті менеджера чи інформаційному табло складу як зрозумілих графіків і діаграм.

При виборі варіанта підходящої системи пілотної реалізації першого етапу зупинилися на Zabbix. Ця система вже використовується для моніторингу ІТ показників складських систем. Додавши окрему інсталяцію для збирання бізнес-метрик роботи складу, можна отримати загальну картину здоров'я складу.

Загальна архітектура системи вийшла як малюнку.

Кожну інстанцію WMS визначено як хост для системи моніторингу. Збір метрик виконується центральним сервером у мережі ЦОД через запуск скрипта з підготовленим запитом SQL. У разі необхідності моніторингу системи, яка не рекомендує прямий доступ до БД (наприклад, SAP EWM) для отримання показників, можна використовувати виклики скриптом документованих API функцій або написати нескладну програму на python/vbascript.

У мережі складу розгортається інстанція Zabbix proxy для розподілу навантаження з основного сервера. Через Proxy забезпечується робота з усіма локальними інстанціями WMS. При черговому запиті параметрів сервером Zabbix на хості з Proxy Zabbix виконується скрипт для запиту метрик з БД WMS.

Для відображення графіків та показників складу на центральному сервері Zabbix розгортаємо Grafana. Окрім виведення підготовлених дешбордів з інфографікою роботи складу, Grafana використовуватиметься для контролю відхилень показників та передачі автоматичних алертів до системи сервісної служби складу для роботи з бізнес-інцидентами.

Як приклад, розглянемо реалізацію контролю завантаження зони приймання складу. Як основні показники роботи процесів на цій ділянці складу вибрали:

кількість транспортних засобів у зоні приймання з урахуванням статусів (заплановано, прибуло, документи, розвантаження, вибуття;
завантаженість зон розміщення та поповнення (за умовами зберігання).

Налаштування

Встановлення та налаштування основних компонентів системи (SQLcl, Zabbix, Grafana) описано у різних джерелах і тут не будемо повторюватися. Використання SQLcl замість SQLplus пов'язане з тим, що SQLcl (інтерфейс командного рядка СУБД Oracle, написаний на java) не вимагає додаткової установки Oracle Client і працює "з коробки".

Опишу основні моменти, яким варто приділити увагу під час використання Zabbix для моніторингу показників бізнес-процесів складу, та один із можливих способів їх реалізації. Також це пост не про безпеку. Безпека підключень та використання представлених методів потребує додаткового опрацювання у процесі переведення пілотного рішення у продуктивну експлуатацію.

Головне, що при реалізації такої системи можна обійтися без програмування, використовуючи можливості налаштувань, що надаються системою.

Система моніторингу Zabbix надає кілька варіантів збирання метрик контрольованої системи. Це можна зробити як безпосереднім опитуванням контрольованих хостів, так і більш просунутим методом відправлення даних на сервер через zabbix_sender хоста, включаючи методи налаштування параметрів низькорівневого виявлення (low-level discovery). Для вирішення нашого завдання цілком підходить метод прямого опитування хостів центральним сервером, т.к. це дозволяє отримати повний контроль за послідовністю отримання метрик та забезпечує використання одного пакета налаштувань/скриптів без необхідності поширювати їх на кожен контрольований хост.

Як «піддослідні» для налагодження та налаштування системи використовуємо робочі таблиці WMS для управління прийманням:

ТЗ на прийманні, всі, що прибули: Всі ТЗ зі статусами за період «- 72 години від поточного часу» - ідентифікатор SQL запиту: getCars.
Історія всіх статусів ТЗ: Статуси всіх ТЗ з приходом за 72 години - ідентифікатор SQL запиту: carsHistory.
Заплановані ТЗ на приймання: Статуси всіх ТЗ з приходом у статусі «Запланована», інтервал часу «- 24 години» та «+24 години» від поточного часу - ідентифікатор SQL запиту: carsIn.

Отже, після того, як ми визначилися з набором метрик роботи складу, підготуємо SQL запити до бази даних WMS. Для виконання запитів бажано використовувати не основну базу даних, а її «гарячу» копію — standby.

Підключаємося до standby СУБД Oracle для отримання даних. IP адреса для підключення до тестової бази 192.168.1.106. Параметри підключення зберігаємо на сервері Zabbix у TNSNames.ORA робочої папки SQLcl:

# cat  /opt/sqlcl/bin/TNSNames.ORA
WH1_1=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.106)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME =  WH1_1)
    )
  )

Це дозволить нам запускати SQL запити до кожного хоста через EZconnect, вказавши лише логін/пароль та ім'я БД:

# sql znew/Zabmon1@WH1_1

Підготовлені SQL запити зберігаємо у робочій папці на сервері Zabbix:

/etc/zabbix/sql

і дозволяємо доступ користувачеві zabbix нашого сервера:

# chown zabbix:zabbix -R /etc/zabbix/sql

Файли із запитами одержують унікальний ідентифікатор-назву для звернення з боку сервера Zabbix. Кожен запит до бази даних через SQLcl повертає кілька параметрів. З урахуванням специфіки Zabbix, який вміє обробляти лише одну метрику у запиті, будемо використовувати додаткові скрипти для аналізу результатів запиту на окремі метрики.

Готуємо основний скрипт, назвемо його wh_Metrics.sh, для виклику SQL запиту до БД, збереження результатів та повернення технічної метрики з показниками успішності отримання даних:

#!/bin/sh 
## настройка окружения</i>
export ORACLE_HOME=/usr/lib/oracle/11.2/client64
export PATH=$PATH:$ORACLE_HOME/bin
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/lib64:/usr/lib:$ORACLE_HOME/bin
export TNS_ADMIN=$ORACLE_HOME/network/admin
export JAVA_HOME=/
alias sql="opt/sqlcl/bin/sql"
## задаём путь к файлу с sql-запросом и параметризованное имя файла
scriptLocation=/etc/zabbix/sql
sqlFile=$scriptLocation/sqlScript_"$2".sql
## задаём путь к файлу для хранения результатов
resultFile=/etc/zabbix/sql/mon_"$1"_main.log
## настраиваем строку подключения к БД
username="$3"
password="$4"
tnsname="$1"
## запрашиваем результат из БД
var=$(sql -s $username/$password@$tnsname < $sqlFile)
## форматируем результат запроса и записываем в файл
echo $var | cut -f5-18 -d " " > $resultFile
## проверяем наличие ошибок
if grep -q ora "$resultFile"; then
    echo null > $resultFile
    echo 0
else
    echo 1
fi

Готовий файл зі скриптом розміщуємо в папці для розміщення зовнішніх скриптів відповідно до установок конфігурації Zabbix-proxy (за замовчуванням — /usr/local/share/zabbix/externalscripts).

Ідентифікація БД, з якої скрипт отримуватиме результати, передаватиметься параметром скрипта. Ідентифікатор бази даних повинен відповідати рядку налаштувань у файлі TNSNames.ORA.

Результат виклику SQL запиту зберігається у файлі виду mon_base_id_main.log, де base_id = ідентифікатор БД, отриманий як параметр скрипта. Поділ файлу результату за ідентифікаторами баз даних передбачено у разі запитів від сервера одночасно до кількох БД. Запит повертає відсортований двовимірний масив значень.

Наступний скрипт, назвемо його getMetrica.sh, потрібен для отримання із файлу з результатом запиту заданої метрики:

#!/bin/sh 
## определяем имя файла с результатом запроса
resultFile=/etc/zabbix/sql/mon_”$1”_main.log
## разбираем массив значений результата средствами скрипта:
## при работе со статусами, запрос возвращает нам двумерный массив (RSLT) в виде 
## {статус1 значение1 статус2 значение2…} разделённых пробелами (значение IFS)
## параметром запроса передаём код статуса и скрипт вернёт значение
IFS=’ ‘
str=$(cat $resultFile)
status_id=null
read –ra RSLT <<< “$str”
for i in “${RSLT[@]}”; do
if [[ “$status_id” == null ]]; then
status_id=”$I"
elif [[ “$status_id” == “$2” ]]; then
echo “$i”
break
else
status_id=null
fi
done

Тепер у нас все готове для налаштування Zabbix та початку моніторингу показників процесів приймання складу.

На кожному вузлі БД встановлений та налаштований Zabbix-агент.

На основному сервері визначаємо всі сервери з Zabbix-проксі. Для налаштувань переходимо наступним шляхом:

Адміністрація → Проксі → Створити проксі

Визначаємо контрольовані хости:

Налаштування → Вузли мережі → Створити вузол мережі

Ім'я хоста має збігатися з ім'ям вузла, яке вказано у конфігураційному файлі агента.

Вказуємо групу для вузла, а також IP-адресу або DNS-ім'я вузла з БД.

Створюємо метрики та вказуємо їх властивості:

Установки → Вузли → 'ім'я вузла' → Елементи даних>Створити елемент даних

1) Створюємо основну метрику для запиту всіх параметрів із БД

Задаємо ім'я елемента даних, вказуємо тип "Зовнішня перевірка". У полі “Ключ” визначаємо скрипт, якому як параметри передаємо ім'я БД Oracle, назву sql-запиту, логін та пароль для підключення до БД. Встановлюємо інтервал поновлення запиту 5 хвилин (300 секунд).

2) Створюємо інші метрики кожному за статусу ТС. Значення цих метрик формуватимуться виходячи з результату перевірки основний метрики.

Задаємо ім'я елемента даних, вказуємо тип "Зовнішня перевірка". У полі "Ключ" визначаємо скрипт, якому як параметри передаємо ім'я БД Oracle і код статусу, значення якого хочемо відстежувати. Встановлюємо інтервал оновлення запиту на 10 секунд більше, ніж основна метрика (310 секунд), щоб результати встигли записатися у файл.

Для коректного отримання метрик важливим є порядок активації перевірок. Для того, щоб не виникло конфліктів при отриманні даних, насамперед активуємо основну метрику GetCarsByStatus із викликом скрипта - wh_Metrics.sh.

Установки → Вузли → 'ім'я вузла' → Елементи даних → Підфільтр “Зовнішні перевірки”. Відзначаємо потрібну перевірку та натискаємо "Активувати".

Далі активуємо інші метрики однією операцією, виділивши їх усі разом:

Тепер Zabbix почав збирати бізнес-метрики складів.

У наступних статтях детальніше розглянемо підключення Grafana та формування інформаційних дешбордів роботи складу для різних категорій користувачів. Також на базі Grafana реалізується контроль відхилень у роботі складу та, залежно від меж та повторюваності відхилень, реєстрація інцидентів у системі сервіс-центру управління складом через API або просте відправлення повідомлень менеджеру електронною поштою.

Джерело: habr.com

DIY: як ми автоматизуємо моніторинг складу

Налаштування

Додати коментар або відгук Скасувати відповідь