DIY: Wie wir die Lagerüberwachung automatisieren

X5 betreibt 43 Vertriebszentren und 4 eigene LKWs und gewährleistet so eine unterbrechungsfreie Produktversorgung von 029 Filialen. In diesem Artikel werde ich meine Erfahrungen mit der Erstellung eines interaktiven Systems zur Überwachung von Lagerereignissen von Grund auf teilen. Die Informationen werden für Logistiker von Handelsunternehmen mit mehreren Dutzend Vertriebszentren, die eine breite Produktpalette verwalten, nützlich sein.

Der Aufbau von Überwachungs- und Geschäftsprozessmanagementsystemen beginnt in der Regel mit der Bearbeitung von Meldungen und Vorfällen. Gleichzeitig wird ein wichtiger technologischer Punkt im Zusammenhang mit der Möglichkeit der Automatisierung des tatsächlichen Auftretens von Geschäftsereignissen und der Aufzeichnung von Vorfällen übersehen. Die meisten Geschäftssysteme wie WMS, TMS usw. verfügen über integrierte Tools zur Überwachung ihrer eigenen Prozesse. Handelt es sich jedoch um Systeme unterschiedlicher Hersteller oder ist die Überwachungsfunktionalität nicht ausreichend ausgereift, müssen für zusätzliche Einstellungen teure Modifikationen in Auftrag gegeben oder Fachberater hinzugezogen werden.

Betrachten wir einen Ansatz, bei dem wir nur einen kleinen Teil der Beratung benötigen, die mit der Identifizierung von Quellen (Tabellen) verbunden ist, um Indikatoren aus dem System zu erhalten.

Die Besonderheit unserer Lager besteht darin, dass in einem Logistikkomplex mehrere Lagerverwaltungssysteme (WMS Exceed) betrieben werden. Lagerhäuser sind nicht nur logisch nach Kategorien der Warenlagerung (trocken, alkoholisch, gefroren usw.) unterteilt. Innerhalb eines Logistikkomplexes gibt es mehrere separate Lagergebäude, die jeweils von einem eigenen WMS verwaltet werden.

Um sich einen Überblick über die im Lager ablaufenden Prozesse zu verschaffen, analysieren Manager mehrmals täglich die Berichte jedes WMS, verarbeiten Meldungen von Lagermitarbeitern (Empfänger, Kommissionierer, Stapler) und fassen aktuelle Betriebsindikatoren zur Reflexion auf der Informationstafel zusammen.

Um den Managern Zeit zu sparen, haben wir uns entschieden, ein kostengünstiges System zur betrieblichen Kontrolle von Lagerereignissen zu entwickeln. Das neue System soll nicht nur „heiße“ Indikatoren für die Betriebsleistung von Lagerprozessen anzeigen, sondern den Managern auch dabei helfen, Vorfälle zu erfassen und die Umsetzung von Aufgaben zu überwachen, um die Ursachen zu beseitigen, die sich auf die angegebenen Indikatoren auswirken. Nach einer allgemeinen Prüfung der IT-Architektur des Unternehmens stellten wir fest, dass einzelne Teile des erforderlichen Systems in unserer Landschaft bereits auf die eine oder andere Weise vorhanden sind und für diese sowohl eine Prüfung der Einstellungen als auch der erforderlichen Supportleistungen erforderlich sind. Es bleibt nur noch, das gesamte Konzept in einer einzigen architektonischen Lösung zusammenzufassen und den Umfang der Entwicklung abzuschätzen.

Nach der Einschätzung des Arbeitsaufwands, der für den Aufbau eines neuen Systems erforderlich ist, wurde beschlossen, das Projekt in mehrere Phasen aufzuteilen:

1. Erfassung von Kennzahlen für Lagerprozesse, Visualisierung und Kontrolle von Kennzahlen und Abweichungen
2. Automatisierung von Prozessstandards und Registrierung von Anträgen im Business Services Service für Abweichungen
3. Proaktive Überwachung mit Lastprognose und Erstellung von Empfehlungen für Manager.

In der ersten Phase muss das System vorbereitete Abschnitte von Betriebsdaten aus allen WMS des Komplexes sammeln. Das Ablesen erfolgt nahezu in Echtzeit (Intervalle von weniger als 5 Minuten). Der Trick besteht darin, dass bei der Bereitstellung des Systems im gesamten Netzwerk Daten aus dem DBMS von mehreren Dutzend Lagern abgerufen werden müssen. Die empfangenen Betriebsdaten werden von der Logik des Systemkerns verarbeitet, um Abweichungen von geplanten Indikatoren zu berechnen und Statistiken zu berechnen. Die so verarbeiteten Daten müssen auf dem Tablet des Managers oder auf der Lagerinformationstafel in Form verständlicher Grafiken und Diagramme angezeigt werden.

Bei der Auswahl eines geeigneten Systems für die Pilotumsetzung der ersten Stufe haben wir uns für Zabbix entschieden. Dieses System wird bereits zur Überwachung der IT-Leistung von Lagersystemen eingesetzt. Durch das Hinzufügen einer separaten Installation zur Erfassung von Geschäftskennzahlen des Lagerbetriebs können Sie sich einen Gesamtüberblick über den Zustand des Lagers verschaffen.

Die allgemeine Architektur des Systems entsprach der Abbildung.

Jede WMS-Instanz ist als Host für das Überwachungssystem definiert. Metriken werden von einem zentralen Server im Rechenzentrumsnetzwerk erfasst, indem ein Skript mit einer vorbereiteten SQL-Abfrage ausgeführt wird. Wenn Sie ein System überwachen müssen, das keinen direkten Zugriff auf die Datenbank empfiehlt (z. B. SAP EWM), können Sie Skriptaufrufe an dokumentierte API-Funktionen verwenden, um Indikatoren zu erhalten, oder ein einfaches Programm in Python/Vbascript schreiben.

Eine Zabbix-Proxy-Instanz wird im Lagernetzwerk bereitgestellt, um die Last vom Hauptserver zu verteilen. Durch Proxy wird die Arbeit mit allen lokalen WMS-Instanzen sichergestellt. Wenn der Zabbix-Server das nächste Mal Parameter anfordert, wird auf dem Host mit dem Zabbix-Proxy ein Skript ausgeführt, um Metriken aus der WMS-Datenbank anzufordern.

Um Grafiken und Lagerindikatoren auf dem zentralen Zabbix-Server anzuzeigen, setzen wir Grafana ein. Neben der Anzeige vorbereiteter Dashboards mit Infografiken des Lagerbetriebs wird Grafana auch zur Überwachung von Abweichungen bei Indikatoren und zum Senden automatischer Warnungen an das Lagerservicesystem zur Bearbeitung von Geschäftsvorfällen eingesetzt.

Betrachten wir als Beispiel die Umsetzung der Ladungskontrolle im Wareneingangsbereich des Lagers. Als Hauptindikatoren für die Prozessleistung in diesem Bereich des Lagers wurden ausgewählt:

• Anzahl der Fahrzeuge im Empfangsbereich unter Berücksichtigung der Status (geplant, angekommen, Dokumente, Entladung, Abfahrt);
• Auslastung der Platzierungs- und Nachschubbereiche (je nach Lagerbedingungen).

Einstellungen

Die Installation und Konfiguration der Hauptkomponenten des Systems (SQLcl, Zabbix, Grafana) wird in verschiedenen Quellen beschrieben und wird hier nicht wiederholt. Die Verwendung von SQLcl anstelle von SQLplus ist auf die Tatsache zurückzuführen, dass SQLcl (die in Java geschriebene Befehlszeilenschnittstelle des Oracle DBMS) keine zusätzliche Installation des Oracle Client erfordert und sofort einsatzbereit ist.

Ich beschreibe die wichtigsten Punkte, auf die bei der Verwendung von Zabbix zur Überwachung von Lagergeschäftsprozessindikatoren geachtet werden sollte, und eine der möglichen Möglichkeiten, diese zu implementieren. Außerdem geht es in diesem Beitrag nicht um Sicherheit. Die Sicherheit der Verbindungen und der Einsatz der vorgestellten Methoden erfordert zusätzliche Untersuchungen im Prozess der Überführung der Pilotlösung in den Produktivbetrieb.

Die Hauptsache ist, dass bei der Implementierung eines solchen Systems auf die Programmierung verzichtet werden kann und die vom System bereitgestellten Einstellungen verwendet werden können.

Das Zabbix-Überwachungssystem bietet mehrere Optionen zum Sammeln von Metriken aus dem überwachten System. Dies kann entweder durch direktes Abfragen überwachter Hosts oder durch eine erweiterte Methode zum Senden von Daten an den Server über den zabbix_sender des Hosts erfolgen, einschließlich Methoden zum Konfigurieren von Erkennungsparametern auf niedriger Ebene. Um unser Problem zu lösen, ist die Methode der direkten Abfrage von Hosts durch einen zentralen Server durchaus geeignet, denn Dadurch erhalten Sie die volle Kontrolle über die Reihenfolge der Metrikerfassung und stellen sicher, dass Sie einen Satz Einstellungen/Skripts verwenden, ohne diese an jeden überwachten Host verteilen zu müssen.

Als „Testpersonen“ zum Debuggen und Einrichten des Systems nutzen wir das WMS-Arbeitsblatt für das Abnahmemanagement:

1. Fahrzeuge an der Rezeption, alle angekommenen: Alle Fahrzeuge mit Status für den Zeitraum „- 72 Stunden ab der aktuellen Zeit“ – SQL-Abfragekennung: getCars.
2. Historie aller Fahrzeugstatus: Status aller innerhalb von 72 Stunden eintreffenden Fahrzeuge – SQL-Abfrage-ID: AutosGeschichte.
3. Geplante Fahrzeuge zur Annahme: Status aller Fahrzeuge mit Ankunft im Status „geplant“, Zeitintervall „- 24 Stunden“ und „+24 Stunden“ ab der aktuellen Uhrzeit – SQL-Abfragekennung: AutosIn.

Nachdem wir uns für eine Reihe von Kennzahlen zur Lagerleistung entschieden haben, bereiten wir SQL-Abfragen für die WMS-Datenbank vor. Um Abfragen auszuführen, empfiehlt es sich, nicht die Hauptdatenbank, sondern deren „heiße“ Kopie – Standby – zu verwenden.

Wir stellen eine Verbindung zum Standby-Oracle-DBMS her, um Daten zu empfangen. IP-Adresse für die Verbindung zur Testdatenbank 192.168.1.106. Wir speichern die Verbindungsparameter auf dem Zabbix-Server in TNSNames.ORA des SQLcl-Arbeitsordners:

# 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)
    )
  )

Dadurch können wir über EZconnect SQL-Abfragen an jeden Host ausführen und dabei nur den Benutzernamen/das Passwort und den Datenbanknamen angeben:

# sql znew/Zabmon1@WH1_1

Wir speichern die vorbereiteten SQL-Abfragen im Arbeitsordner auf dem Zabbix-Server:

/etc/zabbix/sql

und erlauben Sie dem Zabbix-Benutzer unseren Serverzugriff:

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

Dateien mit Anfragen erhalten einen eindeutigen Bezeichnernamen für den Zugriff vom Zabbix-Server. Jede Datenbankabfrage über SQLcl gibt uns mehrere Parameter zurück. Unter Berücksichtigung der Besonderheiten von Zabbix, das nur eine Metrik pro Anfrage verarbeiten kann, werden wir zusätzliche Skripte verwenden, um die Abfrageergebnisse in einzelne Metriken zu analysieren.

Bereiten wir das Hauptskript vor, nennen wir es wh_Metrics.sh, um eine SQL-Abfrage an die Datenbank aufzurufen, die Ergebnisse zu speichern und eine technische Metrik mit Indikatoren für den Erfolg des Datenabrufs zurückzugeben:

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

Wir legen die fertige Datei mit dem Skript im Ordner zum Speichern externer Skripte gemäß den Zabbix-Proxy-Konfigurationseinstellungen ab (standardmäßig - /usr/local/share/zabbix/externalscripts).

Die Identifikation der Datenbank, aus der das Skript Ergebnisse erhält, wird als Skriptparameter übergeben. Die Datenbank-ID muss mit der Einstellungszeile in der Datei TNSNames.ORA übereinstimmen.

Das Ergebnis des SQL-Abfrageaufrufs wird in einer Datei gespeichert mon_base_id_main.log wobei base_id = Die als Skriptparameter empfangene Datenbankkennung. Die Aufteilung der Ergebnisdatei nach Datenbankkennungen ist bei gleichzeitigen Anfragen des Servers an mehrere Datenbanken vorgesehen. Die Abfrage gibt ein sortiertes zweidimensionales Array von Werten zurück.

Das folgende Skript, nennen wir es getMetrica.sh, wird benötigt, um eine bestimmte Metrik aus einer Datei mit dem Ergebnis einer Anfrage abzurufen:

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

Jetzt können wir Zabbix konfigurieren und mit der Überwachung von Indikatoren für Lagerannahmeprozesse beginnen.

Auf jedem Datenbankknoten wird ein Zabbix-Agent installiert und konfiguriert.

Auf dem Hauptserver definieren wir alle Server mit Zabbix-Proxy. Für Einstellungen gehen Sie zu folgendem Pfad:

Administration → Proxy → Proxy erstellen

Wir definieren kontrollierte Hosts:

Einstellungen → Hosts → Host erstellen

Der Hostname muss mit dem Hostnamen übereinstimmen, der in der Agent-Konfigurationsdatei angegeben ist.

Wir geben die Gruppe für den Knoten sowie die IP-Adresse oder den DNS-Namen des Knotens mit der Datenbank an.

Wir erstellen Metriken und spezifizieren deren Eigenschaften:

Einstellungen → Knoten → 'Knotenname' → Datenelemente > Datenelement erstellen

1) Erstellen Sie eine Hauptmetrik, um alle Parameter aus der Datenbank abzufragen

Wir legen den Namen des Datenelements fest und geben den Typ „Externe Überprüfung“ an. Im Feld „Schlüssel“ definieren wir ein Skript, an das wir als Parameter den Namen der Oracle-Datenbank, den Namen der SQL-Abfrage, den Login und das Passwort für die Verbindung zur Datenbank übergeben. Legen Sie das Abfrageaktualisierungsintervall auf 5 Minuten (300 Sekunden) fest.

2) Erstellen Sie die verbleibenden Metriken für jeden Fahrzeugstatus. Die Werte dieser Metriken werden basierend auf dem Ergebnis der Überprüfung der Hauptmetrik generiert.

Wir legen den Namen des Datenelements fest und geben den Typ „Externe Überprüfung“ an. Im Feld „Schlüssel“ definieren wir ein Skript, dem wir als Parameter den Namen der Oracle-Datenbank und den Statuscode übergeben, dessen Wert wir verfolgen möchten. Wir legen das Abfrageaktualisierungsintervall auf 10 Sekunden länger als die Hauptmetrik (310 Sekunden) fest, damit die Ergebnisse Zeit haben, in die Datei geschrieben zu werden.

Um die Metriken korrekt zu erhalten, ist die Reihenfolge, in der die Prüfungen aktiviert werden, wichtig. Um Konflikte beim Empfang von Daten zu vermeiden, aktivieren wir zunächst die Hauptmetrik GetCarsByStatus, indem wir das Skript wh_Metrics.sh aufrufen.

Einstellungen → Knoten → „Knotenname“ → Datenelemente → Unterfilter „Externe Prüfungen“. Markieren Sie den gewünschten Haken und klicken Sie auf „Aktivieren“.

Als nächstes aktivieren wir die verbleibenden Metriken in einem Vorgang und wählen sie alle zusammen aus:

Jetzt hat Zabbix damit begonnen, Lagergeschäftskennzahlen zu sammeln.

In den folgenden Artikeln werfen wir einen genaueren Blick auf die Anbindung von Grafana und die Erstellung von Informations-Dashboards des Lagerbetriebs für verschiedene Benutzerkategorien. Grafana wird auch verwendet, um Abweichungen im Lagerbetrieb zu überwachen und je nach Grenzen und Häufigkeit der Abweichungen Vorfälle im Warehouse Management Service Center-System per API zu registrieren oder einfach Benachrichtigungen per E-Mail an den Manager zu senden.

Source: habr.com