DIY: как мы автоматизируем мониторинг склада

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



Как правило, построение систем мониторинга и управления бизнес-процессами начинают с обработки сообщений и инцидентов. При этом упускается важный технологический момент, связанный с возможностью автоматизации самого факта возникновения бизнес-событий и регистрации инцидентов. Большинство бизнес-систем класса WMS, TMS и др., имеют встроенные средства мониторинга собственных процессов. Но, если это системы разных производителей или функционал мониторинга недостаточно развит, приходится заказывать дорогостоящие доработки или привлекать специализированных консультантов для дополнительных настроек.

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

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



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

Чтобы сэкономить время менеджеров, мы приняли решение разработать недорогую систему оперативного контроля событий склада. Новая система, кроме отображения «горячих» показателей оперативной работы складских процессов, должна также помочь менеджерам в фиксации инцидентов и контроле выполнения задач по устранению причин, которые влияют на заданные показатели. Проведя общий аудит ИТ-архитектуры компании, мы поняли, что отдельные части требуемой системы уже так или иначе существуют в нашем ландшафте и для них есть как экспертиза настроек, так и необходимые службы поддержки. Осталось только свести весь концепт в единое архитектурное решение и оценить объём разработок.

После оценки объёма работ, который необходимо выполнить для построения новой системы, было решено разбить проект на несколько этапов:

1. Сбор показателей по процессам склада, визуализация и контроль показателей и отклонений
2. Автоматизация нормативов по процессам и регистрация заявок в службе бизнес-сервисов по отклонениям
3. Проактивный мониторинг с прогнозированием нагрузки и создание рекомендаций менеджерам.

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



При выборе варианта подходящей системы для пилотной реализации первого этапа остановились на Zabbix. Эта система уже используется для мониторинга ИТ показателей складских систем. Добавив отдельную инсталляцию для сбора бизнес-метрик работы склада, можно получить общую картину здоровья склада.

Общая архитектура системы получилась как на рисунке.



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

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

Для отображения графиков и показателей склада на центральном сервере Zabbix разворачиваем Grafana. Кроме вывода подготовленных дэшбордов с инфографикой работы склада, Grafana будет использоваться для контроля отклонений показателей и передачи автоматических алертов в систему сервисной службы склада для работы с бизнес-инцидентами.

В качестве примера, рассмотрим реализацию контроля загрузки зоны приёмки склада. В качестве основных показателей работы процессов на этом участке склада выбрали:

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

Настройки

Установка и настройка основных компонентов системы (SQLcl, Zabbix, Grafana) описана в разных источниках и здесь не будем повторяться. Использование SQLcl вместо SQLplus связано с тем, что SQLcl (интерфейс командной строки СУБД Oracle, написанный на java) не требует дополнительной установки Oracle Client и работает «из коробки».

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

Главное, что при реализации подобной системы возможно обойтись без программирования, используя возможности настроек, предоставляемых системой.

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

В качестве «подопытных» для отладки и настройки системы используем рабочие таблицы WMS для управления приёмкой:

1. ТС на приёмке, все, которые прибыли: Все ТС со статусами за период "- 72 часа от текущего времени" — идентификатор SQL запроса: getCars.
2. История всех статусов ТС: Статусы всех ТС с приходом за 72 часа — идентификатор SQL запроса: carsHistory.
3. Запланированные ТС на приемку: Статусы всех ТС с приходом в статусе «Запланирована», интервал времени "- 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 или простая отправка уведомлений менеджеру по электронной почте.