წვრილმანი: როგორ ვა ავტომატიზირებთ საწყობის მონიტორინგს

X5 მართავს 43 სადისტრიბუციო ცენტრს და 4 საკუთარ სატვირთო მანქანას, რაც უზრუნველყოფს პროდუქციის უწყვეტ მიწოდებას 029 მაღაზიაში. ამ სტატიაში მე გაგიზიარებთ გამოცდილებას ნულიდან საწყობის მოვლენების მონიტორინგის ინტერაქტიული სისტემის შექმნის შესახებ. ინფორმაცია სასარგებლო იქნება სავაჭრო კომპანიების ლოჯისტიკოსებისთვის, რომლებსაც აქვთ რამდენიმე ათეული სადისტრიბუციო ცენტრი, რომლებიც მართავენ პროდუქციის ფართო სპექტრს.

როგორც წესი, მონიტორინგისა და ბიზნეს პროცესის მართვის სისტემების მშენებლობა იწყება შეტყობინებების და ინციდენტების დამუშავებით. ამავდროულად, გამოტოვებულია მნიშვნელოვანი ტექნოლოგიური პუნქტი, რომელიც დაკავშირებულია საქმიანი მოვლენების წარმოშობისა და ინციდენტების ჩაწერის ფაქტის ავტომატიზაციის შესაძლებლობასთან. ბიზნეს სისტემების უმეტესობას, როგორიცაა WMS, TMS და ა.შ., აქვს ჩაშენებული ინსტრუმენტები საკუთარი პროცესების მონიტორინგისთვის. მაგრამ, თუ ეს არის სხვადასხვა მწარმოებლის სისტემები ან მონიტორინგის ფუნქციონირება საკმარისად არ არის განვითარებული, თქვენ უნდა შეუკვეთოთ ძვირადღირებული მოდიფიკაციები ან მოიზიდოთ სპეციალიზებული კონსულტანტები დამატებითი პარამეტრებისთვის.

განვიხილოთ მიდგომა, რომლის დროსაც ჩვენ გვჭირდება მხოლოდ კონსულტაციის მცირე ნაწილი, რომელიც დაკავშირებულია წყაროების (ცხრილების) იდენტიფიკაციასთან სისტემიდან ინდიკატორების მისაღებად.

ჩვენი საწყობების სპეციფიკა არის ის, რომ საწყობის მართვის რამდენიმე სისტემა (WMS Exceed) მუშაობს ერთ ლოჯისტიკურ კომპლექსში. საწყობები იყოფა საქონლის შენახვის კატეგორიების მიხედვით (მშრალი, სპირტი, გაყინული და ა.შ.) არა მხოლოდ ლოგიკურად. ერთი ლოგისტიკური კომპლექსის ფარგლებში არის რამდენიმე ცალკეული საწყობის შენობა, რომელთაგან თითოეულს მართავს საკუთარი WMS.

საწყობში მიმდინარე პროცესების ზოგადი სურათის შესაქმნელად, მენეჯერები აანალიზებენ თითოეული WMS-ის მოხსენებას დღეში რამდენჯერმე, ამუშავებენ შეტყობინებებს საწყობის ოპერატორებისგან (მიმღებები, ამომრჩევები, სტეკერები) და აჯამებენ რეალურ საოპერაციო ინდიკატორებს საინფორმაციო დაფაზე ასახვისთვის.

მენეჯერების დროის დაზოგვის მიზნით, ჩვენ გადავწყვიტეთ შეგვემუშავებინა იაფი სისტემა საწყობის ღონისძიებების ოპერატიული კონტროლისთვის. ახალი სისტემა, გარდა საწყობის პროცესების ოპერატიული შესრულების „ცხელი“ ინდიკატორების ჩვენების გარდა, ასევე უნდა დაეხმაროს მენეჯერებს ინციდენტების აღრიცხვაში და დავალებების შესრულების მონიტორინგში, რათა აღმოფხვრას მიზეზები, რომლებიც გავლენას ახდენს მოცემულ ინდიკატორებზე. კომპანიის IT არქიტექტურის ზოგადი აუდიტის ჩატარების შემდეგ მივხვდით, რომ საჭირო სისტემის ცალკეული ნაწილები ასე თუ ისე უკვე არსებობს ჩვენს ლანდშაფტში და მათთვის არის როგორც პარამეტრების შემოწმება, ასევე საჭირო დამხმარე სერვისები. რჩება მხოლოდ მთელი კონცეფციის ერთ არქიტექტურულ გადაწყვეტაში მოყვანა და განვითარების ფარგლების შეფასება.

სამუშაოს მოცულობის შეფასების შემდეგ, რომელიც უნდა გაკეთდეს ახალი სისტემის ასაშენებლად, გადაწყდა პროექტის დაყოფა რამდენიმე ეტაპად:

1. სასაწყობო პროცესების ინდიკატორების შეგროვება, ინდიკატორებისა და გადახრების ვიზუალიზაცია და კონტროლი
2. პროცესის სტანდარტების ავტომატიზაცია და განაცხადების რეგისტრაცია ბიზნეს სერვისების სერვისში გადახრებისთვის
3. პროაქტიული მონიტორინგი დატვირთვის პროგნოზირებით და მენეჯერებისთვის რეკომენდაციების შექმნით.

პირველ ეტაპზე სისტემამ უნდა შეაგროვოს ოპერატიული მონაცემების მომზადებული ნაჭერი კომპლექსის ყველა WMS-დან. კითხვა ხდება თითქმის რეალურ დროში (5 წუთზე ნაკლები ინტერვალით). ხრიკი იმაში მდგომარეობს, რომ მონაცემები უნდა იქნას მიღებული რამდენიმე ათეული საწყობის DBMS-დან სისტემის მთელ ქსელში განლაგებისას. მიღებული ოპერატიული მონაცემები მუშავდება სისტემის ბირთვის ლოგიკით, დაგეგმილი ინდიკატორებიდან გადახრების გამოსათვლელად და სტატისტიკის გამოსათვლელად. ამ გზით დამუშავებული მონაცემები უნდა იყოს ნაჩვენები მენეჯერის პლანშეტზე ან საწყობის საინფორმაციო დაფაზე გასაგები გრაფიკების და დიაგრამების სახით.

პირველი ეტაპის საპილოტე განხორციელებისთვის შესაფერისი სისტემის არჩევისას ჩვენ ავირჩიეთ Zabbix. ეს სისტემა უკვე გამოიყენება საწყობის სისტემების IT მუშაობის მონიტორინგისთვის. საწყობის მუშაობის საქმიანი მეტრიკის შესაგროვებლად ცალკე ინსტალაციის დამატებით, შეგიძლიათ მიიღოთ საწყობის ჯანმრთელობის ზოგადი სურათი.

სისტემის ზოგადი არქიტექტურა აღმოჩნდა, როგორც ფიგურაში.

თითოეული 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 სახელს მონაცემთა ბაზასთან ერთად.

ჩვენ ვქმნით მეტრიკას და ვაზუსტებთ მათ თვისებებს:

პარამეტრები → კვანძები → "კვანძის სახელი" → Data Items>Create Data Item

1) შექმენით ძირითადი მეტრიკა მონაცემთა ბაზიდან ყველა პარამეტრის შეკითხვისთვის

ჩვენ დავაყენეთ მონაცემთა ელემენტის სახელი, მიუთითეთ ტიპი "გარე დადასტურება". "Key" ველში განვსაზღვრავთ სკრიპტს, რომელსაც პარამეტრებად გადავცემთ Oracle-ის მონაცემთა ბაზის სახელს, sql მოთხოვნის სახელს, ლოგინს და პაროლს მონაცემთა ბაზასთან დასაკავშირებლად. დააყენეთ შეკითხვის განახლების ინტერვალი 5 წუთზე (300 წამში).

2) შექმენით დარჩენილი მეტრიკა თითოეული მანქანის სტატუსისთვის. ამ მეტრიკის მნიშვნელობები გენერირებული იქნება ძირითადი მეტრიკის შემოწმების შედეგის საფუძველზე.

ჩვენ დავაყენეთ მონაცემთა ელემენტის სახელი, მიუთითეთ ტიპი "გარე დადასტურება". „გასაღების“ ველში განვსაზღვრავთ სკრიპტს, რომელსაც პარამეტრებად გადავცემთ Oracle-ის მონაცემთა ბაზის სახელს და სტატუსის კოდს, რომლის მნიშვნელობაც გვინდა თვალყური ადევნოთ. ჩვენ დავაყენეთ შეკითხვის განახლების ინტერვალი 10 წამით მეტზე, ვიდრე ძირითადი მეტრიკა (310 წამი), რათა შედეგებს დრო ჰქონდეს ფაილში ჩასაწერად.

მეტრიკის სწორად მისაღებად მნიშვნელოვანია ჩეკების გააქტიურების თანმიმდევრობა. მონაცემების მიღებისას კონფლიქტების თავიდან აცილების მიზნით, უპირველეს ყოვლისა, ჩვენ ვააქტიურებთ მთავარ მეტრს GetCarsByStatus სკრიპტის - wh_Metrics.sh გამოძახებით.

პარამეტრები → კვანძები → „კვანძის სახელი“ → მონაცემთა ელემენტები → ქვეფილტრი „გარე შემოწმებები“. მონიშნეთ საჭირო შემოწმება და დააჭირეთ "გააქტიურება".

შემდეგი, ჩვენ ვააქტიურებთ დარჩენილ მეტრებს ერთ ოპერაციაში, ვირჩევთ მათ ყველა ერთად:

ახლა Zabbix-მა დაიწყო საწყობის ბიზნეს მეტრიკის შეგროვება.

შემდეგ სტატიებში ჩვენ უფრო დეტალურად განვიხილავთ გრაფანას დაკავშირებას და საწყობის ოპერაციების საინფორმაციო დაფების შექმნას სხვადასხვა კატეგორიის მომხმარებლებისთვის. Grafana ასევე გამოიყენება საწყობის ოპერაციებში გადახრების მონიტორინგისთვის და, გადახრების საზღვრებისა და სიხშირის მიხედვით, დაარეგისტრირებს ინციდენტს საწყობის მართვის სერვის ცენტრის სისტემაში API-ის საშუალებით ან უბრალოდ გაუგზავნეს შეტყობინებები მენეჯერს ელექტრონული ფოსტით.

წყარო: www.habr.com