🥇 DIY: چگونه نظارت بر انبار را خودکار می کنیم

X5 43 مرکز توزیع و 4 کامیون خود را اداره می کند و از عرضه بی وقفه محصولات به 029 فروشگاه اطمینان می دهد. در این مقاله تجربه خود را از ایجاد یک سیستم تعاملی برای نظارت بر رویدادهای انبار از ابتدا به اشتراک خواهم گذاشت. این اطلاعات برای تدارکات شرکت های تجاری با چندین مرکز توزیع که طیف گسترده ای از محصولات را مدیریت می کنند مفید خواهد بود.

به عنوان یک قاعده، ساخت سیستم های نظارت و مدیریت فرآیندهای تجاری با پردازش پیام ها و حوادث آغاز می شود. در عین حال، یک نکته مهم تکنولوژیکی مربوط به امکان خودکارسازی واقعیت وقوع رویدادهای تجاری و ثبت حوادث نادیده گرفته شده است. اکثر سیستم های تجاری مانند WMS، TMS و غیره دارای ابزارهای داخلی برای نظارت بر فرآیندهای خود هستند. اما، اگر اینها سیستم هایی از تولید کنندگان مختلف هستند یا عملکرد نظارت به اندازه کافی توسعه نیافته است، باید تغییرات گران قیمت را سفارش دهید یا مشاوران تخصصی را برای تنظیمات اضافی جذب کنید.

بیایید رویکردی را در نظر بگیریم که در آن فقط به بخش کوچکی از مشاوره مرتبط با شناسایی منابع (جدول) برای به دست آوردن شاخص‌ها از سیستم نیاز داریم.

ویژگی انبارهای ما این است که چندین سیستم مدیریت انبار (WMS Exceed) در یک مجتمع لجستیکی کار می کنند. انبارها بر اساس دسته بندی های ذخیره سازی کالا (خشک، الکل، منجمد و غیره) نه تنها از نظر منطقی تقسیم می شوند. در یک مجتمع لجستیکی چندین ساختمان انبار جداگانه وجود دارد که هر یک توسط WMS خاص خود مدیریت می شوند.

برای تشکیل یک تصویر کلی از فرآیندهای رخ داده در انبار، مدیران گزارش هر WMS را چندین بار در روز تجزیه و تحلیل می‌کنند، پیام‌های اپراتورهای انبار (گیرنده، جمع‌کننده، پشته‌گذار) را پردازش می‌کنند و شاخص‌های عملیاتی واقعی را برای بازتاب در تابلوی اطلاعات خلاصه می‌کنند.

برای صرفه جویی در وقت مدیران، تصمیم گرفتیم یک سیستم ارزان قیمت برای کنترل عملیاتی رویدادهای انبار توسعه دهیم. سیستم جدید علاوه بر نمایش شاخص‌های «گرم» عملکرد عملیاتی فرآیندهای انبار، باید مدیران را در ثبت حوادث و نظارت بر اجرای وظایف برای حذف عوامل مؤثر بر شاخص‌های داده شده یاری کند. پس از انجام ممیزی کلی از معماری فناوری اطلاعات شرکت، متوجه شدیم که بخش‌های مجزای سیستم مورد نیاز از قبل به هر طریقی در چشم‌انداز ما وجود دارد و برای آنها هم بررسی تنظیمات و هم خدمات پشتیبانی لازم وجود دارد. تنها چیزی که باقی می ماند این است که کل مفهوم را در یک راه حل معماری واحد آورده و دامنه توسعه را تخمین بزنیم.

پس از ارزیابی میزان کاری که برای ساخت یک سیستم جدید باید انجام شود، تصمیم گرفته شد که پروژه به چند مرحله تقسیم شود:

مجموعه شاخص های فرآیندهای انبار، تجسم و کنترل شاخص ها و انحرافات
اتوماسیون استانداردهای فرآیند و ثبت برنامه های کاربردی در سرویس خدمات تجاری برای انحرافات
نظارت فعال با پیش بینی بار و ایجاد توصیه هایی برای مدیران.

در مرحله اول، سیستم باید برش های آماده شده از داده های عملیاتی را از تمام WMS های مجتمع جمع آوری کند. خواندن تقریباً در زمان واقعی (در فواصل زمانی کمتر از 5 دقیقه) اتفاق می افتد. ترفند این است که هنگام استقرار سیستم در کل شبکه، داده ها باید از DBMS چند ده انبار بدست آید. داده های عملیاتی دریافت شده توسط منطق هسته سیستم برای محاسبه انحراف از شاخص های برنامه ریزی شده و محاسبه آمار پردازش می شود. داده های پردازش شده به این روش باید در تبلت مدیر یا تابلوی اطلاعات انبار به صورت نمودارها و نمودارهای قابل فهم نمایش داده شود.

هنگام انتخاب سیستم مناسب برای اجرای آزمایشی مرحله اول، Zabbix را انتخاب کردیم. این سیستم در حال حاضر برای نظارت بر عملکرد فناوری اطلاعات سیستم های انبار استفاده می شود. با افزودن یک نصب جداگانه برای جمع آوری معیارهای تجاری عملیات انبار، می توانید تصویری کلی از سلامت انبار بدست آورید.

معماری کلی سیستم مانند شکل است.

هر نمونه WMS به عنوان یک میزبان برای سیستم نظارت تعریف می شود. معیارها توسط یک سرور مرکزی در شبکه مرکز داده با اجرای یک اسکریپت با یک پرس و جوی SQL آماده جمع آوری می شود. اگر نیاز به نظارت بر سیستمی دارید که دسترسی مستقیم به پایگاه داده را توصیه نمی کند (به عنوان مثال SAP EWM)، می توانید از فراخوانی های اسکریپت برای توابع API مستند شده برای به دست آوردن شاخص ها یا نوشتن یک برنامه ساده در python/vbascript استفاده کنید.

یک نمونه پروکسی Zabbix در شبکه انبار مستقر می شود تا بار را از سرور اصلی توزیع کند. از طریق Proxy، کار با تمام نمونه های WMS محلی تضمین می شود. دفعه بعد که سرور Zabbix پارامترها را درخواست می کند، یک اسکریپت روی هاست با پراکسی Zabbix برای درخواست معیارها از پایگاه داده WMS اجرا می شود.

برای نمایش نمودارها و نشانگرهای انبار در سرور مرکزی Zabbix، Grafana را مستقر می کنیم. گرافانا علاوه بر نمایش داشبوردهای آماده شده با اینفوگرافیک عملیات انبار، برای نظارت بر انحرافات در نشانگرها و ارسال هشدار خودکار به سامانه خدمات انبار برای کار با حوادث تجاری مورد استفاده قرار می گیرد.

به عنوان مثال، اجازه دهید اجرای کنترل بار در منطقه دریافت انبار را در نظر بگیریم. موارد زیر به عنوان شاخص های اصلی عملکرد فرآیند در این منطقه از انبار انتخاب شدند:

تعداد وسایل نقلیه در منطقه پذیرش با در نظر گرفتن وضعیت (برنامه ریزی شده، وارد شده، اسناد، تخلیه، خروج).
حجم کار مناطق قرار دادن و پر کردن (با توجه به شرایط ذخیره سازی).

تنظیمات

نصب و پیکربندی اجزای اصلی سیستم (SQLcl، Zabbix، Grafana) در منابع مختلف توضیح داده شده است و در اینجا تکرار نخواهد شد. استفاده از SQLcl به جای SQLplus به این دلیل است که SQLcl (رابط خط فرمان Oracle DBMS که در جاوا نوشته شده است) نیازی به نصب اضافی Oracle Client ندارد و خارج از جعبه کار می کند.

نکات اصلی را که هنگام استفاده از Zabbix برای نظارت بر شاخص های فرآیند کسب و کار انبار باید به آن توجه کرد و یکی از راه های ممکن برای پیاده سازی آنها را شرح خواهم داد. همچنین، این یک پست در مورد امنیت نیست. امنیت اتصالات و استفاده از روش های ارائه شده مستلزم مطالعه بیشتر در فرآیند انتقال راه حل آزمایشی به عملیات تولیدی است.

نکته اصلی این است که هنگام پیاده سازی چنین سیستمی، با استفاده از تنظیمات ارائه شده توسط سیستم، می توان بدون برنامه نویسی انجام داد.

سیستم نظارت Zabbix چندین گزینه برای جمع آوری معیارها از سیستم نظارت شده ارائه می دهد. این را می توان با نظرسنجی مستقیم میزبان های نظارت شده یا با روش پیشرفته تر ارسال داده به سرور از طریق zabbix_sender میزبان، از جمله روش هایی برای پیکربندی پارامترهای کشف سطح پایین انجام داد. برای حل مشکل ما، روش نظرسنجی مستقیم هاست توسط سرور مرکزی کاملا مناسب است، زیرا این به شما امکان می‌دهد تا کنترل کاملی بر توالی دریافت معیارها داشته باشید و تضمین می‌کند که از یک مجموعه تنظیمات/اسکریپت‌ها بدون نیاز به توزیع آن‌ها در هر میزبان نظارت شده استفاده می‌کنید.

به عنوان "موضوعات آزمایشی" برای اشکال زدایی و راه اندازی سیستم، از کاربرگ WMS برای مدیریت پذیرش استفاده می کنیم:

وسایل نقلیه در پذیرش، همه آنها که وارد شده اند: همه وسایل نقلیه دارای وضعیت برای دوره "- 72 ساعت از زمان فعلی" - شناسه جستجوی SQL: getCars.
تاریخچه همه وضعیت‌های خودرو: وضعیت تمام خودروهایی که ظرف 72 ساعت وارد می‌شوند - شناسه جستجوی SQL: تاریخچه ماشین.
وسایل نقلیه برنامه ریزی شده برای پذیرش: وضعیت همه وسایل نقلیه با ورود به وضعیت "برنامه ریزی شده"، فاصله زمانی "- 24 ساعت" و "24 ساعت" از زمان فعلی - شناسه پرس و جو SQL: carsIn.

بنابراین، پس از اینکه درباره مجموعه‌ای از معیارهای عملکرد انبار تصمیم گرفتیم، کوئری‌های SQL را برای پایگاه داده WMS آماده می‌کنیم. برای اجرای پرس و جوها، توصیه می شود از پایگاه داده اصلی استفاده نکنید، بلکه از کپی "داغ" آن - آماده به کار استفاده کنید.

ما برای دریافت داده به Oracle DBMS آماده به کار متصل می شویم. آدرس IP برای اتصال به پایگاه داده تست 192.168.1.106. ما پارامترهای اتصال را در سرور Zabbix در TNSNames.ORA پوشه کاری 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)
    )
  )

این به ما این امکان را می‌دهد که کوئری‌های 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).

شناسایی پایگاه داده ای که اسکریپت از آن نتایج را دریافت می کند به عنوان پارامتر اسکریپت ارسال می شود. شناسه پایگاه داده باید با خط تنظیمات موجود در فایل 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) یک معیار اصلی برای پرس و جو کردن همه پارامترها از پایگاه داده ایجاد کنید

ما نام عنصر داده را تنظیم می کنیم، نوع "تأیید خارجی" را نشان می دهیم. در قسمت “Key” اسکریپتی تعریف می کنیم که به عنوان پارامتر نام پایگاه داده اوراکل، نام کوئری sql، لاگین و رمز عبور برای اتصال به پایگاه داده را به آن منتقل می کنیم. فاصله به روز رسانی پرس و جو را روی 5 دقیقه (300 ثانیه) تنظیم کنید.

2) معیارهای باقیمانده را برای هر وضعیت خودرو ایجاد کنید. مقادیر این معیارها بر اساس نتیجه بررسی معیار اصلی تولید می شود.

ما نام عنصر داده را تنظیم می کنیم، نوع "تأیید خارجی" را نشان می دهیم. در قسمت "Key"، اسکریپتی تعریف می کنیم که به عنوان پارامتر، نام پایگاه داده اوراکل و کد وضعیتی که می خواهیم مقدار آن را دنبال کنیم، به آن منتقل می کنیم. فاصله به روز رسانی پرس و جو را 10 ثانیه بیشتر از معیار اصلی (310 ثانیه) تنظیم کردیم تا نتایج زمان برای نوشتن در فایل داشته باشند.

برای به دست آوردن معیارهای صحیح، ترتیب فعال شدن چک ها مهم است. برای جلوگیری از درگیری هنگام دریافت داده ها، ابتدا معیار اصلی GetCarsByStatus را با فراخوانی اسکریپت - wh_Metrics.sh فعال می کنیم.

تنظیمات → گره ها → «نام گره» → عناصر داده → زیرفیلتر «بررسی های خارجی». چک مورد نیاز را علامت بزنید و روی "فعال کردن" کلیک کنید.

در مرحله بعد، معیارهای باقیمانده را در یک عملیات فعال می کنیم و همه آنها را با هم انتخاب می کنیم:

اکنون Zabbix شروع به جمع آوری معیارهای تجاری انبار کرده است.

در مقالات بعدی نگاهی دقیق تر به اتصال گرافانا و ایجاد داشبورد اطلاعاتی عملیات انبار برای دسته های مختلف کاربران خواهیم داشت. گرافانا همچنین برای نظارت بر انحرافات در عملیات انبار و بسته به حدود و دفعات انحرافات، ثبت حوادث در سیستم مرکز خدمات مدیریت انبار از طریق API یا ارسال اعلان‌ها به مدیر به سادگی از طریق ایمیل استفاده می‌شود.

منبع: www.habr.com

DIY: چگونه نظارت بر انبار را خودکار می کنیم

تنظیمات

اضافه کردن نظر انصراف از پاسخ