DIY: Sådan automatiserer vi lagerovervågning

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 lagerhændelsesovervågningssystem fra bunden. Oplysningerne vil være nyttige for logistikere fra handelsvirksomheder med flere dusin distributionscentre, der administrerer en bred vifte af varer.

Som regel begynder opbygningen af ​​overvågning af forretningsprocesser og styringssystemer med behandlingen af ​​beskeder og hændelser. Samtidig savnes et vigtigt teknologisk punkt, relateret til muligheden for at automatisere selve forekomsten af ​​forretningsbegivenheder og registreringen af ​​hændelser. De fleste forretningssystemer i klassen 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 inddrage specialiserede konsulenter for yderligere indstillinger.

Lad os overveje en tilgang, hvor vi kun har brug for en lille del af rådgivningen relateret til at definere kilder (tabeller) for at opnå indikatorer fra systemet.

Det særlige ved vores varehuse er, at flere lagerstyringssystemer (WMS Exceed) fungerer i ét logistikkompleks. Lagerhuse er opdelt efter kategorierne for opbevaring af varer (tørt, alkohol, frosset osv.) ikke kun logisk. Inden for et logistikkompleks er der flere separate lagerbygninger, driften på hver af dem styres af deres eget WMS.

For at danne et generelt billede af de processer, der foregår på lageret, analyserer ledere rapporterne fra hvert WMS flere gange om dagen, behandler beskeder fra lageroperatører (modtagere, plukkere, stablere) og opsummerer de faktiske driftsindikatorer til visning på informationstavlen.

For at spare ledernes tid besluttede vi at udvikle et billigt system til driftskontrol af lagerbegivenheder. Det nye system skal ud over at vise "varme" indikatorer for operationelt arbejde i lagerprocesser også hjælpe ledere med at registrere hændelser og overvåge implementeringen af ​​opgaver for at eliminere de årsager, der påvirker de angivne 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 i vores landskab på den ene eller anden måde, og for dem er der både ekspertkonfiguration og de nødvendige supporttjenester. Tilbage er kun at kombinere hele konceptet i en enkelt arkitektonisk løsning og evaluere omfanget af udviklingen.

Efter at have vurderet mængden af ​​arbejde, der skulle udføres for at bygge det nye system, blev det besluttet at dele projektet op i flere faser:

1. Indsamling af lagerprocesindikatorer, visualisering og kontrol af indikatorer og afvigelser
2. Automatisering af processtandarder og registrering af anmodninger i erhvervsserviceafdelingen for afvigelser
3. Proaktiv overvågning med belastningsforecasting og udarbejdelse af anbefalinger til ledere.

I det første trin skal systemet indsamle forberedte udsnit af driftsdata fra alle WMS-komplekser. 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 på tværs af hele netværket. De modtagne driftsdata behandles af systemets kernelogik 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 tydelige grafer og diagrammer.

Da vi valgte et passende system til pilotimplementeringen af ​​den første fase, slog vi os til Zabbix. Dette system bruges allerede til at overvåge it-ydelsen af ​​lagersystemer. Ved at tilføje en separat installation til at indsamle lagerforretningsmålinger kan du få et samlet billede af lagerets helbred.

Systemets generelle arkitektur viste sig at være som vist på figuren.

Hver WMS-instans er defineret som en vært for overvågningssystemet. Indsamlingen af ​​metrics udføres 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 implementeret i lagernetværket for at fordele belastningen fra hovedserveren. Proxy giver support til at arbejde med alle lokale WMS-instanser. Når Zabbix-serveren anmoder om parametre igen, udføres et script på værten med Zabbix-proxyen for at anmode om metrics fra WMS-databasen.

For at vise grafer og lagerindikatorer på centralen server Vi implementerer Grafana i Zabbix. Udover at vise forberedte dashboards med infografik over lagerets ydeevne, vil Grafana blive brugt til at overvåge afvigelser i metrikdata og sende automatiske advarsler til lagerets servicesystem til håndtering af forretningshændelser.

Lad os som et eksempel overveje implementeringen af ​​kontrol over lastningen af ​​lagermodtagelsesområdet. Følgende blev valgt som de vigtigste præstationsindikatorer for processerne i denne sektion af lageret:

• antallet af køretøjer i receptionsområdet under hensyntagen til status (planlagt, ankommet, dokumenter, aflæsning, afgang);
• arbejdsbelastning af placerings- og genopfyldningszoner (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å. Desuden handler dette indlæg ikke om sikkerhed. Sikkerheden af ​​forbindelser og brugen af ​​de præsenterede metoder kræver yderligere udvikling 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 indstillingsmulighederne fra systemet.

Zabbix-overvågningssystemet giver flere muligheder for at indsamle metrikker fra det overvågede system. Dette kan gøres enten ved direkte at polle de overvågede værter eller ved en mere avanceret metode til at sende data til serveren via værtens zabbix_sender, herunder metoder til at konfigurere opdagelsesparametre på lavt niveau. Metoden til direkte polling af værter af den centrale server er ganske velegnet til at løse vores problem, da dette giver mulighed for fuld kontrol over sekvensen af ​​metrikmodtagelse og sikrer brugen af ​​en enkelt pakke med indstillinger/scripts uden behov for at distribuere dem til hver overvåget vært.

Som "marsvin" til debugging og opsætning af systemet bruger vi WMS arbejdstabeller til acceptstyring:

1. Køretøjer i receptionen, alt der ankom: Alle køretøjer med status for perioden "- 72 timer fra det aktuelle tidspunkt" - SQL-forespørgsels-id: getCars.
2. Historik for alle køretøjsstatusser: Statusser for alle køretøjer med ankomster inden for 72 timer — SQL-forespørgsels-id: biler Historie.
3. Planlagte køretøjer til accept: Statusser for alle køretøjer med ankomst i status "Planlagt", 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, lad os 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.106Vi gemmer forbindelsesparametrene på server Zabbix 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, idet vi kun angiver login/adgangskode og databasenavn:

# sql znew/Zabmon1@WH1_1

Vi gemmer de forberedte SQL-forespørgsler i arbejdsmappen på Zabbix-serveren:

/etc/zabbix/sql

og tillad adgang til zabbix-brugeren af ​​vores server:

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

Filer med anmodninger modtager et unikt identifikationsnavn til adgang fra Zabbix-serveren. Hver forespørgsel til databasen via SQLcl returnerer os flere parametre. Under hensyntagen til detaljerne ved Zabbix, som kun kan behandle én metric i en anmodning, vil vi bruge yderligere scripts til at parse forespørgselsresultaterne i individuelle metrics.

Vi forbereder 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 succesen 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
fi

Placer den færdige fil med scriptet i mappen til at placere 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. DB-id'et skal matche indstillingsstrengen i filen TNSNames.ORA.

Resultatet af at kalde en SQL-forespørgsel gemmes i en fil af følgende type: mon_base_id_main.log hvor base_id = DB-id 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 given metrik fra en fil med forespørgselsresultatet:

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

Nu er vi klar til at konfigurere Zabbix og begynde at overvåge lageracceptprocesmetrikker.

På hver databasenode er en Zabbix-agent installeret og konfigureret.

På hovedserveren definerer vi alle servere med Zabbix proxy. For indstillinger skal du følge følgende sti:

Administration → Proxy → Opret proxy

Vi definerer de kontrollerede værter:

Opsætning → Netværksknudepunkter → Opret netværksknudepunkt

Værtsnavnet skal matche nodenavnet, 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 angiver navnet på dataelementet og angiver typen "Ekstern kontrol". I feltet "Nøgle" definerer vi et script, hvortil vi sender Oracle-databasenavnet, navnet på SQL-forespørgslen, login og adgangskode til at oprette forbindelse til databasen som parametre. Vi indstiller 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 angiver navnet på dataelementet og angiver typen "Ekstern kontrol". I feltet "Nøgle" definerer vi et script, hvortil vi sender Oracle-databasenavnet og statuskoden, hvis værdi vi ønsker at spore som parametre. Vi indstiller forespørgselsopdateringsintervallet til 10 sekunder mere 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, når vi modtager data, aktiverer vi først og fremmest hovedmetrikken GetCarsByStatus ved at kalde scriptet — wh_Metrics.sh.

Indstillinger → Noder → 'nodenavn' → Dataelementer → Underfilter "Eksterne kontroller". Vi markerer den nødvendige kontrol og klikker 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 dashboards til lagerdrift til forskellige kategorier af brugere. Ligeledes, baseret på Grafana, implementeres kontrol af afvigelser i lagerdrift og, afhængig af grænser og gentagelse af afvigelser, registrering af hændelser i lagerstyringsservicecentersystemet via API eller simpel afsendelse af meddelelser til lederen via e-mail.

Kilde: www.habr.com