DIY: kiel ni aŭtomatigas magazenan monitoradon

X5 funkciigas 43 distribucentrojn kaj 4 el siaj propraj kamionoj, certigante seninterrompan provizon de produktoj al 029 butikoj. En ĉi tiu artikolo mi dividos mian sperton pri kreado de interaga sistemo por monitori magazenajn eventojn de nulo. La informoj estos utilaj al loĝistoj de komercaj kompanioj kun pluraj dekduoj da distribucentroj, kiuj administras ampleksan gamon de produktoj.

Kiel regulo, la konstruado de monitoraj kaj komercaj procezaj administradsistemoj komenciĝas per prilaborado de mesaĝoj kaj okazaĵoj. Samtempe, grava teknologia punkto rilata al la ebleco aŭtomatigi la fakton mem de okazo de komercaj eventoj kaj registrado de incidentoj estas maltrafita. Plej multaj komercaj sistemoj kiel WMS, TMS, ktp., havas enkonstruitajn ilojn por monitori siajn proprajn procezojn. Sed, se ĉi tiuj estas sistemoj de malsamaj fabrikantoj aŭ la monitora funkcio ne estas sufiĉe evoluinta, vi devas mendi multekostajn modifojn aŭ altiri specialigitajn konsultistojn por pliaj agordoj.

Ni konsideru aliron, en kiu ni bezonas nur malgrandan parton de la konsultado asociita kun identigaj fontoj (tabeloj) por akiri indikilojn de la sistemo.

La specifeco de niaj magazenoj estas, ke pluraj mastrumaj sistemoj (WMS Exceed) funkcias ĉe unu loĝistika komplekso. Stokejoj estas dividitaj laŭ kategorioj de stokado de varoj (sekaj, alkoholaj, frostitaj, ktp.) ne nur logike. Ene de unu loĝistika komplekso ekzistas pluraj apartaj stokkonstruaĵoj, ĉiu el kiuj estas administrita memstare WMS.

Por formi ĝeneralan bildon de la procezoj okazantaj en la magazeno, manaĝeroj analizas la raportadon de ĉiu WMS plurajn fojojn tage, prilaboras mesaĝojn de magazenfunkciigistoj (riceviloj, plukistoj, stakiloj) kaj resumas faktajn funkciajn indikilojn por reflektado sur la informtabulo.

Por ŝpari tempon de administrantoj, ni decidis evoluigi malmultekostan sistemon por operacia kontrolo de magazenaj eventoj. La nova sistemo, krom montri "varmajn" indikilojn de la funkcia agado de magazenaj procezoj, ankaŭ devus helpi administrantojn registri incidentojn kaj monitori la efektivigon de taskoj por forigi la kaŭzojn, kiuj influas la donitajn indikilojn. Farinte ĝeneralan revizion de la IT-arkitekturo de la kompanio, ni rimarkis, ke individuaj partoj de la bezonata sistemo jam ekzistas laŭ unu maniero aŭ alia en nia pejzaĝo kaj por ili estas kaj ekzameno de la agordoj kaj la necesaj subtenaj servoj. Restas nur alporti la tutan koncepton en ununuran arkitekturan solvon kaj taksi la amplekson de evoluo.

Post taksado de la kvanto da laboro, kiu devas esti farita por konstrui novan sistemon, oni decidis dividi la projekton en plurajn stadiojn:

1. Kolekto de indikiloj por magazenaj procezoj, bildigo kaj kontrolo de indikiloj kaj devioj
2. Aŭtomatigo de procezaj normoj kaj registrado de aplikoj en la komerca servo por devioj
3. Proaktiva monitorado kun ŝarĝoprognozo kaj kreado de rekomendoj por administrantoj.

En la unua etapo, la sistemo devas kolekti pretajn tranĉaĵojn de operaciaj datumoj de ĉiuj WMS de la komplekso. Legado okazas preskaŭ en reala tempo (intervaloj de malpli ol 5 minutoj). La lertaĵo estas, ke datumoj devas esti akiritaj de la DBMS de pluraj dekduoj da magazenoj kiam oni disfaldas la sistemon al la tuta reto. La ricevitaj operaciaj datumoj estas traktataj de la logiko de la sistema kerno por kalkuli deviojn de planitaj indikiloj kaj kalkuli statistikojn. La datumoj tiel prilaboritaj devas esti montrataj sur la tablojdo de la administranto aŭ sur la magazena informtabulo en formo de kompreneblaj grafikaĵoj kaj diagramoj.

Elektinte taŭgan sistemon por la pilota efektivigo de la unua etapo, ni elektis Zabbix. Ĉi tiu sistemo jam estas uzata por kontroli IT-agadon de stoksistemoj. Aldonante apartan instaladon por kolekti komercajn metrikojn de magazena operacio, vi povas akiri ĝeneralan bildon pri la sano de la magazeno.

La ĝenerala arkitekturo de la sistemo rezultis kiel en la figuro.

Ĉiu WMS-instanco estas difinita kiel gastiganto por la monitora sistemo. Metrikoj estas kolektitaj de centra servilo en la datumcentra reto rulante skripton kun preta SQL-demando. Se vi bezonas kontroli sistemon, kiu ne rekomendas rektan aliron al la datumbazo (ekzemple SAP EWM), vi povas uzi skriptovokojn al dokumentitaj API-funkcioj por akiri indikilojn aŭ skribi simplan programon en python/vbascript.

Zabbix prokura kazo estas deplojita en la stokreto por distribui la ŝarĝon de la ĉefa servilo. Per Proxy, laboro kun ĉiuj lokaj WMS-instancoj estas certigita. La venontan fojon kiam la Zabbix-servilo petas parametrojn, skripto estas ekzekutita sur la gastiganto kun Zabbix-prokurilo por peti metrikojn de la WMS-datumbazo.

Por montri grafikaĵojn kaj stokajn indikilojn sur la centra servilo Zabbix, ni deplojas Grafana. Krom montri pretajn panelojn kun infografioj pri magazenaj operacioj, Grafana estos uzata por monitori deviojn en indikiloj kaj sendi aŭtomatajn atentigojn al la magazena servosistemo por labori kun komercaj okazaĵoj.

Ekzemple, ni konsideru la efektivigon de ŝarĝa kontrolo en la magazena riceva areo. La jenaj estis elektitaj kiel la ĉefaj indikiloj de proceza agado en ĉi tiu areo de la magazeno:

• nombro da veturiloj en la akceptejo, konsiderante statusojn (planitaj, alvenintaj, dokumentoj, malŝarĝo, foriro;
• laborŝarĝo de lokigaj kaj replenigejoj (laŭ konservadkondiĉoj).

Agordoj

Instalado kaj agordo de la ĉefaj komponantoj de la sistemo (SQLcl, Zabbix, Grafana) estas priskribitaj en diversaj fontoj kaj ne estos ripetitaj ĉi tie. La uzo de SQLcl anstataŭ SQLplus estas pro tio, ke SQLcl (la komandlinia interfaco de la Oracle DBMS, skribita en java) ne postulas plian instaladon de la Oracle Kliento kaj funkcias ekster la skatolo.

Mi priskribos la ĉefajn punktojn, kiujn oni devas atenti kiam oni uzas Zabbix por monitori magazenajn komercajn procezajn indikilojn, kaj unu el la eblaj manieroj efektivigi ilin. Ankaŭ ĉi tio ne estas afiŝo pri sekureco. La sekureco de ligoj kaj la uzo de la prezentitaj metodoj postulas plian studon en la procezo de translokigo de la pilota solvo en produktan operacion.

La ĉefa afero estas, ke kiam oni efektivigas tian sistemon, oni povas fari sen programado, uzante la agordojn provizitajn de la sistemo.

La monitora sistemo Zabbix disponigas plurajn eblojn por kolekti metrikojn de la monitorita sistemo. Tio povas esti farita aŭ rekte voĉdonante monitoritajn gastigantojn, aŭ per pli progresinta metodo de sendado de datenoj al la servilo per zabbix_sender de la gastiganto, inkluzive de metodoj por agordi malaltnivelajn malkovrajn parametrojn. Por solvi nian problemon, la metodo de rekta balotado de gastigantoj per centra servilo estas sufiĉe taŭga, ĉar ĉi tio ebligas al vi akiri plenan kontrolon pri la sekvenco de akiro de metrikoj kaj certigas, ke vi uzas unu aron da agordoj/skriptoj sen la bezono distribui ilin al ĉiu monitorita gastiganto.

Kiel "testsubjektoj" por elpurigi kaj agordi la sistemon, ni uzas WMS-laborfolion por akcepta administrado:

1. Veturiloj ĉe akceptejo, ĉiuj alvenintaj: Ĉiuj veturiloj kun statusoj por la periodo "- 72 horoj de la nuna tempo" - SQL-demandidentigilo: getCars.
2. Historio de ĉiuj veturiloj: Statusoj de ĉiuj veturiloj alvenantaj ene de 72 horoj - SQL-demandidentigilo: aŭtomobilojHistorio.
3. Planitaj veturiloj por akcepto: Statuoj de ĉiuj veturiloj kun alveno en la "Planita" statuso, tempointervalo "- 24 horoj" kaj "+24 horoj" de la nuna tempo - SQL-demandidentigilo: aŭtojEn.

Do, post kiam ni decidis pri aro de stokaj agado-metrikoj, ni preparos SQL-demandojn por la WMS-datumbazo. Por efektivigi demandojn, estas konsilinde uzi ne la ĉefan datumbazon, sed ĝian "varman" kopion - standby.

Ni konektas al standby Oracle DBMS por ricevi datumojn. IP-adreso por konektiĝi al la testa datumbazo 192.168.1.106. Ni konservas la konektajn parametrojn sur la servilo Zabbix en TNSNames.ORA de la labordosierujo de 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)
    )
  )

Ĉi tio permesos al ni ruli SQL-demandojn al ĉiu gastiganto per EZconnect, specifante nur la ensaluton/pasvorton kaj datumbazan nomon:

# sql znew/Zabmon1@WH1_1

Ni konservas la pretajn SQL-demandojn en la labordosierujo sur la servilo Zabbix:

/etc/zabbix/sql

kaj permesi aliron al la zabbix-uzanto de nia servilo:

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

Dosieroj kun petoj ricevas unikan identigilon-nomon por aliro de la Zabbix-servilo. Ĉiu datumbaza demando per SQLcl resendas al ni plurajn parametrojn. Konsiderante la specifaĵojn de Zabbix, kiu povas prilabori nur unu metrikon per peto, ni uzos pliajn skriptojn por analizi la serĉrezultojn en individuajn metrikojn.

Ni pretigu la ĉefan skripton, ni nomu ĝin wh_Metrics.sh, por voki SQL-demandon al la datumbazo, konservi la rezultojn kaj redoni teknikan metrikon kun indikiloj de la sukceso de datum-reakiro:

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

Ni metas la finitan dosieron kun la skripto en la dosierujon por stoki eksterajn skriptojn konforme al la agordoj de Zabbix-proxy (defaŭlte - /usr/local/share/zabbix/externalscripts).

La identigo de la datumbazo de kiu la skripto ricevos rezultojn estos pasita kiel skripto-parametro. La datumbaza ID devas kongrui kun la agorda linio en la dosiero TNSNames.ORA.

La rezulto de la SQL-demanda voko estas konservita en dosiero kiel mon_base_id_main.log kie bazo_id = La datumbaza identigilo ricevita kiel skriptoparametro. La divido de la rezultdosiero per datumbazaj identigiloj estas provizita en kazo de petoj de la servilo al pluraj datumbazoj samtempe. La demando liveras ordigitan dudimensian tabelon de valoroj.

La sekva skripto, ni nomu ĝin getMetrica.sh, estas necesa por akiri specifitan metrikon de dosiero kun la rezulto de peto:

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

Nun ni pretas agordi Zabbix kaj komenci monitori indikilojn de magazenaj akceptoprocezoj.

Zabbix-agento estas instalita kaj agordita sur ĉiu datumbaza nodo.

Sur la ĉefa servilo ni difinas ĉiujn servilojn kun Zabbix-prokurilo. Por agordoj, iru al la sekva vojo:

Administrado → Prokurilo → Krei prokurilon

Ni difinas kontrolitajn gastigantojn:

Agordoj → Gastigantoj → Krei gastiganton

La gastiga nomo devas kongrui kun la gastiga nomo kiu estas specifita en la agorda dosiero.

Ni specifas la grupon por la nodo, same kiel la IP-adreson aŭ DNS-nomon de la nodo kun la datumbazo.

Ni kreas metrikojn kaj specifas iliajn trajtojn:

Agordoj → Nodoj → 'nodonomo' → Datumoj>Krei Datumajn Erojn

1) Kreu ĉefan metrikon por pridemandi ĉiujn parametrojn el la datumbazo

Ni fiksas la nomon de la datuma elemento, indikas la tipon "Ekstera konfirmo". En la kampo "Ŝlosilo", ni difinas skripton, al kiu ni transdonas kiel parametrojn la nomon de la Oracle-datumbazo, la nomon de la sql-demando, la ensaluton kaj pasvorton por konektiĝi al la datumbazo. Agordu la demandan ĝisdatigintervalon al 5 minutoj (300 sekundoj).

2) Kreu la ceterajn metrikojn por ĉiu veturilo-statuso. La valoroj de ĉi tiuj metrikoj estos generitaj surbaze de la rezulto de kontrolado de la ĉefa metriko.

Ni fiksas la nomon de la datuma elemento, indikas la tipon "Ekstera konfirmo". En la kampo "Ŝlosilo", ni difinas skripton, al kiu ni transdonas kiel parametrojn la nomon de la Oracle-datumbazo kaj la statuskodon, kies valoron ni volas spuri. Ni fiksas la demandan ĝisdatigintervalon je 10 sekundoj pli longa ol la ĉefa metriko (310 sekundoj) por ke la rezultoj havu tempon por esti skribitaj al la dosiero.

Por akiri metrikojn ĝuste, la ordo en kiu ĉekoj estas aktivigitaj estas grava. Por eviti konfliktojn dum ricevado de datumoj, unue ni aktivigas la ĉefan metrikon GetCarsByStatus vokante la skripton - wh_Metrics.sh.

Agordoj → Nodoj → 'nodonomo' → Datumaj elementoj → Subfiltrilo “Eksteraj kontroloj”. Marku la bezonatan ĉekon kaj alklaku "Aktivigi".

Poste, ni aktivigas la ceterajn metrikojn en unu operacio, elektante ilin ĉiujn kune:

Nun Zabbix komencis kolekti stokajn komercajn metrikojn.

En la sekvaj artikoloj, ni rigardos pli detale pri konekto de Grafana kaj kreado de informaj paneloj de magazenaj operacioj por diversaj kategorioj de uzantoj. Grafana ankaŭ estas uzata por monitori deviojn en stokoperacioj kaj, depende de la limoj kaj ofteco de devioj, registri okazaĵojn en la stokadministradserva centrosistemo per API aŭ simple sendi sciigojn al la administranto retpoŝte.

fonto: www.habr.com