X5 pārvalda 43 izplatīšanas centrus un 4 savas kravas automašīnas, nodrošinot nepārtrauktu produkcijas piegādi 029 15 veikaliem. Šajā rakstā dalīšos pieredzē, veidojot interaktīvu sistēmu noliktavas notikumu uzraudzībai no nulles. Informācija būs noderīga tirdzniecības uzņēmumu loģistiem ar vairākiem desmitiem izplatīšanas centru, kas pārvalda plašu produktu klāstu.
Parasti uzraudzības un biznesa procesu vadības sistēmu izveide sākas ar ziņojumu un incidentu apstrādi. Tajā pašā laikā tiek palaists garām svarīgs tehnoloģisks punkts, kas saistīts ar iespēju automatizēt pašu biznesa notikumu rašanās faktu un reģistrēt incidentus. Lielākajai daļai biznesa sistēmu, piemēram, WMS, TMS utt., ir iebūvēti rīki savu procesu uzraudzībai. Bet, ja tās ir dažādu ražotāju sistēmas vai uzraudzības funkcionalitāte nav pietiekami attīstīta, ir jāpasūta dārgas modifikācijas vai jāpiesaista specializēti konsultanti papildu iestatījumiem.
Apskatīsim pieeju, kurā mums ir nepieciešama tikai neliela daļa no konsultācijām, kas saistītas ar avotu (tabulu) identificēšanu, lai iegūtu rādītājus no sistēmas.
Mūsu noliktavu specifika ir tāda, ka vienā loģistikas kompleksā darbojas vairākas noliktavas vadības sistēmas (WMS Exceed). Noliktavas tiek sadalītas pēc preču uzglabāšanas kategorijām (sausā, spirta, saldētā u.c.) ne tikai loģiski. Viena loģistikas kompleksa ietvaros ir vairākas atsevišķas noliktavu ēkas, no kurām katru pārvalda savs WMS.
Lai veidotu vispārēju priekšstatu par noliktavā notiekošajiem procesiem, vadītāji vairākas reizes dienā analizē katras WMS atskaites, apstrādā ziņojumus no noliktavas operatoriem (saņēmējiem, savācējiem, krāvējiem) un apkopo faktiskos darbības rādītājus atspoguļošanai informācijas stendā.
Lai ietaupītu vadītāju laiku, nolēmām izstrādāt lētu sistēmu noliktavas notikumu operatīvai kontrolei. Jaunajai sistēmai līdzās noliktavas procesu operatīvās darbības “karsto” rādītāju attēlošanai jāpalīdz vadītājiem arī incidentu reģistrēšanā un uzdevumu izpildes uzraudzībā, lai novērstu cēloņus, kas ietekmē dotos rādītājus. Veicot vispārēju uzņēmuma IT arhitektūras auditu, sapratām, ka atsevišķas nepieciešamās sistēmas daļas mūsu ainavā tā vai citādi jau pastāv un tām ir gan iestatījumu pārbaude, gan nepieciešamie atbalsta pakalpojumi. Atliek vien apvienot visu koncepciju vienotā arhitektoniskā risinājumā un novērtēt attīstības apjomu.
Izvērtējot veicamo darbu apjomu, lai izveidotu jaunu sistēmu, tika nolemts projektu sadalīt vairākos posmos:
- Rādītāju vākšana noliktavas procesiem, rādītāju un noviržu vizualizācija un kontrole
- Procesu standartu automatizācija un pieteikumu reģistrēšana biznesa pakalpojumu servisā novirzēm
- Proaktīva uzraudzība ar slodzes prognozēšanu un ieteikumu izveidi vadītājiem.
Pirmajā posmā sistēmai jāsavāc sagatavoti operatīvo datu gabali no visām kompleksa WMS. Lasīšana notiek gandrīz reāllaikā (intervāls ir mazāks par 5 minūtēm). Viltība ir tāda, ka, izvietojot sistēmu visā tīklā, dati ir jāiegūst no vairāku desmitu noliktavu DBVS. Saņemtos operatīvos datus apstrādā sistēmas kodola loģika, lai aprēķinātu novirzes no plānotajiem rādītājiem un aprēķinātu statistiku. Šādi apstrādātiem datiem ir jābūt attēlotiem uz pārvaldnieka planšetdatora vai uz noliktavas informācijas stenda saprotamu grafiku un diagrammu veidā.
Izvēloties piemērotu sistēmu pirmā posma izmēģinājuma ieviešanai, izvēlējāmies Zabbix. Šī sistēma jau tiek izmantota, lai uzraudzītu noliktavas sistēmu IT veiktspēju. Pievienojot atsevišķu instalāciju noliktavas darbības biznesa metrikas apkopošanai, varat iegūt vispārēju priekšstatu par noliktavas stāvokli.
Sistēmas vispārējā arhitektūra izrādījās tāda, kā attēlā.
Katrs WMS gadījums ir definēts kā uzraudzības sistēmas resursdators. Metrikus apkopo centrālais serveris datu centra tīklā, palaižot skriptu ar sagatavotu SQL vaicājumu. Ja jums ir jāuzrauga sistēma, kas neiesaka tiešu piekļuvi datu bāzei (piemēram, SAP EWM), varat izmantot skriptu izsaukumus dokumentētām API funkcijām, lai iegūtu rādītājus vai rakstītu vienkāršu programmu python/vbascript.
Noliktavas tīklā tiek izvietots Zabbix starpniekservera gadījums, lai sadalītu slodzi no galvenā servera. Izmantojot starpniekserveri, tiek nodrošināts darbs ar visiem lokālajiem WMS gadījumiem. Nākamajā reizē, kad Zabbix serveris pieprasa parametrus, resursdatorā ar Zabbix starpniekserveri tiek izpildīts skripts, lai pieprasītu metriku no WMS datu bāzes.
Lai parādītu grafikus un noliktavas rādītājus centrālajā Zabbix serverī, mēs izvietojam Grafana. Papildus sagatavotu informācijas paneļu attēlošanai ar noliktavas darbību infografiku Grafana tiks izmantota, lai uzraudzītu rādītāju novirzes un nosūtītu automātiskus brīdinājumus uz noliktavas servisa sistēmu darbam ar biznesa incidentiem.
Kā piemēru aplūkosim slodzes kontroles ieviešanu noliktavas pieņemšanas zonā. Par galvenajiem procesa veiktspējas rādītājiem šajā noliktavas zonā tika izvēlēti šādi:
- transportlīdzekļu skaits uzņemšanas zonā, ņemot vērā statusus (plānots, ieradies, dokumenti, izkraušana, izbraukšana;
- izvietošanas un papildināšanas laukumu noslodze (atbilstoši uzglabāšanas apstākļiem).
iestatījumi
Sistēmas galveno komponentu (SQLcl, Zabbix, Grafana) uzstādīšana un konfigurēšana ir aprakstīta dažādos avotos un šeit netiks atkārtota. SQLcl izmantošana SQLplus vietā ir saistīta ar to, ka SQLcl (Oracle DBVS komandrindas interfeiss, kas rakstīts java) neprasa papildu Oracle klienta instalēšanu un darbojas jau sākotnēji.
Aprakstīšu galvenos punktus, kam jāpievērš uzmanība, izmantojot Zabbix noliktavas biznesa procesu indikatoru uzraudzībai, un vienu no iespējamajiem to ieviešanas veidiem. Turklāt šis nav ziņojums par drošību. Savienojumu drošība un piedāvāto metožu izmantošana prasa papildu izpēti pilotrisinājuma pārnešanas procesā produktīvā darbībā.
Galvenais, lai, ieviešot šādu sistēmu, var iztikt bez programmēšanas, izmantojot sistēmas sniegtos iestatījumus.
Zabbix uzraudzības sistēma nodrošina vairākas iespējas, kā savākt metriku no pārraudzītās sistēmas. To var izdarīt, vai nu tieši aptaujājot uzraudzītos saimniekdatorus, vai arī izmantojot progresīvāku metodi datu nosūtīšanai uz serveri, izmantojot resursdatora zabbix_sender, tostarp zema līmeņa atklāšanas parametru konfigurēšanas metodes. Mūsu problēmas risināšanai diezgan piemērota ir centrālā servera veiktās saimniekdatoru tiešās aptaujas metode, jo tas ļauj iegūt pilnīgu kontroli pār metrikas iegūšanas secību un nodrošina, ka izmantojat vienu iestatījumu/skriptu kopu bez nepieciešamības tos izplatīt katram uzraudzītajam resursdatoram.
Kā “pārbaudes subjekti” atkļūdošanai un sistēmas iestatīšanai mēs izmantojam WMS darblapu pieņemšanas pārvaldībai:
- Transportlīdzekļi reģistratūrā, visi atnākušie: Visi transportlīdzekļi ar statusiem periodam “- 72 stundas no pašreizējā laika” - SQL vaicājuma identifikators: getCars.
- Visu transportlīdzekļu statusu vēsture: visu transportlīdzekļu statusi, kas pienāk 72 stundu laikā — SQL vaicājuma identifikators: automašīnasVēsture.
- Plānotie transportlīdzekļi pieņemšanai: visu transportlīdzekļu statusi ar iebraukšanu statusā “Plānots”, laika intervāls “- 24 stundas” un “+24 stundas” no pašreizējā laika - SQL vaicājuma identifikators: automašīnasIekšā.
Tātad, pēc tam, kad būsim izlēmuši par noliktavas veiktspējas rādītāju kopu, mēs sagatavosim SQL vaicājumus WMS datu bāzei. Lai izpildītu vaicājumus, ieteicams izmantot nevis galveno datu bāzi, bet gan tās “karsto” kopiju - gaidīšanas režīmu.
Mēs pieslēdzamies gaidstāves Oracle DBMS, lai saņemtu datus. IP adrese savienojuma izveidei ar testa datubāzi 192.168.1.106. Mēs saglabājam savienojuma parametrus Zabbix serverī SQLcl darba mapes TNSNames.ORA:
# 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)
)
)Tas ļaus mums palaist SQL vaicājumus katram resursdatoram, izmantojot EZconnect, norādot tikai pieteikumvārdu/paroli un datu bāzes nosaukumu:
# sql znew/Zabmon1@WH1_1Sagatavotos SQL vaicājumus saglabājam Zabbix servera darba mapē:
/etc/zabbix/sqlun atļaut piekļuvi mūsu servera zabbix lietotājam:
# chown zabbix:zabbix -R /etc/zabbix/sqlFaili ar pieprasījumiem saņem unikālu identifikatora nosaukumu, lai piekļūtu no Zabbix servera. Katrs datu bāzes vaicājums, izmantojot SQLcl, atgriež mums vairākus parametrus. Ņemot vērā Zabbix specifiku, kas vienā pieprasījumā var apstrādāt tikai vienu metriku, mēs izmantosim papildu skriptus, lai parsētu vaicājuma rezultātus atsevišķās metrikās.
Sagatavosim galveno skriptu, sauksim to par wh_Metrics.sh, lai izsauktu datu bāzē SQL vaicājumu, saglabātu rezultātus un atgrieztu tehnisko metriku ar datu izguves panākumu rādītājiem:
#!/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
fiMēs ievietojam gatavo failu ar skriptu ārējo skriptu glabāšanas mapē saskaņā ar Zabbix starpniekservera konfigurācijas iestatījumiem (pēc noklusējuma - /usr/local/share/zabbix/externalscripts).
Tās datu bāzes identifikācija, no kuras skripts saņems rezultātus, tiks nodota kā skripta parametrs. Datu bāzes ID ir jāatbilst iestatījumu rindiņai failā TNSNames.ORA.
SQL vaicājuma izsaukuma rezultāts tiek saglabāts failā, piemēram mon_base_id_main.log kur base_id = Datu bāzes identifikators saņemts kā skripta parametrs. Rezultātu faila sadalīšana pēc datu bāzes identifikatoriem tiek nodrošināta gadījumos, kad serveri pieprasa vairākas datu bāzes vienlaikus. Vaicājums atgriež sakārtotu divdimensiju vērtību masīvu.
Šis skripts, sauksim to par getMetrica.sh, ir nepieciešams, lai iegūtu noteiktu metriku no faila ar pieprasījuma rezultātu:
#!/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
doneTagad esam gatavi konfigurēt Zabbix un uzsākt noliktavas pieņemšanas procesu indikatoru uzraudzību.
Zabbix aģents ir instalēts un konfigurēts katrā datu bāzes mezglā.
Galvenajā serverī mēs definējam visus serverus ar Zabbix starpniekserveri. Lai iegūtu iestatījumus, dodieties uz šādu ceļu:
Administrēšana → Starpniekserveris → Izveidot starpniekserveri
Mēs definējam kontrolētos saimniekdatorus:
Iestatījumi → Saimnieki → Izveidot saimniekdatoru
Saimniekdatora nosaukumam ir jāatbilst resursdatora nosaukumam, kas norādīts aģenta konfigurācijas failā.
Mēs norādām mezgla grupu, kā arī mezgla IP adresi vai DNS nosaukumu ar datu bāzi.
Mēs veidojam metriku un norādām to īpašības:
Iestatījumi → Mezgli → 'mezgla nosaukums' → Datu elementi> Izveidot datu elementu
1) Izveidojiet galveno metriku, lai vaicātu visus parametrus no datu bāzes
Mēs iestatām datu elementa nosaukumu, norādiet veidu “Ārējā pārbaude”. Laukā “Atslēga” mēs definējam skriptu, kuram kā parametrus nododam Oracle datu bāzes nosaukumu, sql vaicājuma nosaukumu, pieteikumvārdu un paroli, lai izveidotu savienojumu ar datu bāzi. Iestatiet vaicājuma atjaunināšanas intervālu uz 5 minūtēm (300 sekundēm).
2) Izveidojiet atlikušos rādītājus katram transportlīdzekļa statusam. Šo metrikas vērtības tiks ģenerētas, pamatojoties uz galvenās metrikas pārbaudes rezultātu.
Mēs iestatām datu elementa nosaukumu, norādiet veidu “Ārējā pārbaude”. Laukā “Atslēga” mēs definējam skriptu, kuram kā parametrus nododam Oracle datu bāzes nosaukumu un statusa kodu, kura vērtību vēlamies izsekot. Mēs iestatījām vaicājuma atjaunināšanas intervālu uz 10 sekundēm garāku par galveno metriku (310 sekundes), lai rezultātiem būtu laiks ierakstīties failā.
Lai pareizi iegūtu metriku, svarīga ir pārbaužu aktivizēšanas secība. Lai izvairītos no konfliktiem, saņemot datus, vispirms aktivizējam galveno metriku GetCarsByStatus, izsaucot skriptu - wh_Metrics.sh.
Iestatījumi → Mezgli → 'mezgla nosaukums' → Datu elementi → Apakšfiltrs “Ārējās pārbaudes”. Atzīmējiet nepieciešamo atzīmi un noklikšķiniet uz "Aktivizēt".
Tālāk mēs aktivizējam atlikušos rādītājus vienā darbībā, atlasot tos visus kopā:
Tagad Zabbix ir sācis vākt noliktavas biznesa rādītājus.
Nākamajos rakstos sīkāk aplūkosim Grafana pieslēgšanu un informācijas paneļu izveidi par noliktavas darbībām dažādām lietotāju kategorijām. Grafana tiek izmantota arī, lai uzraudzītu novirzes noliktavas darbībās un, atkarībā no noviržu robežām un biežuma, reģistrētu incidentus noliktavas vadības servisa centra sistēmā caur API vai vienkārši nosūtītu paziņojumus pārvaldniekam pa e-pastu.
Avots: www.habr.com