DIY: hogyan automatizáljuk a raktárfelügyeletet

Az X5 43 elosztó központot és 4 saját teherautót üzemeltet, 029 15 üzletnek biztosítva ezzel a folyamatos termékellátást. Ebben a cikkben megosztom tapasztalataimat egy olyan interaktív rendszer létrehozásával kapcsolatban, amely a semmiből követi a raktári eseményeket. Az információk hasznosak lesznek a több tucat elosztóközponttal rendelkező kereskedelmi társaságok logisztikusai számára, amelyek széles termékskálát kezelnek.

A felügyeleti és üzleti folyamatirányítási rendszerek felépítése általában az üzenetek és incidensek feldolgozásával kezdődik. Ugyanakkor kimarad egy fontos technológiai pont, amely az üzleti események bekövetkezésének tényét automatizálni és az incidenseket rögzíteni tudja. A legtöbb üzleti rendszer, mint például a WMS, a TMS stb., rendelkezik beépített eszközökkel a saját folyamatainak figyelésére. De ha ezek különböző gyártók rendszerei, vagy a felügyeleti funkcionalitás nem kellően fejlett, akkor költséges módosításokat kell megrendelnie, vagy speciális tanácsadókat kell bevonnia további beállításokhoz.

Tekintsünk egy olyan megközelítést, amelyben a források (táblázatok) azonosításához kapcsolódó tanácsadásnak csak egy kis részére van szükségünk ahhoz, hogy indikátorokat kapjunk a rendszerből.

Raktáraink sajátossága, hogy egy logisztikai komplexumban több raktárirányítási rendszer (WMS Exceed) is működik. A raktárak nem csak logikailag vannak felosztva az áruk tárolási kategóriái szerint (száraz, alkoholos, fagyasztott stb.). Egy logisztikai komplexumban több különálló raktárépület található, melyek mindegyikét saját WMS kezeli.

A raktárban lezajló folyamatok általános képének kialakítása érdekében a vezetők naponta többször elemzik az egyes WMS-ek jelentését, feldolgozzák a raktárüzemeltetőktől (átvevők, komissiózók, rakodók) érkező üzeneteket, és összefoglalják a tényleges működési mutatókat az információs táblán való tükrözéshez.

A vezetők idejének megtakarítása érdekében úgy döntöttünk, hogy egy olcsó rendszert fejlesztünk ki a raktári események operatív ellenőrzésére. Az új rendszer a raktári folyamatok működési teljesítményének „forró” mutatóinak megjelenítése mellett az incidensek rögzítésében és a feladatok végrehajtásának nyomon követésében is segíti a vezetőket az adott mutatókat érintő okok kiküszöbölésére. A cég informatikai architektúrájának általános auditálása után rájöttünk, hogy a szükséges rendszer egyes részei így vagy úgy már léteznek a mi tájunkon, és ezek számára a beállítások vizsgálata és a szükséges támogatási szolgáltatások is rendelkezésre állnak. Már csak az egész koncepciót egyetlen építészeti megoldásba kell foglalni, és megbecsülni a fejlesztési kört.

Az új rendszer kiépítéséhez szükséges munka mennyiségének felmérése után úgy döntöttek, hogy a projektet több szakaszra osztják:

1. Mutatók gyűjtése raktári folyamatokhoz, mutatók és eltérések megjelenítése és ellenőrzése
2. Folyamatszabványok automatizálása és kérelmek regisztrációja az üzleti szolgáltatások szolgáltatásban eltérések esetén
3. Proaktív monitorozás terhelés-előrejelzéssel és ajánlások készítésével a vezetők számára.

Az első szakaszban a rendszernek össze kell gyűjtenie az előkészített üzemi adatok szeleteit a komplexum összes WMS-éből. Az olvasás szinte valós időben történik (5 percnél rövidebb időközönként). A trükk az, hogy több tucat raktár DBMS-éből kell adatokat szerezni, amikor a rendszert a teljes hálózatra telepítik. A kapott üzemi adatokat a rendszermag logikája dolgozza fel, hogy kiszámítsa a tervezett mutatóktól való eltéréseket és statisztikát. Az így feldolgozott adatokat a vezető táblagépén vagy a raktári információs táblán közérthető grafikonok és diagramok formájában kell megjeleníteni.

Az első szakasz kísérleti megvalósításához megfelelő rendszer kiválasztásánál a Zabbix-ot választottuk. Ezt a rendszert már használják a raktári rendszerek informatikai teljesítményének figyelésére. A raktár működésének üzleti mutatóinak összegyűjtésére szolgáló külön telepítés hozzáadásával átfogó képet kaphat a raktár állapotáról.

A rendszer általános felépítése az ábrán látható módon alakult.

Minden WMS-példány a megfigyelőrendszer gazdagépeként van meghatározva. A mérőszámokat az adatközpont-hálózat központi kiszolgálója gyűjti össze egy parancsfájl futtatásával egy előkészített SQL-lekérdezéssel. Ha olyan rendszert kell felügyelnie, amely nem ajánl közvetlen hozzáférést az adatbázishoz (például SAP EWM), használhatja a dokumentált API-függvények parancsfájlhívásait indikátorok beszerzéséhez, vagy írhat egy egyszerű programot python/vbascript nyelven.

A raktárhálózatban egy Zabbix proxypéldány kerül telepítésre a terhelés elosztására a fő kiszolgálóról. A Proxy-n keresztül biztosított az összes helyi WMS-példánnyal való munka. A következő alkalommal, amikor a Zabbix szerver paramétereket kér, egy parancsfájl fut le a gazdagépen a Zabbix proxyval a metrikák lekéréséhez a WMS adatbázisból.

Grafák és raktári mutatók megjelenítéséhez a központi Zabbix szerveren a Grafanát telepítjük. Amellett, hogy előkészített műszerfalakat jelenít meg a raktári műveletek infografikájával, a Grafana a mutatók eltéréseit figyeli, és automatikus riasztásokat küld a raktári szolgáltatási rendszernek az üzleti incidensek kezeléséhez.

Példaként tekintsük a rakományvezérlés megvalósítását a raktár fogadó területén. Az alábbiakat választották a folyamat teljesítményének fő mutatóinak a raktár ezen a területén:

• a fogadótérben lévő járművek száma, az állapotok figyelembevételével (tervezett, érkezett, okmányok, kirakodás, indulás;
• az elhelyezési és feltöltési területek leterheltsége (a tárolási feltételeknek megfelelően).

beállítások

A rendszer fő összetevőinek (SQLcl, Zabbix, Grafana) telepítését és konfigurálását különböző források írják le, és itt nem ismételjük meg. Az SQLcl használata az SQLplus helyett annak a ténynek köszönhető, hogy az SQLcl (az Oracle DBMS java nyelven írt parancssori felülete) nem igényli az Oracle Client további telepítését, és a dobozból kiindulva működik.

Leírom azokat a főbb pontokat, amelyekre érdemes odafigyelni a Zabbix raktári üzleti folyamatok mutatóinak figyelésekor, illetve ezek megvalósításának egyik lehetséges módját. Ezenkívül ez a bejegyzés nem a biztonságról szól. A kapcsolatok biztonsága és a bemutatott módszerek alkalmazása további tanulmányozást igényel a pilot megoldás produktív üzembe helyezése során.

A lényeg az, hogy egy ilyen rendszer megvalósítása során programozás nélkül is megtehető, a rendszer által megadott beállításokkal.

A Zabbix felügyeleti rendszer számos lehetőséget kínál a mérőszámok gyűjtésére a felügyelt rendszerből. Ez megtehető a felügyelt gazdagépek közvetlen lekérdezésével, vagy a gazdagép zabbix_senderén keresztül a kiszolgálónak történő adatküldés fejlettebb módszerével, beleértve az alacsony szintű felderítési paraméterek konfigurálására szolgáló módszereket is. Problémánk megoldására nagyon alkalmas a hosztok központi szerver általi közvetlen lekérdezésének módszere, mert Ez lehetővé teszi, hogy teljes irányítást szerezzen a mérőszámok beszerzésének sorrendje felett, és biztosítja, hogy egyetlen beállítás-/szkriptkészletet használjon anélkül, hogy ezeket minden egyes megfigyelt gazdagéphez ki kellene osztania.

A hibakeresés és a rendszer beállításának „tesztalanyaiként” WMS munkalapot használunk az elfogadás kezeléséhez:

1. Járművek a recepción, minden, ami megérkezett: Minden jármű, amelynek állapota a „- aktuális időponttól számított 72 óra” időszakra vonatkozik - SQL lekérdezési azonosító: getCars.
2. Az összes járműállapot előzményei: A 72 órán belül érkező összes jármű állapota - SQL lekérdezési azonosító: autókTörténelem.
3. Átvételre tervezett járművek: Minden olyan jármű állapota, amelyek érkezése „Ütemezett” állapotban van, időintervallum „- 24 óra” és „+24 óra” az aktuális időponttól számítva - SQL lekérdezés azonosítója: carsIn.

Tehát miután eldöntöttük a raktárteljesítmény mérőszámait, SQL lekérdezéseket készítünk a WMS adatbázishoz. A lekérdezések végrehajtásához nem a fő adatbázist célszerű használni, hanem annak „forró” másolatát - készenléti állapotot.

Az adatok fogadásához csatlakozunk a készenléti Oracle DBMS-hez. IP-cím a tesztadatbázishoz való csatlakozáshoz 192.168.1.106. A kapcsolati paramétereket a Zabbix szerveren mentjük az SQLcl munkamappa TNSNames.ORA mappájába:

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

Ez lehetővé teszi számunkra, hogy SQL-lekérdezéseket futtassunk minden gazdagépen az EZconnect-en keresztül, csak a bejelentkezési/jelszót és az adatbázis nevét megadva:

# sql znew/Zabmon1@WH1_1

Az előkészített SQL lekérdezéseket a Zabbix szerver munkamappájába mentjük:

/etc/zabbix/sql

és hozzáférést biztosítunk szerverünk zabbix felhasználójához:

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

A kérést tartalmazó fájlok egyedi azonosító-nevet kapnak a hozzáféréshez a Zabbix szervertől. Minden adatbázis-lekérdezés SQLcl-n keresztül több paramétert ad vissza. Figyelembe véve a Zabbix sajátosságait, amely kérésenként csak egy metrikát tud feldolgozni, további szkripteket használunk a lekérdezés eredményeinek egyedi metrikákba történő elemzéséhez.

Készítsük elő a fő szkriptet, nevezzük wh_Metrics.sh-nek, hogy meghívjunk egy SQL-lekérdezést az adatbázisba, mentsük el az eredményeket, és adjunk vissza egy technikai mérőszámot az adatvisszakeresés sikerének mutatóival:

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

A kész fájlt a szkripttel a külső szkriptek tárolására szolgáló mappába helyezzük a Zabbix-proxy konfigurációs beállításai szerint (alapértelmezés szerint - /usr/local/share/zabbix/externalscripts).

Szkriptparaméterként átadjuk annak az adatbázisnak az azonosítását, amelyből a szkript eredményeket kap. Az adatbázis-azonosítónak meg kell egyeznie a TNSNames.ORA fájl beállítási sorával.

Az SQL lekérdezés hívás eredménye egy fájlba kerül mentésre mon_base_id_main.log ahol base_id = A parancsfájl paramétereként kapott adatbázis-azonosító. Az eredményfájl adatbázis-azonosítók szerinti felosztása a szervertől több adatbázisba érkező kérések esetén biztosított. A lekérdezés egy rendezett, kétdimenziós értékek tömbjét adja vissza.

A következő szkriptre (nevezzük getMetrica.sh-nek) van szükség egy megadott metrika lekéréséhez egy fájlból egy kérés eredményeként:

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

Most készen állunk a Zabbix konfigurálására és a raktári átvételi folyamatok mutatóinak monitorozására.

Minden adatbázis-csomóponton telepítve és konfigurálva van egy Zabbix-ügynök.

A fő szerveren minden szervert Zabbix proxyval határozunk meg. A beállításokhoz lépjen a következő útvonalra:

Adminisztráció → Proxy → Proxy létrehozása

Ellenőrzött gazdagépeket határozunk meg:

Beállítások → Gazdagépek → Gazda létrehozása

A gazdagépnévnek meg kell egyeznie az ügynök konfigurációs fájljában megadott gazdagépnévvel.

Megadjuk a csomópont csoportját, valamint az adatbázissal rendelkező csomópont IP-címét vagy DNS-nevét.

Mérőket készítünk, és meghatározzuk tulajdonságaikat:

Beállítások → Csomópontok → "csomópont neve" → Adatelemek> Adatelem létrehozása

1) Hozzon létre egy fő mérőszámot az adatbázis összes paraméterének lekérdezéséhez

Beállítjuk az adatelem nevét, megadjuk a „Külső ellenőrzés” típusát. A „Kulcs” mezőben definiálunk egy szkriptet, amelynek paraméterként átadjuk az Oracle adatbázis nevét, az sql lekérdezés nevét, az adatbázishoz való csatlakozáshoz szükséges bejelentkezési nevet és jelszót. A lekérdezés frissítési időközét állítsa 5 percre (300 másodpercre).

2) Hozza létre a fennmaradó mutatókat az egyes járműállapotokhoz. Ezeknek a mutatóknak az értékeit a rendszer a fő mérőszám ellenőrzésének eredménye alapján állítja elő.

Beállítjuk az adatelem nevét, megadjuk a „Külső ellenőrzés” típusát. A „Kulcs” mezőben definiálunk egy szkriptet, amelynek paraméterként átadjuk az Oracle adatbázis nevét és az állapotkódot, amelynek értékét nyomon akarjuk követni. A lekérdezés frissítési időközét 10 másodperccel hosszabbra állítjuk, mint a fő metrika (310 másodperc), hogy az eredményeknek legyen ideje a fájlba írni.

A mérőszámok helyes megszerzéséhez fontos az ellenőrzések aktiválási sorrendje. Annak érdekében, hogy elkerüljük az ütközéseket az adatok fogadásakor, először aktiváljuk a GetCarsByStatus fő metrikát a wh_Metrics.sh szkript meghívásával.

Beállítások → Csomópontok → 'csomópont neve' → Adatelemek → „Külső ellenőrzések” alszűrő. Jelölje be a szükséges jelölőnégyzetet, és kattintson az „Aktiválás” gombra.

Ezután egy műveletben aktiváljuk a fennmaradó mérőszámokat, mindegyiket együtt kiválasztva:

A Zabbix most megkezdte a raktári üzleti mutatók gyűjtését.

A következő cikkekben közelebbről megvizsgáljuk a Grafana összekapcsolását és a raktári műveletek információs irányítópultjainak létrehozását a különböző felhasználói kategóriák számára. A Grafana a raktári műveletek eltéréseinek nyomon követésére is szolgál, és az eltérések határaitól és gyakoriságától függően API-n keresztül regisztrálja az incidenseket a raktármenedzsment szolgáltatási központ rendszerében, vagy egyszerűen csak e-mailben küld értesítést a vezetőnek.

Forrás: will.com