A X5 opera 43 centros de distribuição e 4 caminhões próprios, garantindo o fornecimento ininterrupto de produtos para 029 lojas. Neste artigo compartilharei minha experiência na criação de um sistema interativo para monitorar eventos de warehouse do zero. As informações serão úteis para logísticos de empresas comerciais com dezenas de centros de distribuição que gerenciam uma ampla gama de produtos.
Via de regra, a construção de sistemas de monitoramento e gestão de processos de negócios começa com o processamento de mensagens e incidentes. Ao mesmo tempo, falta um importante ponto tecnológico relacionado à possibilidade de automatizar o próprio fato da ocorrência de eventos de negócios e registrar incidentes. A maioria dos sistemas de negócios, como WMS, TMS, etc., possuem ferramentas integradas para monitorar seus próprios processos. Mas, se se tratar de sistemas de fabricantes diferentes ou se a funcionalidade de monitoramento não estiver suficientemente desenvolvida, será necessário solicitar modificações caras ou atrair consultores especializados para configurações adicionais.
Consideremos uma abordagem em que necessitamos apenas de uma pequena parte da consultoria associada à identificação de fontes (tabelas) para obter indicadores do sistema.
A especificidade dos nossos armazéns é que vários sistemas de gestão de armazéns (WMS Exceed) operam num único complexo logístico. Os armazéns são divididos de acordo com as categorias de armazenamento de mercadorias (secas, alcoólicas, congeladas, etc.) não apenas logicamente. Dentro de um complexo logístico existem vários armazéns separados, cada um deles gerenciado por seu próprio WMS.
Para formar uma visão geral dos processos que ocorrem no armazém, os gestores analisam os relatórios de cada WMS várias vezes ao dia, processam mensagens dos operadores do armazém (receptores, selecionadores, empilhadores) e resumem os indicadores operacionais reais para reflexão no quadro de informações.
Para poupar tempo aos gestores, decidimos desenvolver um sistema barato para controle operacional de eventos de armazém. O novo sistema, além de apresentar indicadores “quentes” do desempenho operacional dos processos de armazém, deverá também auxiliar os gestores no registo de incidentes e no acompanhamento da execução de tarefas para eliminar as causas que afetam os indicadores indicados. Depois de realizar uma auditoria geral da arquitetura de TI da empresa, percebemos que partes individuais do sistema necessário já existem de uma forma ou de outra em nosso cenário e para elas há um exame das configurações e dos serviços de suporte necessários. Resta reunir todo o conceito em uma única solução arquitetônica e estimar o escopo do desenvolvimento.
Depois de avaliar a quantidade de trabalho que precisa ser feito para construir um novo sistema, decidiu-se dividir o projeto em várias etapas:
- Coleta de indicadores de processos de armazém, visualização e controle de indicadores e desvios
- Automação de padrões de processos e registro de solicitações no serviço business services para desvios
- Monitoramento proativo com previsão de carga e criação de recomendações para gestores.
Na primeira etapa, o sistema deve coletar fatias preparadas de dados operacionais de todos os WMS do complexo. A leitura ocorre quase em tempo real (intervalos inferiores a 5 minutos). O truque é que os dados devem ser obtidos do SGBD de várias dezenas de armazéns ao implantar o sistema em toda a rede. Os dados operacionais recebidos são processados pela lógica do núcleo do sistema para calcular desvios dos indicadores planejados e calcular estatísticas. Os dados assim processados devem ser apresentados no tablet do gestor ou no quadro de informações do armazém na forma de gráficos e diagramas compreensíveis.
Na escolha de um sistema adequado para a implementação piloto da primeira etapa, optamos pelo Zabbix. Este sistema já é usado para monitorar o desempenho de TI dos sistemas de armazém. Ao adicionar uma instalação separada para coletar métricas de negócios da operação do armazém, você pode obter uma visão geral da integridade do armazém.
A arquitetura geral do sistema ficou como na figura.
Cada instância do WMS é definida como um host para o sistema de monitoramento. As métricas são coletadas por um servidor central na rede do data center, executando um script com uma consulta SQL preparada. Se precisar monitorar um sistema que não recomenda acesso direto ao banco de dados (por exemplo, SAP EWM), você pode usar chamadas de script para funções de API documentadas para obter indicadores ou escrever um programa simples em python/vbascript.
Uma instância do proxy Zabbix é implantada na rede do warehouse para distribuir a carga do servidor principal. Através do Proxy é garantido o trabalho com todas as instâncias locais do WMS. Na próxima vez que o servidor Zabbix solicitar parâmetros, um script será executado no host com o proxy Zabbix para solicitar métricas do banco de dados WMS.
Para exibir gráficos e indicadores de warehouse no servidor central Zabbix, implantamos o Grafana. Além de exibir dashboards elaborados com infográficos das operações do armazém, o Grafana será utilizado para monitorar desvios nos indicadores e enviar alertas automáticos ao sistema de atendimento do armazém para atendimento de incidentes de negócio.
Como exemplo, consideremos a implementação do controle de carga na área de recebimento do armazém. Foram escolhidos como principais indicadores de desempenho dos processos nesta área do armazém:
- quantidade de veículos na área de recepção, levando em consideração status (planejado, chegado, documentos, descarga, saída);
- carga de trabalho das áreas de colocação e reposição (conforme condições de armazenamento).
configurações
A instalação e configuração dos principais componentes do sistema (SQLcl, Zabbix, Grafana) são descritas em diversas fontes e não serão repetidas aqui. O uso de SQLcl em vez de SQLplus se deve ao fato de que SQLcl (a interface de linha de comando do Oracle DBMS, escrita em java) não requer instalação adicional do Oracle Client e funciona imediatamente.
Descreverei os principais pontos que devem ser observados ao usar o Zabbix para monitorar indicadores de processos de negócios de warehouse, e uma das possíveis formas de implementá-los. Além disso, este não é um post sobre segurança. A segurança das conexões e a utilização dos métodos apresentados requerem estudos adicionais no processo de transferência da solução piloto para operação produtiva.
O principal é que na implementação de tal sistema seja possível prescindir de programação, utilizando as configurações fornecidas pelo sistema.
O sistema de monitoramento Zabbix oferece diversas opções para coletar métricas do sistema monitorado. Isso pode ser feito pesquisando diretamente os hosts monitorados ou por um método mais avançado de envio de dados ao servidor através do zabbix_sender do host, incluindo métodos para configurar parâmetros de descoberta de baixo nível. Para resolver nosso problema, o método de pesquisa direta de hosts por um servidor central é bastante adequado, porque isso permite que você obtenha controle total sobre a sequência de aquisição de métricas e garante que você use um conjunto de configurações/scripts sem a necessidade de distribuí-los para cada host monitorado.
Como “cobaias” para depuração e configuração do sistema, utilizamos planilha WMS para gerenciamento de aceitação:
- Veículos na recepção, todos os que chegaram: Todos os veículos com status do período “- 72 horas a partir do horário atual” - Identificador da consulta SQL: getCars.
- Histórico de todos os status dos veículos: Status de todos os veículos que chegam dentro de 72 horas - Identificador de consulta SQL: carrosHistória.
- Veículos programados para aceitação: Situações de todos os veículos com chegada no estado “Programado”, intervalo de tempo “- 24 horas” e “+24 horas” a partir do horário atual - Identificador da consulta SQL: carrosEm.
Assim, depois de decidirmos sobre um conjunto de métricas de desempenho do armazém, prepararemos consultas SQL para o banco de dados WMS. Para executar consultas, é aconselhável utilizar não o banco de dados principal, mas sua cópia “quente” - standby.
Nós nos conectamos ao Oracle DBMS em espera para receber dados. Endereço IP para conexão com o banco de dados de teste 192.168.1.106. Salvamos os parâmetros de conexão no servidor Zabbix em TNSNames.ORA da pasta de trabalho 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)
)
)Isso nos permitirá executar consultas SQL para cada host via EZconnect, especificando apenas o login/senha e o nome do banco de dados:
# sql znew/Zabmon1@WH1_1Salvamos as consultas SQL preparadas na pasta de trabalho do servidor Zabbix:
/etc/zabbix/sqle permitir acesso ao usuário zabbix do nosso servidor:
# chown zabbix:zabbix -R /etc/zabbix/sqlArquivos com requisições recebem um nome-identificador exclusivo para acesso do servidor Zabbix. Cada consulta ao banco de dados via SQLcl nos retorna diversos parâmetros. Levando em consideração as especificidades do Zabbix, que pode processar apenas uma métrica por solicitação, usaremos scripts adicionais para analisar os resultados da consulta em métricas individuais.
Vamos preparar o script principal, vamos chamá-lo de wh_Metrics.sh, para chamar uma consulta SQL ao banco de dados, salvar os resultados e retornar uma métrica técnica com indicadores de sucesso na recuperação dos dados:
#!/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 o arquivo finalizado com o script na pasta para armazenar scripts externos de acordo com as configurações do proxy Zabbix (por padrão - /usr/local/share/zabbix/externalscripts).
A identificação do banco de dados do qual o script receberá os resultados será passada como parâmetro do script. O ID do banco de dados deve corresponder à linha de configurações no arquivo TNSNames.ORA.
O resultado da chamada de consulta SQL é salvo em um arquivo como mon_base_id_main.log onde base_id = O identificador do banco de dados recebido como parâmetro de script. A divisão do arquivo de resultados por identificadores de banco de dados é fornecida no caso de solicitações do servidor para vários bancos de dados simultaneamente. A consulta retorna uma matriz bidimensional classificada de valores.
O script a seguir, vamos chamá-lo de getMetrica.sh, é necessário para obter uma métrica especificada de um arquivo com o resultado de uma solicitação:
#!/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
doneAgora estamos prontos para configurar o Zabbix e começar a monitorar os indicadores dos processos de aceitação do warehouse.
Um agente Zabbix é instalado e configurado em cada nó do banco de dados.
No servidor principal definimos todos os servidores com proxy Zabbix. Para configurações, vá para o seguinte caminho:
Administração → Proxy → Criar proxy
Definimos hosts controlados:
Configurações → Hosts → Criar host
O nome do host deve corresponder ao nome do host especificado no arquivo de configuração do agente.
Especificamos o grupo do nó, bem como o endereço IP ou nome DNS do nó com o banco de dados.
Criamos métricas e especificamos suas propriedades:
Configurações → Nós → 'nome do nó' → Itens de dados>Criar item de dados
1) Crie uma métrica principal para consultar todos os parâmetros do banco de dados
Definimos o nome do elemento de dados, indicamos o tipo “Verificação externa”. No campo “Chave” definimos um script para o qual passamos como parâmetros o nome do banco de dados Oracle, o nome da consulta sql, o login e senha para conexão ao banco de dados. Defina o intervalo de atualização da consulta para 5 minutos (300 segundos).
2) Crie as métricas restantes para cada status do veículo. Os valores dessas métricas serão gerados com base no resultado da verificação da métrica principal.
Definimos o nome do elemento de dados, indicamos o tipo “Verificação externa”. No campo “Chave” definimos um script para o qual passamos como parâmetros o nome do banco de dados Oracle e o código de status cujo valor queremos rastrear. Definimos o intervalo de atualização da consulta para 10 segundos a mais que a métrica principal (310 segundos) para que os resultados tenham tempo de serem gravados no arquivo.
Para obter métricas corretamente, a ordem em que as verificações são ativadas é importante. Para evitar conflitos no recebimento dos dados, primeiro ativamos a métrica principal GetCarsByStatus chamando o script - wh_Metrics.sh.
Configurações → Nós → 'nome do nó' → Elementos de dados → Subfiltro “Verificações externas”. Marque a verificação necessária e clique em “Ativar”.
A seguir, ativamos as demais métricas em uma operação, selecionando todas juntas:
Agora o Zabbix começou a coletar métricas de negócios de warehouse.
Nos artigos a seguir, examinaremos mais de perto a conexão do Grafana e a criação de painéis de informações de operações de warehouse para diversas categorias de usuários. O Grafana também é utilizado para monitorar desvios nas operações de armazém e, dependendo dos limites e frequência dos desvios, registrar incidentes no sistema da central de serviços de gestão de armazém via API ou simplesmente enviar notificações ao gestor por e-mail.
Fonte: habr.com