DIY: cum automatizăm monitorizarea depozitului

X5 operează 43 de centre de distribuție și 4 de camioane proprii, asigurând furnizarea neîntreruptă de produse către 029 de magazine. În acest articol voi împărtăși experiența mea în crearea unui sistem interactiv pentru monitorizarea evenimentelor din depozit de la zero. Informațiile vor fi utile logisticienilor companiilor comerciale cu câteva zeci de centre de distribuție care gestionează o gamă largă de produse.

De regulă, construcția sistemelor de monitorizare și management al proceselor de afaceri începe cu procesarea mesajelor și incidentelor. În același timp, este ratat un punct tehnologic important legat de posibilitatea automatizării însuși faptului de apariție a evenimentelor de afaceri și de înregistrare a incidentelor. Majoritatea sistemelor de afaceri, cum ar fi WMS, TMS etc., au instrumente încorporate pentru monitorizarea propriilor procese. Însă, dacă acestea sunt sisteme de la diferiți producători sau funcționalitatea de monitorizare nu este suficient de dezvoltată, trebuie să comandați modificări costisitoare sau să atrageți consultanți de specialitate pentru setări suplimentare.

Să luăm în considerare o abordare în care avem nevoie doar de o mică parte din consultanța asociată cu identificarea surselor (tabelelor) pentru a obține indicatori din sistem.

Specificul depozitelor noastre este că mai multe sisteme de management al depozitelor (WMS Exceed) funcționează într-un singur complex logistic. Depozitele sunt împărțite pe categorii de depozitare a mărfurilor (uscate, alcoolice, congelate etc.) nu numai logic. În cadrul unui complex logistic există mai multe clădiri de depozite separate, fiecare dintre acestea fiind gestionată de propriul WMS.

Pentru a-și forma o imagine generală a proceselor care se desfășoară în depozit, managerii analizează raportarea fiecărui WMS de mai multe ori pe zi, prelucrează mesajele de la operatorii depozitului (receptori, pickeri, stivuitori) și sintetizează indicatorii operaționali efectivi pentru reflectarea pe panoul informativ.

Pentru a economisi timp managerilor, am decis să dezvoltăm un sistem ieftin pentru controlul operațional al evenimentelor din depozit. Noul sistem, pe lângă afișarea indicatorilor „fierbinți” ai performanței operaționale a proceselor din depozit, ar trebui să ajute și managerii în înregistrarea incidentelor și monitorizarea implementării sarcinilor pentru eliminarea cauzelor care afectează indicatorii dați. După efectuarea unui audit general al arhitecturii IT a companiei, ne-am dat seama că părți individuale ale sistemului necesar există deja într-un fel sau altul în peisajul nostru și pentru acestea există atât o examinare a setărilor, cât și a serviciilor de asistență necesare. Tot ce rămâne este să aducem întregul concept într-o singură soluție arhitecturală și să estimăm domeniul de dezvoltare.

După evaluarea volumului de lucru care trebuie făcut pentru a construi un nou sistem, s-a decis împărțirea proiectului în mai multe etape:

1. Colectarea indicatorilor pentru procesele din depozit, vizualizarea si controlul indicatorilor si abaterilor
2. Automatizarea standardelor de proces și înregistrarea aplicațiilor în serviciul de servicii pentru afaceri pentru abateri
3. Monitorizare proactiva cu prognoza sarcinii si crearea de recomandari pentru manageri.

În prima etapă, sistemul trebuie să colecteze secțiuni pregătite de date operaționale de la toate WMS ale complexului. Citirea are loc aproape în timp real (intervale de mai puțin de 5 minute). Trucul este că datele trebuie obținute din DBMS-urile câtorva zeci de depozite la implementarea sistemului în întreaga rețea. Datele operaționale primite sunt procesate de logica nucleului sistemului pentru a calcula abaterile de la indicatorii planificați și pentru a calcula statistici. Datele astfel prelucrate trebuie afișate pe tableta managerului sau pe panoul informativ al depozitului sub formă de grafice și diagrame ușor de înțeles.

Atunci când am ales un sistem potrivit pentru implementarea pilot a primei etape, am ales Zabbix. Acest sistem este deja folosit pentru a monitoriza performanța IT a sistemelor de depozit. Adăugând o instalație separată pentru colectarea valorilor comerciale ale funcționării depozitului, puteți obține o imagine de ansamblu a stării de sănătate a depozitului.

Arhitectura generală a sistemului sa dovedit ca în figură.

Fiecare instanță WMS este definită ca o gazdă pentru sistemul de monitorizare. Valorile sunt colectate de un server central din rețeaua centrelor de date prin rularea unui script cu o interogare SQL pregătită. Dacă trebuie să monitorizați un sistem care nu recomandă accesul direct la baza de date (de exemplu, SAP EWM), puteți utiliza apeluri de script la funcții API documentate pentru a obține indicatori sau pentru a scrie un program simplu în python/vbascript.

O instanță proxy Zabbix este implementată în rețeaua de depozit pentru a distribui încărcarea de pe serverul principal. Prin proxy, este asigurată lucrul cu toate instanțele WMS locale. Data viitoare când serverul Zabbix solicită parametri, se execută un script pe gazdă cu proxy Zabbix pentru a solicita valori din baza de date WMS.

Pentru a afișa grafice și indicatori de depozit pe serverul central Zabbix, implementăm Grafana. Pe lângă afișarea tablourilor de bord pregătite cu infografice ale operațiunilor din depozit, Grafana va fi folosită pentru a monitoriza abaterile indicatorilor și a trimite alerte automate către sistemul de service al depozitului pentru lucrul cu incidente de afaceri.

Ca exemplu, să luăm în considerare implementarea controlului sarcinii în zona de primire a depozitului. Următorii au fost aleși ca principali indicatori ai performanței procesului în această zonă a depozitului:

• numărul de vehicule în zona de recepție, ținând cont de stări (planificate, sosite, acte, descărcare, plecare;
• volumul de muncă al zonelor de amplasare și reaprovizionare (în funcție de condițiile de depozitare).

Setări

Instalarea și configurarea principalelor componente ale sistemului (SQLcl, Zabbix, Grafana) sunt descrise în diverse surse și nu vor fi repetate aici. Utilizarea SQLcl în loc de SQLplus se datorează faptului că SQLcl (interfața de linie de comandă a SGBD-ului Oracle, scrisă în java) nu necesită instalare suplimentară a clientului Oracle și funcționează din nou.

Voi descrie principalele puncte cărora ar trebui să li se acorde atenție atunci când se utilizează Zabbix pentru a monitoriza indicatorii procesului de afaceri din depozit și una dintre modalitățile posibile de implementare a acestora. De asemenea, aceasta nu este o postare despre securitate. Securitatea conexiunilor și utilizarea metodelor prezentate necesită un studiu suplimentar în procesul de transfer al soluției pilot în exploatare productivă.

Principalul lucru este că atunci când implementați un astfel de sistem, este posibil să faceți fără programare, folosind setările furnizate de sistem.

Sistemul de monitorizare Zabbix oferă mai multe opțiuni pentru colectarea valorilor din sistemul monitorizat. Acest lucru se poate face fie prin sondarea directă a gazdelor monitorizate, fie printr-o metodă mai avansată de trimitere a datelor către server prin intermediul zabbix_sender al gazdei, inclusiv metode pentru configurarea parametrilor de descoperire de nivel scăzut. Pentru a ne rezolva problema, metoda de interogare directă a gazdelor de către un server central este destul de potrivită, deoarece aceasta vă permite să obțineți control deplin asupra secvenței de achiziție a valorilor și vă asigură că utilizați un set de setări/scripturi fără a fi nevoie să le distribuiți fiecărei gazde monitorizate.

Ca „subiecți de testare” pentru depanarea și configurarea sistemului, folosim foaia de lucru WMS pentru gestionarea acceptării:

1. Vehicule la recepție, toate cele care au sosit: Toate vehiculele cu stări pentru perioada „- 72 de ore de la ora curentă” - identificator de interogare SQL: getCars.
2. Istoricul tuturor stărilor vehiculelor: stările tuturor vehiculelor care sosesc în decurs de 72 de ore - identificator de interogare SQL: mașiniIstoria.
3. Vehicule programate pentru acceptare: stările tuturor vehiculelor cu sosire în starea „Programat”, interval de timp „- 24 de ore” și „+24 de ore” de la ora curentă - identificator de interogare SQL: masiniIn.

Deci, după ce ne-am decis asupra unui set de metrici de performanță a depozitului, vom pregăti interogări SQL pentru baza de date WMS. Pentru a executa interogări, este recomandabil să folosiți nu baza de date principală, ci copia sa „fierbinte” - standby.

Ne conectăm la DBMS Oracle de așteptare pentru a primi date. Adresă IP pentru conectarea la baza de date de testare 192.168.1.106. Salvam parametrii de conectare pe serverul Zabbix în TNSNames.ORA din folderul de lucru 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)
    )
  )

Acest lucru ne va permite să rulăm interogări SQL către fiecare gazdă prin EZconnect, specificând doar numele de conectare/parola și numele bazei de date:

# sql znew/Zabmon1@WH1_1

Salvăm interogările SQL pregătite în folderul de lucru de pe serverul Zabbix:

/etc/zabbix/sql

și permiteți accesul utilizatorului zabbix al serverului nostru:

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

Fișierele cu solicitări primesc un nume de identificare unic pentru acces de la serverul Zabbix. Fiecare interogare de bază de date prin SQLcl ne returnează câțiva parametri. Ținând cont de specificul Zabbix, care poate procesa doar o singură valoare per cerere, vom folosi scripturi suplimentare pentru a analiza rezultatele interogării în valori individuale.

Să pregătim scriptul principal, să-l numim wh_Metrics.sh, pentru a apela o interogare SQL în baza de date, a salva rezultatele și a returna o metrică tehnică cu indicatori ai succesului regăsării datelor:

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

Plasăm fișierul terminat cu scriptul în folderul pentru stocarea scripturilor externe în conformitate cu setările de configurare Zabbix-proxy (în mod implicit - /usr/local/share/zabbix/externalscripts).

Identificarea bazei de date din care scriptul va primi rezultate va fi transmisă ca parametru de script. ID-ul bazei de date trebuie să se potrivească cu linia de setări din fișierul TNSNames.ORA.

Rezultatul apelului de interogare SQL este salvat într-un fișier ca mon_base_id_main.log unde base_id = Identificatorul bazei de date primit ca parametru de script. Împărțirea fișierului rezultat pe identificatorii bazei de date este asigurată în cazul solicitărilor de la server către mai multe baze de date simultan. Interogarea returnează o matrice bidimensională sortată de valori.

Următorul script, să-l numim getMetrica.sh, este necesar pentru a obține o metrică specificată dintr-un fișier cu rezultatul unei solicitări:

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

Acum suntem gata să configuram Zabbix și să începem să monitorizăm indicatorii proceselor de acceptare a depozitului.

Un agent Zabbix este instalat și configurat pe fiecare nod al bazei de date.

Pe serverul principal definim toate serverele cu proxy Zabbix. Pentru setări, accesați următoarea cale:

Administrare → Proxy → Creare proxy

Definim gazde controlate:

Setări → Gazde → Creare gazdă

Numele de gazdă trebuie să se potrivească cu numele de gazdă specificat în fișierul de configurare a agentului.

Specificăm grupul pentru nod, precum și adresa IP sau numele DNS al nodului cu baza de date.

Creăm valori și le specificăm proprietățile:

Setări → Noduri → „numele nodului” → Elemente de date>Creează element de date

1) Creați o metrică principală pentru a interoga toți parametrii din baza de date

Setăm numele elementului de date, indicăm tipul „Verificare externă”. În câmpul „Key” definim un script căruia îi trecem ca parametri numele bazei de date Oracle, numele interogării sql, login-ul și parola pentru conectarea la baza de date. Setați intervalul de actualizare a interogărilor la 5 minute (300 de secunde).

2) Creați valorile rămase pentru fiecare stare a vehiculului. Valorile acestor valori vor fi generate pe baza rezultatului verificării valorii principale.

Setăm numele elementului de date, indicăm tipul „Verificare externă”. În câmpul „Cheie”, definim un script căruia îi trecem ca parametri numele bazei de date Oracle și codul de stare a cărui valoare dorim să urmărim. Am setat intervalul de actualizare a interogării la 10 secunde mai lung decât valoarea principală (310 secunde), astfel încât rezultatele să aibă timp să fie scrise în fișier.

Pentru a obține valorile corect, este importantă ordinea în care sunt activate controalele. Pentru a evita conflictele la primirea datelor, în primul rând activăm metrica principală GetCarsByStatus apelând scriptul - wh_Metrics.sh.

Setări → Noduri → „numele nodului” → Elemente de date → Subfiltru „Verificări externe”. Marcați verificarea necesară și faceți clic pe „Activați”.

Apoi, activăm valorile rămase într-o singură operație, selectându-le pe toate împreună:

Acum, Zabbix a început să colecteze valori de afaceri din depozit.

În următoarele articole, vom arunca o privire mai atentă la conectarea Grafana și la crearea tablourilor de bord informative ale operațiunilor din depozit pentru diferite categorii de utilizatori. Grafana este folosită și pentru a monitoriza abaterile în operațiunile din depozit și, în funcție de limitele și frecvența abaterilor, înregistrează incidente în sistemul centrului de servicii de management al depozitului prin intermediul API sau pur și simplu trimite notificări către manager prin e-mail.

Sursa: www.habr.com