DIY: hoe we magazijnmonitoring automatiseren

X5 exploiteert 43 distributiecentra en 4 eigen vrachtwagens, waardoor een ononderbroken levering van producten aan 029 winkels wordt gegarandeerd. In dit artikel deel ik mijn ervaring met het creëren van een interactief systeem voor het vanaf het begin monitoren van magazijngebeurtenissen. De informatie zal nuttig zijn voor logistieke medewerkers van handelsbedrijven met enkele tientallen distributiecentra die een breed scala aan producten beheren.

In de regel begint de constructie van monitoring- en bedrijfsprocesbeheersystemen met het verwerken van berichten en incidenten. Tegelijkertijd wordt een belangrijk technologisch punt gemist dat verband houdt met de mogelijkheid om juist het feit dat zakelijke gebeurtenissen plaatsvinden en het registreren van incidenten te automatiseren. De meeste bedrijfssystemen zoals WMS, TMS etc. hebben ingebouwde tools om de eigen processen te monitoren. Maar als dit systemen van verschillende fabrikanten zijn of als de monitoringfunctionaliteit niet voldoende ontwikkeld is, moet u dure aanpassingen bestellen of gespecialiseerde adviseurs inschakelen voor aanvullende instellingen.

Laten we een aanpak overwegen waarbij we slechts een klein deel van het advies nodig hebben dat gepaard gaat met het identificeren van bronnen (tabellen) om indicatoren uit het systeem te verkrijgen.

Het specifieke van onze magazijnen is dat er meerdere magazijnbeheersystemen (WMS Exceed) op één logistiek complex draaien. Magazijnen zijn niet alleen logisch verdeeld volgens categorieën van opslag van goederen (droog, alcohol, bevroren, enz.). Binnen één logistiek complex bevinden zich meerdere afzonderlijke magazijngebouwen, die elk worden beheerd door een eigen WMS.

Om een ​​algemeen beeld te vormen van de processen die in het magazijn plaatsvinden, analyseren managers meerdere keren per dag de rapportage van elk WMS, verwerken ze berichten van magazijnbeheerders (ontvangers, pickers, stapelaars) en vatten ze feitelijke operationele indicatoren samen voor reflectie op het informatiebord.

Om managers tijd te besparen, besloten we een goedkoop systeem te ontwikkelen voor de operationele controle van magazijngebeurtenissen. Het nieuwe systeem zou, naast het weergeven van ‘hot’ indicatoren van de operationele prestaties van magazijnprocessen, managers ook moeten helpen bij het registreren van incidenten en het monitoren van de implementatie van taken om de oorzaken te elimineren die van invloed zijn op de gegeven indicatoren. Na het uitvoeren van een algemene audit van de IT-architectuur van het bedrijf, realiseerden we ons dat afzonderlijke delen van het vereiste systeem al op de een of andere manier in ons landschap bestaan ​​en voor hen is er zowel een onderzoek naar de instellingen als de noodzakelijke ondersteunende diensten. Het enige dat overblijft is om het hele concept in één architectonische oplossing te brengen en de omvang van de ontwikkeling in te schatten.

Na beoordeling van de hoeveelheid werk die moet worden gedaan om een ​​nieuw systeem te bouwen, werd besloten het project in verschillende fasen op te splitsen:

1. Verzameling van indicatoren voor magazijnprocessen, visualisatie en controle van indicatoren en afwijkingen
2. Automatisering van processtandaarden en registratie van applicaties in de zakelijke dienstverlening op afwijkingen
3. Proactieve monitoring met belastingprognoses en het opstellen van aanbevelingen voor managers.

In de eerste fase moet het systeem voorbereide segmenten van operationele gegevens verzamelen uit alle WMS van het complex. Het lezen gebeurt vrijwel in realtime (intervallen van minder dan 5 minuten). De truc is dat gegevens moeten worden verkregen uit het DBMS van enkele tientallen magazijnen wanneer het systeem op het hele netwerk wordt geïmplementeerd. De ontvangen operationele gegevens worden verwerkt door de logica van de systeemkern om afwijkingen van geplande indicatoren te berekenen en statistieken te berekenen. De op deze manier verwerkte gegevens moeten in de vorm van begrijpelijke grafieken en diagrammen op de tablet van de manager of op het magazijninformatiebord worden weergegeven.

Bij het kiezen van een geschikt systeem voor de pilot-implementatie van de eerste fase hebben we gekozen voor Zabbix. Dit systeem wordt al gebruikt om de IT-prestaties van magazijnsystemen te monitoren. Door een aparte installatie toe te voegen voor het verzamelen van bedrijfsgegevens over de werking van het magazijn, krijgt u een algemeen beeld van de gezondheid van het magazijn.

De algemene architectuur van het systeem bleek zoals in de figuur.

Elke WMS-instantie wordt gedefinieerd als een host voor het monitoringsysteem. Metrieken worden verzameld door een centrale server in het datacenternetwerk door een script uit te voeren met een voorbereide SQL-query. Als u een systeem moet monitoren dat geen directe toegang tot de database aanbeveelt (bijvoorbeeld SAP EWM), kunt u scriptaanroepen naar gedocumenteerde API-functies gebruiken om indicatoren te verkrijgen of een eenvoudig programma in python/vbascript te schrijven.

Een Zabbix-proxy-instantie wordt geïmplementeerd in het magazijnnetwerk om de belasting van de hoofdserver te verdelen. Via Proxy is het werken met alle lokale WMS-instanties verzekerd. De volgende keer dat de Zabbix-server om parameters vraagt, wordt er een script uitgevoerd op de host met Zabbix-proxy om statistieken op te vragen uit de WMS-database.

Om grafieken en magazijnindicatoren op de centrale Zabbix-server weer te geven, zetten we Grafana in. Naast het weergeven van voorbereide dashboards met infographics van magazijnactiviteiten, zal Grafana worden gebruikt om afwijkingen in indicatoren te monitoren en automatische waarschuwingen naar het magazijnservicesysteem te sturen voor het werken met bedrijfsincidenten.

Laten we als voorbeeld eens kijken naar de implementatie van lastcontrole in het magazijnontvangstgebied. Het volgende werd gekozen als de belangrijkste indicatoren voor de procesprestaties in dit deel van het magazijn:

• aantal voertuigen in de ontvangstruimte, rekening houdend met statussen (gepland, aangekomen, documenten, lossen, vertrek);
• werklast van plaatsings- en bevoorradingsgebieden (afhankelijk van opslagomstandigheden).

Instellingen

Installatie en configuratie van de belangrijkste componenten van het systeem (SQLcl, Zabbix, Grafana) wordt in verschillende bronnen beschreven en zal hier niet worden herhaald. Het gebruik van SQLcl in plaats van SQLplus is te danken aan het feit dat SQLcl (de opdrachtregelinterface van het Oracle DBMS, geschreven in Java) geen extra installatie van de Oracle Client vereist en out-of-the-box werkt.

Ik zal de belangrijkste punten beschrijven waarop gelet moet worden bij het gebruik van Zabbix om bedrijfsprocesindicatoren in magazijnen te monitoren, en een van de mogelijke manieren om deze te implementeren. Dit is ook geen bericht over beveiliging. De veiligheid van verbindingen en het gebruik van de gepresenteerde methoden vereisen aanvullend onderzoek in het proces van het omzetten van de proefoplossing naar productieve werking.

Het belangrijkste is dat het bij de implementatie van een dergelijk systeem mogelijk is om te doen zonder programmeren, met behulp van de instellingen van het systeem.

Het Zabbix-monitoringsysteem biedt verschillende opties voor het verzamelen van statistieken van het bewaakte systeem. Dit kan worden gedaan door rechtstreeks gecontroleerde hosts te ondervragen, of door een meer geavanceerde methode voor het verzenden van gegevens naar de server via de zabbix_sender van de host, inclusief methoden voor het configureren van detectieparameters op laag niveau. Om ons probleem op te lossen is de methode van directe polling van hosts door een centrale server zeer geschikt, omdat Hierdoor krijgt u volledige controle over de volgorde van het verkrijgen van metrische gegevens en zorgt u ervoor dat u één set instellingen/scripts gebruikt zonder dat u deze naar elke bewaakte host hoeft te distribueren.

Als “proefpersonen” voor het debuggen en opzetten van het systeem, gebruiken we het WMS-werkblad voor acceptatiebeheer:

1. Voertuigen bij de receptie, alle aangekomen: Alle voertuigen met status voor de periode “- 72 uur vanaf de huidige tijd” - SQL-query-ID: haal auto's.
2. Geschiedenis van alle voertuigstatussen: Statussen van alle voertuigen die binnen 72 uur arriveren - SQL-query-ID: auto'sGeschiedenis.
3. Geplande voertuigen voor acceptatie: statussen van alle voertuigen met aankomst in de status "Gepland", tijdsinterval "- 24 uur" en "+24 uur" vanaf de huidige tijd - SQL-query-ID: auto'sIn.

Dus nadat we een reeks magazijnprestatiestatistieken hebben vastgesteld, zullen we SQL-query's voorbereiden voor de WMS-database. Om query's uit te voeren, is het raadzaam om niet de hoofddatabase te gebruiken, maar de "hot" kopie - stand-by.

We maken verbinding met stand-by Oracle DBMS om gegevens te ontvangen. IP-adres voor verbinding met de testdatabase 192.168.1.106. We slaan de verbindingsparameters op de Zabbix-server op in TNSNames.ORA van de SQLcl-werkmap:

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

Hierdoor kunnen we SQL-query's uitvoeren op elke host via EZconnect, waarbij alleen de login/wachtwoord en databasenaam worden opgegeven:

# sql znew/Zabmon1@WH1_1

We slaan de voorbereide SQL-query's op in de werkmap op de Zabbix-server:

/etc/zabbix/sql

en toegang verlenen aan de zabbix-gebruiker van onze server:

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

Bestanden met verzoeken ontvangen een unieke identificatienaam voor toegang vanaf de Zabbix-server. Elke databasequery via SQLcl levert ons verschillende parameters op. Rekening houdend met de specifieke kenmerken van Zabbix, die slechts één statistiek per verzoek kan verwerken, zullen we aanvullende scripts gebruiken om de zoekopdrachtresultaten te ontleden in individuele statistische gegevens.

Laten we het hoofdscript voorbereiden, laten we het wh_Metrics.sh noemen, om een ​​SQL-query naar de database op te roepen, de resultaten op te slaan en een technische metriek terug te geven met indicatoren voor het succes van het ophalen van gegevens:

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

We plaatsen het voltooide bestand met het script in de map voor het opslaan van externe scripts in overeenstemming met de Zabbix-proxy-configuratie-instellingen (standaard - /usr/local/share/zabbix/externalscripts).

De identificatie van de database waarvan het script resultaten zal ontvangen, wordt doorgegeven als een scriptparameter. Het database-ID moet overeenkomen met de instellingenregel in het TNSNames.ORA-bestand.

Het resultaat van de SQL-queryaanroep wordt opgeslagen in een bestand zoals mon_base_id_main.log waarbij base_id = De database-ID ontvangen als scriptparameter. De indeling van het resultaatbestand op basis van database-identificatoren vindt plaats bij verzoeken van de server aan meerdere databases tegelijk. De query retourneert een gesorteerde tweedimensionale matrix met waarden.

Het volgende script, laten we het getMetrica.sh noemen, is nodig om een ​​gespecificeerde metriek uit een bestand te verkrijgen met het resultaat van een verzoek:

#!/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 zijn we klaar om Zabbix te configureren en indicatoren van magazijnacceptatieprocessen te monitoren.

Op elk databaseknooppunt wordt een Zabbix-agent geïnstalleerd en geconfigureerd.

Op de hoofdserver definiëren we alle servers met Zabbix-proxy. Ga voor instellingen naar het volgende pad:

Beheer → Proxy → Proxy maken

We definiëren gecontroleerde hosts:

Instellingen → Hosts → Host aanmaken

De hostnaam moet overeenkomen met de hostnaam die is opgegeven in het agentconfiguratiebestand.

We specificeren de groep voor het knooppunt, evenals het IP-adres of de DNS-naam van het knooppunt met de database.

We creëren statistieken en specificeren hun eigenschappen:

Instellingen → Knooppunten → 'knooppuntnaam' → Gegevensitems>Gegevensitem maken

1) Maak een hoofdstatistiek om alle parameters uit de database op te vragen

We stellen de naam van het data-element in en geven het type "Externe verificatie" aan. In het veld "Sleutel" definiëren we een script waaraan we als parameters de naam van de Oracle-database, de naam van de SQL-query, de login en het wachtwoord voor verbinding met de database doorgeven. Stel het update-interval voor de query in op 5 minuten (300 seconden).

2) Creëer de resterende statistieken voor elke voertuigstatus. De waarden van deze statistieken worden gegenereerd op basis van het resultaat van het controleren van de hoofdstatistiek.

We stellen de naam van het data-element in en geven het type "Externe verificatie" aan. In het veld “Sleutel” definiëren we een script waaraan we als parameters de naam van de Oracle-database doorgeven en de statuscode waarvan we de waarde willen volgen. We hebben het update-interval voor de query ingesteld op 10 seconden langer dan de hoofdstatistiek (310 seconden), zodat de resultaten de tijd hebben om naar het bestand te worden geschreven.

Om de statistieken correct te verkrijgen, is de volgorde waarin controles worden geactiveerd belangrijk. Om conflicten bij het ontvangen van gegevens te voorkomen, activeren we eerst de hoofdstatistiek GetCarsByStatus door het script aan te roepen - wh_Metrics.sh.

Instellingen → Knooppunten → 'knooppuntnaam' → Data-elementen → Subfilter “Externe controles”. Vink het gewenste vinkje aan en klik op “Activeren”.

Vervolgens activeren we de resterende statistieken in één handeling en selecteren ze allemaal samen:

Nu is Zabbix begonnen met het verzamelen van bedrijfsstatistieken voor magazijnen.

In de volgende artikelen gaan we dieper in op het verbinden van Grafana en het creëren van informatiedashboards van magazijnactiviteiten voor verschillende categorieën gebruikers. Grafana wordt ook gebruikt om afwijkingen in de magazijnactiviteiten te monitoren en, afhankelijk van de grenzen en frequentie van afwijkingen, incidenten te registreren in het Warehouse Management Service Center-systeem via API of eenvoudigweg per e-mail meldingen naar de manager te sturen.

Bron: www.habr.com