Bricolatge: com automatitzem el seguiment del magatzem

X5 opera 43 centres de distribució i 4 camions propis, assegurant el subministrament ininterromput de productes a 029 botigues. En aquest article compartiré la meva experiència de crear un sistema interactiu per controlar els esdeveniments del magatzem des de zero. La informació serà útil per als logístics de les empreses comercials amb diverses desenes de centres de distribució que gestionen una àmplia gamma de productes.

Per regla general, la construcció de sistemes de supervisió i gestió de processos de negoci comença amb el processament de missatges i incidències. Al mateix temps, es perd un punt tecnològic important relacionat amb la possibilitat d'automatitzar el fet mateix d'ocurrència d'esdeveniments empresarials i registrar incidències. La majoria de sistemes empresarials com WMS, TMS, etc., tenen eines integrades per supervisar els seus propis processos. Però, si es tracta de sistemes de diferents fabricants o la funcionalitat de monitorització no està prou desenvolupada, cal demanar modificacions costoses o atraure consultors especialitzats per a configuracions addicionals.

Considerem un plantejament en el qual només necessitem una petita part de la consulta associada a la identificació de fonts (taules) per obtenir indicadors del sistema.

L'especificitat dels nostres magatzems és que diversos sistemes de gestió de magatzems (WMS Exceed) funcionen en un mateix complex logístic. Els magatzems es divideixen segons categories d'emmagatzematge de mercaderies (sec, alcohol, congelats, etc.) no només lògicament. Dins d'un complex logístic hi ha diversos edificis de magatzems separats, cadascun dels quals està gestionat pel seu propi WMS.

Per formar una visió general dels processos que tenen lloc al magatzem, els responsables analitzen els informes de cada WMS diverses vegades al dia, processen els missatges dels operadors del magatzem (receptors, recol·lectors, apiladors) i resumeixen els indicadors operatius reals per a la reflexió al tauler informatiu.

Per estalviar temps als gestors, vam decidir desenvolupar un sistema econòmic per al control operatiu dels esdeveniments del magatzem. El nou sistema, a més de mostrar indicadors "calents" del rendiment operatiu dels processos de magatzem, també hauria d'ajudar els responsables a registrar incidències i fer el seguiment de l'execució de les tasques per eliminar les causes que afecten els indicadors donats. Després de realitzar una auditoria general de l'arquitectura informàtica de l'empresa, ens vam adonar que les parts individuals del sistema requerit ja existeixen d'una manera o altra al nostre panorama i per a elles hi ha tant un examen de la configuració com els serveis de suport necessaris. Només queda portar tot el concepte en una única solució arquitectònica i estimar l'abast del desenvolupament.

Després d'avaluar la quantitat de treball que cal fer per construir un nou sistema, es va decidir dividir el projecte en diverses etapes:

1. Recollida d'indicadors de processos de magatzem, visualització i control d'indicadors i desviacions
2. Automatització d'estàndards de procés i registre d'aplicacions al servei de serveis empresarials per desviacions
3. Seguiment proactiu amb previsió de càrrega i creació de recomanacions per als gestors.

En la primera etapa, el sistema ha de recollir porcions preparades de dades operatives de tots els WMS del complex. La lectura es fa gairebé en temps real (intervals de menys de 5 minuts). El truc és que les dades s'han d'obtenir del SGBD de diverses desenes de magatzems quan es desplega el sistema a tota la xarxa. Les dades operatives rebudes són processades per la lògica del nucli del sistema per calcular les desviacions dels indicadors planificats i calcular les estadístiques. Les dades tractades d'aquesta manera s'han de mostrar a la tauleta del gestor o al tauler informatiu del magatzem en forma de gràfics i diagrames comprensibles.

A l'hora de triar un sistema adequat per a la implementació pilot de la primera etapa, vam triar Zabbix. Aquest sistema ja s'utilitza per controlar el rendiment informàtic dels sistemes de magatzem. Si afegiu una instal·lació separada per recopilar mètriques comercials de l'operació del magatzem, podeu obtenir una imatge general de la salut del magatzem.

L'arquitectura general del sistema va resultar com a la figura.

Cada instància WMS es defineix com a host per al sistema de supervisió. Les mètriques les recopila un servidor central a la xarxa del centre de dades mitjançant l'execució d'un script amb una consulta SQL preparada. Si necessiteu supervisar un sistema que no recomana l'accés directe a la base de dades (per exemple, SAP EWM), podeu utilitzar trucades d'script a funcions de l'API documentades per obtenir indicadors o escriure un programa senzill en python/vbascript.

Una instància de proxy Zabbix es desplega a la xarxa de magatzem per distribuir la càrrega des del servidor principal. Mitjançant Proxy, es garanteix el treball amb totes les instàncies locals de WMS. La propera vegada que el servidor Zabbix sol·liciti paràmetres, s'executa un script a l'amfitrió amb el servidor intermediari Zabbix per sol·licitar mètriques de la base de dades WMS.

Per mostrar gràfics i indicadors de magatzem al servidor central de Zabbix, despleguem Grafana. A més de mostrar taulers preparats amb infografia de les operacions del magatzem, Grafana s'utilitzarà per controlar les desviacions dels indicadors i enviar alertes automàtiques al sistema de servei del magatzem per treballar amb incidències comercials.

Com a exemple, considerem la implementació del control de càrrega a l'àrea de recepció del magatzem. Els següents es van escollir com a principals indicadors del rendiment del procés en aquesta àrea del magatzem:

• nombre de vehicles a la zona de recepció, tenint en compte els estats (previst, arribat, documents, descàrrega, sortida;
• càrrega de treball de les zones de col·locació i reposició (segons condicions d'emmagatzematge).

ajustos

La instal·lació i configuració dels components principals del sistema (SQLcl, Zabbix, Grafana) es descriu en diverses fonts i no es repetirà aquí. L'ús de SQLcl en lloc de SQLplus es deu al fet que SQLcl (la interfície de línia d'ordres del SGBD d'Oracle, escrita en java) no requereix instal·lació addicional del client Oracle i funciona de manera immediata.

Descriuré els punts principals als quals s'ha de prestar atenció quan s'utilitza Zabbix per supervisar els indicadors del procés de negoci del magatzem i una de les possibles maneres d'implementar-los. A més, aquesta no és una publicació sobre seguretat. La seguretat de les connexions i l'ús dels mètodes presentats requereix un estudi addicional en el procés de transferència de la solució pilot a l'operació productiva.

El més important és que en implementar aquest sistema, és possible prescindir de la programació, utilitzant la configuració proporcionada pel sistema.

El sistema de monitorització Zabbix ofereix diverses opcions per recopilar mètriques del sistema monitoritzat. Això es pot fer enquestant directament els amfitrions supervisats o mitjançant un mètode més avançat d'enviament de dades al servidor mitjançant el zabbix_sender de l'amfitrió, inclosos els mètodes per configurar paràmetres de descobriment de baix nivell. Per resoldre el nostre problema, el mètode d'enquesta directa dels amfitrions per part d'un servidor central és bastant adequat, perquè això us permet obtenir un control total sobre la seqüència d'adquisició de mètriques i garanteix que feu servir un conjunt de paràmetres/scripts sense necessitat de distribuir-los a cada amfitrió supervisat.

Com a "subjectes de prova" per depurar i configurar el sistema, utilitzem el full de treball WMS per a la gestió de l'acceptació:

1. Vehicles a recepció, tots els que han arribat: Tots els vehicles amb estats durant el període “- 72 hores des de l'hora actual” - Identificador de consulta SQL: getCars.
2. Historial de tots els estats de vehicles: estats de tots els vehicles que arriben en 72 hores - Identificador de consulta SQL: Història dels cotxes.
3. Vehicles programats per a l'acceptació: estats de tots els vehicles amb arribada en estat "Programat", interval de temps "-24 hores" i "+24 hores" des de l'hora actual - identificador de consulta SQL: cotxesEn.

Per tant, després d'haver decidit un conjunt de mètriques de rendiment del magatzem, prepararem consultes SQL per a la base de dades WMS. Per executar consultes, és recomanable utilitzar no la base de dades principal, sinó la seva còpia "calenta" - en espera.

Ens connectem al SGBD d'Oracle en espera per rebre dades. Adreça IP per connectar-se a la base de dades de prova 192.168.1.106. Desem els paràmetres de connexió al servidor Zabbix a TNSNames.ORA de la carpeta de treball 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)
    )
  )

Això ens permetrà executar consultes SQL a cada host mitjançant EZconnect, especificant només l'inici de sessió/contrasenya i el nom de la base de dades:

# sql znew/Zabmon1@WH1_1

Desem les consultes SQL preparades a la carpeta de treball del servidor Zabbix:

/etc/zabbix/sql

i permetre l'accés a l'usuari zabbix del nostre servidor:

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

Els fitxers amb sol·licituds reben un nom d'identificador únic per accedir des del servidor Zabbix. Cada consulta de base de dades mitjançant SQLcl ens retorna diversos paràmetres. Tenint en compte les especificitats de Zabbix, que només pot processar una mètrica per sol·licitud, utilitzarem scripts addicionals per analitzar els resultats de la consulta en mètriques individuals.

Preparem l'script principal, anomenem-lo wh_Metrics.sh, per cridar una consulta SQL a la base de dades, desar els resultats i retornar una mètrica tècnica amb indicadors de l'èxit de la recuperació de dades:

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

Col·loquem el fitxer acabat amb l'script a la carpeta per emmagatzemar scripts externs d'acord amb la configuració de Zabbix-proxy (per defecte - /usr/local/share/zabbix/externalscripts).

La identificació de la base de dades de la qual l'script rebrà els resultats es passarà com a paràmetre de l'script. L'identificador de la base de dades ha de coincidir amb la línia de configuració del fitxer TNSNames.ORA.

El resultat de la trucada de consulta SQL es desa en un fitxer com mon_base_id_main.log on base_id = L'identificador de base de dades rebut com a paràmetre d'script. La divisió del fitxer de resultats per identificadors de bases de dades es proporciona en cas de sol·licituds del servidor a diverses bases de dades simultàniament. La consulta retorna una matriu de valors bidimensional ordenada.

El següent script, anomenem-lo getMetrica.sh, és necessari per obtenir una mètrica especificada d'un fitxer amb el resultat d'una sol·licitud:

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

Ara estem preparats per configurar Zabbix i començar a supervisar els indicadors dels processos d'acceptació del magatzem.

S'instal·la i configura un agent Zabbix a cada node de base de dades.

Al servidor principal definim tots els servidors amb proxy Zabbix. Per a la configuració, aneu al camí següent:

Administració → Proxy → Crea un proxy

Definim hosts controlats:

Configuració → Amfitrions → Crea amfitrió

El nom d'amfitrió ha de coincidir amb el que s'especifica al fitxer de configuració de l'agent.

Especifiquem el grup del node, així com l'adreça IP o el nom DNS del node amb la base de dades.

Creem mètriques i especifiquem les seves propietats:

Configuració → Nodes → 'nom del node' → Elements de dades>Crea un element de dades

1) Creeu una mètrica principal per consultar tots els paràmetres de la base de dades

Establem el nom de l'element de dades, indiquem el tipus "Verificació externa". En el camp “Clau”, definim un script al qual passem com a paràmetres el nom de la base de dades Oracle, el nom de la consulta sql, el login i la contrasenya per connectar-nos a la base de dades. Estableix l'interval d'actualització de la consulta a 5 minuts (300 segons).

2) Creeu les mètriques restants per a l'estat de cada vehicle. Els valors d'aquestes mètriques es generaran a partir del resultat de la comprovació de la mètrica principal.

Establem el nom de l'element de dades, indiquem el tipus "Verificació externa". Al camp "Clau", definim un script al qual passem com a paràmetres el nom de la base de dades Oracle i el codi d'estat del valor del qual volem fer un seguiment. Establem l'interval d'actualització de la consulta en 10 segons més que la mètrica principal (310 segons) perquè els resultats tinguin temps d'escriure's al fitxer.

Per obtenir les mètriques correctament, és important l'ordre en què s'activen els controls. Per tal d'evitar conflictes en rebre dades, primer de tot activem la mètrica principal GetCarsByStatus cridant l'script - wh_Metrics.sh.

Configuració → Nodes → "nom del node" → Elements de dades → Subfiltre "Comprovacions externes". Marqueu la comprovació necessària i feu clic a "Activa".

A continuació, activem les mètriques restants en una operació, seleccionant-les totes juntes:

Ara Zabbix ha començat a recopilar mètriques de negoci del magatzem.

En els articles següents, analitzarem de prop la connexió de Grafana i la creació de taulers d'informació d'operacions de magatzem per a diverses categories d'usuaris. Grafana també s'utilitza per controlar les desviacions en les operacions del magatzem i, en funció dels límits i la freqüència de les desviacions, registrar incidències en el sistema del centre de serveis de gestió del magatzem mitjançant API o simplement enviar notificacions al responsable per correu electrònic.

Font: www.habr.com