DIY: hoe ons pakhuismonitering outomatiseer

X5 bestuur 43 verspreidingsentrums en 4 029 van sy eie vragmotors, wat ononderbroke voorsiening van produkte aan 15 752 winkels verseker. In die artikel sal ek my ervaring van die skep van 'n interaktiewe pakhuisgebeurtenismoniteringstelsel van nuuts af deel. Die inligting sal nuttig wees vir logistieke van handelsondernemings met 'n paar dosyn verspreidingsentrums wat 'n wye reeks produkte bestuur.

As 'n reël begin die konstruksie van stelsels vir die monitering en bestuur van besigheidsprosesse met die verwerking van boodskappe en voorvalle. Dit mis 'n belangrike tegnologiese punt wat verband hou met die moontlikheid om die feit van die voorkoms van besigheidsgebeurtenisse te outomatiseer en voorvalle te registreer. Die meeste besigheidstelsels van die WMS, TMS, ens.-klas het ingeboude gereedskap om hul eie prosesse te monitor. Maar as dit stelsels van verskillende vervaardigers is of die moniteringsfunksie nie voldoende ontwikkel is nie, moet jy duur verbeterings bestel of gespesialiseerde konsultante vir bykomende instellings betrek.

Kom ons kyk na 'n benadering waarin ons slegs 'n klein deel van konsultasie benodig wat verband hou met die definisie van bronne (tabelle) vir die verkryging van aanwysers uit die stelsel.

Die spesifisiteit van ons pakhuise lê in die feit dat verskeie pakhuisbestuurstelsels (WMS Exceed) by een logistieke kompleks werk. Pakhuise word verdeel volgens die kategorieë van berging van goedere (droog, alkohol, vries, ens.) Nie net logies nie. Binne een logistieke kompleks is daar verskeie afsonderlike pakhuisgeboue, bedrywighede op elkeen word deur hul eie WMS beheer.

Om 'n algemene prentjie te vorm van die prosesse wat in die pakhuis plaasvind, ontleed bestuurders 'n paar keer per dag die verslae van elke WMS, verwerk die boodskappe van die pakhuisoperateurs (ontvangers, plukkers, stapelaars) en som die werklike operasionele aanwysers op vir besinning oor die inligtingsbord.

Om tyd vir bestuurders te bespaar, het ons besluit om 'n goedkoop stelsel vir operasionele beheer van pakhuisgebeure te ontwikkel. Die nuwe stelsel, benewens die vertoon van "warm" aanwysers van die operasionele werk van pakhuisprosesse, behoort ook bestuurders te help om insidente reg te stel en die implementering van take te monitor om die oorsake wat die gespesifiseerde aanwysers beïnvloed, uit te skakel. Nadat ons 'n algemene oudit van die maatskappy se IT-argitektuur uitgevoer het, het ons besef dat sekere dele van die vereiste stelsel reeds op een of ander manier in ons landskap bestaan, en vir hulle is daar sowel 'n ondersoek na die instellings as die nodige ondersteuningsdienste. Dit bly net om die hele konsep in 'n enkele argitektoniese oplossing te bring en die omvang van ontwikkeling te evalueer.

Na die beoordeling van die hoeveelheid werk wat gedoen moet word om 'n nuwe stelsel te bou, is besluit om die projek in verskeie fases op te deel:

1. Versameling van aanwysers vir pakhuisprosesse, visualisering en beheer van aanwysers en afwykings
2. Outomatisering van prosesregulasies en registrasie van versoeke in die besigheidsdienstediens vir afwykings
3. Proaktiewe monitering met vragvooruitskatting en die maak van aanbevelings aan bestuurders.

In die eerste stadium moet die stelsel voorbereide snye operasionele data van alle WMS van die kompleks versamel. Lees vind byna intyds plaas (intervalle minder as 5 minute). Die truuk is dat data van die DBBS van 'n paar dosyn pakhuise verkry moet word wanneer die stelsel na die hele netwerk ontplooi word. Die ontvangde operasionele data word deur die logika van die stelselkern verwerk om afwykings van die beplande aanwysers te bereken en statistieke te bereken. Die data wat so verwerk word, moet in die vorm van verstaanbare grafieke en diagramme op die bestuurder se tablet of op die inligtingsbord van die pakhuis vertoon word.

Toe ons 'n variant van 'n geskikte stelsel vir die loodsimplementering van die eerste fase gekies het, het ons op Zabbix gevestig. Hierdie stelsel word reeds gebruik om die IT-werkverrigting van pakhuisstelsels te monitor. Deur 'n aparte installasie by te voeg om pakhuisbesigheidsstatistieke in te samel, kan u 'n algehele prentjie van pakhuisgesondheid kry.

Die algemene argitektuur van die stelsel het uitgedraai soos in die figuur.

Elke WMS-instansie word gedefinieer as 'n gasheer vir die moniteringstelsel. Metrieke word deur 'n sentrale bediener in die datasentrumnetwerk ingesamel deur 'n skrip met 'n voorbereide SQL-navraag uit te voer. As jy 'n stelsel moet monitor wat nie direkte toegang tot die databasis aanbeveel nie (byvoorbeeld SAP EWM), kan jy script-oproepe na gedokumenteerde API-funksies gebruik om aanwysers te kry of 'n eenvoudige python/vbascript-program te skryf.

'n Zabbix-instaanbediener-instansie word in die pakhuisnetwerk ontplooi om die las vanaf die hoofbediener te versprei. Proxy verskaf werk met alle plaaslike gevalle van WMS. Wanneer die Zabbix-bediener volgende parameters versoek, word 'n skrip op die gasheer uitgevoer met Zabbix-instaanbediener om maatstawwe vanaf die WMS-databasis te versoek.

Ontplooi Grafana om grafieke en pakhuisaanwysers op die sentrale Zabbix-bediener te vertoon. Benewens die vertoon van voorbereide kontroleskerms met pakhuisbedryfinfografika, sal Grafana gebruik word om afwykings in aanwysers te beheer en outomatiese waarskuwings na die pakhuisdiensstelsel oor te dra om met besigheidsinsidente te werk.

As 'n voorbeeld, kom ons kyk na die implementering van laaibeheer van die pakhuisontvangsarea. Die volgende is gekies as die hoofaanwysers van die prosesse in hierdie afdeling van die pakhuis:

• die aantal voertuie in die aanvaardingsgebied, met inagneming van die statusse (beplan, aangekom, dokumente, aflaai, vertrek;
• werklading van verblyf en aanvullingsareas (volgens bergingstoestande).

Stellings

Installasie en konfigurasie van die hoofkomponente van die stelsel (SQLcl, Zabbix, Grafana) word in verskeie bronne beskryf en ons sal nie hier herhaal nie. Die gebruik van SQLcl in plaas van SQLplus is te wyte aan die feit dat SQLcl (Oracle DBMS command line koppelvlak geskryf in Java) nie addisionele Oracle Client installasie vereis nie en uit die boks werk.

Ek sal die hoofpunte beskryf waaraan u moet let wanneer u Zabbix gebruik om pakhuisbesigheidsproses-aanwysers te monitor, en een van die moontlike maniere om dit te implementeer. Hierdie pos gaan ook nie oor sekuriteit nie. Die sekuriteit van verbindings en die gebruik van die voorgestelde metodes benodig bykomende uitwerking in die proses om die loodsoplossing na produktiewe werking oor te dra.

Die belangrikste ding is dat wanneer u so 'n stelsel implementeer, dit moontlik is om sonder programmering te doen, met behulp van die instellings wat deur die stelsel verskaf word.

Die Zabbix-moniteringstelsel bied verskeie opsies om gemonitorde stelselstatistieke in te samel. Dit kan gedoen word óf deur beheerde gashere direk te stem, óf deur 'n meer gevorderde metode om data na die bediener te stuur via die gasheer se zabbix_sender, insluitend metodes om lae-vlak ontdekking parameters in te stel. Om ons probleem op te los, is die metode van direkte peiling van gashere deur die sentrale bediener baie geskik, want dit laat jou toe om volle beheer te hê oor die volgorde van die verkryging van metrieke en verseker die gebruik van een pakket instellings / skrifte sonder dat dit nodig is om dit na elke beheerde gasheer te versprei.

As "proefkonyne" vir ontfouting en konfigurasie van die stelsel, gebruik ons ​​WMS-werkblaaie om aanvaarding te bestuur:

1. Voertuie met aanvaarding, alles wat aangekom het: Alle voertuie met statusse vir die tydperk "- 72 uur vanaf die huidige tyd" - identifiseerder van die SQL-navraag: kry Motors.
2. Geskiedenis van alle voertuigstatusse: Statusse van alle voertuie met aankoms binne 72 uur — SQL-navraagidentifiseerder: motors Geskiedenis.
3. Geskeduleerde voertuie vir aanvaarding: Statusse van alle voertuie met aankoms in die "Geskeduleerde" status, tydinterval "- 24 uur" en "+24 uur" vanaf die huidige tyd - SQL-navraagidentifiseerder: motors In.

Dus, nadat ons besluit het op 'n stel pakhuisoperasie-metrieke, sal ons SQL-navrae vir die WMS-databasis voorberei. Om navrae uit te voer, is dit wenslik om nie die hoofdatabasis te gebruik nie, maar sy "warm" kopie - bystand.

Koppel tans aan bystand Oracle DBMS om data te kry. IP-adres om aan die toetsdatabasis te koppel 192.168.1.106. Die verbindingsparameters word op die Zabbix-bediener in TNSNames.ORA van die SQLcl-werklêer gestoor:

# 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)
    )
  )

Dit sal ons toelaat om SQL-navrae na elke gasheer te laat loop deur EZconnect, wat slegs die aanmeld/wagwoord en die databasisnaam spesifiseer:

# sql znew/Zabmon1@WH1_1

Voorbereide SQL-navrae word in die werkmap op die Zabbix-bediener gestoor:

/etc/zabbix/sql

en laat toegang toe tot die zabbix-gebruiker van ons bediener:

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

Versoeklêers ontvang 'n unieke identifiseerder-naam wat deur die Zabbix-bediener verkry kan word. Elke navraag na die databasis deur SQLcl gee ons verskeie parameters terug. Met inagneming van die besonderhede van Zabbix, wat slegs een maatstaf in 'n versoek kan verwerk, sal ons bykomende skrifte gebruik om die navraagresultate in aparte maatstawwe te ontleed.

Ons berei die hoofskrif voor, kom ons noem dit wh_Metrics.sh, om 'n SQL-navraag na die databasis te roep, die resultate te stoor en 'n tegniese maatstaf terug te gee met aanwysers van die sukses van die verkryging van data:

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

Ons plaas die voltooide lêer met die skrif in die gids vir die plasing van eksterne skrifte in ooreenstemming met die Zabbix-instaanbediener-konfigurasie-instellings (by verstek - /usr/local/share/zabbix/externalscripts).

Die identifikasie van die databasis waaruit die skrip resultate sal kry, sal as 'n skripparameter deurgegee word. Die databasis-identifiseerder moet ooreenstem met die instellingstring in die TNSNames.ORA-lêer.

Die resultaat van die SQL-navraagoproep word in die aansiglêer gestoor mon_base_id_main.log waar base_id = databasis identifiseerder ontvang as 'n script parameter. Skeiding van die resultaatlêer deur databasisidentifiseerders word verskaf vir die geval van versoeke vanaf die bediener gelyktydig na verskeie databasisse. Die navraag gee 'n gesorteerde tweedimensionele reeks waardes terug.

Die volgende skrif, kom ons noem dit getMetrica.sh, is nodig om 'n gegewe metriek uit 'n lêer met 'n navraagresultaat te kry:

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

Nou is ons gereed om Zabbix op te stel en die aanwysers van die pakhuisontvangsprosesse te begin monitor.

Elke databasisnodus het 'n Zabbix-agent geïnstalleer en gekonfigureer.

Op die hoofbediener definieer ons alle bedieners met Zabbix-instaanbediener. Vir instellings, gaan na die volgende pad:

Administrasie → Volmag → Skep instaanbediener

Definieer beheerde gashere:

Opstelling → Gashere → Skep gasheer

Die gasheernaam moet ooreenstem met die gasheernaam wat in die agent se konfigurasielêer gespesifiseer is.

Spesifiseer die groep vir die nodus, sowel as die IP-adres of DNS-naam van die nodus vanaf die databasis.

Skep maatstawwe en spesifiseer hul eienskappe:

Instellings → Nodes → 'gasheernaam' → Items>Skep item

1) Skep 'n hoofmetriek om alle parameters vanaf die databasis te bevraagteken

Stel die naam van die data-element, spesifiseer die tipe "Eksterne tjek". In die "Sleutel"-veld definieer ons 'n skrip, waarna ons die naam van die Oracle-databasis, die naam van die sql-navraag, die login en wagwoord vir koppeling aan die databasis as parameters deurgee. Stel die navraagopdateringsinterval op 5 minute (300 sekondes).

2) Skep ander maatstawwe vir elke voertuigstatus. Die waardes van hierdie maatstawwe sal gegenereer word op grond van die resultaat van die nagaan van die hoofmetriek.

Stel die naam van die data-element, spesifiseer die tipe "Eksterne tjek". In die "Sleutel"-veld definieer ons 'n skrip, waarna ons die naam van die Oracle-databasis en die statuskode, waarvan die waarde ons wil naspoor, as parameters deurgee. Ons stel die navraagopdateringsinterval op 10 sekondes meer as die hoofmetriek (310 sekondes) sodat die resultate tyd het om na die lêer te skryf.

Om die maatstawwe korrek te kry, is die volgorde waarin tjeks geaktiveer word belangrik. Om konflikte te vermy wanneer ons data ontvang, aktiveer ons eerstens die hoofmetriek GetCarsByStatus met 'n script-oproep - wh_Metrics.sh.

Instellings → Nodes → 'knooppuntnaam' → Items → Subfilter “Eksterne tjeks”. Ons merk die nodige tjek en klik "Aktiveer".

Vervolgens aktiveer ons die oorblywende maatstawwe in een bewerking, en kies hulle almal saam:

Nou het Zabbix begin om pakhuisbesigheidsstatistieke in te samel.

In die volgende artikels sal ons die verband van Grafana en die vorming van inligtingspaneelborde van pakhuiswerk van verskillende kategorieë gebruikers van nader bekyk. Ook op grond van Grafana word beheer van afwykings in die werk van die pakhuis geïmplementeer en, afhangende van die grense en frekwensie van afwykings, registrasie van insidente in die pakhuisbestuurdienssentrumstelsel via die API of eenvoudige stuur van kennisgewings aan die bestuurder deur e-pos.

Bron: will.com