DIY: kako automatiziramo nadzor skladišta

X5 upravlja sa 43 distributivna centra i 4 vlastitih kamiona, osiguravajući nesmetanu opskrbu proizvodima u 029 trgovine. U ovom članku ću podijeliti svoje iskustvo kreiranja interaktivnog sistema za praćenje događaja u skladištu od nule. Informacije će biti korisne logističarima trgovačkih kompanija sa nekoliko desetina distributivnih centara koji upravljaju širokim spektrom proizvoda.

Izgradnja sistema za praćenje i upravljanje poslovnim procesima po pravilu počinje obradom poruka i incidenata. Istovremeno, propušta se važna tehnološka tačka koja se odnosi na mogućnost automatizacije same činjenice nastanka poslovnih događaja i evidentiranja incidenata. Većina poslovnih sistema kao što su WMS, TMS, itd., imaju ugrađene alate za praćenje sopstvenih procesa. Ali, ako se radi o sistemima različitih proizvođača ili funkcionalnost nadzora nije dovoljno razvijena, morate naručiti skupe modifikacije ili privući specijalizirane konsultante za dodatna podešavanja.

Razmotrimo pristup u kojem nam je potreban samo mali dio konsultacija vezanih za identifikaciju izvora (tabela) za dobijanje indikatora iz sistema.

Specifičnost naših skladišta je da u jednom logističkom kompleksu funkcioniše više sistema upravljanja skladištem (WMS Exceed). Skladišta su podijeljena prema kategorijama skladištenja robe (suvo, alkoholno, smrznuto itd.) ne samo logično. U okviru jednog logističkog kompleksa nalazi se nekoliko odvojenih skladišnih zgrada, od kojih svaki upravlja vlastitim WMS-om.

Da bi formirali opštu sliku procesa koji se odvijaju u skladištu, menadžeri analiziraju izveštaje svakog WMS-a nekoliko puta dnevno, obrađuju poruke od skladišnih operatera (prijemača, komisionara, slagača) i sumiraju stvarne operativne indikatore za odraz na informativnoj tabli.

Kako bismo uštedjeli vrijeme menadžera, odlučili smo da razvijemo jeftin sistem za operativnu kontrolu događaja u skladištu. Novi sistem, osim što prikazuje „vruće“ indikatore operativnog učinka skladišnih procesa, treba da pomogne i menadžerima u evidentiranju incidenata i praćenju realizacije zadataka za otklanjanje uzroka koji utiču na date pokazatelje. Nakon sprovođenja generalne revizije IT arhitekture kompanije, shvatili smo da pojedinačni delovi potrebnog sistema već postoje na ovaj ili onaj način u našem pejzažu i za njih postoji i ispitivanje podešavanja i neophodne usluge podrške. Ostaje samo da se cijeli koncept dovede u jedinstveno arhitektonsko rješenje i procijeni obim razvoja.

Nakon procjene obima posla koji je potrebno uraditi za izgradnju novog sistema, odlučeno je da se projekat podijeli u nekoliko faza:

1. Prikupljanje indikatora za skladišne ​​procese, vizualizacija i kontrola indikatora i odstupanja
2. Automatizacija standarda procesa i registracija prijava u servisu poslovnih usluga za odstupanja
3. Proaktivno praćenje sa predviđanjem opterećenja i kreiranjem preporuka za menadžere.

U prvoj fazi, sistem mora prikupiti pripremljene rezove operativnih podataka iz svih WMS kompleksa. Čitanje se odvija gotovo u realnom vremenu (intervali kraći od 5 minuta). Trik je u tome što se podaci moraju dobiti iz DBMS-a nekoliko desetina skladišta prilikom postavljanja sistema na cijelu mrežu. Primljeni operativni podaci se obrađuju logikom jezgra sistema za izračunavanje odstupanja od planiranih pokazatelja i izračunavanje statistike. Ovako obrađeni podaci moraju biti prikazani na tabletu menadžera ili na informativnoj tabli skladišta u obliku razumljivih grafikona i dijagrama.

Prilikom odabira odgovarajućeg sistema za pilot implementaciju prve faze, odabrali smo Zabbix. Ovaj sistem se već koristi za praćenje IT performansi skladišnih sistema. Dodavanjem zasebne instalacije za prikupljanje poslovnih metrika rada skladišta, možete dobiti ukupnu sliku o ispravnosti skladišta.

Opća arhitektura sistema ispala je kao na slici.

Svaka WMS instanca je definirana kao host za sistem nadzora. metrike prikuplja centralni server u mreži data centara pokretanjem skripte sa pripremljenim SQL upitom. Ako trebate nadgledati sistem koji ne preporučuje direktan pristup bazi podataka (na primjer, SAP EWM), možete koristiti pozive skripte dokumentovanim API funkcijama da biste dobili indikatore ili napisali jednostavan program u python/vbascript.

Zabbix proxy instanca je raspoređena u mreži skladišta da distribuira opterećenje sa glavnog servera. Preko proxyja je osiguran rad sa svim lokalnim WMS instancama. Sljedeći put kada Zabbix server zatraži parametre, skripta se izvršava na hostu sa Zabbix proxyjem da bi zatražila metriku iz WMS baze podataka.

Za prikaz grafikona i indikatora skladišta na centralnom Zabbix serveru postavljamo Grafanu. Pored prikaza pripremljenih dashboard-a sa infografikama skladišnog poslovanja, Grafana će se koristiti za praćenje odstupanja indikatora i slanje automatskih upozorenja sistemu skladišnih servisa za rad sa poslovnim incidentima.

Kao primjer, razmotrimo implementaciju kontrole opterećenja u zoni prijema skladišta. Kao glavne pokazatelje performansi procesa u ovoj oblasti skladišta izabrani su:

• broj vozila u recepciji, uzimajući u obzir statuse (planirano, stiglo, dokumenti, istovar, polazak;
• opterećenost prostora za smještaj i dopunu (prema uslovima skladištenja).

Postavke

Instalacija i konfiguracija glavnih komponenti sistema (SQLcl, Zabbix, Grafana) opisana je u raznim izvorima i ovdje se neće ponavljati. Upotreba SQLcl umjesto SQLplus-a je zbog činjenice da SQLcl (sučelje komandne linije Oracle DBMS-a, napisano na java) ne zahtijeva dodatnu instalaciju Oracle klijenta i radi iz kutije.

Opisaću glavne tačke na koje treba obratiti pažnju kada koristite Zabbix za praćenje indikatora procesa skladištenja i jedan od mogućih načina za njihovu implementaciju. Također, ovo nije post o sigurnosti. Sigurnost veza i korištenje prikazanih metoda zahtijeva dodatno proučavanje u procesu prelaska pilot rješenja u produktivan rad.

Glavna stvar je da je prilikom implementacije takvog sistema moguće učiniti bez programiranja, koristeći postavke koje pruža sistem.

Zabbix sistem za praćenje pruža nekoliko opcija za prikupljanje metrike iz nadziranog sistema. Ovo se može uraditi ili direktnim prozivanjem nadgledanih hostova, ili naprednijim metodom slanja podataka na server preko zabbix_sender hosta, uključujući metode za konfigurisanje parametara otkrivanja niskog nivoa. Za rješavanje našeg problema sasvim je prikladna metoda direktnog prozivanja hostova od strane centralnog servera, jer ovo vam omogućava da dobijete potpunu kontrolu nad redoslijedom akvizicije metrike i osigurava da koristite jedan skup postavki/skriptova bez potrebe da ih distribuirate svakom nadgledanom hostu.

Kao “testne subjekte” za otklanjanje grešaka i postavljanje sistema, koristimo WMS radni list za upravljanje prihvatanjem:

1. Vozila na recepciji, sva pristigla: Sva vozila sa statusima za period “- 72 sata od trenutnog vremena” - SQL identifikator upita: getCars.
2. Istorija statusa svih vozila: Statusi svih vozila koja stižu u roku od 72 sata - SQL identifikator upita: carsHistory.
3. Predviđena vozila za prijem: Statusi svih vozila sa dolaskom u statusu "Planirano", vremenski interval "- 24 sata" i "+24 sata" od trenutnog vremena - SQL identifikator upita: carsIn.

Dakle, nakon što smo se odlučili za skup metrika performansi skladišta, pripremit ćemo SQL upite za WMS bazu podataka. Za izvršavanje upita preporučljivo je koristiti ne glavnu bazu podataka, već njenu „vruću“ kopiju - stanje pripravnosti.

Povezujemo se na standby Oracle DBMS za primanje podataka. IP adresa za povezivanje sa test bazom podataka 192.168.1.106. Spremamo parametre veze na Zabbix server u TNSNames.ORA radnog foldera 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)
    )
  )

Ovo će nam omogućiti da pokrenemo SQL upite svakom hostu putem EZconnect-a, navodeći samo login/lozinku i ime baze podataka:

# sql znew/Zabmon1@WH1_1

Pripremljene SQL upite spremamo u radni folder na Zabbix serveru:

/etc/zabbix/sql

i dozvolite pristup zabbix korisniku našeg servera:

# chown zabbix:zabbix -R /etc/zabbix/sql

Datoteke sa zahtjevima dobijaju jedinstveni identifikator-ime za pristup sa Zabbix servera. Svaki upit baze podataka preko SQLcl-a vraća nam nekoliko parametara. Uzimajući u obzir specifičnosti Zabbixa, koji može obraditi samo jednu metriku po zahtjevu, koristit ćemo dodatne skripte za raščlanjivanje rezultata upita u pojedinačne metrike.

Pripremimo glavnu skriptu, nazovimo je wh_Metrics.sh, da pozovemo SQL upit bazi podataka, spremimo rezultate i vratimo tehničku metriku sa pokazateljima uspješnosti preuzimanja podataka:

#!/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

Gotovu datoteku sa skriptom stavljamo u mapu za pohranjivanje vanjskih skripti u skladu sa postavkama konfiguracije Zabbix-proxy (podrazumevano - /usr/local/share/zabbix/externalscripts).

Identifikacija baze podataka iz koje će skripta primati rezultate će biti proslijeđena kao parametar skripte. ID baze podataka mora odgovarati liniji postavki u datoteci TNSNames.ORA.

Rezultat poziva SQL upita pohranjuje se u datoteku poput mon_base_id_main.log gdje je base_id = Identifikator baze podataka primljen kao parametar skripte. Podjela datoteke rezultata po identifikatorima baze podataka je predviđena u slučaju zahtjeva sa servera na više baza podataka istovremeno. Upit vraća sortirani dvodimenzionalni niz vrijednosti.

Sljedeća skripta, nazovimo je getMetrica.sh, potrebna je za dobivanje određene metrike iz datoteke s rezultatom zahtjeva:

#!/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

Sada smo spremni da konfigurišemo Zabbix i počnemo da pratimo indikatore procesa prihvatanja skladišta.

Zabbix agent je instaliran i konfiguriran na svakom čvoru baze podataka.

Na glavnom serveru definiramo sve servere sa Zabbix proxyjem. Za postavke idite na sljedeću stazu:

Administracija → Proxy → Kreiraj proxy

Definiramo kontrolirane hostove:

Postavke → Domaćini → Kreiraj host

Ime hosta mora odgovarati imenu hosta koje je navedeno u konfiguracijskoj datoteci agenta.

Navodimo grupu za čvor, kao i IP adresu ili DNS ime čvora sa bazom podataka.

Mi kreiramo metriku i specificiramo njihova svojstva:

Postavke → Čvorovi → 'ime čvora' → Stavke podataka>Kreiraj stavku podataka

1) Kreirajte glavnu metriku za upit svih parametara iz baze podataka

Postavljamo naziv elementa podataka, označavamo tip „Spoljna verifikacija“. U polju „Ključ“ definiramo skriptu kojoj kao parametre prosljeđujemo naziv Oracle baze podataka, naziv sql upita, login i lozinku za povezivanje s bazom podataka. Postavite interval ažuriranja upita na 5 minuta (300 sekundi).

2) Kreirajte preostale metrike za svaki status vozila. Vrijednosti ovih metrika će se generirati na osnovu rezultata provjere glavne metrike.

Postavljamo naziv elementa podataka, označavamo tip „Spoljna verifikacija“. U polju „Ključ“ definiramo skriptu kojoj kao parametre prosljeđujemo naziv Oracle baze podataka i statusni kod čiju vrijednost želimo pratiti. Postavili smo interval ažuriranja upita na 10 sekundi duži od glavne metrike (310 sekundi) tako da rezultati imaju vremena da se zapišu u datoteku.

Za ispravno dobijanje metrike važan je redosled kojim se provere aktiviraju. Kako bismo izbjegli konflikte prilikom prijema podataka, prije svega aktiviramo glavnu metriku GetCarsByStatus pozivanjem skripte - wh_Metrics.sh.

Postavke → Čvorovi → 'ime čvora' → Elementi podataka → Podfilter “Spoljne provjere”. Označite potrebnu provjeru i kliknite na “Aktiviraj”.

Zatim aktiviramo preostale metrike u jednoj operaciji, birajući ih sve zajedno:

Sada je Zabbix počeo prikupljati metriku poslovanja skladišta.

U narednim člancima detaljnije ćemo se osvrnuti na povezivanje Grafane i kreiranje informativnih dashboarda poslovanja skladišta za različite kategorije korisnika. Grafana se također koristi za praćenje odstupanja u poslovanju skladišta i, ovisno o granicama i učestalosti odstupanja, registruje incidente u sistemu uslužnog centra za upravljanje skladištem putem API-ja ili jednostavno šalje obavještenja menadžeru e-poštom.

izvor: www.habr.com