DIY: si e automatizojmë monitorimin e depove

X5 operon me 43 qendra shpërndarjeje dhe 4 kamionë të vet, duke siguruar furnizim të pandërprerë me produkte në 029 dyqane. Në këtë artikull do të ndaj përvojën time për krijimin e një sistemi interaktiv për monitorimin e ngjarjeve të magazinës nga e para. Informacioni do të jetë i dobishëm për logjistikët e kompanive tregtare me disa dhjetëra qendra shpërndarjeje që menaxhojnë një gamë të gjerë produktesh.

Si rregull, ndërtimi i sistemeve të monitorimit dhe menaxhimit të proceseve të biznesit fillon me përpunimin e mesazheve dhe incidenteve. Në të njëjtën kohë, mungon një pikë e rëndësishme teknologjike që lidhet me mundësinë e automatizimit të vetë faktit të ndodhjes së ngjarjeve të biznesit dhe regjistrimit të incidenteve. Shumica e sistemeve të biznesit si WMS, TMS, etj., kanë mjete të integruara për monitorimin e proceseve të tyre. Por, nëse këto janë sisteme nga prodhues të ndryshëm ose funksionaliteti i monitorimit nuk është zhvilluar mjaftueshëm, duhet të porosisni modifikime të shtrenjta ose të tërheqni konsulentë të specializuar për cilësime shtesë.

Le të shqyrtojmë një qasje në të cilën na duhet vetëm një pjesë e vogël e konsultimit të lidhur me identifikimin e burimeve (tabelave) për të marrë tregues nga sistemi.

Specifikimi i depove tona është se disa sisteme të menaxhimit të magazinës (WMS Exceed) funksionojnë në një kompleks logjistik. Magazinat ndahen sipas kategorive të magazinimit të mallrave (të thata, alkool, të ngrira, etj.) jo vetëm logjikisht. Brenda një kompleksi logjistik ka disa ndërtesa të veçanta magazine, secila prej të cilave menaxhohet nga WMS e saj.

Për të formuar një pamje të përgjithshme të proceseve që ndodhin në magazinë, menaxherët analizojnë raportimin e çdo WMS disa herë në ditë, përpunojnë mesazhet nga operatorët e magazinës (marrësit, mbledhësit, grumbulluesit) dhe përmbledhin treguesit aktualë operacionalë për reflektim në tabelën e informacionit.

Për të kursyer kohën e menaxherëve, ne vendosëm të zhvillojmë një sistem të lirë për kontrollin operacional të ngjarjeve të magazinës. Sistemi i ri, përveç shfaqjes së treguesve “të nxehtë” të performancës operacionale të proceseve të magazinës, duhet të ndihmojë edhe menaxherët në regjistrimin e incidenteve dhe monitorimin e zbatimit të detyrave për eliminimin e shkaqeve që ndikojnë në treguesit e dhënë. Pas kryerjes së një auditimi të përgjithshëm të arkitekturës së IT të kompanisë, ne kuptuam se pjesë të veçanta të sistemit të kërkuar tashmë ekzistojnë në një mënyrë ose në një tjetër në peizazhin tonë dhe për ta ekziston edhe një ekzaminim i cilësimeve dhe shërbimet e nevojshme mbështetëse. E tëra që mbetet është të sjellim të gjithë konceptin në një zgjidhje të vetme arkitekturore dhe të vlerësojmë shtrirjen e zhvillimit.

Pas vlerësimit të sasisë së punës që duhet bërë për të ndërtuar një sistem të ri, u vendos që projekti të ndahej në disa faza:

1. Mbledhja e treguesve për proceset e magazinës, vizualizimi dhe kontrolli i treguesve dhe devijimeve
2. Automatizimi i standardeve të procesit dhe regjistrimi i aplikacioneve në shërbimin e shërbimeve të biznesit për devijimet
3. Monitorim proaktiv me parashikim të ngarkesës dhe krijimi i rekomandimeve për menaxherët.

Në fazën e parë, sistemi duhet të mbledhë pjesë të përgatitura të të dhënave operative nga të gjitha WMS të kompleksit. Leximi ndodh pothuajse në kohë reale (intervale më pak se 5 minuta). Truku është se të dhënat duhet të merren nga DBMS e disa dhjetëra depove kur vendoset sistemi në të gjithë rrjetin. Të dhënat operative të marra përpunohen sipas logjikës së bërthamës së sistemit për të llogaritur devijimet nga treguesit e planifikuar dhe për të llogaritur statistikat. Të dhënat e përpunuara në këtë mënyrë duhet të shfaqen në tabletin e menaxherit ose në tabelën e informacionit të magazinës në formën e grafikëve dhe diagrameve të kuptueshme.

Kur zgjodhëm një sistem të përshtatshëm për zbatimin pilot të fazës së parë, ne zgjodhëm Zabbix. Ky sistem përdoret tashmë për të monitoruar performancën e IT të sistemeve të magazinës. Duke shtuar një instalim të veçantë për mbledhjen e matjeve të biznesit të funksionimit të magazinës, mund të merrni një pamje të përgjithshme të shëndetit të magazinës.

Arkitektura e përgjithshme e sistemit doli si në figurë.

Çdo shembull WMS është përcaktuar si një host për sistemin e monitorimit. Metrikat mblidhen nga një server qendror në rrjetin e qendrës së të dhënave duke ekzekutuar një skript me një pyetje të përgatitur SQL. Nëse keni nevojë të monitoroni një sistem që nuk rekomandon qasje të drejtpërdrejtë në bazën e të dhënave (për shembull, SAP EWM), mund të përdorni thirrjet e skripteve për funksionet e dokumentuara të API për të marrë tregues ose për të shkruar një program të thjeshtë në python/vbascript.

Një shembull i përfaqësuesit Zabbix vendoset në rrjetin e magazinës për të shpërndarë ngarkesën nga serveri kryesor. Nëpërmjet Proxy, sigurohet puna me të gjitha instancat lokale të WMS. Herën tjetër që serveri Zabbix kërkon parametra, një skript ekzekutohet në host me përfaqësues Zabbix për të kërkuar metrikë nga baza e të dhënave WMS.

Për të shfaqur grafikët dhe treguesit e magazinës në serverin qendror Zabbix, ne vendosim Grafana. Krahas shfaqjes së tabelave të përgatitura me infografikë të funksionimit të magazinës, Grafana do të përdoret për monitorimin e devijimeve në tregues dhe dërgimin e sinjalizimeve automatike në sistemin e shërbimit të magazinës për punën me incidentet e biznesit.

Si shembull, le të shqyrtojmë zbatimin e kontrollit të ngarkesës në zonën e marrjes së magazinës. Si tregues kryesorë të performancës së procesit në këtë zonë të magazinës u zgjodhën si më poshtë:

• numri i automjeteve në zonën e pritjes, duke marrë parasysh statuset (të planifikuara, të mbërritura, dokumentet, shkarkimi, nisja;
• ngarkesa e punës së zonave të vendosjes dhe rimbushjes (sipas kushteve të ruajtjes).

Cilësimet

Instalimi dhe konfigurimi i komponentëve kryesorë të sistemit (SQLcl, Zabbix, Grafana) përshkruhet në burime të ndryshme dhe nuk do të përsëritet këtu. Përdorimi i SQLcl në vend të SQLplus është për shkak të faktit se SQLcl (ndërfaqja e linjës së komandës së Oracle DBMS, e shkruar në java) nuk kërkon instalim shtesë të Oracle Client dhe funksionon jashtë kutisë.

Unë do të përshkruaj pikat kryesore që duhet t'u kushtohet vëmendje kur përdorni Zabbix për të monitoruar treguesit e procesit të biznesit të magazinës dhe një nga mënyrat e mundshme për t'i zbatuar ato. Gjithashtu, ky nuk është një postim për sigurinë. Siguria e lidhjeve dhe përdorimi i metodave të paraqitura kërkon studim shtesë në procesin e transferimit të zgjidhjes pilot në funksionim produktiv.

Gjëja kryesore është që kur zbatoni një sistem të tillë, është e mundur të bëhet pa programim, duke përdorur cilësimet e ofruara nga sistemi.

Sistemi i monitorimit Zabbix ofron disa opsione për mbledhjen e metrikave nga sistemi i monitoruar. Kjo mund të bëhet ose duke anketuar drejtpërdrejt hostet e monitoruar, ose me një metodë më të avancuar të dërgimit të të dhënave në server nëpërmjet zabbix_sender të hostit, duke përfshirë metodat për konfigurimin e parametrave të zbulimit të nivelit të ulët. Për të zgjidhur problemin tonë, metoda e sondazhit të drejtpërdrejtë të hosteve nga një server qendror është mjaft e përshtatshme, sepse kjo ju lejon të fitoni kontroll të plotë mbi sekuencën e përvetësimit të metrikës dhe siguron që të përdorni një grup cilësimesh/skriptesh pa pasur nevojë t'i shpërndani ato në çdo host të monitoruar.

Si "subjekte testimi" për korrigjimin dhe konfigurimin e sistemit, ne përdorim fletën e punës WMS për menaxhimin e pranimit:

1. Automjetet në recepsion, të gjitha që kanë mbërritur: Të gjitha automjetet me status për periudhën “- 72 orë nga koha aktuale” - Identifikuesi i pyetjes SQL: merrni Makina.
2. Historia e të gjitha statuseve të automjeteve: Statuset e të gjitha automjeteve që mbërrijnë brenda 72 orëve - identifikuesi i pyetjes SQL: Historia e makinave.
3. Automjetet e planifikuara për pranim: Statuset e të gjitha automjeteve me mbërritje në statusin "Programuar", intervali kohor "- 24 orë" dhe "+24 orë" nga koha aktuale - identifikuesi i pyetjes SQL: makinaNë.

Pra, pasi të kemi vendosur për një grup metrikash të performancës së magazinës, ne do të përgatisim pyetje SQL për bazën e të dhënave WMS. Për të ekzekutuar pyetjet, këshillohet të përdorni jo bazën e të dhënave kryesore, por kopjen e saj "të nxehtë" - gatishmërinë.

Ne lidhemi me Oracle DBMS në pritje për të marrë të dhëna. Adresa IP për t'u lidhur me bazën e të dhënave të testimit 192.168.1.106. Ne i ruajmë parametrat e lidhjes në serverin Zabbix në TNSNames.ORA të dosjes së punës 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)
    )
  )

Kjo do të na lejojë të ekzekutojmë pyetje SQL për secilin host përmes EZconnect, duke specifikuar vetëm emrin e hyrjes/fjalëkalimit dhe emrin e bazës së të dhënave:

# sql znew/Zabmon1@WH1_1

Ne i ruajmë pyetjet e përgatitura SQL në dosjen e punës në serverin Zabbix:

/etc/zabbix/sql

dhe lejoni aksesin te përdoruesi zabbix i serverit tonë:

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

Skedarët me kërkesa marrin një emër unik identifikues për qasje nga serveri Zabbix. Çdo pyetje e bazës së të dhënave nëpërmjet SQLcl na kthen disa parametra. Duke marrë parasysh specifikat e Zabbix, i cili mund të përpunojë vetëm një metrikë për kërkesë, ne do të përdorim skripta shtesë për të analizuar rezultatet e pyetjes në metrika individuale.

Le të përgatisim skriptin kryesor, le ta quajmë wh_Metrics.sh, për të thirrur një pyetje SQL në bazën e të dhënave, për të ruajtur rezultatet dhe për të kthyer një metrikë teknike me tregues të suksesit të rikthimit të të dhënave:

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

Ne e vendosim skedarin e përfunduar me skriptin në dosjen për ruajtjen e skripteve të jashtme në përputhje me cilësimet e konfigurimit të përfaqësuesit Zabbix (si parazgjedhje - /usr/local/share/zabbix/externalscripts).

Identifikimi i bazës së të dhënave nga e cila skripti do të marrë rezultatet do të kalohet si një parametër skripti. ID-ja e bazës së të dhënave duhet të përputhet me linjën e cilësimeve në skedarin TNSNames.ORA.

Rezultati i thirrjes së pyetjes SQL ruhet në një skedar si mon_base_id_main.log ku base_id = Identifikuesi i bazës së të dhënave është marrë si një parametër skripti. Ndarja e skedarit të rezultateve sipas identifikuesve të bazës së të dhënave sigurohet në rast të kërkesave nga serveri në disa baza të dhënash njëkohësisht. Pyetja kthen një grup vlerash dydimensionale të renditura.

Skripti i mëposhtëm, le ta quajmë getMetrica.sh, nevojitet për të marrë një metrikë të specifikuar nga një skedar me rezultatin e një kërkese:

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

Tani jemi gati të konfigurojmë Zabbix dhe të fillojmë monitorimin e treguesve të proceseve të pranimit të magazinës.

Një agjent Zabbix është instaluar dhe konfiguruar në secilën nyje të bazës së të dhënave.

Në serverin kryesor ne përcaktojmë të gjithë serverët me proxy Zabbix. Për cilësimet, shkoni në shtegun e mëposhtëm:

Administrimi → Proxy → Krijo përfaqësues

Ne përcaktojmë hostet e kontrolluar:

Cilësimet → Hosts → Krijo host

Emri i hostit duhet të përputhet me emrin e hostit që është specifikuar në skedarin e konfigurimit të agjentit.

Ne specifikojmë grupin për nyjen, si dhe adresën IP ose emrin DNS të nyjes me bazën e të dhënave.

Ne krijojmë metrikë dhe specifikojmë vetitë e tyre:

Cilësimet → Nyjet → 'emri i nyjes' → Artikujt e të dhënave>Krijoni artikullin e të dhënave

1) Krijoni një metrikë kryesore për të kërkuar të gjithë parametrat nga baza e të dhënave

Ne vendosim emrin e elementit të të dhënave, tregojmë llojin "Verifikimi i jashtëm". Në fushën "Key", ne përcaktojmë një skript të cilit i kalojmë si parametra emrin e bazës së të dhënave Oracle, emrin e pyetjes sql, hyrjen dhe fjalëkalimin për t'u lidhur me bazën e të dhënave. Cakto intervalin e përditësimit të pyetjeve në 5 minuta (300 sekonda).

2) Krijoni metrikat e mbetura për çdo status automjeti. Vlerat e këtyre metrikës do të gjenerohen në bazë të rezultatit të kontrollit të metrikës kryesore.

Ne vendosim emrin e elementit të të dhënave, tregojmë llojin "Verifikimi i jashtëm". Në fushën "Key", ne përcaktojmë një skript të cilit i kalojmë si parametra emrin e bazës së të dhënave Oracle dhe kodin e statusit, vlerën e të cilit duam të gjurmojmë. Ne vendosëm intervalin e përditësimit të pyetjes në 10 sekonda më të gjatë se metrika kryesore (310 sekonda) në mënyrë që rezultatet të kenë kohë për t'u shkruar në skedar.

Për të marrë saktë metrikat, është e rëndësishme rendi në të cilin aktivizohen kontrollet. Për të shmangur konfliktet gjatë marrjes së të dhënave, para së gjithash aktivizojmë metrikën kryesore GetCarsByStatus duke thirrur skriptin - wh_Metrics.sh.

Cilësimet → Nyjet → 'emri i nyjes' → Elementet e të dhënave → Nënfiltri "Kontrollet e jashtme". Shënoni kontrollin e kërkuar dhe klikoni "Aktivizo".

Më pas, ne aktivizojmë matjet e mbetura në një operacion, duke i zgjedhur të gjitha së bashku:

Tani Zabbix ka filluar të mbledhë matjet e biznesit të magazinës.

Në artikujt e mëposhtëm do t'i hedhim një vështrim më të afërt lidhjes së Grafana-s dhe krijimit të tabelave të informacionit të operacioneve të magazinës për kategori të ndryshme përdoruesish. Grafana përdoret gjithashtu për të monitoruar devijimet në operacionet e magazinës dhe, në varësi të kufijve dhe shpeshtësisë së devijimeve, regjistron incidente në sistemin e qendrës së shërbimit të menaxhimit të magazinës nëpërmjet API ose thjesht dërgoni njoftime te menaxheri me email.

Burimi: www.habr.com