X5 prevádzkuje 43 distribučných centier a 4 029 vlastných nákladných vozidiel, čím zabezpečuje nepretržitú dodávku produktov do 15 752 predajní. V tomto článku sa podelím o svoje skúsenosti s vytvorením interaktívneho systému na monitorovanie skladových udalostí od začiatku. Informácie budú užitočné pre logistov obchodných spoločností s niekoľkými desiatkami distribučných centier spravujúcich širokú škálu produktov.
Konštrukcia systémov monitorovania a riadenia obchodných procesov sa spravidla začína spracovaním správ a incidentov. Zároveň chýba dôležitý technologický bod súvisiaci s možnosťou automatizácie samotnej skutočnosti vzniku obchodných udalostí a evidencie incidentov. Väčšina podnikových systémov ako WMS, TMS atď. má zabudované nástroje na monitorovanie vlastných procesov. Ak však ide o systémy od rôznych výrobcov alebo funkcia monitorovania nie je dostatočne vyvinutá, musíte si objednať drahé úpravy alebo prilákať špecializovaných konzultantov na ďalšie nastavenia.
Uvažujme o prístupe, pri ktorom potrebujeme len malú časť poradenstva spojeného s identifikáciou zdrojov (tabuľky) na získanie ukazovateľov zo systému.
Špecifikom našich skladov je, že na jednom logistickom komplexe funguje viacero systémov skladového hospodárstva (WMS Exceed). Sklady sú rozdelené podľa kategórií skladovania tovaru (suché, liehové, mrazené a pod.) nielen logicky. V rámci jedného logistického komplexu sa nachádza niekoľko samostatných skladových budov, z ktorých každá je riadená vlastným WMS.
Aby si manažéri vytvorili všeobecný obraz o procesoch prebiehajúcich v sklade, niekoľkokrát denne analyzujú reporting každého WMS, spracovávajú správy od skladníkov (prijímačov, vychystávačov, zakladačov) a sumarizujú aktuálne prevádzkové ukazovatele pre reflexiu na informačnej tabuli.
Aby sme manažérom ušetrili čas, rozhodli sme sa vyvinúť lacný systém operatívneho riadenia skladových udalostí. Nový systém by mal okrem zobrazovania „horúcich“ ukazovateľov prevádzkovej výkonnosti skladových procesov pomôcť manažérom aj pri evidencii incidentov a sledovaní plnenia úloh, aby sa odstránili príčiny, ktoré dané ukazovatele ovplyvňujú. Po vykonaní všeobecného auditu IT architektúry spoločnosti sme si uvedomili, že jednotlivé časti požadovaného systému už v našom prostredí tak či onak existujú a existuje pre ne tak kontrola nastavení, ako aj potrebné podporné služby. Ostáva už len dotiahnuť celý koncept do jediného architektonického riešenia a odhadnúť rozsah zástavby.
Po zhodnotení množstva práce, ktorú je potrebné vykonať na vybudovanie nového systému, bolo rozhodnuté rozdeliť projekt do niekoľkých etáp:
- Zber ukazovateľov pre skladové procesy, vizualizácia a kontrola ukazovateľov a odchýlok
- Automatizácia procesných štandardov a evidencia žiadostí v službe obchodných služieb pre odchýlky
- Proaktívny monitoring s prognózovaním záťaže a tvorbou odporúčaní pre manažérov.
V prvej fáze musí systém zozbierať pripravené plátky prevádzkových dát zo všetkých WMS komplexu. Čítanie prebieha takmer v reálnom čase (intervaly menšie ako 5 minút). Trik je v tom, že dáta je potrebné získať z DBMS niekoľkých desiatok skladov pri nasadení systému do celej siete. Prijaté prevádzkové údaje spracováva logika jadra systému na výpočet odchýlok od plánovaných ukazovateľov a výpočet štatistík. Takto spracované údaje je potrebné zobraziť na manažérskom tablete alebo na informačnej tabuli skladu vo forme zrozumiteľných grafov a schém.
Pri výbere vhodného systému pre pilotnú implementáciu prvej etapy sme zvolili Zabbix. Tento systém sa už používa na monitorovanie výkonu IT skladových systémov. Pridaním samostatnej inštalácie na zhromažďovanie obchodných metrík prevádzky skladu môžete získať celkový obraz o stave skladu.
Všeobecná architektúra systému sa ukázala ako na obrázku.
Každá inštancia WMS je definovaná ako hostiteľ pre monitorovací systém. Metriky zbiera centrálny server v sieti dátového centra spustením skriptu s pripraveným SQL dotazom. Ak potrebujete monitorovať systém, ktorý neodporúča priamy prístup k databáze (napríklad SAP EWM), môžete použiť volania skriptov na zdokumentované funkcie API na získanie indikátorov alebo napísať jednoduchý program v jazyku python/vbascript.
Inštancia proxy Zabbix je nasadená v sieti skladu na distribúciu záťaže z hlavného servera. Prostredníctvom Proxy je zabezpečená práca so všetkými lokálnymi WMS inštanciami. Keď si server Zabbix nabudúce vyžiada parametre, na hostiteľovi s proxy serverom Zabbix sa spustí skript, ktorý vyžiada metriky z databázy WMS.
Na zobrazenie grafov a indikátorov skladu na centrálnom serveri Zabbix nasadíme Grafana. Okrem zobrazovania pripravených dashboardov s infografikou skladových prevádzok bude Grafana slúžiť na sledovanie odchýlok ukazovateľov a odosielanie automatických upozornení do systému skladových služieb pre prácu s obchodnými incidentmi.
Ako príklad uvažujme implementáciu kontroly zaťaženia v oblasti príjmu skladu. Ako hlavné ukazovatele výkonnosti procesov v tejto oblasti skladu boli vybrané:
- počet vozidiel v oblasti recepcie, berúc do úvahy stavy (plánované, privezené, doklady, vykládka, odchod;
- pracovná náplň priestorov umiestňovania a doplňovania (podľa podmienok skladovania).
Nastavenie
Inštalácia a konfigurácia hlavných komponentov systému (SQLcl, Zabbix, Grafana) je popísaná v rôznych zdrojoch a nebude sa tu opakovať. Použitie SQLcl namiesto SQLplus je spôsobené tým, že SQLcl (rozhranie príkazového riadka Oracle DBMS, napísané v jazyku Java) nevyžaduje dodatočnú inštaláciu klienta Oracle a funguje hneď po vybalení.
Popíšem hlavné body, ktorým treba venovať pozornosť pri používaní Zabbixu na sledovanie indikátorov obchodného procesu skladu a jeden z možných spôsobov ich implementácie. Toto tiež nie je príspevok o bezpečnosti. Bezpečnosť spojení a využitie prezentovaných metód si vyžaduje ďalšie štúdium v procese prenosu pilotného riešenia do produktívnej prevádzky.
Hlavná vec je, že pri implementácii takéhoto systému je možné urobiť bez programovania pomocou nastavení, ktoré poskytuje systém.
Monitorovací systém Zabbix poskytuje niekoľko možností zberu metrík z monitorovaného systému. Dá sa to urobiť buď priamym dotazovaním monitorovaných hostiteľov, alebo pokročilejšou metódou odosielania údajov na server cez hostiteľský zabbix_sender, vrátane metód na konfiguráciu nízkoúrovňových parametrov zisťovania. Na vyriešenie nášho problému je celkom vhodná metóda priameho dotazovania hostiteľov centrálnym serverom, pretože to vám umožňuje získať plnú kontrolu nad sekvenciou získavania metrík a zaisťuje, že budete používať jednu sadu nastavení/skriptov bez toho, aby ste ich museli distribuovať každému monitorovanému hostiteľovi.
Ako „testovacie subjekty“ na ladenie a nastavenie systému používame WMS pracovný hárok na správu akceptácie:
- Všetky vozidlá na recepcii: Všetky vozidlá so stavom za obdobie „- 72 hodín od aktuálneho času“ - Identifikátor dotazu SQL: getCars.
- História všetkých stavov vozidiel: Stavy všetkých vozidiel prichádzajúcich do 72 hodín - identifikátor SQL dotazu: autáHistória.
- Naplánované vozidlá na prijatie: Stavy všetkých vozidiel s príjazdom v stave „Naplánované“, časový interval „- 24 hodín“ a „+24 hodín“ od aktuálneho času - identifikátor SQL dotazu: carsIn.
Takže potom, čo sme sa rozhodli pre sadu metrík výkonu skladu, pripravíme SQL dotazy pre WMS databázu. Na vykonávanie dotazov sa odporúča použiť nie hlavnú databázu, ale jej „horúcu“ kópiu - pohotovostný režim.
Pripojíme sa k pohotovostnému systému Oracle DBMS, aby sme mohli prijímať údaje. IP adresa na pripojenie k testovacej databáze 192.168.1.106. Parametre pripojenia uložíme na server Zabbix do TNNames.ORA pracovného priečinka 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)
)
)To nám umožní spúšťať SQL dotazy na každého hostiteľa cez EZconnect, pričom uvedieme iba prihlasovacie meno/heslo a názov databázy:
# sql znew/Zabmon1@WH1_1Pripravené SQL dotazy uložíme do pracovného priečinka na serveri Zabbix:
/etc/zabbix/sqla povoliť prístup používateľovi zabbix nášho servera:
# chown zabbix:zabbix -R /etc/zabbix/sqlSúbory s požiadavkami dostanú jedinečný názov identifikátora pre prístup zo servera Zabbix. Každý databázový dotaz cez SQLcl nám vráti niekoľko parametrov. Berúc do úvahy špecifiká Zabbixu, ktorý dokáže spracovať len jednu metriku na požiadavku, použijeme ďalšie skripty na analýzu výsledkov dotazu do jednotlivých metrík.
Pripravme si hlavný skript, nazvime ho wh_Metrics.sh, na zavolanie SQL dotazu do databázy, uloženie výsledkov a vrátenie technickej metriky s indikátormi úspešnosti získania údajov:
#!/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
fiHotový súbor so skriptom umiestnime do priečinka na ukladanie externých skriptov v súlade s konfiguračnými nastaveniami Zabbix-proxy (štandardne - /usr/local/share/zabbix/externalscripts).
Ako parameter skriptu bude odovzdaná identifikácia databázy, z ktorej bude skript prijímať výsledky. ID databázy sa musí zhodovať s riadkom nastavení v súbore TNNames.ORA.
Výsledok volania SQL dotazu sa uloží do súboru ako mon_base_id_main.log kde base_id = Identifikátor databázy prijatý ako parameter skriptu. Rozdelenie výsledného súboru podľa databázových identifikátorov je zabezpečené v prípade požiadaviek zo servera na viacero databáz súčasne. Dotaz vráti zoradené dvojrozmerné pole hodnôt.
Nasledujúci skript, nazvime ho getMetrica.sh, je potrebný na získanie špecifikovanej metriky zo súboru s výsledkom požiadavky:
#!/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
doneTeraz sme pripravení nakonfigurovať Zabbix a začať monitorovať indikátory procesov skladovej akceptácie.
Na každom databázovom uzle je nainštalovaný a nakonfigurovaný agent Zabbix.
Na hlavnom serveri definujeme všetky servery so Zabbix proxy. Pre nastavenia prejdite na nasledujúcu cestu:
Správa → Proxy → Vytvoriť proxy
Definujeme riadených hostiteľov:
Nastavenia → Hostitelia → Vytvoriť hostiteľa
Názov hostiteľa sa musí zhodovať s názvom hostiteľa, ktorý je zadaný v konfiguračnom súbore agenta.
Určíme skupinu pre uzol, ako aj IP adresu alebo DNS názov uzla s databázou.
Vytvárame metriky a špecifikujeme ich vlastnosti:
Nastavenia → Uzly → 'názov uzla' → Dátové položky>Vytvoriť dátovú položku
1) Vytvorte hlavnú metriku na dopytovanie všetkých parametrov z databázy
Nastavíme názov dátového prvku, uvedieme typ „Externé overenie“. V poli “Kľúč” definujeme skript, ktorému odovzdáme ako parametre názov databázy Oracle, názov sql dotazu, prihlasovacie meno a heslo pre pripojenie k databáze. Nastavte interval aktualizácie dotazu na 5 minút (300 sekúnd).
2) Vytvorte zostávajúce metriky pre každý stav vozidla. Hodnoty týchto metrík sa vygenerujú na základe výsledku kontroly hlavnej metriky.
Nastavíme názov dátového prvku, uvedieme typ „Externé overenie“. V poli “Kľúč” definujeme skript, ktorému odovzdáme ako parametre názov databázy Oracle a stavový kód, ktorého hodnotu chceme sledovať. Interval aktualizácie dotazu sme nastavili o 10 sekúnd dlhší ako hlavná metrika (310 sekúnd), aby sa výsledky stihli zapísať do súboru.
Pre správne získanie metrík je dôležité poradie, v ktorom sú kontroly aktivované. Aby sme predišli konfliktom pri prijímaní údajov, najskôr aktivujeme hlavnú metriku GetCarsByStatus zavolaním skriptu - wh_Metrics.sh.
Nastavenia → Uzly → „názov uzla“ → Dátové prvky → Podfilter „Externé kontroly“. Označte požadovanú kontrolu a kliknite na „Aktivovať“.
Potom v jednej operácii aktivujeme zostávajúce metriky a vyberieme ich všetky spolu:
Teraz Zabbix začal zbierať obchodné metriky skladu.
V nasledujúcich článkoch sa bližšie pozrieme na prepojenie Grafany a vytváranie informačných dashboardov skladových prevádzok pre rôzne kategórie užívateľov. Grafana slúži aj na sledovanie odchýlok v skladových operáciách a v závislosti od hraníc a frekvencie odchýlok eviduje incidenty v systéme obslužného centra skladu cez API alebo jednoducho posiela notifikácie manažérovi emailom.
Zdroj: hab.com