🥇DIY: як мы аўтаматызуем маніторынг склада

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

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

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

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

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

Каб зэканоміць час мэнэджараў, мы прынялі рашэнне распрацаваць недарагую сістэму аператыўнага кантролю падзей склада. Новая сістэма, акрамя адлюстравання "гарачых" паказчыкаў аператыўнай працы складскіх працэсаў, павінна таксама дапамагчы менеджэрам у фіксацыі інцыдэнтаў і кантролі выканання задач па ўстараненню прычын, якія ўплываюць на зададзеныя паказчыкі. Правёўшы агульны аўдыт ІТ-архітэктуры кампаніі, мы зразумелі, што асобныя часткі патрабаванай сістэмы ўжо так ці інакш існуюць у нашым ландшафце і для іх ёсць як экспертыза налад, так і неабходныя службы падтрымкі. Засталося толькі звесці ўвесь канцэпт у адзінае архітэктурнае рашэнне і ацаніць аб'ём распрацовак.

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

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

На першым этапе сістэма павінна збіраць з усіх 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 для кіравання прыёмкай:

МС на прыёмцы, усе, якія прыбылі: Усе МС са статусамі за перыяд «- 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: як мы аўтаматызуем маніторынг склада

Налады

Дадаць каментар Адмяніць адказ