X5 driver 43 distribusjonssentre og 4 egne lastebiler, noe som sikrer uavbrutt tilførsel av produkter til 029 butikker. I denne artikkelen vil jeg dele min erfaring med å lage et interaktivt system for å overvåke lagerhendelser fra bunnen av. Informasjonen vil være nyttig for logistikere fra handelsbedrifter med flere dusin distribusjonssentre som administrerer et bredt spekter av produkter.
Som regel begynner konstruksjonen av overvåkings- og forretningsprosessstyringssystemer med behandling av meldinger og hendelser. Samtidig savnes et viktig teknologisk poeng knyttet til muligheten for å automatisere selve forekomsten av forretningshendelser og registrering av hendelser. De fleste forretningssystemer som WMS, TMS osv. har innebygde verktøy for å overvåke egne prosesser. Men hvis dette er systemer fra forskjellige produsenter eller overvåkingsfunksjonaliteten ikke er tilstrekkelig utviklet, må du bestille dyre modifikasjoner eller tiltrekke spesialiserte konsulenter for ytterligere innstillinger.
La oss vurdere en tilnærming der vi bare trenger en liten del av rådgivningen knyttet til å identifisere kilder (tabeller) for å få indikatorer fra systemet.
Spesifisiteten til våre varehus er at flere lagerstyringssystemer (WMS Exceed) opererer på ett logistikkkompleks. Lagre er delt inn etter kategorier av lagring av varer (tørr, alkohol, frossen, etc.) ikke bare logisk. Innenfor ett logistikkkompleks er det flere separate lagerbygninger, som hver administreres av sitt eget WMS.
For å danne et generelt bilde av prosessene som skjer på lageret, analyserer ledere rapporteringen av hvert WMS flere ganger om dagen, behandler meldinger fra lageroperatører (mottakere, plukkere, stablere) og oppsummerer faktiske driftsindikatorer for refleksjon på informasjonstavlen.
For å spare tid for ledere, bestemte vi oss for å utvikle et rimelig system for driftskontroll av lagerhendelser. Det nye systemet, i tillegg til å vise "varme" indikatorer for den operasjonelle ytelsen til lagerprosesser, skal også hjelpe ledere med å registrere hendelser og overvåke implementeringen av oppgaver for å eliminere årsakene som påvirker de gitte indikatorene. Etter å ha gjennomført en generell revisjon av selskapets IT-arkitektur, innså vi at individuelle deler av det nødvendige systemet allerede eksisterer på en eller annen måte i vårt landskap, og for dem er det både en undersøkelse av innstillingene og nødvendige støttetjenester. Alt som gjenstår er å bringe hele konseptet inn i en enkelt arkitektonisk løsning og anslå omfanget av utviklingen.
Etter å ha vurdert mengden arbeid som må gjøres for å bygge et nytt system, ble det besluttet å dele opp prosjektet i flere stadier:
- Innsamling av indikatorer for lagerprosesser, visualisering og kontroll av indikatorer og avvik
- Automatisering av prosessstandarder og registrering av søknader i bedriftstjenesten for avvik
- Proaktiv overvåking med belastningsprognoser og opprettelse av anbefalinger til ledere.
I det første trinnet må systemet samle forberedte skiver av driftsdata fra alle WMS i komplekset. Lesing skjer nesten i sanntid (intervaller på mindre enn 5 minutter). Trikset er at data må hentes fra DBMS til flere dusin varehus når systemet distribueres til hele nettverket. De mottatte driftsdataene behandles av logikken til systemkjernen for å beregne avvik fra planlagte indikatorer og beregne statistikk. Dataene som behandles på denne måten må vises på lederens nettbrett eller på lagerinformasjonstavlen i form av forståelige grafer og diagrammer.
Da vi valgte et passende system for pilotimplementeringen av første trinn, valgte vi Zabbix. Dette systemet brukes allerede til å overvåke IT-ytelsen til lagersystemer. Ved å legge til en egen installasjon for innsamling av forretningsberegninger for lagerdrift, kan du få et helhetlig bilde av helsen til lageret.
Den generelle arkitekturen til systemet viste seg som i figuren.
Hver WMS-forekomst er definert som en vert for overvåkingssystemet. Beregninger samles inn av en sentral server i datasenternettverket ved å kjøre et skript med en forberedt SQL-spørring. Hvis du trenger å overvåke et system som ikke anbefaler direkte tilgang til databasen (for eksempel SAP EWM), kan du bruke skriptkall til dokumenterte API-funksjoner for å få indikatorer eller skrive et enkelt program i python/vbascript.
En Zabbix proxy-forekomst er distribuert i lagernettverket for å distribuere belastningen fra hovedserveren. Gjennom Proxy sikres arbeid med alle lokale WMS-instanser. Neste gang Zabbix-serveren ber om parametere, kjøres et skript på verten med Zabbix-proxy for å be om beregninger fra WMS-databasen.
For å vise grafer og lagerindikatorer på den sentrale Zabbix-serveren, distribuerer vi Grafana. I tillegg til å vise forberedte dashboard med infografikk av lagerdrift, vil Grafana brukes til å overvåke avvik i indikatorer og sende automatiske varsler til lagerservicesystemet for arbeid med forretningshendelser.
Som et eksempel, la oss vurdere implementeringen av lastkontroll i lagermottaksområdet. Følgende ble valgt som hovedindikatorer for prosessytelse i dette området av lageret:
- antall kjøretøy i resepsjonsområdet, tatt i betraktning statuser (planlagt, ankommet, dokumenter, lossing, avgang;
- arbeidsbelastning av plasserings- og påfyllingsområder (i henhold til lagringsforhold).
Innstillinger
Installasjon og konfigurasjon av hovedkomponentene i systemet (SQLcl, Zabbix, Grafana) er beskrevet i ulike kilder og vil ikke bli gjentatt her. Bruken av SQLcl i stedet for SQLplus skyldes det faktum at SQLcl (kommandolinjegrensesnittet til Oracle DBMS, skrevet i java) ikke krever ekstra installasjon av Oracle Client og fungerer rett ut av boksen.
Jeg vil beskrive hovedpunktene som bør tas hensyn til når du bruker Zabbix til å overvåke lagerforretningsprosessindikatorer, og en av de mulige måtene å implementere dem på. Dette er heller ikke et innlegg om sikkerhet. Sikkerheten til tilkoblinger og bruken av de presenterte metodene krever ytterligere studier i prosessen med å overføre pilotløsningen til produktiv drift.
Det viktigste er at når du implementerer et slikt system, er det mulig å gjøre uten programmering, ved å bruke innstillingene gitt av systemet.
Zabbix-overvåkingssystemet gir flere alternativer for å samle inn beregninger fra det overvåkede systemet. Dette kan gjøres enten ved direkte polling av overvåkede verter, eller ved en mer avansert metode for å sende data til serveren via vertens zabbix_sender, inkludert metoder for å konfigurere oppdagelsesparametere på lavt nivå. For å løse problemet vårt er metoden for direkte polling av verter av en sentral server ganske egnet, fordi dette lar deg få full kontroll over rekkefølgen av metrikkinnhenting og sikrer at du bruker ett sett med innstillinger/skript uten å måtte distribuere dem til hver overvåket vert.
Som "testpersoner" for feilsøking og oppsett av systemet, bruker vi WMS-regneark for aksepthåndtering:
- Kjøretøy i resepsjonen, alle som har ankommet: Alle kjøretøy med status for perioden "- 72 timer fra gjeldende tid" - SQL-søkeidentifikator: getCars.
- Historikk for alle kjøretøystatuser: Statuser for alle kjøretøy som ankommer innen 72 timer - SQL-søkeidentifikator: bilhistorie.
- Planlagte kjøretøyer for aksept: Statuser for alle kjøretøy med ankomst i "Planlagt"-status, tidsintervall "- 24 timer" og "+24 timer" fra gjeldende tid - SQL-søkeidentifikator: bilerIn.
Så, etter at vi har bestemt oss for et sett med lagerytelsesmålinger, vil vi forberede SQL-spørringer for WMS-databasen. For å utføre spørringer, er det tilrådelig å ikke bruke hoveddatabasen, men dens "hot" kopi - standby.
Vi kobler til standby Oracle DBMS for å motta data. IP-adresse for tilkobling til testdatabasen 192.168.1.106. Vi lagrer tilkoblingsparametrene på Zabbix-serveren i TNSNames.ORA i SQLcl-arbeidsmappen:
# 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 tillate oss å kjøre SQL-spørringer til hver vert via EZconnect, og spesifisere kun pålogging/passord og databasenavn:
# sql znew/Zabmon1@WH1_1Vi lagrer de forberedte SQL-spørringene i arbeidsmappen på Zabbix-serveren:
/etc/zabbix/sqlog gi tilgang til zabbix-brukeren på serveren vår:
# chown zabbix:zabbix -R /etc/zabbix/sqlFiler med forespørsler får et unikt identifikasjonsnavn for tilgang fra Zabbix-serveren. Hver databasespørring via SQLcl returnerer oss flere parametere. Med tanke på spesifikasjonene til Zabbix, som kun kan behandle én beregning per forespørsel, vil vi bruke flere skript for å analysere søkeresultatene til individuelle beregninger.
La oss forberede hovedskriptet, la oss kalle det wh_Metrics.sh, for å ringe en SQL-spørring til databasen, lagre resultatene og returnere en teknisk beregning med indikatorer på suksessen med datainnhenting:
#!/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 plasserer den ferdige filen med skriptet i mappen for lagring av eksterne skript i samsvar med Zabbix-proxy-konfigurasjonsinnstillingene (som standard - /usr/local/share/zabbix/externalscripts).
Identifikasjonen av databasen som skriptet vil motta resultater fra, sendes som en skriptparameter. Database-ID-en må samsvare med innstillingslinjen i filen TNSNames.ORA.
Resultatet av SQL-spørringskallet lagres i en fil som mon_base_id_main.log hvor base_id = Databaseidentifikatoren mottatt som en skriptparameter. Delingen av resultatfilen etter databaseidentifikatorer er gitt i tilfelle forespørsler fra serveren til flere databaser samtidig. Spørringen returnerer en sortert todimensjonal matrise med verdier.
Følgende skript, la oss kalle det getMetrica.sh, er nødvendig for å få en spesifisert beregning fra en fil med resultatet av en forespørsel:
#!/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
doneNå er vi klare til å konfigurere Zabbix og begynne å overvåke indikatorer for varehusakseptprosesser.
En Zabbix-agent er installert og konfigurert på hver databasenode.
På hovedserveren definerer vi alle servere med Zabbix proxy. For innstillinger, gå til følgende bane:
Administrasjon → Proxy → Opprett proxy
Vi definerer kontrollerte verter:
Innstillinger → Verter → Opprett vert
Vertsnavnet må samsvare med vertsnavnet som er angitt i agentkonfigurasjonsfilen.
Vi spesifiserer gruppen for noden, samt IP-adressen eller DNS-navnet til noden med databasen.
Vi lager beregninger og spesifiserer egenskapene deres:
Innstillinger → Noder → 'nodenavn' → Dataelementer>Opprett dataelement
1) Opprett en hovedberegning for å spørre etter alle parametere fra databasen
Vi angir navnet på dataelementet, angir typen "Ekstern verifisering". I "Nøkkel"-feltet definerer vi et skript som vi sender som parametere navnet på Oracle-databasen, navnet på sql-spørringen, påloggingen og passordet for å koble til databasen. Sett spørringsoppdateringsintervallet til 5 minutter (300 sekunder).
2) Opprett de gjenværende beregningene for hver kjøretøystatus. Verdiene til disse beregningene vil bli generert basert på resultatet av å sjekke hovedberegningen.
Vi angir navnet på dataelementet, angir typen "Ekstern verifisering". I "Nøkkel"-feltet definerer vi et skript som vi sender som parametere navnet på Oracle-databasen og statuskoden hvis verdi vi ønsker å spore. Vi setter spørringsoppdateringsintervallet til 10 sekunder lengre enn hovedberegningen (310 sekunder), slik at resultatene rekker å skrives til filen.
For å få korrekte beregninger, er rekkefølgen sjekker aktiveres i viktig. For å unngå konflikter når vi mottar data, aktiverer vi først hovedberegningen GetCarsByStatus ved å kalle skriptet - wh_Metrics.sh.
Innstillinger → Noder → 'nodenavn' → Dataelementer → Underfilter "Eksterne kontroller". Merk den nødvendige kontrollen og klikk "Aktiver".
Deretter aktiverer vi de gjenværende beregningene i én operasjon, og velger dem alle sammen:
Nå har Zabbix begynt å samle inn lagerberegninger.
I de følgende artiklene skal vi se nærmere på å koble sammen Grafana og lage informasjonsdashboard over lagerdrift for ulike kategorier brukere. Grafana brukes også til å overvåke avvik i lagerdrift og, avhengig av grenser og hyppighet av avvik, registrere hendelser i lagerstyringsservicesentersystemet via API eller ganske enkelt sende varsler til lederen på e-post.
Kilde: www.habr.com