Направи си сам: как автоматизираме наблюдението на склада

X5 управлява 43 дистрибуторски центъра и 4 собствени камиона, осигурявайки непрекъсната доставка на продукти до 029 15 магазина. В тази статия ще споделя опита си от създаването на интерактивна система за наблюдение на складови събития от нулата. Информацията ще бъде полезна за логистиците на търговски компании с няколко десетки дистрибуторски центрове, управляващи широка гама от продукти.

По правило изграждането на системи за мониторинг и управление на бизнес процеси започва с обработка на съобщения и инциденти. В същото време се пропуска важен технологичен момент, свързан с възможността за автоматизиране на самия факт на възникване на бизнес събития и записване на инциденти. Повечето бизнес системи като WMS, TMS и др., имат вградени инструменти за наблюдение на собствените процеси. Но ако това са системи от различни производители или функционалността за наблюдение не е достатъчно развита, трябва да поръчате скъпи модификации или да привлечете специализирани консултанти за допълнителни настройки.

Нека разгледаме подход, при който се нуждаем само от малка част от консултирането, свързано с идентифициране на източници (таблици), за да получим индикатори от системата.

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

За да формират обща картина на процесите, протичащи в склада, мениджърите анализират отчитането на всяка WMS няколко пъти на ден, обработват съобщения от складови оператори (получатели, пикери, стекери) и обобщават действителните оперативни показатели за отразяване на информационното табло.

За да спестим време на мениджърите, решихме да разработим евтина система за оперативен контрол на събитията в склада. Новата система, в допълнение към показването на „горещи“ индикатори за оперативното представяне на складовите процеси, трябва също да помогне на мениджърите при записване на инциденти и наблюдение на изпълнението на задачите за отстраняване на причините, които влияят на дадените показатели. След като извършихме общ одит на ИТ архитектурата на компанията, разбрахме, че отделни части от необходимата система вече съществуват по един или друг начин в нашия пейзаж и за тях има както проверка на настройките, така и необходимите услуги за поддръжка. Остава само да се обедини цялата концепция в едно архитектурно решение и да се оцени обхватът на развитие.

След оценка на обема работа, която трябва да се извърши за изграждането на нова система, беше решено проектът да се раздели на няколко етапа:

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

На първия етап системата трябва да събере подготвени срезове оперативни данни от всички WMS на комплекса. Четенето се извършва почти в реално време (интервали от по-малко от 5 минути). Номерът е, че данните трябва да бъдат получени от СУБД на няколко десетки складове, когато системата се разгръща в цялата мрежа. Получените оперативни данни се обработват от логиката на ядрото на системата за изчисляване на отклонения от планираните показатели и изчисляване на статистика. Обработените по този начин данни трябва да се показват на таблета на мениджъра или на информационното табло на склада под формата на разбираеми графики и диаграми.

Когато избирахме подходяща система за пилотно внедряване на първия етап, избрахме Zabbix. Тази система вече се използва за наблюдение на ИТ производителността на складови системи. Чрез добавяне на отделна инсталация за събиране на бизнес показатели за работата на склада, можете да получите цялостна картина на здравето на склада.

Общата архитектура на системата се оказа, както е на фигурата.

Всеки екземпляр на WMS се определя като хост за системата за мониторинг. Метриките се събират от централен сървър в мрежата на центъра за данни чрез изпълнение на скрипт с подготвена SQL заявка. Ако трябва да наблюдавате система, която не препоръчва директен достъп до базата данни (например SAP EWM), можете да използвате извиквания на скрипт към документирани API функции, за да получите индикатори или да напишете проста програма в python/vbascript.

Екземпляр на Zabbix прокси е разположен в складовата мрежа, за да разпредели натоварването от главния сървър. Чрез Proxy е осигурена работа с всички локални WMS инстанции. Следващият път, когато Zabbix сървърът поиска параметри, се изпълнява скрипт на хоста със Zabbix прокси, за да поиска показатели от WMS базата данни.

За да показваме графики и индикатори за складове на централния Zabbix сървър, внедряваме Grafana. Освен за показване на подготвени табла с инфографика на складовата дейност, Grafana ще се използва за следене на отклонения в показателите и изпращане на автоматични сигнали към системата за складово обслужване за работа с бизнес инциденти.

Като пример, нека разгледаме внедряването на контрол на натоварването в зоната за получаване на склада. Следните бяха избрани като основни показатели за ефективност на процеса в тази зона на склада:

• брой превозни средства в рецепцията, като се вземат предвид статусите (планирани, пристигнали, документи, разтоварване, заминаване);
• натоварване на зоните за поставяне и попълване (според условията на съхранение).

Настройки

Инсталирането и конфигурирането на основните компоненти на системата (SQLcl, Zabbix, Grafana) е описано в различни източници и няма да се повтаря тук. Използването на SQLcl вместо SQLplus се дължи на факта, че SQLcl (интерфейсът на командния ред на Oracle DBMS, написан на java) не изисква допълнителна инсталация на Oracle Client и работи извън кутията.

Ще опиша основните моменти, на които трябва да се обърне внимание при използване на Zabbix за наблюдение на индикатори на складови бизнес процеси и един от възможните начини за тяхното прилагане. Също така, това не е публикация за сигурност. Сигурността на връзките и използването на представените методи изисква допълнително проучване в процеса на прехвърляне на пилотното решение в продуктивна експлоатация.

Основното е, че при внедряването на такава система е възможно да се направи без програмиране, като се използват настройките, предоставени от системата.

Системата за наблюдение Zabbix предоставя няколко опции за събиране на показатели от наблюдаваната система. Това може да стане или чрез директно запитване на наблюдавани хостове, или чрез по-усъвършенстван метод за изпращане на данни към сървъра чрез zabbix_sender на хоста, включително методи за конфигуриране на параметри за откриване на ниско ниво. За да разрешим нашия проблем, методът за директно запитване на хостове от централен сървър е доста подходящ, т.к това ви позволява да получите пълен контрол върху последователността на придобиване на показатели и гарантира, че използвате един набор от настройки/скриптове, без да е необходимо да ги разпространявате до всеки наблюдаван хост.

Като „тестови субекти“ за отстраняване на грешки и настройка на системата, ние използваме WMS работен лист за управление на приемането:

1. Превозни средства на рецепция, всички пристигнали: Всички превозни средства със статуси за периода “- 72 часа от текущия час” - идентификатор на SQL заявка: getCars.
2. История на всички състояния на превозни средства: Състояния на всички превозни средства, пристигащи в рамките на 72 часа - идентификатор на SQL заявка: автомобилиИстория.
3. Планирани превозни средства за приемане: Статуси на всички превозни средства с пристигане в статус „Планирано“, времеви интервал „- 24 часа“ и „+24 часа“ от текущото време - идентификатор на SQL заявка: автомобилиIn.

И така, след като сме избрали набор от показатели за ефективност на склада, ще подготвим SQL заявки за WMS базата данни. За да изпълнявате заявки, препоръчително е да използвате не основната база данни, а нейното „горещо“ копие - резервно.

Свързваме се към Oracle DBMS в режим на готовност, за да получаваме данни. 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-прокси (по подразбиране - /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 или просто изпращане на известия до мениджъра по имейл.

Източник: www.habr.com