DIY: 倉庫監視を自動化する方法

X5 は 43 の配送センターと 4 台の自社トラックを運営し、029 店舗への製品の途切れのない供給を保証しています。この記事では、倉庫イベントを監視するための対話型システムを一から作成した私の経験を共有します。この情報は、さまざまな商品を管理する数十の配送センターを持つ商社の物流担当者にとって役立ちます。

通常、監視およびビジネス プロセス管理システムの構築は、メッセージとインシデントの処理から始まります。同時に、ビジネス イベントの発生そのものを自動化し、インシデントを記録する可能性に関する重要な技術的ポイントが見逃されています。 WMS、TMS などのほとんどのビジネス システムには、独自のプロセスを監視するためのツールが組み込まれています。ただし、これらが異なるメーカーのシステムである場合、または監視機能が十分に開発されていない場合は、高価な変更を注文するか、追加設定のために専門のコンサルタントを雇う必要があります。

システムから指標を取得するためのソース (テーブル) の特定に関連するコンサルティングのほんの一部だけが必要なアプローチを考えてみましょう。

当社の倉庫の特徴は、複数の倉庫管理システム (WMS Exceed) が XNUMX つの物流施設で稼働していることです。倉庫は、論理的にだけでなく、商品の保管カテゴリー (ドライ、アルコール、冷凍など) に応じて分割されています。 XNUMX つの物流施設内には複数の倉庫棟があり、それぞれが独自の WMS によって管理されています。

倉庫内で発生するプロセスの全体像を把握するために、管理者は各 WMS のレポートを XNUMX 日に数回分析し、倉庫オペレーター (荷受人、ピッカー、スタッカー) からのメッセージを処理し、情報ボードに反映するために実際の運用指標を要約します。

管理者の時間を節約するために、私たちは倉庫イベントの運用管理のための安価なシステムを開発することにしました。新しいシステムは、倉庫プロセスの運用パフォーマンスの「ホットな」指標を表示することに加えて、管理者がインシデントを記録し、タスクの実施を監視して特定の指標に影響を与える原因を排除するのにも役立ちます。会社の IT アーキテクチャの一般的な監査を実施した後、必要なシステムの個々の部分が何らかの形ですでに当社の環境に存在しており、それらに対して設定の調査と必要なサポート サービスの両方が必要であることがわかりました。残っているのは、コンセプト全体を単一のアーキテクチャ ソリューションにまとめ、開発範囲を見積もることだけです。

新しいシステムを構築するために必要な作業量を評価した後、プロジェクトをいくつかの段階に分割することが決定されました。

1. 倉庫プロセスの指標の収集、指標と偏差の可視化と管理
2. プロセス標準の自動化と逸脱に対するビジネスサービスサービスへのアプリケーションの登録
3. 負荷予測によるプロアクティブなモニタリングと管理者向けの推奨事項の作成。

最初の段階で、システムは複合施設のすべての WMS から運用データの準備されたスライスを収集する必要があります。読み取りはほぼリアルタイム (5 分未満の間隔) で行われます。ポイントは、システムをネットワーク全体に展開するときに、数十のウェアハウスの DBMS からデータを取得する必要があることです。受信した運用データはシステム コアのロジックによって処理され、計画された指標からの偏差が計算され、統計が計算されます。このようにして処理されたデータは、わかりやすいグラフや図の形で管理者のタブレットや倉庫情報ボードに表示される必要があります。

第 XNUMX 段階のパイロット実装に適したシステムを選択する際に、Zabbix を選択しました。このシステムは、倉庫システムの IT パフォーマンスを監視するためにすでに使用されています。倉庫運用のビジネス メトリクスを収集するための別のインストールを追加することで、倉庫の健全性の全体像を把握できます。

システムの一般的なアーキテクチャは図のようになりました。

各 WMS インスタンスは、監視システムのホストとして定義されます。メトリクスは、準備された SQL クエリを使用してスクリプトを実行することにより、データ センター ネットワーク内の中央サーバーによって収集されます。データベースへの直接アクセスが推奨されていないシステム (SAP EWM など) を監視する必要がある場合は、文書化された API 関数へのスクリプト呼び出しを使用してインジケーターを取得したり、Python/vbascript で簡単なプログラムを作成したりできます。

Zabbix プロキシ インスタンスは、メイン サーバーからの負荷を分散するためにウェアハウス ネットワークにデプロイされます。プロキシを通じて、すべてのローカル WMS インスタンスとの連携が保証されます。次回、Zabbix サーバーがパラメータをリクエストするとき、Zabbix プロキシを備えたホスト上でスクリプトが実行され、WMS データベースからメトリクスをリクエストします。

中央の Zabbix サーバーにグラフとウェアハウス インジケーターを表示するために、Grafana をデプロイします。 Grafana は、倉庫業務のインフォグラフィックを含む準備されたダッシュボードを表示するだけでなく、指標の逸脱を監視し、ビジネス インシデントに対処するために倉庫サービス システムに自動アラートを送信するためにも使用されます。

例として、倉庫の受け取りエリアでの負荷制御の実装を考えてみましょう。倉庫のこの領域におけるプロセスパフォーマンスの主な指標として、以下が選択されました。

• ステータス（計画、到着、書類、荷降ろし、出発）を考慮した、受付エリアの車両の数。
• 配置および補充エリアの作業負荷（保管条件による）。

設定

システムの主要コンポーネント (SQLcl、Zabbix、Grafana) のインストールと構成については、さまざまなソースで説明されているため、ここでは繰り返しません。 SQLplus の代わりに SQLcl が使用されるのは、SQLcl (Java で記述された Oracle DBMS のコマンド ライン インターフェイス) が Oracle クライアントの追加インストールを必要とせず、そのまま使用できるためです。

Zabbixを使用して倉庫業務プロセス指標を監視する際に注意すべき主なポイントと、それらを実現するための方法のXNUMXつについて説明します。また、これはセキュリティに関する投稿ではありません。接続のセキュリティと提示された方法の使用については、パイロット ソリューションを本稼働に移行するプロセスで追加の検討が必要です。

主なことは、このようなシステムを実装する場合、システムが提供する設定を使用してプログラミングなしで実行できることです。

Zabbix 監視システムには、監視対象システムからメトリクスを収集するためのいくつかのオプションが用意されています。これは、監視対象ホストを直接ポーリングするか、ホストの zabbix_sender を介してサーバーにデータを送信するより高度な方法 (低レベルの検出パラメーターを構成する方法など) によって実行できます。この問題を解決するには、中央サーバーによるホストの直接ポーリング方法が非常に適しています。これにより、メトリクス取得のシーケンスを完全に制御できるようになり、各監視対象ホストに配布することなく、XNUMX セットの設定/スクリプトを使用できるようになります。

システムのデバッグとセットアップの「テスト対象」として、受け入れ管理に 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 を介した各データベース クエリは、いくつかのパラメータを返します。リクエストごとに XNUMX つのメトリクスのみを処理できる 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 プロキシ構成設定 (デフォルトでは - /usr/local/share/zabbix/externalscripts).

スクリプトが結果を受け取るデータベースの ID は、スクリプト パラメーターとして渡されます。データベース ID は、TNSNames.ORA ファイルの設定行と一致する必要があります。

SQL クエリ呼び出しの結果は、次のようなファイルに保存されます。 mon_base_id_main.log ここで、base_id = スクリプトパラメータとして受け取ったデータベース識別子。サーバーから複数のデータベースに同時にリクエストがあった場合に備えて、データベース識別子による結果ファイルの分割が提供されます。クエリは、並べ替えられた値の XNUMX 次元配列を返します。

次のスクリプト (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 秒長く設定しました。

メトリクスを正しく取得するには、チェックをアクティブにする順序が重要です。データ受信時の競合を避けるために、まずスクリプト wh_Metrics.sh を呼び出してメイン メトリクス GetCarsByStatus をアクティブにします。

設定 → ノード → 'ノード名' → データ要素 → サブフィルター「外部チェック」。必要なチェックを入れて「有効化」をクリックします。

次に、残りのメトリクスを XNUMX 回の操作でアクティブ化し、すべてまとめて選択します。

現在、Zabbix は倉庫ビジネス指標の収集を開始しています。

次の記事では、Grafana の接続と、さまざまなカテゴリのユーザー向けの倉庫業務の情報ダッシュボードの作成について詳しく説明します。また、Grafanaをベースに倉庫業務の逸脱監視を実現し、逸脱の範囲や再現性に応じて、API経由で倉庫管理サービスセンターシステムにインシデントを登録したり、管理者にメールで簡単に通知したりすることも可能です。

出所： habr.com