X5 upravlja s 43 distribucijska centra i 4 vlastitih kamiona, osiguravajući nesmetanu opskrbu proizvodima u 029 trgovine. U ovom ću članku podijeliti svoje iskustvo stvaranja interaktivnog sustava za praćenje događaja u skladištu od nule. Informacije će biti korisne logističarima trgovačkih tvrtki s nekoliko desetaka distribucijskih centara koji upravljaju širokom paletom proizvoda.
Izgradnja sustava za nadzor i upravljanje poslovnim procesima u pravilu započinje obradom poruka i incidenata. Pritom je propuštena bitna tehnološka točka vezana uz mogućnost automatizacije same činjenice nastanka poslovnih događaja i evidentiranja incidenata. Većina poslovnih sustava kao što su WMS, TMS i sl. imaju ugrađene alate za praćenje vlastitih procesa. No, ako se radi o sustavima različitih proizvođača ili funkcionalnost nadzora nije dovoljno razvijena, morate naručiti skupe izmjene ili privući specijalizirane konzultante za dodatne postavke.
Razmotrimo pristup u kojem nam je potreban samo mali dio savjetovanja povezanog s identificiranjem izvora (tablica) za dobivanje pokazatelja iz sustava.
Specifičnost naših skladišta je da na jednom logističkom kompleksu radi više sustava za upravljanje skladištem (WMS Exceed). Skladišta su podijeljena prema kategorijama skladištenja robe (suha, alkoholna, smrznuta itd.) ne samo logično. Unutar jednog logističkog kompleksa nalazi se nekoliko zasebnih skladišnih zgrada od kojih svakim upravlja vlastiti WMS.
Da bi formirali opću sliku procesa koji se odvijaju u skladištu, upravitelji nekoliko puta dnevno analiziraju izvješća svakog WMS-a, obrađuju poruke skladišnih operatera (primatelji, komisionari, slagači) i sažimaju stvarne operativne pokazatelje za odraz na informacijskoj ploči.
Kako bismo menadžerima uštedjeli vrijeme, odlučili smo razviti jeftin sustav za operativni nadzor skladišnih događaja. Novi sustav bi, osim prikaza “vrućih” pokazatelja operativne uspješnosti skladišnih procesa, trebao pomoći menadžerima u evidentiranju incidenata i praćenju provedbe zadataka radi otklanjanja uzroka koji utječu na zadane pokazatelje. Nakon što smo proveli opću reviziju IT arhitekture tvrtke, uvidjeli smo da pojedini dijelovi potrebnog sustava već postoje na ovaj ili onaj način u našem okruženju i za njih postoji i ispitivanje postavki i potrebne usluge podrške. Ostaje još samo da se cjelokupni koncept uklopi u jedinstveno arhitektonsko rješenje i procijeni opseg razvoja.
Nakon procjene količine posla koji je potrebno obaviti za izgradnju novog sustava, odlučeno je da se projekt podijeli u nekoliko faza:
- Zbirka pokazatelja za skladišne procese, vizualizacija i kontrola pokazatelja i odstupanja
- Automatizacija standarda procesa i evidentiranje zahtjeva u službi poslovnih usluga za odstupanja
- Proaktivno praćenje s predviđanjem opterećenja i izradom preporuka za upravitelje.
U prvoj fazi sustav mora prikupiti pripremljene dijelove operativnih podataka iz svih WMS-ova kompleksa. Očitavanje se odvija gotovo u stvarnom vremenu (intervali manji od 5 minuta). Trik je u tome što se podaci moraju dobiti iz DBMS-a nekoliko desetaka skladišta kada se sustav postavlja na cijelu mrežu. Primljeni operativni podaci obrađuju se logikom jezgre sustava za izračun odstupanja od planiranih pokazatelja i obračun statistike. Ovako obrađeni podaci moraju biti prikazani na tabletu upravitelja ili na informacijskoj ploči skladišta u obliku razumljivih grafikona i dijagrama.
Prilikom odabira prikladnog sustava za pilot implementaciju prve faze odabrali smo Zabbix. Ovaj sustav se već koristi za praćenje IT performansi skladišnih sustava. Dodavanjem zasebne instalacije za prikupljanje poslovnih metrika rada skladišta možete dobiti cjelokupnu sliku o stanju skladišta.
Opća arhitektura sustava ispala je kao na slici.
Svaka WMS instanca definirana je kao host za sustav nadzora. Mjerne podatke prikuplja središnji poslužitelj u mreži podatkovnog centra pokretanjem skripte s pripremljenim SQL upitom. Ako trebate nadzirati sustav koji ne preporučuje izravan pristup bazi podataka (na primjer, SAP EWM), možete koristiti pozive skripte dokumentiranim API funkcijama za dobivanje indikatora ili napisati jednostavan program u python/vbascriptu.
Zabbix proxy instanca postavljena je u mrežu skladišta za raspodjelu opterećenja s glavnog poslužitelja. Kroz Proxy je osiguran rad sa svim lokalnim WMS instancama. Sljedeći put kada Zabbix poslužitelj zatraži parametre, skripta se izvršava na hostu sa Zabbix proxyjem kako bi se zatražila metrika iz WMS baze podataka.
Za prikaz grafikona i indikatora skladišta na središnjem Zabbix poslužitelju, postavljamo Grafanu. Osim prikaza pripremljenih nadzornih ploča s infografikom skladišnog poslovanja, Grafana će služiti za praćenje odstupanja u pokazateljima i slanje automatskih upozorenja sustavu skladišnog servisa za rad s poslovnim incidentima.
Kao primjer, razmotrimo implementaciju kontrole opterećenja u skladišnom prijemnom području. Kao glavni pokazatelji performansi procesa u ovom području skladišta odabrani su sljedeći:
- broj vozila u recepciji, uzimajući u obzir statuse (planirano, stiglo, dokumenti, istovar, odlazak);
- radno opterećenje područja za postavljanje i dopunu (prema uvjetima skladištenja).
postavke
Instalacija i konfiguracija glavnih komponenti sustava (SQLcl, Zabbix, Grafana) opisana je u različitim izvorima i ovdje se neće ponavljati. Upotreba SQLcl umjesto SQLplus je zbog činjenice da SQLcl (sučelje naredbenog retka Oracle DBMS-a, napisano u Javi) ne zahtijeva dodatnu instalaciju Oracle Clienta i radi izvan okvira.
Opisat ću glavne točke na koje treba obratiti pozornost pri korištenju Zabbixa za praćenje pokazatelja skladišnih poslovnih procesa te jedan od mogućih načina njihove implementacije. Također, ovo nije post o sigurnosti. Sigurnost veza i korištenje prikazanih metoda zahtijeva dodatna proučavanja u procesu prevođenja pilot rješenja u produktivni rad.
Glavna stvar je da je pri implementaciji takvog sustava moguće učiniti bez programiranja, koristeći postavke koje pruža sustav.
Zabbix nadzorni sustav nudi nekoliko opcija za prikupljanje metrike iz nadziranog sustava. To se može učiniti izravnim prozivanjem nadziranih hostova ili naprednijom metodom slanja podataka na poslužitelj preko zabbix_sendera hosta, uključujući metode za konfiguriranje parametara otkrivanja niske razine. Za rješavanje našeg problema sasvim je prikladna metoda izravnog prozivanja hostova od strane središnjeg poslužitelja, jer ovo vam omogućuje da dobijete potpunu kontrolu nad slijedom prikupljanja metrike i osigurava da koristite jedan skup postavki/skripti bez potrebe da ih distribuirate svakom nadziranom hostu.
Kao “testne subjekte” za otklanjanje pogrešaka i postavljanje sustava koristimo WMS radnu tablicu za upravljanje prihvaćanjem:
- Vozila na prijemu, sva pristigla: Sva vozila sa statusima za period “- 72 sata od trenutnog vremena” - identifikator SQL upita: getCars.
- Povijest svih statusa vozila: Statusi svih vozila koja stižu unutar 72 sata - SQL identifikator upita: automobiliPovijest.
- Predviđena vozila za prihvat: Statusi svih vozila sa dolaskom u statusu “Planirano”, vremenski interval “- 24 sata” i “+24 sata” od trenutnog vremena - identifikator SQL upita: automobiliIn.
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.
Spajamo se na Oracle DBMS u stanju pripravnosti za primanje podataka. IP adresa za povezivanje s testnom bazom podataka 192.168.1.106. Parametre veze spremamo na Zabbix poslužitelj u TNSNames.ORA radne 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 će nam omogućiti pokretanje SQL upita svakom hostu putem EZconnect-a, navodeći samo prijavu/lozinku i naziv baze podataka:
# sql znew/Zabmon1@WH1_1Pripremljene SQL upite spremamo u radnu mapu na Zabbix poslužitelju:
/etc/zabbix/sqli dopustite pristup zabbix korisniku našeg poslužitelja:
# chown zabbix:zabbix -R /etc/zabbix/sqlDatoteke sa zahtjevima dobivaju jedinstveni identifikator-ime za pristup sa Zabbix poslužitelja. Svaki upit baze podataka putem 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 analizu rezultata upita u pojedinačne metrike.
Pripremimo glavnu skriptu, nazovimo je wh_Metrics.sh, za pozivanje SQL upita bazi podataka, spremanje rezultata i vraćanje tehničke metrike s indikatorima uspješnosti dohvaćanja 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
fiGotovu datoteku sa skriptom postavljamo u mapu za pohranu vanjskih skripti u skladu s postavkama konfiguracije Zabbix-proxyja (prema zadanim postavkama - /usr/local/share/zabbix/externalscripts).
Identifikacija baze podataka iz koje će skripta primati rezultate bit će proslijeđena kao parametar skripte. ID baze podataka mora odgovarati retku postavki u datoteci TNSNames.ORA.
Rezultat poziva SQL upita sprema se u datoteku poput mon_base_id_main.log gdje je base_id = Identifikator baze podataka primljen kao parametar skripte. Podjela datoteke rezultata prema identifikatorima baze podataka omogućena je u slučaju zahtjeva s poslužitelja prema nekoliko baza podataka istovremeno. Upit vraća sortirano dvodimenzionalno polje 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
doneSada smo spremni za konfiguraciju Zabbixa i početak praćenja indikatora procesa prihvata skladišta.
Zabbix agent instaliran je i konfiguriran na svakom čvoru baze podataka.
Na glavnom poslužitelju definiramo sve poslužitelje sa Zabbix proxyjem. Za postavke idite na sljedeći put:
Administracija → Proxy → Stvori proxy
Definiramo kontrolirane hostove:
Postavke → Domaćini → Stvori domaćin
Naziv glavnog računala mora odgovarati nazivu glavnog računala navedenom u konfiguracijskoj datoteci agenta.
Specificiramo grupu za čvor, kao i IP adresu ili DNS naziv čvora s bazom podataka.
Mi stvaramo metrike i specificiramo njihova svojstva:
Postavke → Čvorovi → 'ime čvora' → Podatkovne stavke>Stvori podatkovnu stavku
1) Napravite glavnu metriku za upit svih parametara iz baze podataka
Postavljamo naziv elementa podataka, označavamo vrstu "Vanjska provjera". U polju “Ključ” definiramo skriptu kojoj kao parametre prosljeđujemo naziv Oracle baze podataka, naziv sql upita, prijavu i lozinku za povezivanje s bazom. Postavite interval ažuriranja upita na 5 minuta (300 sekundi).
2) Stvorite preostale metrike za svaki status vozila. Vrijednosti ovih metrika bit će generirane na temelju rezultata provjere glavne metrike.
Postavljamo naziv elementa podataka, označavamo vrstu "Vanjska provjera". U polju “Key” 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 dulji od glavne metrike (310 sekundi) tako da rezultati imaju vremena za pisanje u datoteku.
Za ispravno dobivanje metrike važan je redoslijed kojim se provjere aktiviraju. Kako bismo izbjegli konflikte prilikom primanja podataka, prije svega aktiviramo glavnu metriku GetCarsByStatus pozivanjem skripte - wh_Metrics.sh.
Postavke → Čvorovi → 'naziv čvora' → Elementi podataka → Podfilter “Vanjske provjere”. Označite potrebnu oznaku i kliknite "Aktiviraj".
Zatim aktiviramo preostale metrike u jednoj operaciji, odabirući ih sve zajedno:
Sada je Zabbix počeo prikupljati metriku poslovanja skladišta.
U sljedećim člancima pobliže ćemo se pozabaviti povezivanjem Grafana i izradom informacijskih nadzornih ploča skladišnog poslovanja za različite kategorije korisnika. Grafana se koristi i za praćenje odstupanja u skladišnom poslovanju te ovisno o granicama i učestalosti odstupanja registrira incidente u sustavu servisnog centra za upravljanje skladištem putem API-ja ili jednostavno šalje obavijesti upravitelju e-poštom.
Izvor: www.habr.com