DIY. ինչպես ենք մենք ավտոմատացնում պահեստի մոնիտորինգը

X5-ը շահագործում է 43 բաշխիչ կենտրոն և 4 սեփական բեռնատար ավտոմեքենա՝ ապահովելով 029 խանութների ապրանքների անխափան մատակարարում։ Այս հոդվածում ես կկիսվեմ պահեստային իրադարձությունների զրոյից մոնիտորինգի համար ինտերակտիվ համակարգ ստեղծելու իմ փորձով: Տեղեկատվությունը օգտակար կլինի առևտրային ընկերությունների լոգիստիկներին, որոնք ունեն մի քանի տասնյակ բաշխիչ կենտրոններ, որոնք կառավարում են ապրանքների լայն տեսականի:

Որպես կանոն, մոնիտորինգի և բիզնես գործընթացների կառավարման համակարգերի կառուցումը սկսվում է հաղորդագրությունների և միջադեպերի մշակմամբ: Միևնույն ժամանակ, բաց է թողնվել մի կարևոր տեխնոլոգիական կետ՝ կապված բիզնես իրադարձությունների տեղի ունենալու և միջադեպերի գրանցման փաստի ավտոմատացման հնարավորության հետ։ Բիզնես համակարգերի մեծ մասը, ինչպիսիք են WMS-ը, TMS-ը և այլն, ունեն ներկառուցված գործիքներ՝ սեփական գործընթացները վերահսկելու համար: Բայց, եթե դրանք տարբեր արտադրողների համակարգեր են, կամ մոնիտորինգի գործառույթը բավականաչափ զարգացած չէ, դուք պետք է պատվիրեք թանկարժեք փոփոխություններ կամ ներգրավեք մասնագիտացված խորհրդատուների լրացուցիչ պարամետրերի համար:

Դիտարկենք մի մոտեցում, որում մեզ անհրաժեշտ է միայն խորհրդատվության մի փոքր մասը՝ կապված աղբյուրների (աղյուսակների) նույնականացման հետ՝ համակարգից ցուցանիշներ ստանալու համար:

Մեր պահեստների առանձնահատկությունն այն է, որ պահեստների կառավարման մի քանի համակարգեր (WMS Exceed) գործում են մեկ լոգիստիկ համալիրում: Պահեստները բաժանվում են ըստ ապրանքների պահպանման կատեգորիաների (չոր, ալկոհոլ, սառեցված և այլն) ոչ միայն տրամաբանորեն։ Մեկ լոգիստիկ համալիրի ներսում կան մի քանի առանձին պահեստային շենքեր, որոնցից յուրաքանչյուրը կառավարվում է իր սեփական WMS-ի կողմից:

Պահեստում տեղի ունեցող գործընթացների ընդհանուր պատկերացում կազմելու համար մենեջերները օրվա ընթացքում մի քանի անգամ վերլուծում են յուրաքանչյուր WMS-ի հաշվետվությունը, մշակում պահեստի օպերատորների հաղորդագրությունները (ստացողներ, հավաքողներ, ստեկերներ) և ամփոփում փաստացի գործառնական ցուցանիշները տեղեկատվական տախտակի վրա արտացոլելու համար:

Մենեջերների ժամանակը խնայելու համար մենք որոշեցինք մշակել պահեստային իրադարձությունների գործառնական վերահսկողության էժան համակարգ: Նոր համակարգը, ի լրումն պահեստային գործընթացների գործառնական կատարողականի «թեժ» ցուցանիշների ցուցադրման, պետք է նաև օգնի ղեկավարներին միջադեպերի գրանցման և առաջադրանքների կատարման մոնիտորինգի հարցում՝ վերացնելու համար տվյալ ցուցանիշների վրա ազդող պատճառները: Ընկերության ՏՏ ճարտարապետության ընդհանուր աուդիտ անցկացնելուց հետո մենք հասկացանք, որ պահանջվող համակարգի առանձին մասեր այս կամ այն ​​կերպ արդեն գոյություն ունեն մեր լանդշաֆտում, և նրանց համար կա և՛ կարգավորումների ուսումնասիրություն, և՛ անհրաժեշտ օժանդակ ծառայություններ: Մնում է ամբողջ հայեցակարգը բերել մեկ ճարտարապետական ​​լուծման և գնահատել զարգացման շրջանակը:

Նոր համակարգի կառուցման համար անհրաժեշտ աշխատանքի ծավալը գնահատելուց հետո որոշվեց նախագիծը բաժանել մի քանի փուլերի.

1. Պահեստային գործընթացների ցուցիչների հավաքում, ցուցիչների և շեղումների վիզուալացում և վերահսկում
2. Գործընթացների ստանդարտների ավտոմատացում և շեղումների համար բիզնես ծառայությունների ծառայությունում դիմումների գրանցում
3. Նախաձեռնող մոնիտորինգ՝ բեռի կանխատեսմամբ և ղեկավարների համար առաջարկությունների ստեղծում:

Առաջին փուլում համակարգը պետք է հավաքի գործառնական տվյալների պատրաստված հատվածներ համալիրի բոլոր WMS-ից: Ընթերցանությունը տեղի է ունենում գրեթե իրական ժամանակում (5 րոպեից պակաս ընդմիջումներով): Խաբեությունն այն է, որ տվյալները պետք է ձեռք բերվեն մի քանի տասնյակ պահեստների DBMS-ից՝ համակարգը ամբողջ ցանցում տեղակայելիս: Ստացված գործառնական տվյալները մշակվում են համակարգի միջուկի տրամաբանությամբ՝ պլանավորված ցուցանիշներից շեղումները հաշվարկելու և վիճակագրությունը հաշվարկելու համար: Այս կերպ մշակված տվյալները պետք է ցուցադրվեն կառավարչի պլանշետում կամ պահեստի տեղեկատվական տախտակի վրա՝ հասկանալի գրաֆիկների և դիագրամների տեսքով:

Առաջին փուլի փորձնական իրականացման համար հարմար համակարգ ընտրելիս մենք ընտրեցինք Zabbix-ը: Այս համակարգն արդեն օգտագործվում է պահեստային համակարգերի ՏՏ աշխատանքի մոնիտորինգի համար: Պահեստի շահագործման բիզնես ցուցանիշների հավաքագրման համար առանձին տեղադրում ավելացնելով, դուք կարող եք ստանալ պահեստի առողջության ընդհանուր պատկերը:

Համակարգի ընդհանուր ճարտարապետությունը ստացվեց այնպես, ինչպես նկարում:

Յուրաքանչյուր WMS օրինակ սահմանվում է որպես մոնիտորինգի համակարգի հյուրընկալող: Չափումները հավաքվում են կենտրոնական սերվերի կողմից տվյալների կենտրոնի ցանցում՝ գործարկելով սկրիպտը պատրաստված SQL հարցումով: Եթե ​​Ձեզ անհրաժեշտ է վերահսկել մի համակարգ, որը խորհուրդ չի տալիս ուղղակի մուտք գործել տվյալների բազա (օրինակ՝ SAP EWM), կարող եք օգտագործել սկրիպտի կանչեր փաստաթղթավորված API ֆունկցիաներին՝ ցուցիչներ ստանալու կամ պարզ ծրագիր գրել python/vbascript-ով:

Zabbix վստահված անձի օրինակը տեղակայվում է պահեստային ցանցում՝ հիմնական սերվերից բեռը բաշխելու համար: Proxy-ի միջոցով ապահովվում է աշխատանքը բոլոր տեղական WMS ատյանների հետ։ Հաջորդ անգամ, երբ Zabbix սերվերը պահանջի պարամետրեր, սկրիպտը կկատարվի հոսթի վրա Zabbix վստահված անձի միջոցով՝ պահանջելու չափումներ WMS տվյալների բազայից:

Կենտրոնական Zabbix սերվերի վրա գրաֆիկները և պահեստի ցուցիչները ցուցադրելու համար մենք տեղադրում ենք Grafana-ն: Բացի պահեստային գործառնությունների ինֆոգրաֆիկայով պատրաստված վահանակները ցուցադրելուց, Grafana-ն կօգտագործվի ցուցիչների շեղումները վերահսկելու և պահեստի սպասարկման համակարգին ավտոմատ ծանուցումներ ուղարկելու համար՝ բիզնես միջադեպերի հետ աշխատելու համար:

Որպես օրինակ՝ դիտարկենք պահեստի ընդունման տարածքում բեռների վերահսկման իրականացումը։ Որպես պահեստի այս տարածքում գործընթացի կատարման հիմնական ցուցիչներ ընտրվել են հետևյալը.

• Ընդունման տարածքում տրանսպորտային միջոցների քանակը՝ հաշվի առնելով կարգավիճակները (պլանավորված, ժամանած, փաստաթղթեր, բեռնաթափում, մեկնում).
• տեղաբաշխման և համալրման տարածքների ծանրաբեռնվածությունը (ըստ պահեստավորման պայմանների).

Կառավարում

Համակարգի հիմնական բաղադրիչների (SQLcl, Zabbix, Grafana) տեղադրումն ու կազմաձևումը նկարագրված են տարբեր աղբյուրներում և այստեղ չեն կրկնվի: SQLcl-ի օգտագործումը SQLplus-ի փոխարեն պայմանավորված է նրանով, որ SQLcl-ը (Oracle DBMS-ի հրամանի տող ինտերֆեյսը, գրված է java-ով) չի պահանջում Oracle Client-ի լրացուցիչ տեղադրում և աշխատում է առանց տուփի:

Ես նկարագրելու եմ հիմնական կետերը, որոնց վրա պետք է ուշադրություն դարձնել, երբ Zabbix-ն օգտագործում եք պահեստի բիզնես գործընթացի ցուցանիշները վերահսկելու համար և դրանց իրականացման հնարավոր ուղիներից մեկը: Նաև սա անվտանգության մասին գրառում չէ։ Միացումների անվտանգությունը և ներկայացված մեթոդների կիրառումը պահանջում է լրացուցիչ ուսումնասիրություն պիլոտային լուծումը արդյունավետ շահագործման հանձնելու գործընթացում:

Գլխավորն այն է, որ նման համակարգ ներդնելիս հնարավոր է անել առանց ծրագրավորման՝ օգտագործելով համակարգի կողմից տրամադրված կարգավորումները։

Zabbix մոնիտորինգի համակարգը մի քանի տարբերակ է տրամադրում վերահսկվող համակարգից չափումների հավաքագրման համար: Դա կարելի է անել կա՛մ ուղղակիորեն վերահսկվող հոսթինգների հարցումների միջոցով, կա՛մ հոսթի zabbix_sender-ի միջոցով սերվերին տվյալներ ուղարկելու ավելի առաջադեմ եղանակով, ներառյալ ցածր մակարդակի հայտնաբերման պարամետրերը կարգավորելու մեթոդները: Մեր խնդիրը լուծելու համար կենտրոնական սերվերի կողմից հոսթինգների ուղղակի հարցման մեթոդը բավականին հարմար է, քանի որ սա թույլ է տալիս լիարժեք վերահսկողություն ձեռք բերել չափումների ձեռքբերման հաջորդականության վրա և երաշխավորում է, որ դուք օգտագործում եք կարգավորումների/սկրիպտների մեկ փաթեթ՝ առանց դրանք բաժանելու յուրաքանչյուր վերահսկվող հոսթին:

Որպես «թեստային առարկաներ»՝ վրիպազերծման և համակարգի տեղադրման համար, մենք օգտագործում ենք WMS աշխատաթերթը ընդունման կառավարման համար.

1. Տրանսպորտային միջոցներ ընդունարանում, բոլորը, որոնք ժամանել են. Բոլոր տրանսպորտային միջոցները կարգավիճակներով «- ընթացիկ ժամանակից 72 ժամ» ժամանակահատվածի համար - SQL հարցման նույնացուցիչ. getCars.
2. Տրանսպորտային միջոցների բոլոր կարգավիճակների պատմություն. 72 ժամվա ընթացքում ժամանած բոլոր տրանսպորտային միջոցների կարգավիճակները - SQL հարցման նույնացուցիչ. ավտոմեքենաների պատմություն.
3. Պլանավորված տրանսպորտային միջոցների ընդունման համար. «Պլանավորված» կարգավիճակով ժամանած բոլոր տրանսպորտային միջոցների կարգավիճակները, «- 24 ժամ» և «+24 ժամ» ժամանակային միջակայքը ընթացիկ ժամանակից - SQL հարցման նույնացուցիչ. ավտոմեքենաներ.

Այսպիսով, այն բանից հետո, երբ մենք որոշել ենք պահեստի կատարողականի չափման մի շարք, մենք կպատրաստենք SQL հարցումներ WMS տվյալների բազայի համար: Հարցումներ կատարելու համար խորհուրդ է տրվում օգտագործել ոչ թե հիմնական տվյալների բազան, այլ դրա «թեժ» պատճենը՝ սպասման ռեժիմը:

Տվյալներ ստանալու համար մենք միանում ենք սպասման Oracle DBMS-ին: IP հասցե՝ թեստային տվյալների շտեմարանին միանալու համար 192.168.1.106. Մենք պահպանում ենք կապի պարամետրերը Zabbix սերվերում SQLcl աշխատանքային թղթապանակի 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)
    )
  )

Սա թույլ կտա մեզ գործարկել SQL հարցումներ յուրաքանչյուր հոսթին EZconnect-ի միջոցով՝ նշելով միայն մուտքի/գաղտնաբառը և տվյալների բազայի անունը.

# sql znew/Zabmon1@WH1_1

Մենք պահպանում ենք պատրաստված SQL հարցումները Zabbix սերվերի աշխատանքային թղթապանակում.

/etc/zabbix/sql

և թույլ տվեք մուտք գործել մեր սերվերի zabbix օգտվողին.

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

Հարցումներ ունեցող ֆայլերը ստանում են եզակի նույնացուցիչ-անուն Zabbix սերվերից մուտք գործելու համար: SQLcl-ի միջոցով տվյալների բազայի յուրաքանչյուր հարցում մեզ վերադարձնում է մի քանի պարամետր: Հաշվի առնելով Zabbix-ի առանձնահատկությունները, որը յուրաքանչյուր հարցումով կարող է մշակել միայն մեկ չափանիշ, մենք կօգտագործենք լրացուցիչ սկրիպտներ՝ հարցման արդյունքները առանձին չափումների վերլուծելու համար:

Եկեք պատրաստենք հիմնական սկրիպտը, եկեք այն անվանենք wh_Metrics.sh, տվյալների բազայում SQL հարցում կանչելու, արդյունքները պահպանելու և տվյալների որոնման հաջողության ցուցանիշներով տեխնիկական չափանիշ վերադարձնելու համար.

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

Մենք պատրաստի ֆայլը սկրիպտի հետ տեղադրում ենք թղթապանակում՝ Zabbix-proxy-ի կազմաձևման պարամետրերին համապատասխան արտաքին սկրիպտները պահելու համար (լռելյայն - /usr/local/share/zabbix/externalscripts).

Տվյալների բազայի նույնականացումը, որից սկրիպտը կստանա արդյունքներ, կփոխանցվի որպես սցենարի պարամետր: Տվյալների բազայի ID-ն պետք է համապատասխանի TNSNames.ORA ֆայլի կարգավորումների տողին:

SQL հարցման կանչի արդյունքը պահվում է նման ֆայլում mon_base_id_main.log որտեղ base_id = Տվյալների բազայի նույնացուցիչը ստացվել է որպես սցենարի պարամետր: Արդյունքների ֆայլի բաժանումն ըստ տվյալների բազայի նույնացուցիչների տրամադրվում է սերվերից միաժամանակ մի քանի տվյալների բազաների հարցումների դեպքում։ Հարցումը վերադարձնում է արժեքների դասավորված երկչափ զանգված:

Հետևյալ սկրիպտը, եկեք այն անվանենք getMetrica.sh, անհրաժեշտ է հարցման արդյունքով ֆայլից որոշակի չափանիշ ստանալու համար.

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

Այժմ մենք պատրաստ ենք կարգավորել Zabbix-ը և սկսել պահեստի ընդունման գործընթացների ցուցիչների մոնիտորինգը:

Zabbix գործակալը տեղադրվում և կազմաձևվում է տվյալների բազայի յուրաքանչյուր հանգույցում:

Հիմնական սերվերի վրա մենք սահմանում ենք բոլոր սերվերները Zabbix պրոքսիով: Կարգավորումների համար անցեք հետևյալ ուղին.

Ադմինիստրացիա → վստահված անձ → Ստեղծել վստահված անձ

Մենք սահմանում ենք վերահսկվող հյուրընկալողներ.

Կարգավորումներ → Հոսթներ → Ստեղծել հոսթ

Հյուրընկալողի անունը պետք է համապատասխանի գործակալի կազմաձևման ֆայլում նշված հյուրընկալողի անվանը:

Մենք նշում ենք հանգույցի խումբը, ինչպես նաև տվյալների բազայի հետ հանգույցի IP հասցեն կամ DNS անվանումը:

Մենք ստեղծում ենք չափումներ և նշում դրանց հատկությունները.

Կարգավորումներ → Հանգույցներ → «հանգույցի անունը» → Տվյալների իրեր>Ստեղծել տվյալների տարր

1) Ստեղծեք հիմնական չափանիշ տվյալների բազայից բոլոր պարամետրերը հարցումներ անելու համար

Մենք սահմանում ենք տվյալների տարրի անունը, նշում ենք «Արտաքին ստուգում» տեսակը: «Բանալին» դաշտում մենք սահմանում ենք սկրիպտ, որին որպես պարամետր փոխանցում ենք Oracle տվյալների բազայի անվանումը, sql հարցման անվանումը, տվյալների բազային միանալու համար մուտքի և գաղտնաբառը: Հարցման թարմացման միջակայքը սահմանեք 5 րոպե (300 վայրկյան):

2) Ստեղծեք մնացած չափումները յուրաքանչյուր մեքենայի կարգավիճակի համար: Այս չափումների արժեքները կստեղծվեն հիմնական չափման ստուգման արդյունքի հիման վրա:

Մենք սահմանում ենք տվյալների տարրի անունը, նշում ենք «Արտաքին ստուգում» տեսակը: «Բանալին» դաշտում մենք սահմանում ենք սկրիպտ, որին որպես պարամետրեր փոխանցում ենք Oracle տվյալների բազայի անվանումը և կարգավիճակի կոդը, որի արժեքը մենք ցանկանում ենք հետևել: Հարցման թարմացման միջակայքը սահմանել ենք 10 վայրկյանով ավելի, քան հիմնական ցուցանիշը (310 վայրկյան), որպեսզի արդյունքները ժամանակ ունենան ֆայլում գրվելու համար:

Չափումների ճիշտ ձեռքբերման համար կարևոր է չեկերի ակտիվացման հերթականությունը: Տվյալներ ստանալիս կոնֆլիկտներից խուսափելու համար նախ և առաջ մենք ակտիվացնում ենք հիմնական չափանիշը GetCarsByStatus՝ զանգահարելով սկրիպտը՝ wh_Metrics.sh:

Կարգավորումներ → Հանգույցներ → «հանգույցի անուն» → Տվյալների տարրեր → «Արտաքին ստուգումներ» ենթաֆիլտր։ Նշեք պահանջվող ստուգումը և սեղմեք «Ակտիվացնել»:

Հաջորդը, մենք ակտիվացնում ենք մնացած չափումները մեկ գործողության մեջ՝ ընտրելով դրանք բոլորը միասին.

Այժմ Zabbix-ը սկսել է հավաքել պահեստային բիզնեսի ցուցանիշները:

Հետևյալ հոդվածներում մենք ավելի մանրամասն կանդրադառնանք Grafana-ի միացմանը և տարբեր կատեգորիաների օգտատերերի համար պահեստային գործառնությունների տեղեկատվական վահանակների ստեղծմանը: Նաև Grafana-ի հիման վրա իրականացվում է պահեստային գործառնությունների շեղումների մոնիտորինգ և, կախված շեղումների սահմաններից և կրկնելիությունից, միջադեպերի գրանցում պահեստի կառավարման սպասարկման կենտրոնի համակարգում API-ի միջոցով կամ կառավարչին էլփոստով ծանուցումների պարզ ուղարկում:

Source: www.habr.com