O X5 gerencia 43 centros de distribuição e 4.029 caminhões próprios, eles fornecem um suprimento ininterrupto de produtos em 15.752 lojas. No artigo, compartilharei a experiência de criar do zero um sistema interativo para monitorar eventos do armazém. As informações serão úteis para a logística de empresas comerciais com dezenas de centros de distribuição gerenciando uma ampla gama de produtos.
Como regra, a construção de sistemas de monitoramento e gerenciamento de processos de negócios começa com o processamento de mensagens e incidentes. Ao mesmo tempo, perde-se um importante momento tecnológico relacionado à possibilidade de automatizar o fato da ocorrência de eventos de negócios e registrar incidentes. A maioria dos sistemas comerciais da classe WMS, TMS, etc., possui ferramentas internas para monitorar seus próprios processos. Porém, se for um sistema de fabricantes diferentes ou a funcionalidade de monitoramento não for suficientemente desenvolvida, você precisará solicitar melhorias caras ou envolver consultores especializados para configurações adicionais.
Considere uma abordagem na qual precisamos apenas de uma pequena parte da consultoria relacionada à determinação de fontes (tabelas) para obter indicadores do sistema.
A especificidade de nossos armazéns está no fato de que vários sistemas de gerenciamento de armazém (WMS Exceed) operam no mesmo complexo logístico. Os armazéns são divididos de acordo com as categorias de armazenamento de mercadorias (secas, álcool, congelamento etc.) não apenas logicamente. Dentro de um único complexo de logística, existem vários edifícios de armazém separados, as operações em cada um deles são gerenciadas por seu próprio WMS.
Para formar uma imagem geral dos processos que ocorrem no armazém, os gerentes analisam os relatórios de cada WMS várias vezes ao dia, processam as mensagens dos operadores do armazém (receptores, selecionadores, empilhadores) e resumem os indicadores operacionais reais para exibição no quadro de informações.
Para economizar tempo dos gerentes, decidimos desenvolver um sistema barato para controle operacional dos eventos do armazém. O novo sistema, além de exibir indicadores "quentes" do trabalho operacional dos processos do armazém, também deve ajudar os gerentes a corrigir incidentes e monitorar tarefas para eliminar as causas que afetam os indicadores fornecidos. Após realizar uma auditoria geral da arquitetura de TI da empresa, percebemos que certas partes do sistema necessário já existem de alguma forma em nosso cenário e, para elas, há um exame das configurações e dos serviços de suporte necessários. Resta apenas reduzir o conceito inteiro em uma única solução arquitetural e avaliar o escopo do desenvolvimento.
Após 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 sobre processos de armazém, visualização e controle de indicadores e desvios
- Automação de padrões de processo e registro de aplicativos no serviço de serviços de negócios para desvios
- Monitoramento proativo com previsão de carga e recomendações aos gerentes.
No primeiro estágio, o sistema deve coletar fatias preparadas de dados operacionais de todos os complexos WMS. A leitura ocorre quase em tempo real (intervalos inferiores a 5 minutos). O truque é que os dados devem ser obtidos no DBMS de várias dúzias de armazéns ao implantar o sistema em toda a rede. Os dados operacionais recebidos são processados pela lógica central do sistema para calcular desvios dos indicadores planejados e calcular estatísticas. Os dados processados dessa maneira devem ser exibidos no tablet do gerente ou no quadro de informações do armazém na forma de gráficos e diagramas claros.
Ao escolher um sistema adequado para a implementação piloto do primeiro estágio, optamos pelo Zabbix. Este sistema já está sendo 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 para operações de armazém, você pode obter uma imagem geral da saúde do armazém.
A arquitetura geral do sistema é mostrada 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 você precisar monitorar um sistema que não recomenda acesso direto ao banco de dados (por exemplo, SAP EWM), poderá usar chamadas de script para funções da API documentadas para gravar indicadores ou gravar um programa simples em python / vbascript.
O proxy Zabbix é implantado na rede do armazém para distribuir a carga do servidor principal. Por meio do Proxy, é fornecido o trabalho com todas as instâncias locais do WMS. Na próxima solicitação de parâmetros pelo servidor Zabbix no host com proxy Zabbix, um script é executado para solicitar métricas do banco de dados WMS.
Para exibir os gráficos e indicadores do armazém no servidor Zabbix central, implante o Grafana. Além de exibir painéis preparados com infográficos do armazém, o Grafana será usado para controlar desvios de indicadores e transferir alertas automáticos ao sistema de serviço do armazém para trabalhar com incidentes de negócios.
Como exemplo, considere a implementação do controle do carregamento da zona de aceitação do armazém. Como os principais indicadores dos processos nesta seção do armazém selecionados:
- o número de veículos na área de recepção, levando em consideração os status (planejado, chegado, documentos, descarga, partida;
- congestionamento de zonas de colocação e reposição (de acordo com as condições de armazenamento).
Configurações
A instalação e configuração dos principais componentes do sistema (SQLcl, Zabbix, Grafana) é descrita em diferentes fontes e não repetiremos aqui. O uso do SQLcl em vez do SQLplus deve-se ao fato de o SQLcl (a interface de linha de comando do Oracle DBMS escrita em java) não requer instalação adicional do Oracle Client e funciona de maneira imediata.
Descreverei os principais pontos que devem ser prestados atenção ao usar o Zabbix para monitorar o desempenho dos processos de negócios do armazém e uma das maneiras possíveis de implementá-los. Além disso, este post não é sobre segurança. A segurança das conexões e o uso dos métodos apresentados precisam de um estudo adicional no processo de transferência da solução piloto para a operação produtiva.
O principal é que, ao implementar esse sistema, é possível ficar sem programação, usando as configurações fornecidas pelo sistema.
O sistema de monitoramento Zabbix fornece várias opções para coletar métricas de um sistema monitorado. Isso pode ser feito pesquisando diretamente os hosts monitorados ou por um método mais avançado de enviar dados para o servidor através do zabbix_sender do host, incluindo métodos para definir 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. isso permite que você obtenha controle total sobre a sequência de obtenção de métricas e garante o uso de um pacote de configurações / scripts sem a necessidade de distribuí-los para cada host controlado.
Como "experimental" para depurar e ajustar o sistema, usamos as planilhas do WMS para controlar a recepção:
- TS na aceitação, tudo o que chegou: todos os TS com status para o período "- 72 horas a partir do horário atual" - identificador de consulta SQL: getCars .
- Histórico de todos os status dos veículos: status de todos os veículos com chegada em 72 horas - identificador de consulta SQL: carsHistory .
- Veículos agendados para aceitação: status de todos os veículos com o status "Agendado", o intervalo de tempo é " -24 horas" e "+24 horas" a partir do horário atual - identificador de consulta SQL: carsIn .
Portanto, depois de decidirmos sobre um conjunto de métricas de armazém, prepararemos consultas SQL para o banco de dados WMS. Para executar consultas, é aconselhável usar não o banco de dados principal, mas sua cópia "quente" - espera.
Estamos conectados ao Oracle DBMS em espera para aquisição de dados. Endereço IP para conexão à base de teste
192.168.1.106 . Os parâmetros de conexão são salvos no servidor Zabbix em TNSNames.ORA da pasta SQLcl em funcionamento:
# 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 através do EZconnect, especificando apenas o nome de usuário / senha e o nome do banco de dados:
# sql znew/Zabmon1@WH1_1
As consultas SQL preparadas são salvas na pasta de trabalho no servidor Zabbix:
/etc/zabbix/sql
e permita o acesso ao usuário zabbix do nosso servidor:
# chown zabbix:zabbix -R /etc/zabbix/sql
Os arquivos de solicitação recebem um nome de identificador exclusivo para acesso do servidor Zabbix. Cada consulta ao banco de dados através do SQLcl nos retorna vários parâmetros. Dadas as especificidades do Zabbix, que podem processar apenas uma métrica em uma consulta, usaremos scripts adicionais para analisar os resultados da consulta em métricas individuais.
Estamos preparando o script principal, vamos chamá-lo wh_Metrics.sh, para chamar a consulta SQL ao banco de dados, salvar os resultados e retornar a métrica técnica com os indicadores de sucesso para obter 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 fi
Colocamos o arquivo finalizado com o script na pasta para hospedar scripts externos de acordo com as configurações de proxy do Zabbix (por padrão -
/ usr / local / share / zabbix / externalscripts ).
A identificação do banco de dados do qual o script receberá os resultados será transmitida pelo parâmetro script. O identificador do banco de dados deve corresponder à linha de configurações no arquivo TNSNames.ORA.
O resultado da chamada da consulta SQL é salvo em um arquivo no formato
mon_base_id_main.log, em que base_id = identificador de banco de dados obtido como um parâmetro de script. A separação do arquivo de resultados por identificadores de banco de dados é fornecida no caso de solicitações do servidor simultaneamente para vários bancos de dados. A consulta retorna uma matriz bidimensional de valores classificada.
O script a seguir, vamos chamá-lo getMetrica.sh, é necessário para obter a métrica especificada do arquivo com o resultado da 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 done
Agora estamos prontos para configurar o Zabbix e começar a monitorar o desempenho dos processos de aceitação do armazém.
Em cada nó do banco de dados, um agente Zabbix é instalado e configurado.
No servidor principal, definimos todos os servidores com proxies Zabbix. Para configurações, vá para o seguinte caminho:
Administração → Proxies → Criar Proxy
Defina 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.
Indicamos o grupo para o nó, bem como o endereço IP ou o nome DNS do nó no 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 básica para consultar todos os parâmetros do banco de dados
Definimos o nome do elemento de dados, indicamos o tipo de "Verificação externa". No campo “Chave”, definimos um script para o qual transferimos o nome do banco de dados Oracle, o nome da consulta sql, o login e a senha para conectar-se ao banco de dados como parâmetros. Defina o intervalo de atualização da solicitação para 5 minutos (300 segundos).
2) Crie as métricas restantes para cada status do veículo. Os valores dessas métricas serão formados com base no resultado da verificação da métrica principal.
Definimos o nome do elemento de dados, indicamos o tipo de "Verificação externa". No campo "Chave", definimos um script para o qual transferimos o nome do banco de dados Oracle e o código de status, cujo valor queremos rastrear como parâmetros. Definimos o intervalo de atualização para a solicitação 10 segundos a mais que a métrica principal (310 segundos), para que os resultados possam ser gravados no arquivo.
Para obter métricas corretamente, a ordem na qual as verificações são ativadas é importante. Para evitar conflitos ao receber dados, ative primeiro a métrica principal GetCarsByStatus com uma chamada de script - wh_Metrics.sh.
Configurações → Nós → 'nome do nó' → Elementos dos dados → Subfiltro “Verificações externas”. Marcamos a verificação necessária e clicamos em "Ativar".
Em seguida, ative as métricas restantes em uma operação, selecionando todas juntas:
O Zabbix agora começou a coletar métricas de negócios de armazém.
Nos artigos a seguir, examinaremos mais detalhadamente a conexão do Grafana e a formação de painéis informativos para operações de armazém para várias categorias de usuários. A Grafana também monitora os desvios no armazém e, dependendo dos limites e da frequência dos desvios, registra incidentes no sistema do centro de serviços de gerenciamento de armazém por meio da API ou simplesmente envia notificações ao gerente por e-mail.
