X5 valdo 43 paskirstymo centrus ir 4 nuosavus sunkvežimius, užtikrindamas nenutrūkstamą produkcijos tiekimą 029 parduotuvėms. Straipsnyje pasidalinsiu savo patirtimi kuriant interaktyvią sandėlio įvykių stebėjimo sistemą nuo nulio. Informacija bus naudinga prekybos įmonių, turinčių kelias dešimtis platinimo centrų, valdančių platų asortimentą, logistikams.
Paprastai verslo procesų stebėjimo ir valdymo sistemų kūrimas prasideda nuo pranešimų ir incidentų apdorojimo. Taip praleidžiamas svarbus technologinis momentas, susijęs su galimybe automatizuoti patį verslo įvykių faktą ir registruoti incidentus. Dauguma WMS, TMS ir tt klasės verslo sistemų turi įmontuotus įrankius savo procesams stebėti. Bet jei tai skirtingų gamintojų sistemos arba nepakankamai išvystytas stebėjimo funkcionalumas, turite užsakyti brangius patobulinimus arba pasitelkti specializuotus konsultantus papildomiems nustatymams.
Apsvarstykime metodą, kai mums reikia tik nedidelės konsultacijos, susijusios su šaltinių (lentelių) apibrėžimu, norint gauti rodiklius iš sistemos.
Mūsų sandėlių specifika slypi tame, kad viename logistikos komplekse veikia kelios sandėlių valdymo sistemos (WMS Exceed). Pagal prekių saugojimo kategorijas (sausas, alkoholis, šaldymas ir kt.) sandėliai skirstomi ne tik logiškai. Viename logistikos komplekse yra keli atskiri sandėlių pastatai, kurių veiklą valdo savo WMS.
Siekdami susidaryti bendrą sandėlyje vykstančių procesų vaizdą, vadovai kelis kartus per dieną analizuoja kiekvienos WMS ataskaitas, apdoroja sandėlio operatorių (gavėjų, rinkėjų, krovėjų) pranešimus ir apibendrina realius veiklos rodiklius, kad galėtų apmąstyti informacinė lenta.
Norėdami sutaupyti vadovų laiko, nusprendėme sukurti nebrangią sandėlio įvykių operatyvinės kontrolės sistemą. Naujoji sistema, be „karštų“ sandėlio procesų operatyvinio darbo rodiklių atvaizdavimo, taip pat turėtų padėti vadovams fiksuojant incidentus bei stebint užduočių vykdymą, siekiant pašalinti priežastis, turinčias įtakos nurodytiems rodikliams. Atlikę bendrą įmonės IT architektūros auditą supratome, kad tam tikros reikalingos sistemos dalys mūsų kraštovaizdyje vienaip ar kitaip jau egzistuoja, o joms yra ir nustatymų ekspertizė, ir reikalingos pagalbos paslaugos. Belieka visą koncepciją sujungti į vieną architektūrinį sprendimą ir įvertinti plėtros mastą.
Įvertinus, kiek darbų reikia atlikti kuriant naują sistemą, buvo nuspręsta projektą skaidyti į kelis etapus:
- Rodiklių rinkimas sandėlio procesams, rodiklių ir nukrypimų vizualizavimas ir kontrolė
- Procesų reglamentavimo automatizavimas ir užklausų registravimas verslo paslaugų tarnyboje dėl nukrypimų
- Aktyvus stebėjimas su apkrovų prognozavimu ir rekomendacijų teikimu vadovams.
Pirmajame etape sistema turi surinkti paruoštas operatyvinių duomenų dalis iš visų komplekso WMS. Skaitymas vyksta beveik realiu laiku (mažesni nei 5 minučių intervalai). Gudrybė ta, kad diegiant sistemą visame tinkle, duomenys turi būti gauti iš kelių dešimčių sandėlių DBVS. Gauti operatyviniai duomenys apdorojami sistemos branduolio logika apskaičiuojant nuokrypius nuo planuotų rodiklių ir skaičiuojant statistiką. Tokiu būdu tvarkomi duomenys turi būti atvaizduojami vadovo planšetėje arba sandėlio informacinėje lentoje suprantamų grafikų ir diagramų pavidalu.
Pasirinkdami tinkamos sistemos variantą pirmojo etapo pilotiniam įgyvendinimui, apsistojome ties Zabbix. Ši sistema jau naudojama sandėlio sistemų IT našumui stebėti. Pridėję atskirą įrenginį, skirtą sandėlio verslo metrikai rinkti, galite susidaryti bendrą sandėlio būklės vaizdą.
Bendra sistemos architektūra pasirodė kaip paveikslėlyje.
Kiekvienas WMS egzempliorius apibrėžiamas kaip stebėjimo sistemos priegloba. Metrikas renka centrinis serveris duomenų centro tinkle, vykdydamas scenarijų su paruošta SQL užklausa. Jei reikia stebėti sistemą, kuri nerekomenduoja tiesioginės prieigos prie duomenų bazės (pvz., SAP EWM), galite naudoti scenarijaus iškvietimus į dokumentuotas API funkcijas, kad gautumėte rodiklius arba parašyti paprastą python/vbascript programą.
Sandėlio tinkle yra įdiegtas Zabbix tarpinis serveris, kad būtų paskirstyta apkrova iš pagrindinio serverio. Tarpinis serveris teikia darbą su visais vietiniais WMS egzemplioriais. Kai „Zabbix“ serveris kitą kartą prašo parametrų, pagrindiniame kompiuteryje su „Zabbix“ tarpiniu serveriu vykdomas scenarijus, kad būtų užklausta metrika iš WMS duomenų bazės.
Norėdami centriniame „Zabbix“ serveryje rodyti grafikus ir sandėlio indikatorius, įdiekite „Grafana“. Be paruoštų prietaisų skydelių su sandėlio veiklos infografikų rodymo, „Grafana“ bus naudojama indikatorių nukrypimams kontroliuoti ir automatiniams įspėjimams perduoti į sandėlio aptarnavimo sistemą, kad būtų galima dirbti su verslo incidentais.
Kaip pavyzdį panagrinėkime sandėlio priėmimo zonos pakrovimo kontrolės įgyvendinimą. Pagrindiniais šios sandėlio dalies procesų rodikliais pasirinkti:
- transporto priemonių skaičius priėmimo zonoje, atsižvelgiant į būsenas (planuotas, atvyko, dokumentai, iškrovimas, išvykimas;
- apgyvendinimo ir papildymo zonų darbo krūvis (pagal laikymo sąlygas).
Nustatymai
Pagrindinių sistemos komponentų (SQLcl, Zabbix, Grafana) diegimas ir konfigūravimas aprašytas įvairiuose šaltiniuose ir čia nekartosime. SQLcl vietoj SQLplus naudojamas dėl to, kad SQLcl (Oracle DBMS komandinės eilutės sąsaja, parašyta java) nereikalauja papildomo Oracle Client diegimo ir veikia iš karto.
Aprašysiu pagrindinius dalykus, į kuriuos turėtumėte atkreipti dėmesį naudojant Zabbix sandėlio verslo procesų rodiklių stebėjimui ir vieną iš galimų jų įgyvendinimo būdų. Be to, šis įrašas ne apie saugumą. Bandomojo sprendimo perkėlimo į produktyvų darbą procese reikia papildomai patobulinti ryšių saugumą ir pateiktų metodų panaudojimą.
Svarbiausia, kad diegiant tokią sistemą galima apsieiti be programavimo, naudojant sistemos teikiamus nustatymus.
„Zabbix“ stebėjimo sistema suteikia keletą galimybių rinkti stebimos sistemos metriką. Tai galima padaryti tiesiogiai apklausiant valdomus pagrindinius kompiuterius arba naudojant pažangesnį duomenų siuntimo į serverį metodą per pagrindinio kompiuterio zabbix_sender, įskaitant žemo lygio aptikimo parametrų nustatymo metodus. Norint išspręsti mūsų problemą, gana tinka tiesioginio pagrindinio serverio apklausos metodas, nes tai leidžia visiškai kontroliuoti metrikos gavimo seką ir užtikrina vieno nustatymų / scenarijų paketo naudojimą, nereikalaujant jų platinti kiekvienam valdomam kompiuteriui.
Kaip „tyros kiaulytės“ sistemos derinimui ir konfigūravimui, mes naudojame WMS darbalapius priėmimui valdyti:
- Transporto priemonės priėmimo metu, visos atvykusios: Visos transporto priemonės, kurių būsenos laikotarpiui "- 72 valandos nuo dabartinio laiko" - SQL užklausos identifikatorius: gautiCars.
- Visų transporto priemonių būsenų istorija: visų transporto priemonių, atvykusių per 72 valandas, būsenos – SQL užklausos identifikatorius: automobiliaiIstorija.
- Suplanuotos transporto priemonės priimti: Visų transporto priemonių, kurių atvykimo būsena yra "Suplanuota", laiko intervalas "- 24 valandos" ir "+24 valandos" nuo dabartinio laiko - SQL užklausos identifikatorius: automobiliaiIn.
Taigi, apsisprendę dėl sandėlio veiklos metrikų rinkinio, paruošime SQL užklausas WMS duomenų bazei. Norint vykdyti užklausas, pageidautina naudoti ne pagrindinę duomenų bazę, o jos „karštą“ kopiją - budėjimo režimą.
Prisijungiama prie budėjimo režimo „Oracle“ DBMS, kad gautumėte duomenis. IP adresas prisijungti prie bandymų duomenų bazės 192.168.1.106. Ryšio parametrai išsaugomi Zabbix serveryje SQLcl darbo aplanko TNSNames.ORA:
# 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)
)
)Tai leis mums paleisti SQL užklausas kiekvienam kompiuteriui per EZconnect, nurodant tik prisijungimo vardą / slaptažodį ir duomenų bazės pavadinimą:
# sql znew/Zabmon1@WH1_1Paruoštos SQL užklausos išsaugomos Zabbix serverio darbo aplanke:
/etc/zabbix/sqlir leisti pasiekti mūsų serverio zabbix vartotoją:
# chown zabbix:zabbix -R /etc/zabbix/sqlUžklausos failai gauna unikalų identifikatoriaus pavadinimą, kurį turi pasiekti Zabbix serveris. Kiekviena duomenų bazės užklausa per SQLcl grąžina mums kelis parametrus. Atsižvelgdami į „Zabbix“, kuri užklausoje gali apdoroti tik vieną metriką, specifiką, naudosime papildomus scenarijus, kad išanalizuoti užklausos rezultatus į atskiras metrikas.
Ruošiame pagrindinį scenarijų, pavadinkime jį wh_Metrics.sh, kad iškviestume SQL užklausą į duomenų bazę, išsaugotume rezultatus ir pateiktume techninę metriką su duomenų gavimo sėkmės rodikliais:
#!/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
fiBaigtą failą su scenarijumi įdedame į išorinių scenarijų įdėjimo aplanką pagal „Zabbix-proxy“ konfigūracijos nustatymus (pagal numatytuosius nustatymus - /usr/local/share/zabbix/externalscripts).
Duomenų bazės, iš kurios scenarijus gaus rezultatus, identifikavimas bus perduodamas kaip scenarijaus parametras. Duomenų bazės identifikatorius turi atitikti nustatymų eilutę TNSNames.ORA faile.
SQL užklausos iškvietimo rezultatas išsaugomas peržiūros faile mon_base_id_main.log kur bazės_id = duomenų bazės identifikatorius gautas kaip scenarijaus parametras. Rezultatų failo atskyrimas pagal duomenų bazės identifikatorius numatytas tuo atveju, kai užklausos iš serverio vienu metu pateikiamos kelioms duomenų bazėms. Užklausa grąžina surūšiuotą dvimatį reikšmių masyvą.
Šis scenarijus, pavadinkime jį getMetrica.sh, reikalingas norint gauti nurodytą metriką iš failo su užklausos rezultatu:
#!/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
doneDabar esame pasiruošę nustatyti Zabbix ir pradėti stebėti sandėlio priėmimo procesų rodiklius.
Kiekviename duomenų bazės mazge yra įdiegtas ir sukonfigūruotas „Zabbix“ agentas.
Pagrindiniame serveryje mes apibrėžiame visus serverius su Zabbix tarpiniu serveriu. Norėdami nustatyti nustatymus, eikite į šį kelią:
Administravimas → Tarpinis serveris → Sukurti tarpinį serverį
Apibrėžkite valdomus pagrindinius kompiuterius:
Sąranka → Priegloba → Sukurti pagrindinį kompiuterį
Pagrindinio kompiuterio pavadinimas turi atitikti pagrindinio kompiuterio pavadinimą, nurodytą agento konfigūracijos faile.
Nurodykite mazgo grupę, taip pat mazgo IP adresą arba DNS pavadinimą iš duomenų bazės.
Sukurkite metrikas ir nurodykite jų savybes:
Nustatymai → Mazgai → 'host name' → Elementai> Sukurti elementą
1) Sukurkite pagrindinę metriką visų duomenų bazės parametrų užklausai
Nustatykite duomenų elemento pavadinimą, nurodykite tipą „Išorinis patikrinimas“. Lauke „Raktas“ apibrėžiame scenarijų, kuriam kaip parametrus perduodame Oracle duomenų bazės pavadinimą, sql užklausos pavadinimą, prisijungimo prie duomenų bazės prisijungimo vardą ir slaptažodį. Nustatykite užklausos atnaujinimo intervalą į 5 minutes (300 sekundžių).
2) Sukurkite kitas kiekvienos transporto priemonės būsenos metrikas. Šių metrikų reikšmės bus sugeneruotos remiantis pagrindinės metrikos patikrinimo rezultatu.
Nustatykite duomenų elemento pavadinimą, nurodykite tipą „Išorinis patikrinimas“. Lauke „Raktas“ apibrėžiame scenarijų, kuriam kaip parametrus perduodame Oracle duomenų bazės pavadinimą ir būsenos kodą, kurio reikšmę norime sekti. Užklausos atnaujinimo intervalą nustatome 10 sekundžių ilgiau nei pagrindinė metrika (310 sekundžių), kad rezultatai spėtų įrašyti į failą.
Norint teisingai gauti metriką, svarbu, kokia tvarka suaktyvinami patikrinimai. Kad išvengtume konfliktų priimant duomenis, pirmiausia scenarijaus iškvietimu aktyvuojame pagrindinę metriką GetCarsByStatus - wh_Metrics.sh.
Nustatymai → Mazgai → 'mazgo pavadinimas' → Elementai → Subfiltras „Išoriniai patikrinimai“. Pažymime reikiamą čekį ir spaudžiame „Suaktyvinti“.
Tada viena operacija suaktyviname likusias metrikas, pasirinkdami jas visas kartu:
Dabar „Zabbix“ pradėjo rinkti sandėlio verslo metriką.
Tolesniuose straipsniuose atidžiau pažvelgsime į Grafana ryšį ir sandėlio darbo informacinių skydelių formavimą įvairioms vartotojų kategorijoms. Taip pat „Grafana“ pagrindu įgyvendinama sandėlio darbo nukrypimų kontrolė ir, priklausomai nuo nukrypimų ribų ir dažnumo, įvykių registravimas sandėlio valdymo paslaugų centro sistemoje per API arba paprastas pranešimų siuntimas vadovui. elektroniniu paštu.
Šaltinis: www.habr.com