DIY:我們如何自動化倉庫監控

X5營運43個配送中心和4輛自有卡車,確保向029家商店不間斷地供應產品。 在本文中,我將分享我從頭開始建立用於監控倉庫事件的互動式系統的經驗。 這些資訊對於擁有數十個管理各種產品的配送中心的貿易公司的物流人員來說非常有用。

DIY:我們如何自動化倉庫監控

通常,監控和業務流程管理系統的建置從處理訊息和事件開始。 同時,與自動化業務事件發生和記錄事件的可能性相關的重要技術點被忽略。 大多數業務系統如WMS、TMS等都內建了監控自身流程的工具。 但是,如果這些系統來自不同的製造商,或者監控功能尚未充分開發,您就必須訂購昂貴的修改或聘請專業顧問進行額外設定。

讓我們考慮一種方法,在該方法中,我們只需要一小部分與識別來源(表格)相關的諮詢即可從系統中獲取指標。

我們倉庫的特殊性在於,多個倉庫管理系統 (WMS Exceed) 在一個物流綜合體中運作。 倉庫依照存放貨物的類別(乾貨、酒類、冷凍等)進行劃分不僅符合邏輯。 在一個物流綜合體內,有幾個獨立的倉庫大樓,每個倉庫大樓都由自己的 WMS 管理。

DIY:我們如何自動化倉庫監控

為了形成倉庫中發生的流程的整體情況,管理人員每天多次分析每個WMS 的報告,處理來自倉庫操作員(收貨員、揀選員、堆疊員)的訊息,並總結實際操作指標以反映在資訊板上。

為了節省管理人員的時間,我們決定開發一個廉價的系統來對倉庫事件進行操作控制。 新系統除了顯示倉庫流程營運績效的「熱門」指標外,還應協助管理人員記錄事件並監控任務的執行情況,以消除影響給定指標的原因。 在對公司的 IT 架構進行全面審核後,我們意識到所需系統的各個部分已經以某種方式存在於我們的環境中,並且對它們進行了設定檢查和必要的支援服務。 剩下的就是將整個概念納入單一架構解決方案並估計開發範圍。

在評估了建置新系統所需的工作量後,決定將專案分為幾個階段:

  1. 倉庫流程指標收集,指標及偏差可視化及控制
  2. 流程標準自動化以及業務服務中應用程式註冊的偏差
  3. 透過負載預測進行主動監控並為管理人員提供建議。

在第一階段,系統必須從綜合體的所有 WMS 收集準備好的操作資料片段。 閱讀幾乎是即時進行的(間隔少於 5 分鐘)。 訣竅是,在將系統部署到全網時,必須從數十個倉庫的DBMS中取得資料。 接收到的運行資料經過系統核心的邏輯處理,計算出與計畫指標的偏差並進行統計。 以這種方式處理的數據必須以易於理解的圖表和圖表的形式顯示在經理的平板電腦或倉庫資訊板上。

DIY:我們如何自動化倉庫監控

在選擇合適的系統進行第一階段的試點實施時,我們選擇了Zabbix。 該系統已用於監控倉庫系統的 IT 效能。 透過新增單獨的安裝來收集倉庫營運的業務指標,您可以全面了解倉庫的健康狀況。

系統的總體架構如圖所示。

DIY:我們如何自動化倉庫監控

每個WMS實例被定義為監控系統的主機。 資料中心網路中的中央伺服器透過執行帶有準備好的 SQL 查詢的腳本來收集指標。 如果您需要監控不建議直接存取資料庫的系統(例如SAP EWM),您可以使用腳本呼叫記錄的API函數來取得指標或使用python/vbascript編寫簡單的程式。

在倉庫網路中部署一個Zabbix代理實例來分配來自主伺服器的負載。 透過代理,可以確保與所有本地 WMS 實例一起工作。 下次 Zabbix 伺服器請求參數時,將在具有 Zabbix proxy 的主機上執行腳本,以從 WMS 資料庫請求指標。

為了在中央 Zabbix 伺服器上顯示圖形和倉庫指標,我們部署了 Grafana。 除了顯示準備好的帶有倉庫營運資訊圖表的儀表板外,Grafana 還將用於監控指標偏差並向倉庫服務系統發送自動警報以處理業務事件。

作為一個例子,我們考慮在倉庫接收區域實施負載控制。 選擇以下項目作為倉庫該區域流程績效的主要指標:

  • 接待區的車輛數量,考慮到狀態(計畫、到達、文件、卸載、出發;
  • 放置區和補貨區的工作量(依倉儲條件)。

設置

系統主要元件(SQLcl、Zabbix、Grafana)的安裝和配置在各種資料中都有描述,這裡不再重複。 使用 SQLcl 而不是 SQLplus 是因為 SQLcl(Oracle DBMS 的命令列介面,以 java 編寫)不需要額外安裝 Oracle 用戶端,並且開箱即用。

我將描述使用Zabbix監控倉庫業務流程指標時應注意的要點,以及可能的實現方式之一。 另外,這不是一篇關於安全的貼文。 連接的安全性和所提出方法的使用需要在將試點解決方案轉移到生產運營的過程中進行額外的研究。

最主要的是,在實現這樣的系統時,可以使用系統提供的設定而無需編程。

Zabbix 監控系統提供了多種從受監控系統收集指標的選項。 這可以透過直接輪詢受監控的主機來完成,也可以透過主機的 zabbix_sender 向伺服器發送資料的更高級方法來完成,包括配置低階發現參數的方法。 為了解決我們的問題,由中央伺服器直接輪詢主機的方法是相當合適的,因為這使您可以完全控制指標獲取的順序,並確保您使用一組設定/腳本,而無需將它們分發到每個受監控的主機。

作為調試和設定係統的“測試對象”,我們使用WMS工作表進行驗收管理:

  1. 接待處的車輛,所有已到達的車輛:狀態為「- 從目前時間起 72 小時內」期間的所有車輛 - SQL 查詢識別碼: 取得汽車.
  2. 所有車輛狀態歷史記錄:72小時內到達的所有車輛狀態-SQL查詢識別碼: 汽車歷史.
  3. 預約受理車輛:所有處於「預約」狀態的車輛狀態,距離目前時間「- 24 小時」和「+24 小時」的時間間隔 - SQL 查詢識別碼: 汽車在.

因此,在我們確定了一組倉庫效能指標後,我們將為 WMS 資料庫準備 SQL 查詢。 要執行查詢,建議不要使用主資料庫,而是使用其“熱”副本 - 備用資料庫。

我們連接到備用 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)
    )
  )

這將允許我們透過 EZconnect 對每個主機執行 SQL 查詢,僅指定登入名稱/密碼和資料庫名稱:

# 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 代理程式的伺服器。 對於設置,請前往以下路徑:

管理 → 代理 → 建立代理

DIY:我們如何自動化倉庫監控

我們定義受控主機:

設定 → 主機 → 建立主機

DIY:我們如何自動化倉庫監控

主機名稱必須與代理程式設定檔中指定的主機名稱相符。

我們指定節點的群組,以及具有資料庫的節點的 IP 位址或 DNS 名稱。

我們建立指標並指定它們的屬性:

設定 → 節點 → '節點名稱' → 資料項>建立資料項

1)建立一個主要指標,從資料庫中查詢所有參數

DIY:我們如何自動化倉庫監控

我們設定資料元素的名稱,指示類型「外部驗證」。 在「Key」欄位中,我們定義一個腳本,將 Oracle 資料庫的名稱、sql 查詢的名稱、連接資料庫的登入名稱和密碼作為參數傳遞給該腳本。 將查詢更新間隔設定為 5 分鐘(300 秒)。

2) 為每個車輛狀態建立剩餘指標。 這些指標的值將根據檢查主要指標的結果產生。

DIY:我們如何自動化倉庫監控

我們設定資料元素的名稱,指示類型「外部驗證」。 在「Key」欄位中,我們定義一個腳本,將 Oracle 資料庫的名稱和我們想要追蹤其值的狀態代碼作為參數傳遞給該腳本。 我們將查詢更新間隔設定為比主要指標(10 秒)長 310 秒,以便結果有時間寫入檔案。

為了正確取得指標,啟動檢查的順序很重要。 為了避免接收資料時發生衝突,首先我們透過呼叫腳本 wh_Metrics.sh 來啟動主要指標 GetCarsByStatus。

設定→節點→'節點名稱'→資料元素→子過濾器「外部檢查」。 標記所需的檢查並點擊“啟動”。

DIY:我們如何自動化倉庫監控

接下來,我們在一次操作中啟動剩餘的指標,並將它們全部選擇:

DIY:我們如何自動化倉庫監控

現在Zabbix已經開始收集倉庫業務指標。

在接下來的文章中,我們將仔細研究如何連接 Grafana 並為各類使用者建立倉庫營運的資訊儀表板。 Grafana也用於監控倉庫運作中的偏差,並根據偏差的邊界和頻率,透過API在倉庫管理服務中心系統中登記事件,或簡單地透過電子郵件向經理發送通知。

DIY:我們如何自動化倉庫監控

來源: www.habr.com

添加評論