X5 haldab 43 jaotuskeskust ja 4 oma veoautot, tagades 029 15 kaupluse katkematu kaubavarustuse. Selles artiklis jagan oma kogemusi interaktiivse süsteemi loomisel laosündmuste nullist jälgimiseks. Teave on kasulik mitmekümne laia tootevalikuga turustuskeskusega kaubandusettevõtete logistikutele.
Seire- ja äriprotsesside juhtimissüsteemide ehitamine algab reeglina sõnumite ja juhtumite töötlemisest. Samal ajal jääb märkamata oluline tehnoloogiline punkt, mis on seotud võimalusega automatiseerida ärisündmuste toimumise fakti ja fikseerida intsidente. Enamikul ärisüsteemidel, nagu WMS, TMS jne, on sisseehitatud tööriistad oma protsesside jälgimiseks. Kui aga tegemist on erinevate tootjate süsteemidega või seirefunktsioonid pole piisavalt arenenud, tuleb tellida kallid muudatused või meelitada lisaseadete tegemiseks spetsialiseerunud konsultante.
Vaatleme lähenemist, mille puhul vajame vaid väikest osa allikate (tabelite) tuvastamisega seotud konsultatsioonist, et saada süsteemist indikaatoreid.
Meie ladude eripära seisneb selles, et ühes logistikakompleksis töötab mitu laohaldussüsteemi (WMS Exceed). Laod jagunevad kaupade ladustamise kategooriate järgi (kuiv, alkohol, külmutatud jne) mitte ainult loogiliselt. Ühes logistikakompleksis on mitu eraldi laohoonet, millest igaüht haldab oma WMS.
Laos toimuvatest protsessidest üldpildi kujundamiseks analüüsivad juhid iga WMS-i aruandlust mitu korda päevas, töötlevad laooperaatoritelt (vastuvõtjad, komplekteerijad, virnastajad) sõnumeid ning võtavad infotahvlil kajastamiseks kokku tegelikud töönäitajad.
Juhtide aja säästmiseks otsustasime välja töötada odava süsteemi laosündmuste operatiivjuhtimiseks. Uus süsteem peaks lisaks laoprotsesside operatiivse toimivuse "kuumate" näitajate kuvamisele aitama juhte ka intsidentide fikseerimisel ja ülesannete täitmise jälgimisel, et kõrvaldada antud näitajaid mõjutavaid põhjuseid. Pärast ettevõtte IT-arhitektuuri üldauditit saime aru, et meie maastikul on nõutava süsteemi üksikud osad ühel või teisel viisil juba olemas ja nende jaoks toimub nii seadete ülevaatus kui ka vajalikud tugiteenused. Jääb vaid viia kogu kontseptsioon ühtsesse arhitektuursesse lahendusse ja hinnata arendusmahtu.
Pärast uue süsteemi ehitamiseks vajamineva töö mahu hindamist otsustati projekt jagada mitmeks etapiks:
- Laoprotsesside indikaatorite kogumine, näitajate ja kõrvalekallete visualiseerimine ja kontroll
- Protsessistandardite automatiseerimine ja taotluste registreerimine äriteenuste teenuses kõrvalekallete tuvastamiseks
- Proaktiivne jälgimine koos koormuse prognoosimise ja juhtidele soovituste loomisega.
Esimeses etapis peab süsteem koguma ettevalmistatud lõigud tööandmetest kõigist kompleksi WMS-idest. Lugemine toimub peaaegu reaalajas (intervallidega alla 5 minuti). Nipp seisneb selles, et süsteemi kogu võrku juurutamisel tuleb andmeid hankida mitmekümne lao DBMS-ist. Saadud tööandmeid töödeldakse süsteemituuma loogika abil, et arvutada kõrvalekalded planeeritud näitajatest ja arvutada statistikat. Sel viisil töödeldud andmed peavad olema kuvatud juhi tahvelarvutis või lao infotahvlil arusaadavate graafikute ja diagrammidena.
Esimese etapi pilootrakenduseks sobiva süsteemi valimisel valisime Zabbixi. Seda süsteemi kasutatakse juba laosüsteemide IT-tegevuse jälgimiseks. Lisades eraldi installatsiooni laotegevuse ärimõõdikute kogumiseks, saate lao seisundist üldpildi.
Süsteemi üldine arhitektuur osutus selliseks nagu joonisel.
Iga WMS-i eksemplar määratletakse jälgimissüsteemi hostina. Mõõdikud kogub andmekeskuse võrgu keskserver, käivitades ettevalmistatud SQL-päringuga skripti. Kui teil on vaja jälgida süsteemi, mis ei soovita otsejuurdepääsu andmebaasile (näiteks SAP EWM), saate indikaatorite hankimiseks kasutada dokumenteeritud API funktsioonide skriptikutseid või kirjutada lihtsat programmi python/vbascriptis.
Laovõrku juurutatakse Zabbixi puhverserveri eksemplar, et jagada põhiserveri koormust. Proxy kaudu on tagatud töö kõigi kohalike WMS-i eksemplaridega. Järgmine kord, kui Zabbixi server parameetreid küsib, käivitatakse Zabbixi puhverserveriga hostis skript, et nõuda WMS-i andmebaasist mõõdikuid.
Graafikute ja laonäitajate kuvamiseks Zabbixi keskserveris juurutame Grafana. Lisaks ettevalmistatud armatuurlaudade kuvamisele laotoimingute infograafikaga, kasutatakse Grafanat indikaatorite kõrvalekallete jälgimiseks ja automaatsete hoiatuste saatmiseks lao teenindussüsteemi ärijuhtumitega töötamiseks.
Vaatleme näiteks koormuse juhtimise rakendamist lao vastuvõtualal. Selle laopiirkonna protsessi jõudluse peamisteks näitajateks valiti järgmised:
- sõidukite arv vastuvõtualal, võttes arvesse olekuid (planeeritud, saabunud, dokumendid, mahalaadimine, lahkumine;
- paigutus- ja täiendusalade töökoormus (vastavalt ladustamistingimustele).
Seaded
Süsteemi põhikomponentide (SQLcl, Zabbix, Grafana) installimist ja seadistamist on kirjeldatud erinevates allikates ja seda siin ei korrata. SQLcl-i kasutamine SQLplusi asemel tuleneb sellest, et SQLcl (Java keeles kirjutatud Oracle DBMS-i käsurea liides) ei nõua Oracle Clienti täiendavat installimist ja töötab karbist välja.
Kirjeldan põhipunkte, millele tuleks tähelepanu pöörata Zabbixi kasutamisel lao äriprotsesside indikaatorite jälgimisel ning üht võimalikku viisi nende rakendamiseks. Samuti pole see postitus turvalisusest. Ühenduste turvalisus ja esitatud meetodite kasutamine nõuab täiendavat uurimist pilootlahenduse produktiivsesse töösse viimise protsessis.
Peaasi, et sellise süsteemi juurutamisel saaks ilma programmeerimiseta hakkama, kasutades süsteemi poolt antud seadistusi.
Zabbixi seiresüsteem pakub jälgitavast süsteemist mõõdikute kogumiseks mitmeid võimalusi. Seda saab teha kas otse jälgitavate hostide küsitlemise teel või täpsema meetodi abil serverisse andmete saatmiseks hosti zabbix_sender kaudu, sealhulgas madala taseme avastusparameetrite konfigureerimise meetodid. Meie probleemi lahendamiseks on keskserveri poolt hostide otseküsitluse meetod üsna sobiv, kuna see võimaldab teil saavutada täieliku kontrolli mõõdikute hankimise jada üle ja tagab, et kasutate üht seadete/skriptide komplekti, ilma et peaksite neid igale jälgitavale hostile levitama.
Süsteemi silumise ja seadistamise katsealustena kasutame aktsepteerimise haldamiseks WMS-i töölehte:
- Sõidukid vastuvõtus, kõik, mis on saabunud: Kõik sõidukid, mille olekud perioodiks “- 72 tundi praegusest kellaajast” – SQL päringu identifikaator: hankige Cars.
- Kõikide sõidukite olekute ajalugu: kõigi 72 tunni jooksul saabunud sõidukite olekud – SQL päringu identifikaator: autode ajalugu.
- Plaanitud sõidukid vastuvõtmiseks: kõigi sõidukite olekud, mille saabumise olek on "Praegune", ajavahemik "- 24 tundi" ja "+24 tundi" praegusest kellaajast - SQL päringu identifikaator: autodIn.
Seega, kui oleme otsustanud lao jõudlusmõõdikute komplekti, valmistame ette SQL-päringud WMS-i andmebaasi jaoks. Päringute täitmiseks on soovitatav kasutada mitte põhiandmebaasi, vaid selle "kuum" koopiat - ooterežiimi.
Andmete vastuvõtmiseks loome ühenduse ooterežiimis Oracle DBMS-iga. IP-aadress testandmebaasiga ühenduse loomiseks 192.168.1.106. Salvestame ühenduse parameetrid Zabbixi serverisse SQLcl-i töökausta TNSNames.ORA-sse:
# 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)
)
)See võimaldab meil EZconnecti kaudu käivitada igasse hosti SQL-päringud, määrates ainult sisselogimise/parooli ja andmebaasi nime:
# sql znew/Zabmon1@WH1_1Ettevalmistatud SQL-päringud salvestame Zabbixi serveri töökausta:
/etc/zabbix/sqlja lubage juurdepääs meie serveri zabbixi kasutajale:
# chown zabbix:zabbix -R /etc/zabbix/sqlPäringutega failid saavad Zabbixi serverist juurdepääsuks kordumatu identifikaatori-nime. Iga andmebaasi päring SQLcl-i kaudu tagastab meile mitu parameetrit. Võttes arvesse Zabbixi eripära, mis suudab ühe päringu kohta töödelda ainult ühte mõõdikut, kasutame päringutulemuste analüüsimiseks üksikuteks mõõdikuteks täiendavaid skripte.
Valmistame ette põhiskripti, nimetagem seda wh_Metrics.sh, et kutsuda andmebaasi SQL-päring, salvestada tulemused ja tagastada tehniline mõõdik andmete taastamise edukuse näitajatega:
#!/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
fiAsetame valmis faili koos skriptiga kausta väliste skriptide salvestamiseks vastavalt Zabbixi puhverserveri konfiguratsiooniseadetele (vaikimisi - /usr/local/share/zabbix/externalscripts).
Andmebaasi identifitseerimine, kust skript tulemused saavad, edastatakse skriptiparameetrina. Andmebaasi ID peab ühtima faili TNSNames.ORA sätete reaga.
SQL-i päringukõne tulemus salvestatakse faili nagu mon_base_id_main.log kus base_id = Skriptiparameetrina vastu võetud andmebaasi identifikaator. Tulemusfaili jagamine andmebaasi identifikaatorite järgi on ette nähtud juhul, kui serverist tuleb päringuid korraga mitmesse andmebaasi. Päring tagastab sorteeritud kahemõõtmelise väärtuste massiivi.
Järgmist skripti, nimetagem seda getMetrica.sh-ks, on vaja päringu tulemusega failist määratud mõõdiku saamiseks:
#!/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
doneNüüd oleme valmis Zabbixi seadistama ja alustama lao vastuvõtu protsesside indikaatorite jälgimist.
Zabbixi agent on installitud ja konfigureeritud igasse andmebaasisõlme.
Põhiserveris määratleme kõik serverid Zabbixi puhverserveri abil. Seadete jaoks minge järgmisele teele:
Administreerimine → Puhverserver → Loo puhverserver
Me määratleme kontrollitud hostid:
Seaded → Hostid → Loo host
Hostinimi peab ühtima agendi konfiguratsioonifailis määratud hostinimega.
Määrame sõlme grupi, samuti andmebaasiga sõlme IP-aadressi või DNS-nime.
Loome mõõdikuid ja täpsustame nende omadused:
Seaded → Sõlmed → 'sõlme nimi' → Andmeüksused> Loo andmeüksus
1) Looge põhimõõdik kõigi parameetrite päringute tegemiseks andmebaasist
Määrame andmeelemendi nime, märgime tüübi "Väline kontroll". Väljal “Võti” määratleme skripti, millele edastame parameetritena Oracle'i andmebaasi nime, sql-päringu nime, andmebaasiga ühenduse loomise sisselogimise ja parooli. Määra päringu värskendamise intervalliks 5 minutit (300 sekundit).
2) Looge iga sõiduki oleku jaoks ülejäänud mõõdikud. Nende mõõdikute väärtused genereeritakse põhimõõdiku kontrollimise tulemuste põhjal.
Määrame andmeelemendi nime, märgime tüübi "Väline kontroll". Väljal "Võti" määratleme skripti, millele edastame parameetritena Oracle'i andmebaasi nime ja olekukoodi, mille väärtust soovime jälgida. Seadsime päringu uuendamise intervalli 10 sekundit pikemaks kui põhimõõdik (310 sekundit), et tulemused jõuaksid faili kirjutada.
Mõõdikute korrektseks saamiseks on oluline kontrollide aktiveerimise järjekord. Et vältida konflikte andmete vastuvõtmisel, aktiveerime esmalt peamise mõõdiku GetCarsByStatus, kutsudes välja skripti - wh_Metrics.sh.
Seadistused → Sõlmed → 'sõlme nimi' → Andmeelemendid → Alamfilter “Välised kontrollid”. Märkige nõutav linnuke ja klõpsake nuppu "Aktiveeri".
Järgmisena aktiveerime ülejäänud mõõdikud ühe toiminguga, valides need kõik koos:
Nüüd on Zabbix alustanud lao ärimõõdikute kogumist.
Järgmistes artiklites vaatleme lähemalt Grafana ühendamist ja laotoimingute infopaneelide loomist erinevatele kasutajakategooriatele. Samuti on Grafana baasil juurutatud laotoimingute kõrvalekallete jälgimine ning olenevalt kõrvalekallete piiridest ja korratavusest laohalduse teeninduskeskuse süsteemis vahejuhtumite registreerimine API kaudu või lihtsalt teadete saatmine juhatajale meili teel.
Allikas: www.habr.com