X5 driver 43 distributionscentre og 4 egne lastbiler, hvilket sikrer uafbrudt levering af produkter til 029 butikker. I denne artikel vil jeg dele min erfaring med at skabe et interaktivt system til overvågning af lagerbegivenheder fra bunden. Oplysningerne vil være nyttige for logistikere fra handelsvirksomheder med flere dusin distributionscentre, der administrerer en bred vifte af produkter.
Som regel begynder opbygningen af overvågnings- og forretningsprocesstyringssystemer med behandling af beskeder og hændelser. Samtidig savnes et vigtigt teknologisk punkt i forbindelse med muligheden for at automatisere selve forekomsten af forretningsbegivenheder og registrering af hændelser. De fleste forretningssystemer som WMS, TMS osv. har indbyggede værktøjer til at overvåge deres egne processer. Men hvis der er tale om systemer fra forskellige producenter, eller overvågningsfunktionaliteten ikke er tilstrækkeligt udviklet, skal du bestille dyre modifikationer eller tiltrække specialiserede konsulenter til yderligere indstillinger.
Lad os overveje en tilgang, hvor vi kun behøver en lille del af rådgivningen i forbindelse med at identificere kilder (tabeller) for at få indikatorer fra systemet.
Det særlige ved vores varehuse er, at flere lagerstyringssystemer (WMS Exceed) opererer på ét logistikkompleks. Lagre er opdelt efter kategorier af opbevaring af varer (tørt, alkohol, frosset osv.) ikke kun logisk. Inden for ét logistikkompleks er der flere separate lagerbygninger, som hver styres af sit eget WMS.
For at danne et generelt billede af de processer, der foregår på lageret, analyserer ledere rapporteringen af hvert WMS flere gange om dagen, behandler beskeder fra lageroperatører (modtagere, plukkere, stablere) og opsummerer faktiske driftsindikatorer til refleksion på informationstavlen.
For at spare ledere tid besluttede vi at udvikle et billigt system til driftskontrol af lagerbegivenheder. Det nye system skulle udover at vise "varme" indikatorer for lagerprocessernes operationelle ydeevne også hjælpe ledere med at registrere hændelser og overvåge implementeringen af opgaver for at eliminere de årsager, der påvirker de givne indikatorer. Efter at have gennemført en generel revision af virksomhedens it-arkitektur, indså vi, at enkelte dele af det påkrævede system allerede eksisterer på den ene eller anden måde i vores landskab, og for dem er der både en undersøgelse af indstillingerne og de nødvendige supporttjenester. Tilbage er blot at samle hele konceptet i en enkelt arkitektonisk løsning og vurdere udviklingsomfanget.
Efter at have vurderet mængden af arbejde, der skal udføres for at bygge et nyt system, blev det besluttet at opdele projektet i flere faser:
- Indsamling af indikatorer til lagerprocesser, visualisering og kontrol af indikatorer og afvigelser
- Automatisering af processtandarder og registrering af ansøgninger i erhvervsservicetjenesten for afvigelser
- Proaktiv overvågning med belastningsforecasting og udarbejdelse af anbefalinger til ledere.
I første fase skal systemet indsamle forberedte udsnit af driftsdata fra alle WMS i komplekset. Aflæsning sker næsten i realtid (intervaller på mindre end 5 minutter). Tricket er, at data skal hentes fra DBMS i flere dusin varehuse, når systemet implementeres til hele netværket. De modtagne driftsdata behandles af systemkernens logik for at beregne afvigelser fra planlagte indikatorer og beregne statistik. De data, der behandles på denne måde, skal vises på lederens tablet eller på lagerinformationstavlen i form af forståelige grafer og diagrammer.
Da vi valgte et passende system til pilotimplementeringen af den første fase, valgte vi Zabbix. Dette system bruges allerede til at overvåge it-ydelsen af lagersystemer. Ved at tilføje en separat installation til indsamling af forretningsmålinger for lagerdrift, kan du få et samlet billede af lagerets sundhed.
Systemets generelle arkitektur viste sig som i figuren.
Hver WMS-instans er defineret som en vært for overvågningssystemet. Metrics indsamles af en central server i datacenternetværket ved at køre et script med en forberedt SQL-forespørgsel. Hvis du skal overvåge et system, der ikke anbefaler direkte adgang til databasen (f.eks. SAP EWM), kan du bruge scriptkald til dokumenterede API-funktioner for at få indikatorer eller skrive et simpelt program i python/vbascript.
En Zabbix proxy-instans er installeret i lagernetværket for at fordele belastningen fra hovedserveren. Gennem Proxy er arbejdet med alle lokale WMS-instanser sikret. Næste gang Zabbix-serveren anmoder om parametre, udføres et script på værten med Zabbix-proxy for at anmode om metrics fra WMS-databasen.
For at vise grafer og lagerindikatorer på den centrale Zabbix-server implementerer vi Grafana. Udover at vise forberedte dashboards med infografik af lagerdrift, vil Grafana blive brugt til at overvåge afvigelser i indikatorer og sende automatiske alarmer til lagerservicesystemet for arbejde med forretningshændelser.
Lad os som et eksempel overveje implementeringen af belastningskontrol i lagermodtagelsesområdet. Følgende blev valgt som de vigtigste indikatorer for procesydelse i dette område af lageret:
- antal køretøjer i receptionsområdet under hensyntagen til status (planlagt, ankommet, dokumenter, aflæsning, afgang;
- arbejdsbelastning af anbringelses- og genopfyldningsområder (i henhold til opbevaringsforhold).
Indstillinger
Installation og konfiguration af systemets hovedkomponenter (SQLcl, Zabbix, Grafana) er beskrevet i forskellige kilder og vil ikke blive gentaget her. Brugen af SQLcl i stedet for SQLplus skyldes, at SQLcl (kommandolinjegrænsefladen i Oracle DBMS, skrevet i java) ikke kræver yderligere installation af Oracle Client og fungerer ud af boksen.
Jeg vil beskrive de vigtigste punkter, der skal være opmærksomme på, når du bruger Zabbix til at overvåge lagerets forretningsprocesindikatorer, og en af de mulige måder at implementere dem på. Dette er heller ikke et indlæg om sikkerhed. Sikkerheden af forbindelser og brugen af de præsenterede metoder kræver yderligere undersøgelse i processen med at overføre pilotløsningen til produktiv drift.
Det vigtigste er, at når du implementerer et sådant system, er det muligt at undvære programmering ved at bruge de indstillinger, som systemet giver.
Zabbix-overvågningssystemet giver flere muligheder for at indsamle metrics fra det overvågede system. Dette kan gøres enten ved direkte polling af overvågede værter eller ved en mere avanceret metode til at sende data til serveren via værtens zabbix_sender, herunder metoder til konfiguration af registreringsparametre på lavt niveau. For at løse vores problem er metoden til direkte polling af værter af en central server ganske velegnet, fordi dette giver dig mulighed for at få fuld kontrol over rækkefølgen af metrik-indsamling og sikrer, at du bruger ét sæt indstillinger/scripts uden at skulle distribuere dem til hver overvåget vært.
Som "testpersoner" til fejlfinding og opsætning af systemet bruger vi WMS-regneark til acceptstyring:
- Køretøjer i receptionen, alle der er ankommet: Alle køretøjer med status for perioden "- 72 timer fra det aktuelle tidspunkt" - SQL-forespørgsels-id: getCars.
- Historik over alle køretøjsstatusser: Statusser for alle køretøjer, der ankommer inden for 72 timer - SQL-forespørgsels-id: biler Historie.
- Planlagte køretøjer til accept: Statusser for alle køretøjer med ankomst i "Planlagt"-status, tidsinterval "- 24 timer" og "+24 timer" fra det aktuelle tidspunkt - SQL-forespørgsels-id: bilerIn.
Så efter at vi har besluttet os for et sæt lagerydeevnemålinger, vil vi forberede SQL-forespørgsler til WMS-databasen. For at udføre forespørgsler er det tilrådeligt ikke at bruge hoveddatabasen, men dens "hot" kopi - standby.
Vi forbinder til standby Oracle DBMS for at modtage data. IP-adresse for tilslutning til testdatabasen 192.168.1.106. Vi gemmer forbindelsesparametrene på Zabbix-serveren i TNSNames.ORA i SQLcl-arbejdsmappen:
# 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)
)
)Dette vil give os mulighed for at køre SQL-forespørgsler til hver vært via EZconnect og kun angive login/adgangskode og databasenavn:
# sql znew/Zabmon1@WH1_1Vi gemmer de forberedte SQL-forespørgsler i arbejdsmappen på Zabbix-serveren:
/etc/zabbix/sqlog tillad adgang til zabbix-brugeren af vores server:
# chown zabbix:zabbix -R /etc/zabbix/sqlFiler med anmodninger modtager et unikt identifikationsnavn til adgang fra Zabbix-serveren. Hver databaseforespørgsel via SQLcl returnerer os flere parametre. Under hensyntagen til detaljerne ved Zabbix, som kun kan behandle én metric pr. anmodning, vil vi bruge yderligere scripts til at parse forespørgselsresultaterne i individuelle metrics.
Lad os forberede hovedscriptet, lad os kalde det wh_Metrics.sh, for at kalde en SQL-forespørgsel til databasen, gemme resultaterne og returnere en teknisk metrik med indikatorer for succes med datahentning:
#!/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
fiVi placerer den færdige fil med scriptet i mappen til lagring af eksterne scripts i overensstemmelse med Zabbix-proxy-konfigurationsindstillingerne (som standard - /usr/local/share/zabbix/externalscripts).
Identifikationen af den database, hvorfra scriptet vil modtage resultater, videregives som en scriptparameter. Database-id'et skal svare til indstillingslinjen i filen TNSNames.ORA.
Resultatet af SQL-forespørgselskaldet gemmes i en fil som f.eks mon_base_id_main.log hvor base_id = Database-id'et modtaget som en scriptparameter. Opdelingen af resultatfilen efter databaseidentifikatorer gives i tilfælde af anmodninger fra serveren til flere databaser samtidigt. Forespørgslen returnerer et sorteret todimensionelt array af værdier.
Følgende script, lad os kalde det getMetrica.sh, er nødvendigt for at få en specificeret metrik fra en fil med resultatet af en anmodning:
#!/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
doneNu er vi klar til at konfigurere Zabbix og begynde at overvåge indikatorer for lageracceptprocesser.
En Zabbix-agent er installeret og konfigureret på hver databasenode.
På hovedserveren definerer vi alle servere med Zabbix proxy. For indstillinger skal du gå til følgende sti:
Administration → Proxy → Opret proxy
Vi definerer kontrollerede værter:
Indstillinger → Værter → Opret vært
Værtsnavnet skal matche det værtsnavn, der er angivet i agentkonfigurationsfilen.
Vi angiver gruppen for noden, samt IP-adressen eller DNS-navnet på noden med databasen.
Vi opretter metrics og specificerer deres egenskaber:
Indstillinger → Noder → 'node navn' → Dataelementer>Opret dataelement
1) Opret en hovedmetrik for at forespørge alle parametre fra databasen
Vi indstiller navnet på dataelementet, angiver typen "Ekstern verifikation". I feltet "Nøgle" definerer vi et script, som vi sender som parametre navnet på Oracle-databasen, navnet på sql-forespørgslen, login og adgangskode til at oprette forbindelse til databasen. Indstil forespørgselsopdateringsintervallet til 5 minutter (300 sekunder).
2) Opret de resterende målinger for hver køretøjsstatus. Værdierne af disse metrics vil blive genereret baseret på resultatet af kontrol af hovedmetrikken.
Vi indstiller navnet på dataelementet, angiver typen "Ekstern verifikation". I feltet "Nøgle" definerer vi et script, hvortil vi som parametre sender navnet på Oracle-databasen og statuskoden, hvis værdi vi ønsker at spore. Vi indstiller forespørgselsopdateringsintervallet til 10 sekunder længere end hovedmetrikken (310 sekunder), så resultaterne når at blive skrevet til filen.
For at opnå metrics korrekt er rækkefølgen, som kontroller aktiveres i, vigtig. For at undgå konflikter ved modtagelse af data aktiverer vi først og fremmest hovedmetrikken GetCarsByStatus ved at kalde scriptet - wh_Metrics.sh.
Indstillinger → Noder → 'nodenavn' → Dataelementer → Underfilter "Eksterne kontroller". Marker det ønskede flueben, og klik på "Aktiver".
Dernæst aktiverer vi de resterende målinger i én operation og vælger dem alle sammen:
Nu er Zabbix begyndt at indsamle lagerforretningsmålinger.
I de følgende artikler vil vi se nærmere på at forbinde Grafana og skabe informationsdashboards over lagerdrift for forskellige kategorier af brugere. Grafana bruges også til at overvåge afvigelser i lagerdrift og, afhængigt af grænser og hyppighed af afvigelser, registrere hændelser i lagerstyringsservicecentersystemet via API eller blot sende meddelelser til lederen via e-mail.
Kilde: www.habr.com