Fai da te: come automatizziamo il monitoraggio del magazzino

X5 gestisce 43 centri di distribuzione e 4 camion propri, garantendo una fornitura ininterrotta di prodotti a 029 negozi. In questo articolo condividerò la mia esperienza nella creazione di un sistema interattivo per il monitoraggio degli eventi di magazzino da zero. Le informazioni saranno utili ai logisti delle società commerciali con diverse decine di centri di distribuzione che gestiscono una vasta gamma di prodotti.

Di norma, la costruzione di sistemi di monitoraggio e di gestione dei processi aziendali inizia con l'elaborazione di messaggi e incidenti. Allo stesso tempo, viene mancato un importante punto tecnologico relativo alla possibilità di automatizzare il fatto stesso che si verificano eventi aziendali e di registrare gli incidenti. La maggior parte dei sistemi aziendali come WMS, TMS, ecc. dispongono di strumenti integrati per il monitoraggio dei propri processi. Ma se si tratta di sistemi di produttori diversi o se la funzionalità di monitoraggio non è sufficientemente sviluppata, è necessario ordinare modifiche costose o rivolgersi a consulenti specializzati per impostazioni aggiuntive.

Consideriamo un approccio in cui è necessaria solo una piccola parte della consulenza associata all'identificazione delle fonti (tabelle) per ottenere indicatori dal sistema.

La particolarità dei nostri magazzini è che in un complesso logistico operano diversi sistemi di gestione del magazzino (WMS Exceed). I magazzini sono suddivisi non solo logicamente in base alle categorie di stoccaggio delle merci (secche, alcoliche, congelate, ecc.). All'interno di un complesso logistico ci sono diversi magazzini separati, ognuno dei quali è gestito dal proprio WMS.

Per formare un quadro generale dei processi che si verificano nel magazzino, i manager analizzano più volte al giorno i report di ciascun WMS, elaborano i messaggi degli operatori del magazzino (ricevitori, raccoglitori, impilatori) e riassumono gli indicatori operativi effettivi per rifletterli sul pannello informativo.

Per risparmiare tempo ai manager, abbiamo deciso di sviluppare un sistema economico per il controllo operativo degli eventi di magazzino. Il nuovo sistema, oltre a visualizzare gli indicatori “caldi” delle prestazioni operative dei processi di magazzino, dovrebbe anche aiutare i manager a registrare gli incidenti e monitorare l'attuazione delle attività per eliminare le cause che influenzano gli indicatori forniti. Dopo aver effettuato un audit generale dell’architettura informatica dell’azienda, ci siamo resi conto che le singole parti del sistema richiesto esistono già in un modo o nell’altro nel nostro panorama e per queste è previsto sia un esame delle impostazioni sia i necessari servizi di supporto. Non resta che riunire l'intero concetto in un'unica soluzione architettonica e stimare l'ambito di sviluppo.

Dopo aver valutato la mole di lavoro da svolgere per realizzare un nuovo sistema, si è deciso di suddividere il progetto in più fasi:

1. Raccolta di indicatori per i processi di magazzino, visualizzazione e controllo di indicatori e deviazioni
2. Automazione degli standard di processo e registrazione delle domande nel servizio dei servizi alle imprese per le deviazioni
3. Monitoraggio proattivo con previsione del carico e creazione di raccomandazioni per i gestori.

Nella prima fase, il sistema deve raccogliere porzioni preparate di dati operativi da tutti i WMS del complesso. La lettura avviene quasi in tempo reale (intervalli inferiori a 5 minuti). Il problema è che i dati devono essere ottenuti dai DBMS di diverse dozzine di magazzini quando si distribuisce il sistema sull'intera rete. I dati operativi ricevuti vengono elaborati dalla logica del nucleo del sistema per calcolare le deviazioni dagli indicatori pianificati e calcolare le statistiche. I dati così elaborati devono essere visualizzati sul tablet del gestore o sulla bacheca informativa del magazzino sotto forma di grafici e diagrammi comprensibili.

Nella scelta del sistema adatto per l'implementazione pilota della prima fase, abbiamo scelto Zabbix. Questo sistema è già utilizzato per monitorare le prestazioni IT dei sistemi di magazzino. Aggiungendo un'installazione separata per la raccolta dei parametri aziendali relativi al funzionamento del magazzino, è possibile ottenere un quadro generale dello stato del magazzino.

L'architettura generale del sistema è risultata quella in figura.

Ciascuna istanza WMS è definita come host per il sistema di monitoraggio. I parametri vengono raccolti da un server centrale nella rete del data center eseguendo uno script con una query SQL preparata. Se è necessario monitorare un sistema che non consiglia l'accesso diretto al database (ad esempio SAP EWM), è possibile utilizzare chiamate di script a funzioni API documentate per ottenere indicatori o scrivere un semplice programma in python/vbascript.

Un'istanza proxy Zabbix viene distribuita nella rete del magazzino per distribuire il carico dal server principale. Tramite Proxy è garantito il lavoro con tutte le istanze WMS locali. La prossima volta che il server Zabbix richiede parametri, viene eseguito uno script sull'host con proxy Zabbix per richiedere le metriche dal database WMS.

Per visualizzare grafici e indicatori di magazzino sul server centrale Zabbix, utilizziamo Grafana. Oltre a visualizzare dashboard predisposte con infografiche delle operazioni di magazzino, Grafana verrà utilizzato per monitorare le deviazioni degli indicatori e inviare avvisi automatici al sistema di servizio del magazzino per gestire gli incidenti aziendali.

Ad esempio, consideriamo l'implementazione del controllo del carico nell'area di ricevimento del magazzino. Come principali indicatori di performance del processo in quest’area del magazzino sono stati scelti:

• numero di veicoli nell'area di accoglienza, tenendo conto degli stati (previsto, arrivato, documenti, scarico, partenza;
• carico di lavoro delle aree di posizionamento e rifornimento (a seconda delle condizioni di stoccaggio).

Impostazioni

L'installazione e la configurazione dei componenti principali del sistema (SQLcl, Zabbix, Grafana) sono descritte in varie fonti e non verranno ripetute qui. L'uso di SQLcl invece di SQLplus è dovuto al fatto che SQLcl (l'interfaccia della riga di comando di Oracle DBMS, scritta in Java) non richiede un'installazione aggiuntiva di Oracle Client e funziona immediatamente.

Descriverò i punti principali a cui prestare attenzione quando si utilizza Zabbix per monitorare gli indicatori dei processi aziendali di magazzino e uno dei possibili modi per implementarli. Inoltre, questo non è un post sulla sicurezza. La sicurezza delle connessioni e l'uso dei metodi presentati richiedono ulteriori studi nel processo di trasferimento della soluzione pilota in operazioni produttive.

La cosa principale è che quando si implementa un tale sistema è possibile fare a meno della programmazione, utilizzando le impostazioni fornite dal sistema.

Il sistema di monitoraggio Zabbix offre diverse opzioni per la raccolta di parametri dal sistema monitorato. Ciò può essere fatto interrogando direttamente gli host monitorati o mediante un metodo più avanzato di invio di dati al server tramite zabbix_sender dell'host, inclusi metodi per la configurazione di parametri di rilevamento di basso livello. Per risolvere il nostro problema, il metodo del polling diretto degli host da parte di un server centrale è abbastanza adatto, perché ciò consente di ottenere il pieno controllo sulla sequenza di acquisizione delle metriche e garantisce l'utilizzo di un set di impostazioni/script senza la necessità di distribuirli a ciascun host monitorato.

Come “soggetti di prova” per il debug e la configurazione del sistema, utilizziamo il foglio di lavoro WMS per la gestione dell'accettazione:

1. Veicoli alla reception, tutti quelli arrivati: Tutti i veicoli con stati per il periodo “- 72 ore dall'ora corrente” - Identificatore della query SQL: getCars.
2. Cronologia di tutti gli stati dei veicoli: stati di tutti i veicoli in arrivo entro 72 ore - identificatore della query SQL: automobiliStoria.
3. Veicoli programmati per l'accettazione: Stati di tutti i veicoli con arrivo nello stato "Programmato", intervallo di tempo "- 24 ore" e "+24 ore" dall'ora corrente - Identificatore della query SQL: automobiliIn.

Quindi, dopo aver deciso una serie di parametri di prestazione del magazzino, prepareremo le query SQL per il database WMS. Per eseguire le query, è consigliabile utilizzare non il database principale, ma la sua copia “calda” - standby.

Ci colleghiamo al DBMS Oracle in standby per ricevere i dati. Indirizzo IP per la connessione al database di test 192.168.1.106. Salviamo i parametri di connessione sul server Zabbix in TNSNames.ORA della cartella di lavoro SQLcl:

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

Ciò ci consentirà di eseguire query SQL su ciascun host tramite EZconnect, specificando solo login/password e nome del database:

# sql znew/Zabmon1@WH1_1

Salviamo le query SQL preparate nella cartella di lavoro sul server Zabbix:

/etc/zabbix/sql

e consentire l'accesso all'utente zabbix del nostro server:

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

I file con richieste ricevono un nome identificativo univoco per l'accesso dal server Zabbix. Ogni query del database tramite SQLcl ci restituisce diversi parametri. Tenendo conto delle specificità di Zabbix, che può elaborare solo una metrica per richiesta, utilizzeremo script aggiuntivi per analizzare i risultati della query in metriche individuali.

Prepariamo lo script principale, chiamiamolo wh_Metrics.sh, per chiamare una query SQL sul database, salvare i risultati e restituire una metrica tecnica con indicatori del successo del recupero dei dati:

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

Inseriamo il file finito con lo script nella cartella per la memorizzazione di script esterni in conformità con le impostazioni di configurazione del proxy Zabbix (per impostazione predefinita - /usr/local/share/zabbix/externalscripts).

L'identificazione del database da cui lo script riceverà i risultati verrà passato come parametro dello script. L'ID del database deve corrispondere alla riga delle impostazioni nel file TNSNames.ORA.

Il risultato della chiamata alla query SQL viene salvato in un file simile mon_base_id_main.log dove base_id = L'identificatore del database ricevuto come parametro di script. La divisione del file dei risultati per identificatori del database è prevista in caso di richieste dal server a più database contemporaneamente. La query restituisce una matrice di valori bidimensionale ordinata.

Il seguente script, chiamiamolo getMetrica.sh, è necessario per ottenere una metrica specificata da un file con il risultato di una richiesta:

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

Ora siamo pronti per configurare Zabbix e iniziare a monitorare gli indicatori dei processi di accettazione del magazzino.

Un agente Zabbix è installato e configurato su ciascun nodo del database.

Sul server principale definiamo tutti i server con proxy Zabbix. Per le impostazioni, vai al seguente percorso:

Amministrazione → Proxy → Crea proxy

Definiamo host controllati:

Impostazioni → Host → Crea host

Il nome host deve corrispondere al nome host specificato nel file di configurazione dell'agente.

Specifichiamo il gruppo per il nodo, nonché l'indirizzo IP o il nome DNS del nodo con il database.

Creiamo metriche e specifichiamo le loro proprietà:

Impostazioni → Nodi → 'nome nodo' → Elementi dati>Crea elemento dati

1) Creare una metrica principale per interrogare tutti i parametri dal database

Impostiamo il nome dell'elemento dati, indichiamo il tipo “Verifica esterna”. Nel campo “Chiave” definiamo uno script al quale passiamo come parametri il nome del database Oracle, il nome della query sql, il login e la password per la connessione al database. Imposta l'intervallo di aggiornamento della query su 5 minuti (300 secondi).

2) Creare le metriche rimanenti per ogni stato del veicolo. I valori di queste metriche verranno generati in base al risultato del controllo della metrica principale.

Impostiamo il nome dell'elemento dati, indichiamo il tipo “Verifica esterna”. Nel campo “Chiave” definiamo uno script al quale passiamo come parametri il nome del database Oracle e il codice di stato di cui vogliamo tracciare il valore. Impostiamo l'intervallo di aggiornamento della query su 10 secondi in più rispetto alla metrica principale (310 secondi) in modo che i risultati abbiano tempo per essere scritti nel file.

Per ottenere correttamente le metriche, è importante l'ordine in cui vengono attivati ​​i controlli. Per evitare conflitti durante la ricezione dei dati, prima di tutto attiviamo la metrica principale GetCarsByStatus chiamando lo script - wh_Metrics.sh.

Impostazioni → Nodi → 'nome nodo' → Elementi dati → Sottofiltro “Controlli esterni”. Contrassegnare il controllo richiesto e fare clic su "Attiva".

Successivamente, attiviamo le restanti metriche in un'unica operazione, selezionandole tutte insieme:

Ora Zabbix ha iniziato a raccogliere parametri aziendali di magazzino.

Nei seguenti articoli daremo uno sguardo più da vicino al collegamento di Grafana e alla creazione di cruscotti informativi delle operazioni di magazzino per varie categorie di utenti. Grafana viene utilizzato anche per monitorare le deviazioni nelle operazioni di magazzino e, a seconda dei limiti e della frequenza delle deviazioni, registrare gli incidenti nel sistema del centro servizi di gestione del magazzino tramite API o semplicemente inviare notifiche al gestore via e-mail.

Fonte: habr.com