主持人 > 博客 > 管理 > DIY：我们如何自动化仓库监控

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：我们如何自动化仓库监控

来源： habr.com

添加评论