DIY : comment nous automatisons la surveillance des entrepôts

X5 exploite 43 centres de distribution et 4 029 de ses propres camions, assurant un approvisionnement ininterrompu en produits à 15 752 magasins. Dans cet article, je partagerai mon expérience dans la création d'un système interactif de surveillance des événements d'entrepôt à partir de zéro. Ces informations seront utiles aux logisticiens des sociétés commerciales disposant de plusieurs dizaines de centres de distribution gérant une large gamme de produits.

En règle générale, la construction de systèmes de surveillance et de gestion des processus métier commence par le traitement des messages et des incidents. Dans le même temps, un point technologique important lié à la possibilité d'automatiser le fait même de la survenance des événements commerciaux et de l'enregistrement des incidents est négligé. La plupart des systèmes d'entreprise tels que WMS, TMS, etc. disposent d'outils intégrés pour surveiller leurs propres processus. Mais s'il s'agit de systèmes de différents fabricants ou si la fonctionnalité de surveillance n'est pas suffisamment développée, vous devrez commander des modifications coûteuses ou faire appel à des consultants spécialisés pour des réglages supplémentaires.

Considérons une approche dans laquelle nous n'avons besoin que d'une petite partie du conseil associé à l'identification des sources (tableaux) pour obtenir des indicateurs du système.

La spécificité de nos entrepôts réside dans le fait que plusieurs systèmes de gestion d'entrepôt (WMS Exceed) fonctionnent au sein d'un même complexe logistique. Les entrepôts sont répartis selon les catégories de stockage de marchandises (sèches, alcoolisées, congelées, etc.) non seulement de manière logique. Au sein d'un complexe logistique, il existe plusieurs bâtiments d'entrepôt distincts, chacun étant géré par son propre WMS.

Pour se faire une idée générale des processus se déroulant dans l'entrepôt, les responsables analysent plusieurs fois par jour le reporting de chaque WMS, traitent les messages des opérateurs de l'entrepôt (réceptionnaires, préparateurs, gerbeurs) et résument les indicateurs opérationnels réels pour réflexion sur le panneau d'information.

Pour faire gagner du temps aux gestionnaires, nous avons décidé de développer un système peu coûteux de contrôle opérationnel des événements en entrepôt. Le nouveau système, en plus d'afficher des indicateurs « chauds » de la performance opérationnelle des processus de l'entrepôt, devrait également aider les gestionnaires à enregistrer les incidents et à surveiller la mise en œuvre des tâches pour éliminer les causes qui affectent les indicateurs donnés. Après avoir effectué un audit général de l’architecture informatique de l’entreprise, nous avons réalisé que certaines parties du système requis existent déjà d’une manière ou d’une autre dans notre paysage et qu’elles nécessitent à la fois un examen des paramètres et des services de support nécessaires. Il ne reste plus qu'à regrouper l'ensemble du concept en une seule solution architecturale et à estimer l'ampleur du développement.

Après avoir évalué la quantité de travail à effectuer pour construire un nouveau système, il a été décidé de diviser le projet en plusieurs étapes :

1. Collecte d'indicateurs pour les processus d'entrepôt, visualisation et contrôle des indicateurs et des écarts
2. Automatisation des normes de processus et enregistrement des demandes dans le service des services aux entreprises pour les écarts
3. Surveillance proactive avec prévision de charge et création de recommandations pour les gestionnaires.

Dans un premier temps, le système doit collecter des tranches préparées de données opérationnelles de tous les WMS du complexe. La lecture s'effectue quasiment en temps réel (intervalles inférieurs à 5 minutes). L'astuce est que les données doivent être obtenues à partir du SGBD de plusieurs dizaines d'entrepôts lors du déploiement du système sur l'ensemble du réseau. Les données opérationnelles reçues sont traitées par la logique du cœur du système pour calculer les écarts par rapport aux indicateurs prévus et calculer les statistiques. Les données ainsi traitées doivent être affichées sur la tablette du gestionnaire ou sur le panneau d'information de l'entrepôt sous forme de graphiques et de schémas compréhensibles.

Lors du choix d'un système approprié pour la mise en œuvre pilote de la première étape, nous avons choisi Zabbix. Ce système est déjà utilisé pour surveiller les performances informatiques des systèmes d'entrepôt. En ajoutant une installation distincte pour collecter les mesures commerciales du fonctionnement de l'entrepôt, vous pouvez obtenir une image globale de la santé de l'entrepôt.

L'architecture générale du système s'est avérée comme sur la figure.

Chaque instance WMS est définie comme hôte du système de surveillance. Les métriques sont collectées par un serveur central du réseau du centre de données en exécutant un script avec une requête SQL préparée. Si vous devez surveiller un système qui ne recommande pas l'accès direct à la base de données (par exemple, SAP EWM), vous pouvez utiliser des appels de script aux fonctions API documentées pour obtenir des indicateurs ou écrire un programme simple en python/vbascript.

Une instance proxy Zabbix est déployée dans le réseau de l'entrepôt pour répartir la charge du serveur principal. Grâce au proxy, le travail avec toutes les instances WMS locales est assuré. La prochaine fois que le serveur Zabbix demande des paramètres, un script est exécuté sur l'hôte avec le proxy Zabbix pour demander des métriques à la base de données WMS.

Pour afficher des graphiques et des indicateurs d'entrepôt sur le serveur central Zabbix, nous déployons Grafana. En plus d'afficher des tableaux de bord préparés avec des infographies des opérations de l'entrepôt, Grafana sera utilisé pour surveiller les écarts des indicateurs et envoyer des alertes automatiques au système de service de l'entrepôt pour travailler avec les incidents commerciaux.

A titre d'exemple, considérons la mise en place d'un contrôle de charge dans la zone de réception de l'entrepôt. Les éléments suivants ont été choisis comme principaux indicateurs de performance des processus dans cette zone de l'entrepôt :

• nombre de véhicules dans la zone d'accueil, en tenant compte des statuts (prévu, arrivé, documents, déchargement, départ) ;
• charge de travail des zones de placement et de réapprovisionnement (selon les conditions de stockage).

réglages

L'installation et la configuration des principaux composants du système (SQLcl, Zabbix, Grafana) sont décrites dans diverses sources et ne seront pas répétées ici. L'utilisation de SQLcl au lieu de SQLplus est due au fait que SQLcl (l'interface de ligne de commande du SGBD Oracle, écrite en Java) ne nécessite pas d'installation supplémentaire du client Oracle et fonctionne immédiatement.

Je décrirai les principaux points auxquels il convient de prêter attention lors de l'utilisation de Zabbix pour surveiller les indicateurs de processus métier de l'entrepôt, et l'un des moyens possibles de les mettre en œuvre. De plus, ce n'est pas un article sur la sécurité. La sécurité des connexions et l'utilisation des méthodes présentées nécessitent une étude complémentaire dans le processus de transfert de la solution pilote en exploitation productive.

L'essentiel est que lors de la mise en œuvre d'un tel système, il soit possible de se passer de programmation, en utilisant les paramètres fournis par le système.

Le système de surveillance Zabbix propose plusieurs options pour collecter des métriques du système surveillé. Cela peut être fait soit en interrogeant directement les hôtes surveillés, soit par une méthode plus avancée d'envoi de données au serveur via le zabbix_sender de l'hôte, y compris des méthodes de configuration des paramètres de découverte de bas niveau. Pour résoudre notre problème, la méthode d'interrogation directe des hôtes par un serveur central est tout à fait adaptée, car cela vous permet d'avoir un contrôle total sur la séquence d'acquisition des métriques et garantit que vous utilisez un ensemble de paramètres/scripts sans avoir besoin de les distribuer à chaque hôte surveillé.

En tant que « sujets de test » pour le débogage et la configuration du système, nous utilisons la feuille de travail WMS pour la gestion des acceptations :

1. Véhicules à l'accueil, tous arrivés : Tous les véhicules ayant des statuts pour la période « - 72 heures à compter de l'heure actuelle » - Identifiant de requête SQL : obtenir des voitures.
2. Historique de tous les statuts des véhicules : Statuts de tous les véhicules arrivés dans les 72 heures - Identifiant de requête SQL : voituresHistoire.
3. Véhicules programmés pour acceptation : Statuts de tous les véhicules avec arrivée en statut « Programmé », intervalle de temps « - 24 heures » et « +24 heures » à partir de l'heure actuelle - Identifiant de requête SQL : voituresDans.

Ainsi, après avoir décidé d'un ensemble de mesures de performances de l'entrepôt, nous préparerons des requêtes SQL pour la base de données WMS. Pour exécuter des requêtes, il est conseillé d'utiliser non pas la base de données principale, mais sa copie « à chaud » - en veille.

Nous nous connectons au SGBD Oracle en veille pour recevoir des données. Adresse IP de connexion à la base de données de test 192.168.1.106. Nous sauvegardons les paramètres de connexion sur le serveur Zabbix dans TNSNames.ORA du dossier de travail 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)
    )
  )

Cela nous permettra d'exécuter des requêtes SQL sur chaque hôte via EZconnect, en spécifiant uniquement le login/mot de passe et le nom de la base de données :

# sql znew/Zabmon1@WH1_1

Nous enregistrons les requêtes SQL préparées dans le dossier de travail sur le serveur Zabbix :

/etc/zabbix/sql

et autorisez l'accès à l'utilisateur zabbix de notre serveur :

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

Les fichiers avec des requêtes reçoivent un nom d'identifiant unique pour l'accès depuis le serveur Zabbix. Chaque requête de base de données via SQLcl nous renvoie plusieurs paramètres. Compte tenu des spécificités de Zabbix, qui ne peut traiter qu'une seule métrique par requête, nous utiliserons des scripts supplémentaires pour analyser les résultats de la requête en métriques individuelles.

Préparons le script principal, appelons-le wh_Metrics.sh, pour appeler une requête SQL à la base de données, enregistrer les résultats et renvoyer une métrique technique avec des indicateurs de succès de la récupération des données :

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

Nous plaçons le fichier fini avec le script dans le dossier de stockage des scripts externes conformément aux paramètres de configuration du proxy Zabbix (par défaut - /usr/local/share/zabbix/externalscripts).

L'identification de la base de données dont le script recevra les résultats sera passée en paramètre du script. L'ID de la base de données doit correspondre à la ligne de paramètres du fichier TNSNames.ORA.

Le résultat de l'appel de requête SQL est enregistré dans un fichier comme mon_base_id_main.log où base_id = L'identifiant de la base de données reçu en tant que paramètre de script. Le découpage du fichier résultat par identifiants de bases de données est assuré en cas de requêtes du serveur vers plusieurs bases de données simultanément. La requête renvoie un tableau de valeurs bidimensionnel trié.

Le script suivant, appelons-le getMetrica.sh, est nécessaire pour obtenir une métrique spécifiée à partir d'un fichier avec le résultat d'une requête :

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

Nous sommes maintenant prêts à configurer Zabbix et à commencer à surveiller les indicateurs des processus d'acceptation en entrepôt.

Un agent Zabbix est installé et configuré sur chaque nœud de base de données.

Sur le serveur principal, nous définissons tous les serveurs avec le proxy Zabbix. Pour les paramètres, accédez au chemin suivant :

Administration → Proxy → Créer un proxy

Nous définissons des hôtes contrôlés :

Paramètres → Hôtes → Créer un hôte

Le nom d'hôte doit correspondre au nom d'hôte spécifié dans le fichier de configuration de l'agent.

Nous spécifions le groupe du nœud, ainsi que l'adresse IP ou le nom DNS du nœud avec la base de données.

Nous créons des métriques et spécifions leurs propriétés :

Paramètres → Nœuds → 'nom du nœud' → Éléments de données>Créer un élément de données

1) Créez une métrique principale pour interroger tous les paramètres de la base de données

Nous définissons le nom de l'élément de données, indiquons le type « Vérification externe ». Dans le champ « Clé », on définit un script auquel on passe en paramètres le nom de la base de données Oracle, le nom de la requête sql, le login et le mot de passe de connexion à la base de données. Définissez l'intervalle de mise à jour des requêtes sur 5 minutes (300 secondes).

2) Créez les métriques restantes pour chaque statut de véhicule. Les valeurs de ces métriques seront générées en fonction du résultat de la vérification de la métrique principale.

Nous définissons le nom de l'élément de données, indiquons le type « Vérification externe ». Dans le champ « Clé », nous définissons un script auquel nous passons en paramètres le nom de la base de données Oracle et le code d'état dont nous voulons suivre la valeur. Nous définissons l'intervalle de mise à jour des requêtes sur 10 secondes de plus que la métrique principale (310 secondes) afin que les résultats aient le temps d'être écrits dans le fichier.

Pour obtenir correctement les métriques, l'ordre dans lequel les contrôles sont activés est important. Afin d'éviter les conflits lors de la réception des données, nous activons tout d'abord la métrique principale GetCarsByStatus en appelant le script - wh_Metrics.sh.

Paramètres → Nœuds → 'nom du nœud' → Éléments de données → Sous-filtre « Contrôles externes ». Cochez la case requise et cliquez sur « Activer ».

Ensuite, nous activons les métriques restantes en une seule opération, en les sélectionnant toutes ensemble :

Zabbix a maintenant commencé à collecter des statistiques commerciales sur les entrepôts.

Dans les articles suivants, nous examinerons de plus près la connexion de Grafana et la création de tableaux de bord d'informations sur les opérations de l'entrepôt pour différentes catégories d'utilisateurs. Grafana est également utilisé pour surveiller les écarts dans les opérations de l'entrepôt et, en fonction des limites et de la fréquence des écarts, enregistrer les incidents dans le système du centre de services de gestion de l'entrepôt via API ou simplement envoyer des notifications au responsable par e-mail.

Source: habr.com