X5 opera 43 centros de distribución y 4 camiones propios, asegurando el suministro ininterrumpido de productos a 029 tiendas. En este artículo compartiré mi experiencia en la creación de un sistema interactivo para monitorear eventos de almacén desde cero. La información será útil para los encargados de logística de las empresas comerciales con varias docenas de centros de distribución que gestionan una amplia gama de productos.
Como regla general, la construcción de sistemas de monitoreo y gestión de procesos de negocios comienza con el procesamiento de mensajes e incidentes. Al mismo tiempo, se pasa por alto un punto tecnológico importante relacionado con la posibilidad de automatizar el hecho mismo de ocurrencia de eventos comerciales y registrar incidentes. La mayoría de los sistemas empresariales, como WMS, TMS, etc., tienen herramientas integradas para monitorear sus propios procesos. Pero si se trata de sistemas de diferentes fabricantes o la funcionalidad de monitorización no está lo suficientemente desarrollada, habrá que encargar modificaciones costosas o recurrir a consultores especializados para realizar ajustes adicionales.
Consideremos un enfoque en el que sólo necesitamos una pequeña parte de la consultoría asociada a la identificación de fuentes (tablas) para obtener indicadores del sistema.
La especificidad de nuestros almacenes es que en un complejo logístico funcionan varios sistemas de gestión de almacenes (WMS Exceed). Los almacenes se dividen según las categorías de almacenamiento de mercancías (secas, alcohólicas, congeladas, etc.) no sólo de forma lógica. Dentro de un complejo logístico se encuentran varios edificios de almacén separados, cada uno de los cuales está gestionado por su propio WMS.
Para formarse 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 para reflejarlos 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 "calientes" del desempeño operativo de los procesos del almacén, también debería ayudar a los gerentes a registrar incidentes y monitorear la implementación de tareas para eliminar las causas que afectan los indicadores dados. Después de realizar una auditoría general de la arquitectura TI de la empresa, nos dimos cuenta de que las partes individuales del sistema requerido ya existen de una forma u otra en nuestro panorama y para ellas existe tanto un examen de la configuración como los servicios de soporte necesarios. Todo lo que queda es reunir todo el concepto en una única solución arquitectónica y estimar el alcance del desarrollo.
Después de evaluar la cantidad de trabajo que se necesita hacer para construir un nuevo sistema, se decidió dividir el proyecto en varias etapas:
- Recopilación de indicadores para procesos de almacén, visualización y control de indicadores y desviaciones.
- Automatización de estándares de procesos y registro de solicitudes en el servicio de servicios empresariales por desviaciones.
- Monitoreo proactivo con previsión de carga y creación de recomendaciones para gerentes.
En la primera etapa, el sistema debe recopilar fragmentos preparados de datos operativos de todos los WMS del complejo. La lectura se produce casi en tiempo real (intervalos inferiores a 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. Los datos operativos recibidos son procesados por la lógica del núcleo del sistema para calcular las desviaciones de los indicadores planificados y calcular estadísticas. Los datos así procesados deben visualizarse en la tableta del administrador o en el panel informativo del almacén en forma de gráficos y diagramas comprensibles.
A la hora de elegir un sistema adecuado para la implementación piloto de la primera etapa, elegimos Zabbix. Este sistema ya se utiliza para monitorear el desempeño de TI de los sistemas de almacén. Al agregar una instalación separada para recopilar métricas comerciales de la operación del almacén, puede obtener una imagen general del estado del almacén.
La arquitectura general del sistema resultó como en la figura.
Cada instancia de WMS se define como un host para el sistema de monitoreo. Las métricas las recopila un servidor central en la red del centro de datos 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 obtener indicadores o escribir un programa simple en python/vbascript.
Se implementa una instancia de proxy Zabbix en la red del almacén para distribuir la carga desde el servidor principal. A través de Proxy, se garantiza el trabajo con todas las instancias WMS locales. La próxima vez que el servidor Zabbix solicite parámetros, se ejecuta un script en el host con el proxy Zabbix para solicitar métricas de la base de datos WMS.
Para mostrar gráficos e indicadores de almacén en el servidor central de Zabbix, implementamos Grafana. Además de mostrar paneles preparados con infografías de las operaciones del almacén, Grafana se utilizará para monitorear las desviaciones en los indicadores y enviar alertas automáticas al sistema de servicio del almacén para trabajar con incidentes comerciales.
Como ejemplo, consideremos la implementación del control de carga en el área de recepción del almacén. Como principales indicadores del desempeño de los procesos en esta área del almacén se eligieron los siguientes:
- número de vehículos en el área de recepción, teniendo en cuenta los estados (previsto, llegado, documentos, descarga, salida);
- carga de trabajo de las áreas de colocación y reposición (según condiciones de almacenamiento).
Configuración
La instalación y configuración de los componentes principales del sistema (SQLcl, Zabbix, Grafana) se describe en varias fuentes y no se repetirá aquí. El uso de SQLcl en lugar de SQLplus se debe al hecho de que SQLcl (la interfaz de línea de comandos del DBMS de Oracle, escrita en java) no requiere instalación adicional del Cliente Oracle y funciona de inmediato.
Describiré los puntos principales a los que se debe prestar atención al utilizar Zabbix para monitorear los indicadores de los procesos comerciales del almacén y una de las posibles formas de implementarlos. Además, esta no es una publicación sobre seguridad. La seguridad de las conexiones y el uso de los métodos presentados requieren estudios adicionales en el proceso de transferir la solución piloto a una operación productiva.
Lo principal es que al implementar un sistema de este tipo, 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 del sistema monitoreado. Esto se puede hacer ya sea sondeando directamente los hosts monitoreados o mediante un método más avanzado de enviar datos al servidor a través del zabbix_sender del host, incluidos métodos para configurar parámetros de descubrimiento de bajo nivel. Para resolver nuestro problema, el método de sondeo directo de hosts por parte de un servidor central es bastante adecuado, porque esto le permite obtener control total sobre la secuencia de adquisición de métricas y garantiza que utilice un conjunto de configuraciones/scripts sin la necesidad de distribuirlos a cada host monitoreado.
Como “sujetos de prueba” para depurar y configurar el sistema, utilizamos la hoja de trabajo WMS para la gestión de aceptación:
- Vehículos en recepción, todos los que han llegado: Todos los vehículos con estados para el periodo “- 72 horas desde la hora actual” - Identificador de consulta SQL: obtenerCoches.
- Historial de todos los estados de los vehículos: Estados de todos los vehículos que llegan dentro de las 72 horas - Identificador de consulta SQL: autosHistoria.
- Vehículos programados para aceptación: Estados de todos los vehículos con llegada en estado “Programado”, intervalo de tiempo “- 24 horas” y “+24 horas” desde la hora actual - Identificador de consulta SQL: cochesEn.
Entonces, una vez que hayamos decidido un conjunto de métricas de rendimiento del almacén, prepararemos consultas SQL para la base de datos WMS. Para ejecutar consultas, es recomendable utilizar no la base de datos principal, sino su copia "en caliente", en espera.
Nos conectamos al DBMS de Oracle en espera para recibir datos. Dirección IP para conectarse a la base de datos de prueba 192.168.1.106. Guardamos los parámetros de conexión en el servidor Zabbix en TNSNames.ORA de la carpeta de trabajo 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)
)
)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_1Guardamos las consultas SQL preparadas en la carpeta de trabajo del servidor Zabbix:
/etc/zabbix/sqly permitir el acceso al usuario zabbix de nuestro servidor:
# chown zabbix:zabbix -R /etc/zabbix/sqlLos archivos con solicitudes reciben un nombre de identificador único para acceder desde el servidor Zabbix. Cada consulta a la base de datos vía SQLcl nos devuelve varios parámetros. Teniendo en cuenta las características específicas de Zabbix, que solo puede procesar una métrica por solicitud, utilizaremos scripts adicionales para analizar los resultados de la consulta en métricas individuales.
Preparemos el script principal, llamémoslo wh_Metrics.sh, para llamar una consulta SQL a la base de datos, guardar los resultados y devolver una métrica técnica con indicadores del éxito de la recuperación de 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
fiColocamos el archivo terminado con el script en la carpeta para almacenar scripts externos de acuerdo con los ajustes de configuración del proxy Zabbix (de forma predeterminada - /usr/local/share/zabbix/externalscripts).
La identificación de la base de datos de la cual el script recibirá resultados se pasará como parámetro del script. El ID de la base de datos debe coincidir con la línea de configuración del archivo TNSNames.ORA.
El resultado de la llamada de consulta SQL se guarda en un archivo como mon_base_id_main.log donde base_id = El identificador de la base de datos recibido como parámetro del script. La división del archivo de resultados por identificadores de base de datos se proporciona en caso de solicitudes del servidor a varias bases de datos simultáneamente. La consulta devuelve una matriz de valores bidimensional ordenada.
El siguiente script, llamémoslo getMetrica.sh, es necesario para obtener una métrica específica de un archivo con el resultado de una 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
doneAhora estamos listos para configurar Zabbix y comenzar a monitorear los indicadores de los procesos de aceptación del almacén.
Se instala y configura un agente Zabbix en cada nodo de la base de datos.
En el servidor principal definimos todos los servidores con proxy Zabbix. Para la configuración, vaya a la siguiente ruta:
Administración → Proxy → Crear proxy
Definimos hosts controlados:
Configuración → Anfitriones → Crear anfitrión
El nombre de host debe coincidir con el nombre de host especificado en el archivo de configuración del agente.
Especificamos el grupo del nodo, así como la dirección IP o nombre DNS del nodo con la base de datos.
Creamos métricas y especificamos sus propiedades:
Configuración → Nodos → 'nombre del nodo' → Elementos de datos>Crear elemento de datos
1) Cree una métrica principal para consultar todos los parámetros de la base de datos.
Establecemos el nombre del elemento de datos, indicamos el tipo “Verificación externa”. En el campo “Clave” definimos un script al que le pasamos como parámetros el nombre de la base de datos Oracle, el nombre de la consulta SQL, el login y contraseña para conectarse a la base de datos. Establezca el intervalo de actualización de la consulta en 5 minutos (300 segundos).
2) Cree las métricas restantes para cada estado del vehículo. Los valores de estas métricas se generarán en función del resultado de verificar la métrica principal.
Establecemos el nombre del elemento de datos, indicamos el tipo “Verificación externa”. En el campo “Clave” definimos un script al que le pasamos como parámetros el nombre de la base de datos Oracle y el código de estado cuyo valor queremos rastrear. Establecemos el intervalo de actualización de la consulta en 10 segundos más que la métrica principal (310 segundos) para que los resultados tengan tiempo de escribirse en el archivo.
Para obtener las métricas correctamente, es importante el orden en el que se activan los cheques. Para evitar conflictos al recibir datos, primero activamos la métrica principal GetCarsByStatus llamando al script - wh_Metrics.sh.
Configuración → Nodos → 'nombre de nodo' → Elementos de datos → Subfiltro “Comprobaciones externas”. Marque la verificación requerida y haga clic en "Activar".
A continuación, activamos el resto de métricas en una sola operación, seleccionándolas todas juntas:
Ahora Zabbix ha comenzado a recopilar métricas comerciales de almacén.
En los siguientes artículos, analizaremos más de cerca cómo conectar Grafana y crear paneles de información de las operaciones de almacén para varias categorías de usuarios. Grafana también se utiliza para monitorear las desviaciones en las operaciones del almacén y, dependiendo de los límites y la frecuencia de las desviaciones, registrar incidentes en el sistema del centro de servicios de gestión de almacenes a través de API o simplemente enviar notificaciones al gerente por correo electrónico.
Fuente: habr.com