X5 driver 43 distributionscenter och 4 029 egna lastbilar, vilket säkerställer oavbruten leverans av produkter till 15 752 butiker. I den här artikeln kommer jag att dela med mig av min erfarenhet av att skapa ett interaktivt system för att övervaka lagerhändelser från grunden. Informationen kommer att vara användbar för logistiker från handelsföretag med flera dussin distributionscenter som hanterar ett brett utbud av produkter.
Som regel börjar konstruktionen av övervaknings- och affärsprocesshanteringssystem med att bearbeta meddelanden och incidenter. Samtidigt missas en viktig teknisk punkt relaterad till möjligheten att automatisera själva det faktum att affärshändelser inträffar och att registrera incidenter. De flesta affärssystem som WMS, TMS etc har inbyggda verktyg för att övervaka sina egna processer. Men om det är system från olika tillverkare eller om övervakningsfunktionen inte är tillräckligt utvecklad måste du beställa dyra modifieringar eller attrahera specialiserade konsulter för ytterligare inställningar.
Låt oss överväga ett tillvägagångssätt där vi bara behöver en liten del av konsultationen i samband med att identifiera källor (tabeller) för att få indikatorer från systemet.
Det specifika med våra lager är att flera lagerhanteringssystem (WMS Exceed) fungerar på ett logistikkomplex. Lager är indelade efter kategorier av lagring av varor (torrt, alkohol, fryst, etc.) inte bara logiskt. Inom ett logistikkomplex finns flera separata lagerbyggnader, som var och en hanteras av sitt eget WMS.
För att bilda sig en allmän bild av de processer som sker i lagret analyserar chefer rapporteringen av varje WMS flera gånger om dagen, behandlar meddelanden från lageroperatörer (mottagare, plockare, staplare) och sammanfattar faktiska driftsindikatorer för reflektion på informationstavlan.
För att spara tid för chefer beslutade vi att utveckla ett billigt system för operativ kontroll av lagerhändelser. Det nya systemet ska, förutom att visa "heta" indikatorer för lagerprocessernas operativa prestanda, också hjälpa chefer att registrera incidenter och övervaka genomförandet av uppgifter för att eliminera orsakerna som påverkar de givna indikatorerna. Efter att ha genomfört en allmän granskning av företagets IT-arkitektur insåg vi att enskilda delar av det erforderliga systemet redan finns på ett eller annat sätt i vårt landskap och för dem finns det både en granskning av inställningarna och nödvändiga stödtjänster. Allt som återstår är att samla hela konceptet i en enda arkitektonisk lösning och uppskatta omfattningen av utvecklingen.
Efter att ha utvärderat hur mycket arbete som behöver göras för att bygga ett nytt system, beslutades det att dela upp projektet i flera steg:
- Insamling av indikatorer för lagerprocesser, visualisering och kontroll av indikatorer och avvikelser
- Automatisering av processstandarder och registrering av ansökningar i tjänsten företagstjänster för avvikelser
- Proaktiv övervakning med belastningsprognoser och skapande av rekommendationer för chefer.
I det första steget måste systemet samla in förberedda delar av operationsdata från alla WMS i komplexet. Avläsning sker nästan i realtid (intervall på mindre än 5 minuter). Tricket är att data måste hämtas från DBMS för flera dussin lager när systemet distribueras till hela nätverket. Den mottagna operativa data bearbetas av logiken i systemkärnan för att beräkna avvikelser från planerade indikatorer och beräkna statistik. Data som behandlas på detta sätt ska visas på chefens surfplatta eller på lagerinformationstavlan i form av begripliga grafer och diagram.
När vi valde ett lämpligt system för pilotimplementeringen av det första steget valde vi Zabbix. Detta system används redan för att övervaka IT-prestanda hos lagersystem. Genom att lägga till en separat installation för insamling av affärsmått för lagerdrift kan du få en övergripande bild av lagrets hälsa.
Systemets allmänna arkitektur blev som i figuren.
Varje WMS-instans definieras som en värd för övervakningssystemet. Mätvärden samlas in av en central server i datacenternätverket genom att köra ett skript med en förberedd SQL-fråga. Om du behöver övervaka ett system som inte rekommenderar direktåtkomst till databasen (till exempel SAP EWM) kan du använda skriptanrop till dokumenterade API-funktioner för att få indikatorer eller skriva ett enkelt program i python/vbascript.
En Zabbix proxy-instans distribueras i lagernätverket för att fördela belastningen från huvudservern. Genom Proxy säkerställs arbetet med alla lokala WMS-instanser. Nästa gång Zabbix-servern begär parametrar, exekveras ett skript på värden med Zabbix-proxy för att begära mätvärden från WMS-databasen.
För att visa grafer och lagerindikatorer på den centrala Zabbix-servern distribuerar vi Grafana. Förutom att visa förberedda instrumentpaneler med infografik över lagerverksamheten kommer Grafana att användas för att övervaka avvikelser i indikatorer och skicka automatiska varningar till lagerservicesystemet för att arbeta med affärsincidenter.
Som ett exempel, låt oss överväga implementeringen av lastkontroll i lagermottagningsområdet. Följande valdes som huvudindikatorer för processprestanda i detta område av lagret:
- antal fordon i receptionen, med hänsyn till status (planerade, anlände, dokument, lossning, avgång;
- arbetsbelastning av placerings- och påfyllningsområden (enligt lagringsförhållanden).
Inställningar
Installation och konfiguration av huvudkomponenterna i systemet (SQLcl, Zabbix, Grafana) beskrivs i olika källor och kommer inte att upprepas här. Användningen av SQLcl istället för SQLplus beror på att SQLcl (kommandoradsgränssnittet för Oracle DBMS, skrivet i java) inte kräver ytterligare installation av Oracle Client och fungerar direkt.
Jag kommer att beskriva de viktigaste punkterna som bör uppmärksammas när du använder Zabbix för att övervaka lageraffärsprocessindikatorer, och ett av de möjliga sätten att implementera dem. Det här är inte heller ett inlägg om säkerhet. Säkerheten för anslutningar och användningen av de presenterade metoderna kräver ytterligare studier i processen att överföra pilotlösningen till produktiv drift.
Huvudsaken är att när du implementerar ett sådant system är det möjligt att göra utan programmering med hjälp av inställningarna som tillhandahålls av systemet.
Zabbix övervakningssystem ger flera alternativ för att samla in mätvärden från det övervakade systemet. Detta kan göras antingen genom att direkt polla övervakade värdar, eller genom en mer avancerad metod för att skicka data till servern via värdens zabbix_sender, inklusive metoder för att konfigurera upptäcktsparametrar på låg nivå. För att lösa vårt problem är metoden för direkt polling av värdar av en central server ganska lämplig, eftersom detta låter dig få full kontroll över sekvensen av mätvärden och säkerställer att du använder en uppsättning inställningar/skript utan att behöva distribuera dem till varje övervakad värd.
Som "testpersoner" för felsökning och installation av systemet använder vi WMS-kalkylblad för acceptanshantering:
- Fordon i receptionen, alla som har anlänt: Alla fordon med status för perioden "- 72 timmar från aktuell tid" - SQL-frågeidentifierare: getCars.
- Historik för alla fordonsstatusar: Status för alla fordon som anländer inom 72 timmar - SQL-frågeidentifierare: bilars historia.
- Schemalagda fordon för acceptans: Status för alla fordon med ankomst i "Scheduled" status, tidsintervall "- 24 timmar" och "+24 timmar" från den aktuella tiden - SQL frågeidentifierare: bilarIn.
Så efter att vi har bestämt oss för en uppsättning lagerprestandamått, kommer vi att förbereda SQL-frågor för WMS-databasen. För att utföra frågor är det tillrådligt att inte använda huvuddatabasen, utan dess "heta" kopia - standby.
Vi ansluter till standby Oracle DBMS för att ta emot data. IP-adress för anslutning till testdatabasen 192.168.1.106. Vi sparar anslutningsparametrarna på Zabbix-servern i TNSNames.ORA i SQLcl-arbetsmappen:
# 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)
)
)Detta kommer att tillåta oss att köra SQL-frågor till varje värd via EZconnect, och endast ange inloggning/lösenord och databasnamn:
# sql znew/Zabmon1@WH1_1Vi sparar de förberedda SQL-frågorna i arbetsmappen på Zabbix-servern:
/etc/zabbix/sqloch tillåt åtkomst till zabbix-användaren på vår server:
# chown zabbix:zabbix -R /etc/zabbix/sqlFiler med förfrågningar får ett unikt identifieringsnamn för åtkomst från Zabbix-servern. Varje databasfråga via SQLcl returnerar flera parametrar. Med hänsyn till detaljerna för Zabbix, som endast kan behandla ett mätvärde per begäran, kommer vi att använda ytterligare skript för att analysera frågeresultaten till individuella mätvärden.
Låt oss förbereda huvudskriptet, låt oss kalla det wh_Metrics.sh, för att anropa en SQL-fråga till databasen, spara resultaten och returnera ett tekniskt mått med indikatorer på framgången med datahämtning:
#!/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 placerar den färdiga filen med skriptet i mappen för att lagra externa skript i enlighet med Zabbix-proxykonfigurationsinställningarna (som standard - /usr/local/share/zabbix/externalscripts).
Identifieringen av databasen från vilken skriptet kommer att ta emot resultat kommer att skickas som en skriptparameter. Databas-ID:t måste matcha inställningsraden i filen TNSNames.ORA.
Resultatet av SQL-frågeanropet sparas i en fil som mon_base_id_main.log där base_id = Databasidentifieraren som tas emot som en skriptparameter. Uppdelningen av resultatfilen med databasidentifierare tillhandahålls vid förfrågningar från servern till flera databaser samtidigt. Frågan returnerar en sorterad tvådimensionell matris med värden.
Följande skript, låt oss kalla det getMetrica.sh, behövs för att få ett specificerat mått från en fil med resultatet av en begäran:
#!/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 är vi redo att konfigurera Zabbix och börja övervaka indikatorer för lageracceptansprocesser.
En Zabbix-agent installeras och konfigureras på varje databasnod.
På huvudservern definierar vi alla servrar med Zabbix proxy. För inställningar, gå till följande sökväg:
Administration → Proxy → Skapa proxy
Vi definierar kontrollerade värdar:
Inställningar → Värdar → Skapa värd
Värdnamnet måste matcha värdnamnet som anges i agentens konfigurationsfil.
Vi anger gruppen för noden, samt IP-adressen eller DNS-namnet för noden med databasen.
Vi skapar mätvärden och specificerar deras egenskaper:
Inställningar → Noder → 'nodnamn' → Dataobjekt>Skapa dataobjekt
1) Skapa ett huvudmått för att fråga alla parametrar från databasen
Vi anger namnet på dataelementet, anger typen "Extern verifiering". I fältet "Nyckel" definierar vi ett skript som vi skickar som parametrar namnet på Oracle-databasen, namnet på sql-frågan, inloggningen och lösenordet för att ansluta till databasen. Ställ in frågeuppdateringsintervallet till 5 minuter (300 sekunder).
2) Skapa de återstående mätvärdena för varje fordonsstatus. Värdena för dessa mätvärden kommer att genereras baserat på resultatet av att kontrollera huvudmåttet.
Vi anger namnet på dataelementet, anger typen "Extern verifiering". I fältet "Nyckel" definierar vi ett skript som vi skickar som parametrar namnet på Oracle-databasen och statuskoden vars värde vi vill spåra. Vi ställer in frågeuppdateringsintervallet till 10 sekunder längre än huvudmåttet (310 sekunder) så att resultaten hinner skrivas till filen.
För att få mätvärden korrekt är det viktigt i vilken ordning kontrollerna aktiveras. För att undvika konflikter när vi tar emot data, aktiverar vi först och främst huvudmåttet GetCarsByStatus genom att anropa skriptet - wh_Metrics.sh.
Inställningar → Noder → 'nodnamn' → Dataelement → Underfilter "Externa kontroller". Markera den önskade kryssrutan och klicka på "Aktivera".
Därefter aktiverar vi de återstående mätvärdena i en operation och väljer dem alla tillsammans:
Nu har Zabbix börjat samla in affärsmått för lager.
I följande artiklar kommer vi att titta närmare på att koppla ihop Grafana och skapa informationspaneler för lagerdrift för olika kategorier av användare. Även baserat på Grafana implementeras övervakning av avvikelser i lagerverksamheten och beroende på gränser och repeterbarhet av avvikelser, registrering av incidenter i lagerhanteringens servicecentersystem via API eller enkelt sändning av aviseringar till chefen via e-post.
Källa: will.com