X5 gestiona 43 centros de distribución y 4.029 camiones propios, que proporcionan un suministro ininterrumpido de productos en 15.752 tiendas. En el artículo compartiré la experiencia de crear desde cero un sistema interactivo para monitorear eventos de almacén. La información será útil para la logística de las empresas comerciales con docenas de centros de distribución que administran una amplia gama de productos.
Como regla general, la construcción de sistemas de monitoreo y gestión de procesos comerciales comienza con el procesamiento de mensajes e incidentes. Al mismo tiempo, se pierde un momento tecnológico importante, relacionado con la posibilidad de automatizar el hecho mismo de la ocurrencia de eventos comerciales y el registro de incidentes. La mayoría de los sistemas comerciales de la clase WMS, TMS, etc., tienen herramientas integradas para monitorear sus propios procesos. Pero, si se trata de un sistema de diferentes fabricantes o la funcionalidad de monitoreo no está suficientemente desarrollada, debe solicitar mejoras costosas o contar con consultores especializados para configuraciones adicionales.
Considere un enfoque en el que solo necesitamos una pequeña parte de la consultoría relacionada con la determinación de las fuentes (tablas) para obtener indicadores del sistema.
La especificidad de nuestros almacenes radica en el hecho de que varios sistemas de gestión de almacenes (WMS Exceed) operan en el mismo complejo logístico. Los almacenes se dividen de acuerdo con las categorías de almacenamiento de mercancías (seco, alcohol, congelación, etc.) no solo lógicamente. Dentro de un solo complejo logístico hay varios edificios de almacenes separados, las operaciones en cada uno de ellos son administrados por su propio WMS.
Para formar una imagen general de los procesos que ocurren en el almacén, los gerentes analizan los informes de cada WMS varias veces al día, procesan los mensajes de los operadores del almacén (receptores, recolectores, apiladores) y resumen los indicadores operativos reales que se mostrarán en el panel de información.
Para ahorrar tiempo a los gerentes, decidimos desarrollar un sistema económico para el control operativo de los eventos del almacén. El nuevo sistema, además de mostrar indicadores "activos" del trabajo operativo de los procesos de almacén, también debería ayudar a los gerentes a arreglar incidentes y monitorear tareas para eliminar las causas que afectan los indicadores dados. Después de llevar a cabo una auditoría general de la arquitectura de TI de la compañía, nos dimos cuenta de que ciertas partes del sistema requerido ya existen de alguna manera en nuestro panorama y para ellas hay un examen de la configuración y los servicios de soporte necesarios. Solo queda reducir todo el concepto en una única solución arquitectónica y evaluar el alcance del desarrollo.
Después de evaluar la cantidad de trabajo que debe hacerse para construir un nuevo sistema, se decidió dividir el proyecto en varias etapas:
- Colección de indicadores sobre procesos de almacén, visualización y control de indicadores y desviaciones.
- Automatización de estándares de proceso y registro de aplicaciones en el servicio de servicios empresariales para desviaciones
- Monitoreo proactivo con previsión de carga y recomendaciones a gerentes.
En la primera etapa, el sistema debe recopilar segmentos preparados de datos operativos de todos los complejos WMS. La lectura se realiza casi en tiempo real (intervalos de menos de 5 minutos). El truco es que los datos deben obtenerse del DBMS de varias docenas de almacenes al implementar el sistema en toda la red. La lógica central del sistema procesa los datos operativos recibidos para calcular las desviaciones de los indicadores planificados y calcular las estadísticas. Los datos procesados de esta manera deben mostrarse en la tableta del administrador o en el tablero de información del almacén en forma de gráficos y diagramas claros.
Al elegir un sistema adecuado para la implementación piloto de la primera etapa, nos decidimos por Zabbix. Este sistema ya se está utilizando para monitorear el desempeño de TI de los sistemas de almacén. Al agregar una instalación separada para recopilar métricas comerciales para las operaciones del almacén, puede obtener una imagen general del estado del almacén.
La arquitectura general del sistema es como se muestra en la figura.
Cada instancia de WMS se define como un host para el sistema de monitoreo. Un servidor central de la red del centro de datos recopila las métricas ejecutando un script con una consulta SQL preparada. Si necesita monitorear un sistema que no recomienda el acceso directo a la base de datos (por ejemplo, SAP EWM), puede usar llamadas de script a funciones API documentadas para escribir indicadores o escribir un simple programa python / vbascript.
El proxy Zabbix se implementa en la red del almacén para distribuir la carga desde el servidor principal. A través de Proxy, se proporciona trabajo con todas las instancias locales de WMS. En la próxima solicitud de parámetros por parte del servidor Zabbix en el host con el proxy Zabbix, se ejecuta un script para solicitar métricas de la base de datos WMS.
Para mostrar los gráficos e indicadores del almacén en el servidor central de Zabbix, implemente Grafana. Además de generar paneles preparados con infografías de almacén, Grafana se utilizará para controlar las desviaciones de los indicadores y transferir alertas automáticas al sistema de servicio de almacén para trabajar con incidentes comerciales.
Como ejemplo, considere la implementación del control de la carga de la zona de aceptación del almacén. Como los principales indicadores de los procesos en esta sección del almacén seleccionado:
- el número de vehículos en el área de recepción, teniendo en cuenta los estados (planeado, llegado, documentos, descarga, salida;
- congestión de zonas de colocación y reposición (según condiciones de almacenamiento).
Configuraciones
La instalación y configuración de los componentes principales del sistema (SQLcl, Zabbix, Grafana) se describe en diferentes fuentes y no repetiremos aquí. El uso de SQLcl en lugar de SQLplus se debe al hecho de que SQLcl (la interfaz de línea de comandos de Oracle DBMS escrita en Java) no requiere instalación adicional de Oracle Client y funciona de forma inmediata.
Describiré los puntos principales a los que se debe prestar atención cuando se usa Zabbix para monitorear el desempeño de los procesos comerciales del almacén, y una de las posibles formas de implementarlos. Además, esta publicación no se trata de seguridad. La seguridad de las conexiones y el uso de los métodos presentados necesita una elaboración adicional en el proceso de transferencia de la solución piloto a la operación productiva.
Lo principal es que al implementar dicho sistema, es posible prescindir de la programación, utilizando la configuración proporcionada por el sistema.
El sistema de monitoreo Zabbix ofrece varias opciones para recopilar métricas de un sistema monitoreado. Esto se puede hacer tanto mediante el sondeo directo de los hosts controlados como mediante un método más avanzado para enviar datos al servidor a través del zabbix_sender del host, incluidos los métodos para establecer parámetros de descubrimiento de bajo nivel. Para resolver nuestro problema, el método de sondeo directo de hosts por un servidor central es bastante adecuado. esto le permite obtener un control total sobre la secuencia de obtención de métricas y garantiza el uso de un paquete de configuraciones / scripts sin la necesidad de distribuirlos a cada host controlado.
Como "experimental" para depurar y ajustar el sistema, utilizamos las hojas de trabajo WMS para controlar la recepción:
- TS al aceptar, todo lo que llegó: Todos los TS con estados para el período "- 72 horas desde la hora actual" - Identificador de consulta SQL: getCars .
- Historial de todos los estados de los vehículos: estados de todos los vehículos con 72 horas de llegada - Identificador de consulta SQL: carsHistory .
- Vehículos programados para aceptación: estados de todos los vehículos con un estado de "Programado", el intervalo de tiempo es " -24 horas" y "+24 horas" desde la hora actual - Identificador de consulta SQL: carsIn .
Entonces, después de haber decidido un conjunto de métricas de almacén, prepararemos consultas SQL para la base de datos WMS. Para ejecutar consultas, es aconsejable utilizar no la base de datos principal, sino su copia en espera "activa".
Estamos conectados a Oracle DBMS en espera para la adquisición de datos. Dirección IP para conectarse a la base de prueba
192.168.1.106 . Los parámetros de conexión se guardan en el servidor Zabbix en TNSNames.ORA de la carpeta SQLcl de trabajo:
# 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) ) )
Esto nos permitirá ejecutar consultas SQL a cada host a través de EZconnect, especificando solo el nombre de usuario / contraseña y el nombre de la base de datos:
# sql znew/Zabmon1@WH1_1
Las consultas SQL preparadas se guardan en la carpeta de trabajo en el servidor Zabbix:
/etc/zabbix/sql
y permitir el acceso al usuario zabbix de nuestro servidor:
# chown zabbix:zabbix -R /etc/zabbix/sql
Los archivos de solicitud reciben un nombre de identificador único para acceder desde el servidor Zabbix. Cada consulta de base de datos a través de SQLcl nos devuelve varios parámetros. Dados los detalles de Zabbix, que solo puede procesar una métrica en una consulta, utilizaremos scripts adicionales para analizar los resultados de la consulta en métricas individuales.
Estamos preparando el script principal, llamémosle wh_Metrics.sh, para llamar la consulta SQL a la base de datos, guardar los resultados y devolver la métrica técnica con los indicadores de éxito para obtener datos:
#!/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
Colocamos el archivo terminado con el script en la carpeta para alojar scripts externos de acuerdo con la configuración de configuración del proxy Zabbix (por defecto -
/ usr / local / share / zabbix / externalscripts ).
La identificación de la base de datos desde la cual el script recibirá los resultados será transmitida por el parámetro del script. El identificador de la base de datos debe corresponder a la línea de configuración en el archivo TNSNames.ORA.
El resultado de invocar la consulta SQL se guarda en un archivo con el formato
mon_base_id_main.log, donde base_id = identificador de base de datos obtenido como parámetro de script. Se proporciona la separación del archivo de resultados por identificadores de base de datos en caso de solicitudes del servidor simultáneamente a varias bases de datos. La consulta devuelve una matriz de valores bidimensional ordenada.
El siguiente script, llamémoslo getMetrica.sh, es necesario para obtener la métrica especificada del archivo con el resultado de la solicitud:
#!/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
Ahora estamos listos para configurar Zabbix y comenzar a monitorear el desempeño de los procesos de aceptación del almacén.
En cada nodo de la base de datos, se instala y configura un agente Zabbix.
En el servidor principal, definimos todos los servidores con proxies Zabbix. Para la configuración, vaya a la siguiente ruta:
Administración → Proxies → Crear proxy
Definir hosts controlados:
Configuración → Hosts → Crear host
El nombre de host debe coincidir con el nombre de host especificado en el archivo de configuración del agente.
Indicamos el grupo para el nodo, así como la dirección IP o el nombre DNS del nodo de la base de datos.
Creamos métricas y especificamos sus propiedades:
Configuración → Nodos →
'nombre de nodo' → Elementos de datos> Crear elemento de datos
1) Cree una métrica básica para consultar todos los parámetros de la base de datos
Establecemos el nombre del elemento de datos, indicamos el tipo de "Verificación externa". En el campo "Clave", definimos un script al que transferimos el nombre de la base de datos Oracle, el nombre de la consulta SQL, el inicio de sesión y la contraseña para conectarse a la base de datos como parámetros. Establezca el intervalo de actualización para la solicitud en 5 minutos (300 segundos).
2) Cree las métricas restantes para cada estado del vehículo. Los valores de estas métricas se formarán en función del resultado de verificar la métrica principal.
Establecemos el nombre del elemento de datos, indicamos el tipo de "Verificación externa". En el campo "Clave", definimos un script al que transferimos el nombre de la base de datos Oracle y el código de estado, cuyo valor queremos rastrear como parámetros. Establecemos el intervalo de actualización para la solicitud 10 segundos más que la métrica principal (310 segundos) para que los resultados se puedan escribir en el archivo.
Para obtener métricas correctamente, es importante el orden en que se activan las verificaciones. Para evitar conflictos al recibir datos, en primer lugar, active la métrica principal GetCarsByStatus con una llamada de script: wh_Metrics.sh.
Configuración → Nodos → 'nombre de nodo' → Elementos de datos → Subfiltro “Verificaciones externas”. Marcamos la verificación necesaria y hacemos clic en "Activar".
A continuación, active las métricas restantes en una operación, seleccionándolas todas juntas:
Zabbix ahora ha comenzado a recopilar métricas comerciales de almacén.
En los siguientes artículos, examinaremos con más detalle la conexión de Grafana y la formación de paneles de información del almacén de información para diversas categorías de usuarios. Grafana también monitorea las desviaciones en el almacén y, según los límites y la frecuencia de las desviaciones, registra incidentes en el sistema del centro de servicio de gestión de almacenes a través de la API o simplemente envía notificaciones al gerente por correo electrónico.
