DIY: ہم کس طرح گودام کی نگرانی کو خودکار بناتے ہیں۔

X5 43 تقسیمی مراکز اور 4 اپنے ٹرک چلاتا ہے، 029 اسٹورز کو مصنوعات کی بلاتعطل فراہمی کو یقینی بناتا ہے۔ اس مضمون میں میں شروع سے گودام کے واقعات کی نگرانی کے لیے ایک انٹرایکٹو سسٹم بنانے کے اپنے تجربے کا اشتراک کروں گا۔ یہ معلومات تجارتی کمپنیوں کے لاجسٹک ماہرین کے لیے کارآمد ثابت ہوں گی جن کے کئی درجن تقسیم مراکز پروڈکٹس کی وسیع رینج کا انتظام کرتے ہیں۔

ایک اصول کے طور پر، نگرانی اور کاروباری عمل کے انتظام کے نظام کی تعمیر پروسیسنگ پیغامات اور واقعات کے ساتھ شروع ہوتا ہے. ایک ہی وقت میں، کاروباری واقعات اور ریکارڈنگ کے واقعات کی موجودگی کی حقیقت کو خودکار کرنے کے امکان سے متعلق ایک اہم تکنیکی نکتہ چھوٹ گیا ہے۔ زیادہ تر کاروباری نظام جیسے ڈبلیو ایم ایس، ٹی ایم ایس، وغیرہ میں ان کے اپنے عمل کی نگرانی کے لیے بلٹ ان ٹولز ہوتے ہیں۔ لیکن، اگر یہ مختلف مینوفیکچررز کے سسٹمز ہیں یا مانیٹرنگ کی فعالیت کافی حد تک تیار نہیں کی گئی ہے، تو آپ کو اضافی سیٹنگز کے لیے مہنگی ترامیم کا آرڈر دینا ہوگا یا خصوصی کنسلٹنٹس کو راغب کرنا ہوگا۔

آئیے ایک نقطہ نظر پر غور کریں جس میں ہمیں سسٹم سے اشارے حاصل کرنے کے لیے شناختی ذرائع (ٹیبلز) سے منسلک مشاورت کے صرف ایک چھوٹے سے حصے کی ضرورت ہے۔

ہمارے گوداموں کی خصوصیت یہ ہے کہ متعدد گودام مینجمنٹ سسٹم (WMS Exceed) ایک لاجسٹک کمپلیکس میں کام کرتے ہیں۔ گوداموں کو نہ صرف منطقی طور پر سامان ذخیرہ کرنے کے زمرے (خشک، الکحل، منجمد، وغیرہ) کے مطابق تقسیم کیا جاتا ہے۔ ایک لاجسٹک کمپلیکس کے اندر کئی الگ گودام عمارتیں ہیں، جن میں سے ہر ایک کا انتظام اس کے اپنے WMS کے ذریعے کیا جاتا ہے۔

گودام میں ہونے والے عمل کی ایک عمومی تصویر بنانے کے لیے، مینیجر دن میں کئی بار ہر WMS کی رپورٹنگ کا تجزیہ کرتے ہیں، گودام آپریٹرز (رسیور، چننے والے، اسٹیکرز) کے پیغامات پر کارروائی کرتے ہیں اور معلوماتی بورڈ پر عکاسی کے لیے حقیقی آپریشنل اشارے کا خلاصہ کرتے ہیں۔

مینیجرز کا وقت بچانے کے لیے، ہم نے گودام کے واقعات کے آپریشنل کنٹرول کے لیے ایک سستا نظام تیار کرنے کا فیصلہ کیا۔ نیا نظام، گودام کے عمل کی آپریشنل کارکردگی کے "گرم" اشارے ظاہر کرنے کے علاوہ، مینیجرز کو واقعات کو ریکارڈ کرنے اور کاموں کے نفاذ کی نگرانی کرنے میں بھی مدد کرے گا تاکہ دیے گئے اشارے پر اثر انداز ہونے والی وجوہات کو ختم کیا جا سکے۔ کمپنی کے IT فن تعمیر کا عمومی آڈٹ کرنے کے بعد، ہم نے محسوس کیا کہ مطلوبہ نظام کے انفرادی حصے پہلے سے ہی ہمارے منظر نامے میں کسی نہ کسی طریقے سے موجود ہیں اور ان کے لیے سیٹنگز اور ضروری سپورٹ سروسز دونوں کا جائزہ لینا ہے۔ باقی صرف یہ ہے کہ پورے تصور کو ایک ہی تعمیراتی حل میں لایا جائے اور ترقی کے دائرہ کار کا اندازہ لگایا جائے۔

نئے نظام کی تعمیر کے لیے کام کی مقدار کا اندازہ لگانے کے بعد، اس منصوبے کو کئی مراحل میں تقسیم کرنے کا فیصلہ کیا گیا:

1. گودام کے عمل کے لیے اشارے کا مجموعہ، تصور اور اشارے اور انحراف کا کنٹرول
2. عمل کے معیارات کی آٹومیشن اور انحراف کے لیے کاروباری خدمات کی خدمت میں درخواستوں کی رجسٹریشن
3. بوجھ کی پیشن گوئی اور مینیجرز کے لیے سفارشات کی تخلیق کے ساتھ فعال نگرانی۔

پہلے مرحلے پر، سسٹم کو کمپلیکس کے تمام WMS سے آپریشنل ڈیٹا کے تیار کردہ سلائسز جمع کرنے چاہئیں۔ پڑھنا تقریباً حقیقی وقت میں ہوتا ہے (5 منٹ سے کم وقفے)۔ چال یہ ہے کہ سسٹم کو پورے نیٹ ورک پر تعینات کرتے وقت کئی درجن گوداموں کے DBMS سے ڈیٹا حاصل کرنا ضروری ہے۔ موصول ہونے والے آپریشنل ڈیٹا پر سسٹم کور کی منطق کے ذریعے کارروائی کی جاتی ہے تاکہ منصوبہ بند اشارے سے انحراف کا حساب لگایا جا سکے اور شماریات کا حساب لگایا جا سکے۔ اس طریقے سے پروسیس کیے گئے ڈیٹا کو مینیجر کے ٹیبلٹ پر یا گودام کے معلوماتی بورڈ پر قابل فہم گرافس اور خاکوں کی شکل میں ظاہر کیا جانا چاہیے۔

پہلے مرحلے کے پائلٹ نفاذ کے لیے موزوں نظام کا انتخاب کرتے وقت، ہم نے Zabbix کا انتخاب کیا۔ یہ نظام پہلے ہی گودام کے نظام کی آئی ٹی کارکردگی کی نگرانی کے لیے استعمال کیا جاتا ہے۔ گودام کے آپریشن کے کاروباری میٹرکس کو جمع کرنے کے لیے ایک علیحدہ تنصیب شامل کرکے، آپ گودام کی صحت کی مجموعی تصویر حاصل کر سکتے ہیں۔

نظام کے عمومی فن تعمیر اعداد و شمار میں کے طور پر باہر کر دیا.

ہر WMS مثال کو نگرانی کے نظام کے میزبان کے طور پر بیان کیا گیا ہے۔ میٹرکس ڈیٹا سینٹر نیٹ ورک میں ایک مرکزی سرور کے ذریعہ تیار کردہ SQL استفسار کے ساتھ اسکرپٹ چلا کر جمع کیے جاتے ہیں۔ اگر آپ کو کسی ایسے سسٹم کی نگرانی کرنے کی ضرورت ہے جو ڈیٹا بیس تک براہ راست رسائی کی سفارش نہیں کرتا ہے (مثال کے طور پر، SAP EWM)، آپ اشارے حاصل کرنے کے لیے دستاویزی API فنکشنز کے لیے اسکرپٹ کالز کا استعمال کر سکتے ہیں یا python/vbascript میں ایک سادہ پروگرام لکھ سکتے ہیں۔

مین سرور سے بوجھ کو تقسیم کرنے کے لیے ایک Zabbix پراکسی مثال کو ویئر ہاؤس نیٹ ورک میں تعینات کیا جاتا ہے۔ پراکسی کے ذریعے، تمام مقامی WMS مثالوں کے ساتھ کام کو یقینی بنایا جاتا ہے۔ اگلی بار جب Zabbix سرور پیرامیٹرز کی درخواست کرتا ہے، WMS ڈیٹا بیس سے میٹرکس کی درخواست کرنے کے لیے Zabbix پراکسی کے ساتھ میزبان پر ایک اسکرپٹ کو عمل میں لایا جاتا ہے۔

مرکزی پر گراف اور گودام اشارے ظاہر کرنے کے لیے سرور ہم Zabbix میں Grafana تعینات کر رہے ہیں۔ گودام کی کارکردگی کے انفوگرافکس کے ساتھ تیار کردہ ڈیش بورڈز کو ظاہر کرنے کے علاوہ، گرافانا کا استعمال میٹرک انحراف کی نگرانی کے لیے اور کاروباری واقعات کے انتظام کے لیے ویئر ہاؤس سروس سسٹم کو خودکار الرٹس بھیجنے کے لیے کیا جائے گا۔

ایک مثال کے طور پر، آئیے گودام وصول کرنے والے علاقے میں لوڈ کنٹرول کے نفاذ پر غور کریں۔ مندرجہ ذیل کو گودام کے اس علاقے میں عمل کی کارکردگی کے اہم اشارے کے طور پر منتخب کیا گیا تھا:

• ریسیپشن ایریا میں گاڑیوں کی تعداد، حالات کو مدنظر رکھتے ہوئے (منصوبہ بند، پہنچنا، دستاویزات، اتارنا، روانگی؛
• جگہ کا تعین اور دوبارہ بھرنے والے علاقوں کا کام کا بوجھ (اسٹوریج کے حالات کے مطابق)۔

ترتیبات

سسٹم کے اہم اجزاء (SQLcl، Zabbix، Grafana) کی تنصیب اور ترتیب مختلف ذرائع میں بیان کی گئی ہے اور اسے یہاں دہرایا نہیں جائے گا۔ SQLplus کے بجائے SQLcl کا استعمال اس حقیقت کی وجہ سے ہے کہ SQLcl (Oracle DBMS کا کمانڈ لائن انٹرفیس، جاوا میں لکھا ہوا ہے) کو اوریکل کلائنٹ کی اضافی تنصیب کی ضرورت نہیں ہے اور یہ باکس کے باہر کام کرتا ہے۔

میں ان اہم نکات کی وضاحت کروں گا جن پر زبکس کا استعمال کرتے ہوئے گودام کے کاروباری عمل کے اشاریوں کی نگرانی کے لیے توجہ دی جانی چاہیے، اور ان پر عمل درآمد کے ممکنہ طریقوں میں سے ایک۔ اس کے علاوہ، یہ سیکورٹی کے بارے میں ایک پوسٹ نہیں ہے. کنکشن کی حفاظت اور پیش کردہ طریقوں کے استعمال کے لیے پائلٹ حل کو نتیجہ خیز آپریشن میں منتقل کرنے کے عمل میں اضافی مطالعہ کی ضرورت ہے۔

اہم بات یہ ہے کہ اس طرح کے نظام کو لاگو کرتے وقت، نظام کے ذریعہ فراہم کردہ ترتیبات کا استعمال کرتے ہوئے، پروگرامنگ کے بغیر کرنا ممکن ہے.

زبکس مانیٹرنگ سسٹم مانیٹرڈ سسٹم سے میٹرکس اکٹھا کرنے کے لیے کئی اختیارات فراہم کرتا ہے۔ یہ یا تو براہ راست پولنگ کی نگرانی کرنے والے میزبانوں کے ذریعے، یا میزبان کے zabbix_sender کے ذریعے سرور کو ڈیٹا بھیجنے کے زیادہ جدید طریقہ کے ذریعے کیا جا سکتا ہے، بشمول کم سطح کے دریافت کے پیرامیٹرز کو ترتیب دینے کے طریقے۔ ہمارے مسئلے کو حل کرنے کے لیے، مرکزی سرور کے ذریعے میزبانوں کی براہ راست پولنگ کا طریقہ کافی موزوں ہے، کیونکہ یہ آپ کو میٹرکس کے حصول کی ترتیب پر مکمل کنٹرول حاصل کرنے کی اجازت دیتا ہے اور اس بات کو یقینی بناتا ہے کہ آپ سیٹنگز/اسکرپٹس کا ایک سیٹ استعمال کرتے ہیں انہیں ہر نگرانی شدہ میزبان میں تقسیم کرنے کی ضرورت کے بغیر۔

سسٹم کو ڈیبگ کرنے اور ترتیب دینے کے لیے "ٹیسٹ مضامین" کے طور پر، ہم قبولیت کے انتظام کے لیے WMS ورک شیٹ استعمال کرتے ہیں:

1. استقبالیہ پر موجود گاڑیاں، وہ سبھی جو پہنچ چکی ہیں: تمام گاڑیاں جن کی مدت "- موجودہ وقت سے 72 گھنٹے" کے لیے ہے - SQL استفسار شناخت کنندہ: حاصل کاریں.
2. تمام گاڑیوں کے سٹیٹس کی تاریخ: 72 گھنٹے کے اندر آنے والی تمام گاڑیوں کی سٹیٹس - SQL استفسار شناخت کنندہ: کاروں کی تاریخ.
3. قبولیت کے لیے طے شدہ گاڑیاں: "شیڈولڈ" اسٹیٹس میں آنے والی تمام گاڑیوں کے اسٹیٹس، وقت کا وقفہ "- 24 گھنٹے" اور "+24 گھنٹے" موجودہ وقت سے - SQL استفسار شناخت کنندہ: کاروں میں.

لہذا، گودام کی کارکردگی کی پیمائش کے ایک سیٹ پر فیصلہ کرنے کے بعد، ہم WMS ڈیٹا بیس کے لیے SQL سوالات تیار کریں گے۔ استفسارات کو انجام دینے کے لیے، یہ مشورہ دیا جاتا ہے کہ مرکزی ڈیٹا بیس کا استعمال نہ کریں، بلکہ اس کی "ہاٹ" کاپی - اسٹینڈ بائی۔

ڈیٹا حاصل کرنے کے لیے ہم اسٹینڈ بائی Oracle DBMS سے جڑتے ہیں۔ آئی پی ایڈریس ٹیسٹ ڈیٹا بیس سے جڑنے کے لیے 192.168.1.106ہم کنکشن کے پیرامیٹرز کو محفوظ کرتے ہیں۔ سرور SQLcl ورکنگ ڈائرکٹری کے TNSNames.ORA میں Zabbix:

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

یہ ہمیں EZconnect کے ذریعے ہر میزبان سے SQL سوالات چلانے کی اجازت دے گا، صرف لاگ ان/پاس ورڈ اور ڈیٹا بیس کا نام بتاتے ہوئے:

# sql znew/Zabmon1@WH1_1

ہم Zabbix سرور پر کام کرنے والے فولڈر میں تیار کردہ SQL سوالات کو محفوظ کرتے ہیں:

/etc/zabbix/sql

اور ہمارے سرور کے زبکس صارف تک رسائی کی اجازت دیں:

# 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

ہم تیار شدہ فائل کو اسکرپٹ کے ساتھ فولڈر میں خارجی اسکرپٹ کو زبیبکس-پراکسی کنفیگریشن سیٹنگز کے مطابق اسٹور کرنے کے لیے رکھتے ہیں (بطور ڈیفالٹ - /usr/local/share/zabbix/externalscripts).

اس ڈیٹا بیس کی شناخت جس سے اسکرپٹ نتائج حاصل کرے گا اسے اسکرپٹ پیرامیٹر کے طور پر پاس کیا جائے گا۔ ڈیٹابیس ID کا TNSNames.ORA فائل میں سیٹنگ لائن سے مماثل ہونا چاہیے۔

ایس کیو ایل استفسار کال کا نتیجہ اس طرح کی فائل میں محفوظ ہوتا ہے۔ 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 ایجنٹ ہر ڈیٹا بیس نوڈ پر انسٹال اور کنفیگر ہوتا ہے۔

مین سرور پر ہم تمام سرورز کی تعریف زبکس پراکسی کے ساتھ کرتے ہیں۔ ترتیبات کے لیے، درج ذیل راستے پر جائیں:

انتظامیہ → پراکسی → پراکسی بنائیں

ہم کنٹرولڈ میزبانوں کی وضاحت کرتے ہیں:

ترتیبات → میزبان → میزبان بنائیں

میزبان نام کا میزبان نام سے مماثل ہونا چاہیے جو ایجنٹ کنفیگریشن فائل میں بیان کیا گیا ہے۔

ہم نوڈ کے لیے گروپ کے ساتھ ساتھ ڈیٹا بیس کے ساتھ نوڈ کا IP ایڈریس یا DNS نام بھی بتاتے ہیں۔

ہم میٹرکس بناتے ہیں اور ان کی خصوصیات بتاتے ہیں:

ترتیبات → نوڈس → 'نوڈ کا نام' → ڈیٹا آئٹمز> ڈیٹا آئٹم بنائیں

1) ڈیٹا بیس سے تمام پیرامیٹرز کو استفسار کرنے کے لیے ایک مین میٹرک بنائیں

ہم ڈیٹا عنصر کا نام سیٹ کرتے ہیں، "بیرونی تصدیق" کی قسم کی نشاندہی کرتے ہیں۔ "Key" فیلڈ میں، ہم ایک اسکرپٹ کی وضاحت کرتے ہیں جس کو ہم پیرامیٹرز کے طور پر اوریکل ڈیٹا بیس کا نام، sql استفسار کا نام، ڈیٹا بیس سے منسلک کرنے کے لیے لاگ ان اور پاس ورڈ کے طور پر منتقل کرتے ہیں۔ استفسار اپ ڈیٹ کا وقفہ 5 منٹ (300 سیکنڈ) پر سیٹ کریں۔

2) ہر گاڑی کی حیثیت کے لیے بقیہ میٹرکس بنائیں۔ ان میٹرکس کی قدریں مین میٹرک کو چیک کرنے کے نتیجے کی بنیاد پر تیار کی جائیں گی۔

ہم ڈیٹا عنصر کا نام سیٹ کرتے ہیں، "بیرونی تصدیق" کی قسم کی نشاندہی کرتے ہیں۔ "کلیدی" فیلڈ میں، ہم ایک اسکرپٹ کی وضاحت کرتے ہیں جس میں ہم پیرامیٹرز کے طور پر اوریکل ڈیٹا بیس کا نام اور اسٹیٹس کوڈ جس کی قدر کو ہم ٹریک کرنا چاہتے ہیں۔ ہم نے استفسار کے اپ ڈیٹ کا وقفہ مین میٹرک (10 سیکنڈ) سے 310 سیکنڈ لمبا کر دیا ہے تاکہ نتائج کو فائل میں لکھے جانے کا وقت ملے۔

میٹرکس کو صحیح طریقے سے حاصل کرنے کے لیے، چیک کو چالو کرنے کی ترتیب اہم ہے۔ ڈیٹا وصول کرتے وقت تنازعات سے بچنے کے لیے، سب سے پہلے ہم اسکرپٹ - wh_Metrics.sh پر کال کرکے مین میٹرک GetCarsByStatus کو چالو کرتے ہیں۔

ترتیبات → نوڈس → 'نوڈ کا نام' → ڈیٹا عناصر → سب فلٹر "بیرونی چیک"۔ مطلوبہ چیک کو نشان زد کریں اور "فعال کریں" پر کلک کریں۔

اگلا، ہم بقیہ میٹرکس کو ایک آپریشن میں چالو کرتے ہیں، ان سب کو ایک ساتھ منتخب کرتے ہوئے:

اب Zabbix نے ویئر ہاؤس بزنس میٹرکس اکٹھا کرنا شروع کر دیا ہے۔

مندرجہ ذیل مضامین میں، ہم گرافانا کو مربوط کرنے اور صارفین کے مختلف زمروں کے لیے گودام آپریشنز کے معلوماتی ڈیش بورڈز بنانے پر گہری نظر ڈالیں گے۔ گرافانا کو گودام کے آپریشنز میں انحراف کی نگرانی کے لیے بھی استعمال کیا جاتا ہے اور انحراف کی حدود اور تعدد پر منحصر ہے، API کے ذریعے گودام مینجمنٹ سروس سینٹر سسٹم میں واقعات کو رجسٹر کریں یا صرف ای میل کے ذریعے مینیجر کو اطلاعات بھیجیں۔

ماخذ: www.habr.com