X5 verwaltet 43 Distributionszentren und 4.029 eigene Lkws, die in 15.752 Filialen für eine unterbrechungsfreie Warenversorgung sorgen. In dem Artikel werde ich die Erfahrung des Erstellens eines interaktiven Systems zur Überwachung von Lagerereignissen von Grund auf teilen. Die Informationen werden für die Logistik von Handelsunternehmen mit Dutzenden von Vertriebszentren nützlich sein, die eine breite Palette von Produkten verwalten.
Der Aufbau von Überwachungs- und Geschäftsprozessmanagementsystemen beginnt in der Regel mit der Verarbeitung von Meldungen und Ereignissen. Gleichzeitig wird ein wichtiger technologischer Moment im Zusammenhang mit der Möglichkeit der Automatisierung des Auftretens von Geschäftsereignissen und der Aufzeichnung von Vorfällen verpasst. Die meisten Geschäftssysteme der Klasse WMS, TMS usw. verfügen über integrierte Tools zur Überwachung ihrer eigenen Prozesse. Wenn es sich jedoch um ein System verschiedener Hersteller handelt oder die Überwachungsfunktionen nicht ausreichend entwickelt sind, müssen Sie teure Verbesserungen in Auftrag geben oder spezialisierte Berater für zusätzliche Einstellungen hinzuziehen.
Betrachten Sie einen Ansatz, bei dem wir nur einen kleinen Teil der Beratung in Bezug auf die Ermittlung von Quellen (Tabellen) benötigen, um Indikatoren aus dem System zu erhalten.
Die Besonderheit unserer Lager liegt darin, dass mehrere Lagerverwaltungssysteme (WMS Exceed) auf demselben Logistikkomplex arbeiten. Die Lager sind nicht nur logisch nach den Kategorien der Lagerung von Waren (trocken, Alkohol, Einfrieren usw.) unterteilt. Innerhalb eines Logistikkomplexes befinden sich mehrere separate Lagergebäude, deren Betrieb jeweils von einem eigenen WMS verwaltet wird.
Um ein allgemeines Bild der im Lager ablaufenden Prozesse zu erhalten, analysieren die Manager mehrmals täglich die Berichte der einzelnen WMS, verarbeiten die Meldungen der Lagerarbeiter (Empfänger, Kommissionierer, Stapler) und fassen die tatsächlichen Betriebsanzeigen für die Anzeige auf der Informationstafel zusammen.
Um den Managern Zeit zu sparen, haben wir uns entschlossen, ein kostengünstiges System zur Betriebssteuerung von Lagerereignissen zu entwickeln. Das neue System soll neben der Anzeige von „heißen“ Indikatoren für die operative Arbeit von Lagerprozessen auch den Managern helfen, Vorfälle zu beheben und Aufgaben zu überwachen, um die Ursachen zu beseitigen, die die angegebenen Indikatoren betreffen. Nach einer allgemeinen Prüfung der IT-Architektur des Unternehmens haben wir festgestellt, dass die einzelnen Teile des erforderlichen Systems in unserer Landschaft bereits vorhanden sind und für sie gibt es sowohl eine Prüfung der Einstellungen als auch der erforderlichen Supportleistungen. Es bleibt nur, das gesamte Konzept auf eine einzige architektonische Lösung zu reduzieren und den Entwicklungsumfang zu bewerten.
Nach der Prüfung des Arbeitsaufwands für den Aufbau eines neuen Systems wurde beschlossen, das Projekt in mehrere Phasen zu unterteilen:
- Erfassung von Kennzahlen zu Lagerprozessen, Visualisierung und Kontrolle von Kennzahlen und Abweichungen
- Automatisierung von Prozessstandards und Registrierung von Anwendungen im Business Services Service für Abweichungen
- Proaktive Überwachung mit Lastprognose und Empfehlungen an die Manager.
In der ersten Phase sollte das System vorbereitete Schichten von Betriebsdaten aus allen WMS-Komplexen erfassen. Das Lesen erfolgt fast in Echtzeit (Intervalle von weniger als 5 Minuten). Der Trick besteht darin, dass die Daten aus dem DBMS von mehreren Dutzend Lagern abgerufen werden müssen, wenn das System im gesamten Netzwerk bereitgestellt wird. Die empfangenen Betriebsdaten werden von der Systemkernlogik verarbeitet, um Abweichungen von den geplanten Indikatoren zu berechnen und Statistiken zu berechnen. Die auf diese Weise verarbeiteten Daten müssen auf dem Manager-Tablet oder auf der Informationstafel des Lagers in Form klarer Grafiken und Diagramme angezeigt werden.
Bei der Auswahl eines geeigneten Systems für die Pilotimplementierung der ersten Stufe haben wir uns für Zabbix entschieden. Dieses System wird bereits zur Überwachung der IT-Leistung von Lagersystemen eingesetzt. Durch Hinzufügen einer separaten Installation zum Erfassen von Geschäftsmetriken für den Lagerbetrieb erhalten Sie einen Gesamtüberblick über den Zustand des Lagers.
Die allgemeine Architektur des Systems ist in der Abbildung dargestellt.
Jede WMS-Instanz wird 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 mithilfe von Skriptaufrufen dokumentierte API-Funktionen verwenden, um Indikatoren zu schreiben oder ein einfaches Python- / V-Javascript-Programm zu schreiben.
Der Zabbix-Proxy wird im Warehouse-Netzwerk bereitgestellt, um die Last vom Hauptserver zu verteilen. Über Proxy wird die Arbeit mit allen lokalen WMS-Instanzen bereitgestellt. Bei der nächsten Anforderung von Parametern durch den Zabbix-Server auf dem Host mit Zabbix-Proxy wird ein Skript ausgeführt, um Metriken aus der WMS-Datenbank anzufordern.
Stellen Sie Grafana bereit, um die Grafiken und Anzeigen des Warehouse auf dem zentralen Zabbix-Server anzuzeigen. Neben der Ausgabe vorbereiteter Dashboards mit Warehouse-Infografiken werden mit Grafana auch Abweichungen von Indikatoren kontrolliert und automatische Warnungen an das Warehouse-Service-System für die Arbeit mit Geschäftsvorfällen übertragen.
Betrachten Sie als Beispiel die Implementierung der Steuerung der Beladung der Lagerannahmezone. Als Hauptindikatoren für die Prozesse in diesem Bereich des Lagers wurden ausgewählt:
- die Anzahl der Fahrzeuge im Empfangsbereich unter Berücksichtigung des Status (geplant, angekommen, Dokumente, Entladen, Abfahrt);
- Überlastung der Plazierungs- und Wiederauffüllungszonen (entsprechend den Lagerbedingungen).
Einstellungen
Die Installation und Konfiguration der Hauptkomponenten des Systems (SQLcl, Zabbix, Grafana) wird in verschiedenen Quellen beschrieben und hier nicht wiederholt. Die Verwendung von SQLcl anstelle von SQLplus ist darauf zurückzuführen, dass SQLcl (die in Java geschriebene Oracle DBMS-Befehlszeilenschnittstelle) keine zusätzliche Installation von Oracle Client erfordert und sofort einsatzbereit ist.
Ich werde die wichtigsten Punkte beschreiben, die bei der Verwendung von Zabbix zur Überwachung der Leistung von Warehouse-Geschäftsprozessen beachtet werden sollten, 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 erfordern zusätzliche Untersuchungen bei der Überführung der Pilotlösung in den produktiven Betrieb.
Die Hauptsache ist, dass bei der Implementierung eines solchen Systems auf die Programmierung mit den vom System bereitgestellten Einstellungen verzichtet werden kann.
Das Zabbix-Überwachungssystem bietet mehrere Optionen zum Erfassen von Metriken aus einem überwachten System. Dies kann sowohl durch direktes Abfragen gesteuerter Hosts als auch durch eine erweiterte Methode zum Senden von Daten an den Server über den zabbix_sender des Hosts erfolgen, einschließlich Methoden zum Festlegen 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. Auf diese Weise erhalten Sie die vollständige Kontrolle über die Reihenfolge des Abrufs von Metriken und können ein Paket von Einstellungen / Skripten verwenden, ohne diese an jeden gesteuerten Host weitergeben zu müssen.
Als "experimentelles" Verfahren zum Debuggen und Optimieren des Systems verwenden wir die WMS-Arbeitsblätter, um den Empfang zu steuern:
- TS bei Annahme, alles, was angekommen ist: Alle TS mit Status für den Zeitraum "- 72 Stunden ab der aktuellen Zeit" - SQL-Abfrage- ID : getCars .
- Verlauf aller Fahrzeugzustände: Zustände aller Fahrzeuge mit 72-Stunden-Ankunft - SQL- Abfragekennung : carsHistory .
- Geplante Fahrzeuge zur Annahme: Status aller Fahrzeuge mit dem Status "Geplant", Zeitintervall " -24 Stunden" und "+24 Stunden" ab der aktuellen Uhrzeit - SQL- Abfragekennung : carsIn .
Nachdem wir uns für eine Reihe von Warehouse-Metriken entschieden haben, bereiten wir SQL-Abfragen für die WMS-Datenbank vor. Für die Ausführung von Abfragen wird empfohlen, nicht die Hauptdatenbank zu verwenden, sondern deren "Hot" -Kopie - Standby.
Wir sind für die Datenerfassung mit dem Standby-Oracle-DBMS verbunden. IP-Adresse für die Verbindung zur
Testbasis 192.168.1.106 . Verbindungsparameter werden auf dem Zabbix-Server in TNSNames.ORA des Arbeitsordners SQLcl gespeichert:
# 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) ) )
Auf diese Weise können wir über EZconnect SQL-Abfragen für jeden Host ausführen und dabei nur den Benutzernamen / das Kennwort und den Datenbanknamen angeben:
# sql znew/Zabmon1@WH1_1
Die vorbereiteten SQL-Abfragen werden im Arbeitsordner auf dem Zabbix-Server gespeichert:
/etc/zabbix/sql
und erlauben Sie dem zabbix-Benutzer unseres Servers den Zugriff auf:
# chown zabbix:zabbix -R /etc/zabbix/sql
Anforderungsdateien erhalten einen eindeutigen Bezeichnernamen für den Zugriff vom Zabbix-Server. Jede Datenbankabfrage über SQLcl gibt mehrere Parameter zurück. Angesichts der Besonderheiten von Zabbix, das nur eine Metrik in einer Abfrage verarbeiten kann, verwenden wir zusätzliche Skripts, um die Abfrageergebnisse in einzelne Metriken zu zerlegen.
Wir bereiten das Hauptskript vor, nennen wir es wh_Metrics.sh, um die SQL-Abfrage in der Datenbank aufzurufen, die Ergebnisse zu speichern und die technische Metrik mit den Erfolgsindikatoren zum Abrufen von Daten 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 platzieren die fertige Datei mit dem Skript in dem Ordner zum Hosten externer Skripte gemäß den Zabbix-Proxy-Konfigurationseinstellungen (standardmäßig -
/ usr / local / share / zabbix / externalscripts ).
Die Identifikation der Datenbank, von der das Skript die Ergebnisse erhält, wird vom Skriptparameter übertragen. Die Datenbankkennung muss der Einstellungszeile in der Datei TNSNames.ORA entsprechen.
Das Ergebnis des Aufrufs der SQL-Abfrage wird in einer Datei der Form
mon_base_id_main.log gespeichert, wobei base_id = DB-Kennung, die als
Skriptparameter abgerufen wird. Die Trennung der Ergebnisdatei durch Datenbankkennungen erfolgt bei gleichzeitigen Anfragen des Servers an mehrere Datenbanken. Die Abfrage gibt ein sortiertes zweidimensionales Array von Werten zurück.
Das folgende Skript, nennen wir es getMetrica.sh, wird benötigt, um die angegebene Metrik aus der Datei mit dem Ergebnis der Anforderung 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 einrichten und mit der Überwachung der Leistung von Lagerabnahmeprozessen beginnen.
Auf jedem Datenbankknoten wird ein Zabbix-Agent installiert und konfiguriert.
Auf dem Hauptserver definieren wir alle Server mit Zabbix-Proxys. Einstellungen finden Sie unter folgendem Pfad:
Administration → Proxies → Proxy erstellen
Kontrollierte Hosts definieren:
Einstellungen → Hosts → Host erstellen
Der Hostname muss mit dem in der Agentenkonfigurationsdatei angegebenen Hostnamen übereinstimmen.
Wir geben die Gruppe für den Knoten sowie die IP-Adresse oder den DNS-Namen des Knotens aus der Datenbank an.
Wir erstellen Metriken und legen deren Eigenschaften fest:
Einstellungen → Knoten →
'Knotenname' → Datenelemente> Datenelement erstellen
1) Erstellen Sie eine grundlegende Metrik, um alle Parameter aus der Datenbank abzufragen
Wir setzen den Namen des Datenelements, geben die Art der "externen Verifikation" an. Im Feld „Schlüssel“ definieren wir ein Skript, an das wir den Namen der Oracle-Datenbank, den Namen der SQL-Abfrage, den Benutzernamen und das Kennwort für die Verbindung zur Datenbank als Parameter übergeben. Legen Sie das Aktualisierungsintervall für die Anforderung 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 gebildet.
Wir setzen den Namen des Datenelements, geben die Art der "externen Verifikation" an. Im Feld „Key“ definieren wir ein Skript, an das wir den Namen der Oracle-Datenbank und den Statuscode übergeben, dessen Wert wir als Parameter verfolgen möchten. Das Aktualisierungsintervall für die Anforderung ist 10 Sekunden länger als die Hauptmetrik (310 Sekunden), damit die Ergebnisse in die Datei geschrieben werden können.
Für den korrekten Abruf von Metriken ist die Reihenfolge wichtig, in der die Überprüfungen aktiviert werden. Um Konflikte beim Datenempfang zu vermeiden, aktivieren Sie zunächst die Hauptmetrik GetCarsByStatus mit einem Skriptaufruf - wh_Metrics.sh.
Einstellungen → Knoten → 'Knotenname' → Datenelemente → Unterfilter “Externe Prüfungen”. Wir markieren den erforderlichen Haken und klicken auf "Aktivieren".
Aktivieren Sie als Nächstes die verbleibenden Metriken in einem Vorgang und wählen Sie sie alle zusammen aus:
Zabbix hat nun begonnen, Kennzahlen für das Lagergeschäft zu erfassen.
In den folgenden Artikeln werden wir die Verbindung von Grafana und die Bildung von Informations-Dashboards für den Lagerbetrieb für verschiedene Benutzerkategorien genauer untersuchen. Grafana überwacht auch Abweichungen im Lager und erfasst, abhängig von den Grenzen und der Häufigkeit der Abweichungen, Vorfälle im System des Warehouse Management Service Centers über die API oder sendet einfach Benachrichtigungen per E-Mail an den Manager.
