X5 upravlja 43 distribucijskih centrov in 4 lastnih tovornjakov, ki zagotavljajo nemoteno dobavo izdelkov v 029 trgovin. V tem članku bom delil svoje izkušnje z ustvarjanjem interaktivnega sistema za spremljanje dogodkov v skladišču iz nič. Informacije bodo uporabne za logiste trgovskih podjetij z več desetimi distribucijskimi centri, ki upravljajo široko paleto izdelkov.
Izgradnja sistemov za spremljanje in upravljanje poslovnih procesov se praviloma začne z obdelavo sporočil in incidentov. Ob tem je zamujena pomembna tehnološka točka, povezana z možnostjo avtomatizacije samega nastanka poslovnih dogodkov in evidentiranja incidentov. Večina poslovnih sistemov, kot so WMS, TMS itd., ima vgrajena orodja za spremljanje lastnih procesov. Če pa gre za sisteme različnih proizvajalcev ali pa funkcionalnost spremljanja ni dovolj razvita, morate naročiti drage modifikacije ali privabiti specializirane svetovalce za dodatne nastavitve.
Oglejmo si pristop, pri katerem potrebujemo le majhen del svetovanja, povezanega z identifikacijo virov (tabel) za pridobitev indikatorjev iz sistema.
Posebnost naših skladišč je, da na enem logističnem kompleksu deluje več sistemov za upravljanje skladišč (WMS Exceed). Skladišča so razdeljena po kategorijah skladiščenja blaga (suha, alkoholna, zamrznjena itd.) Ne le logično. Znotraj enega logističnega kompleksa je več ločenih skladiščnih zgradb, od katerih vsako upravlja svoj WMS.
Za oblikovanje splošne slike procesov, ki se dogajajo v skladišču, vodje analizirajo poročanje vsakega WMS večkrat na dan, obdelajo sporočila operaterjev skladišča (sprejemniki, izbirniki, zlagalci) in povzemajo dejanske kazalnike delovanja za razmislek na informacijski tabli.
Zaradi prihranka časa vodjem smo se odločili razviti poceni sistem za operativni nadzor nad skladiščnimi dogodki. Nov sistem naj bi poleg prikaza »vročih« kazalnikov operativne uspešnosti skladiščnih procesov pomagal vodjem tudi pri evidentiranju dogodkov in spremljanju izvajanja nalog za odpravo vzrokov, ki vplivajo na dane kazalnike. Po generalni reviziji IT arhitekture podjetja smo ugotovili, da posamezni deli zahtevanega sistema tako ali drugače že obstajajo v naši pokrajini in zanje obstaja tako pregled nastavitev kot potrebne podporne storitve. Preostane le še združitev celotnega koncepta v enotno arhitekturno rešitev in ocena obsega razvoja.
Po oceni obsega dela, ki ga je treba opraviti za izgradnjo novega sistema, je bilo odločeno, da se projekt razdeli na več stopenj:
- Zbirka indikatorjev za skladiščne procese, vizualizacija in kontrola indikatorjev in odstopanj
- Avtomatizacija procesnih standardov in registracija vlog v službi poslovnih storitev za odstopanja
- Proaktivno spremljanje z napovedovanjem obremenitev in oblikovanjem priporočil za upravnike.
Na prvi stopnji mora sistem zbrati pripravljene rezine operativnih podatkov iz vseh WMS kompleksa. Branje poteka skoraj v realnem času (intervali manj kot 5 minut). Trik je v tem, da je treba pri uvajanju sistema v celotno omrežje pridobiti podatke iz DBMS več deset skladišč. Prejete operativne podatke obdeluje logika jedra sistema za izračun odstopanj od načrtovanih kazalnikov in izračun statistike. Tako obdelani podatki morajo biti prikazani na upravljavčevi tablici ali na informacijski tabli skladišča v obliki razumljivih grafov in diagramov.
Pri izbiri ustreznega sistema za pilotno izvedbo prve stopnje smo izbrali Zabbix. Ta sistem se že uporablja za spremljanje IT delovanja skladiščnih sistemov. Z dodajanjem ločene namestitve za zbiranje poslovnih metrik delovanja skladišča lahko dobite celovito sliko zdravja skladišča.
Splošna arhitektura sistema se je izkazala kot na sliki.
Vsaka instanca WMS je definirana kot gostitelj za nadzorni sistem. Metrike zbira centralni strežnik v omrežju podatkovnega centra z izvajanjem skripte s pripravljeno SQL poizvedbo. Če morate nadzorovati sistem, ki ne priporoča neposrednega dostopa do baze podatkov (na primer SAP EWM), lahko uporabite skriptne klice dokumentiranih funkcij API, da pridobite indikatorje ali napišete preprost program v python/vbascript.
Proxy instanca Zabbix je nameščena v omrežju skladišča za porazdelitev obremenitve z glavnega strežnika. Prek proxyja je zagotovljeno delo z vsemi lokalnimi instancami WMS. Naslednjič, ko strežnik Zabbix zahteva parametre, se na gostitelju s proxyjem Zabbix izvede skript, ki zahteva meritve iz baze podatkov WMS.
Za prikaz grafov in indikatorjev skladišča na osrednjem strežniku Zabbix namestimo Grafano. Poleg prikaza pripravljenih nadzornih plošč z infografiko skladiščnega poslovanja bo Grafana namenjena spremljanju odstopanj kazalnikov in pošiljanju avtomatskih opozoril v sistem skladiščnega servisa za delo s poslovnimi incidenti.
Kot primer si oglejmo izvedbo kontrole tovora v skladiščnem sprejemnem prostoru. Kot glavni indikatorji uspešnosti procesa na tem področju skladišča so bili izbrani naslednji:
- število vozil v sprejemnem prostoru, ob upoštevanju statusov (načrtovano, prispelo, dokumenti, razkladanje, odhod);
- delovna obremenitev območij postavitve in dopolnitve (glede na pogoje skladiščenja).
Nastavitve
Namestitev in konfiguracija glavnih komponent sistema (SQLcl, Zabbix, Grafana) je opisana v različnih virih in je tukaj ne bomo ponavljali. Uporaba SQLcl namesto SQLplus je posledica dejstva, da SQLcl (vmesnik ukazne vrstice Oracle DBMS, napisan v Javi) ne zahteva dodatne namestitve Oracle Client in deluje takoj po namestitvi.
Opisal bom glavne točke, na katere moramo biti pozorni pri uporabi Zabbixa za spremljanje indikatorjev skladiščnih poslovnih procesov, in enega od možnih načinov njihove implementacije. Poleg tega to ni objava o varnosti. Varnost povezav in uporaba predstavljenih metod zahteva dodatne študije v procesu prenosa pilotne rešitve v produktivno delovanje.
Glavna stvar je, da je pri izvajanju takšnega sistema mogoče storiti brez programiranja z uporabo nastavitev, ki jih zagotavlja sistem.
Sistem za spremljanje Zabbix ponuja več možnosti za zbiranje metrik iz nadzorovanega sistema. To je mogoče storiti z neposrednim anketiranjem nadzorovanih gostiteljev ali z naprednejšo metodo pošiljanja podatkov strežniku prek gostiteljevega zabbix_senderja, vključno z metodami za konfiguracijo parametrov odkrivanja na nizki ravni. Za rešitev našega problema je zelo primerna metoda neposrednega anketiranja gostiteljev s strani centralnega strežnika, ker to vam omogoča popoln nadzor nad zaporedjem pridobivanja meritev in zagotavlja, da uporabljate en nabor nastavitev/skriptov, ne da bi jih bilo treba razdeliti vsakemu nadzorovanemu gostitelju.
Kot »testne subjekte« za odpravljanje napak in nastavitev sistema uporabljamo delovni list WMS za upravljanje sprejemljivosti:
- Vozila na sprejemu, vsa prispela: Vsa vozila s statusi za obdobje “- 72 ur od trenutnega časa” - SQL identifikator poizvedbe: getCars.
- Zgodovina vseh statusov vozil: Statusi vseh vozil, ki prispejo v 72 urah - identifikator poizvedbe SQL: avtomobiliZgodovina.
- Redna vozila za prevzem: Statusi vseh vozil s prihodom v statusu “Načrtovani”, časovni interval “- 24 ur” in “+24 ur” od trenutnega časa - SQL identifikator poizvedbe: avtomobiliIn.
Torej, ko se odločimo za nabor metrik zmogljivosti skladišča, bomo pripravili SQL poizvedbe za bazo WMS. Za izvajanje poizvedb je priporočljivo uporabiti ne glavno bazo podatkov, temveč njeno "vročo" kopijo - pripravljenost.
Za sprejem podatkov se povežemo s pripravljenostjo Oracle DBMS. IP naslov za povezavo s testno bazo 192.168.1.106. Parametre povezave shranimo na Zabbix strežnik v TNSNames.ORA delovne mape 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 nam bo omogočilo izvajanje poizvedb SQL do vsakega gostitelja prek EZconnect, pri čemer bomo podali samo prijavo/geslo in ime baze podatkov:
# sql znew/Zabmon1@WH1_1Pripravljene SQL poizvedbe shranimo v delovno mapo na Zabbix strežniku:
/etc/zabbix/sqlin omogočite dostop uporabniku zabbix našega strežnika:
# chown zabbix:zabbix -R /etc/zabbix/sqlDatoteke z zahtevami prejmejo edinstveno identifikatorsko ime za dostop s strežnika Zabbix. Vsaka poizvedba baze podatkov prek SQLcl nam vrne več parametrov. Upoštevajoč specifiko Zabbixa, ki lahko obdela le eno metriko na zahtevo, bomo z dodatnimi skripti razčlenili rezultate poizvedbe na posamezne metrike.
Pripravimo glavno skripto, poimenujmo jo wh_Metrics.sh, da pokličemo poizvedbo SQL v bazo podatkov, shranimo rezultate in vrnemo tehnično metriko z indikatorji uspešnosti pridobivanja podatkov:
#!/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
fiKončano datoteko s skriptom postavimo v mapo za shranjevanje zunanjih skriptov v skladu s konfiguracijskimi nastavitvami Zabbix-proxy (privzeto - /usr/local/share/zabbix/externalscripts).
Identifikacija baze podatkov, iz katere bo skript prejel rezultate, bo posredovana kot parameter skripta. ID baze podatkov se mora ujemati z vrstico z nastavitvami v datoteki TNSNames.ORA.
Rezultat klica poizvedbe SQL se shrani v datoteko, kot je mon_base_id_main.log kjer je base_id = Identifikator baze podatkov, prejet kot parameter skripta. Razdelitev datoteke rezultatov po identifikatorjih podatkovnih baz je zagotovljena v primeru zahtev strežnika do več baz podatkov hkrati. Poizvedba vrne razvrščeno dvodimenzionalno matriko vrednosti.
Naslednji skript, imenujemo ga getMetrica.sh, je potreben za pridobitev določene metrike iz datoteke z rezultatom zahteve:
#!/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
doneZdaj smo pripravljeni konfigurirati Zabbix in začeti spremljati indikatorje procesov sprejema v skladišču.
Agent Zabbix je nameščen in konfiguriran na vsakem vozlišču baze podatkov.
Na glavnem strežniku definiramo vse strežnike z Zabbix proxy. Za nastavitve pojdite na naslednjo pot:
Skrbništvo → Proxy → Ustvari proxy
Definiramo nadzorovane gostitelje:
Nastavitve → Gostitelji → Ustvari gostitelja
Ime gostitelja se mora ujemati z imenom gostitelja, podanim v konfiguracijski datoteki posrednika.
Določimo skupino za vozlišče ter IP naslov ali DNS ime vozlišča z bazo podatkov.
Ustvarjamo metrike in določamo njihove lastnosti:
Nastavitve → Vozlišča → 'ime vozlišča' → Podatkovne postavke>Ustvari podatkovno postavko
1) Ustvarite glavno metriko za poizvedovanje po vseh parametrih iz baze podatkov
Določimo ime podatkovnega elementa, označimo vrsto "Zunanje preverjanje". V polju “Ključ” definiramo skripto, ki ji kot parametre posredujemo ime baze Oracle, ime sql poizvedbe, prijavo in geslo za povezavo z bazo. Nastavite interval posodabljanja poizvedbe na 5 minut (300 sekund).
2) Ustvarite preostale meritve za vsak status vozila. Vrednosti teh metrik bodo ustvarjene na podlagi rezultata preverjanja glavne metrike.
Določimo ime podatkovnega elementa, označimo vrsto "Zunanje preverjanje". V polju “Ključ” definiramo skripto, ki ji kot parametra posredujemo ime baze podatkov Oracle in statusno kodo, katere vrednosti želimo slediti. Interval posodabljanja poizvedbe smo nastavili na 10 sekund dlje od glavne metrike (310 sekund), tako da imajo rezultati čas za zapis v datoteko.
Za pravilno pridobivanje metrik je pomemben vrstni red, v katerem so aktivirana preverjanja. Da bi se izognili konfliktom pri prejemanju podatkov, najprej aktiviramo glavno metriko GetCarsByStatus s klicem skripte - wh_Metrics.sh.
Nastavitve → Vozlišča → 'ime vozlišča' → Podatkovni elementi → Podfilter “Zunanja preverjanja”. Označite zahtevano polje in kliknite »Aktiviraj«.
Nato z eno operacijo aktiviramo preostale metrike in jih vse skupaj izberemo:
Zdaj je Zabbix začel zbirati metrike skladiščnega poslovanja.
V naslednjih člankih si bomo podrobneje ogledali povezovanje Grafana in izdelavo informacijskih nadzornih plošč skladiščnega poslovanja za različne kategorije uporabnikov. Grafana se uporablja tudi za spremljanje odstopanj v skladiščnem poslovanju in glede na meje in pogostost odstopanj registrira incidente v sistemu storitvenega centra za vodenje skladišč prek API-ja ali preprosto pošilja obvestila upravitelju po elektronski pošti.
Vir: www.habr.com