DIY: 창고 모니터링을 자동화하는 방법

X5는 43개의 유통 센터와 4대의 자체 트럭을 운영하여 029개 매장에 중단 없이 제품을 공급합니다. 이 기사에서는 창고 이벤트를 처음부터 모니터링하기 위한 대화형 시스템을 만든 경험을 공유하겠습니다. 이 정보는 다양한 제품을 관리하는 수십 개의 유통 센터를 보유한 무역 회사의 물류 전문가에게 유용할 것입니다.

원칙적으로 모니터링 및 비즈니스 프로세스 관리 시스템 구축은 메시지 및 사고 처리부터 시작됩니다. 동시에, 비즈니스 이벤트 발생 사실을 자동화하고 사건을 기록하는 가능성과 관련된 중요한 기술적 포인트가 누락되었습니다. WMS, TMS 등과 같은 대부분의 비즈니스 시스템에는 자체 프로세스를 모니터링하기 위한 도구가 내장되어 있습니다. 그러나 이것이 다른 제조업체의 시스템이거나 모니터링 기능이 충분히 개발되지 않은 경우 값비싼 수정을 주문하거나 추가 설정을 위해 전문 컨설턴트를 유치해야 합니다.

시스템에서 지표를 얻기 위해 소스(테이블) 식별과 관련된 컨설팅의 일부만 필요한 접근 방식을 고려해 보겠습니다.

우리 창고의 특징은 여러 창고 관리 시스템(WMS Exceed)이 하나의 물류 단지에서 운영된다는 것입니다. 창고는 논리적일 뿐만 아니라 물품 보관 범주(건조품, 주류, 냉동품 등)에 따라 구분됩니다. 하나의 물류 단지 내에는 여러 개의 별도 창고 건물이 있으며, 각 건물은 자체 WMS에 의해 관리됩니다.

창고에서 발생하는 프로세스에 대한 전반적인 그림을 형성하기 위해 관리자는 하루에 여러 번 각 WMS의 보고를 분석하고 창고 운영자(수취인, 피커, 스태커)의 메시지를 처리하고 실제 운영 지표를 요약하여 정보 게시판에 반영합니다.

관리자의 시간을 절약하기 위해 우리는 창고 이벤트의 운영 제어를 위한 저렴한 시스템을 개발하기로 결정했습니다. 새로운 시스템은 창고 프로세스의 운영 성과에 대한 "핫" 지표를 표시하는 것 외에도 관리자가 사고를 기록하고 작업 구현을 모니터링하여 해당 지표에 영향을 미치는 원인을 제거하는 데 도움이 됩니다. 회사의 IT 아키텍처에 대한 일반 감사를 실시한 후, 우리는 필요한 시스템의 개별 부분이 이미 우리 환경에 어떤 방식으로든 존재하며 해당 부분에 대한 설정 검사와 필요한 지원 서비스가 모두 있다는 것을 깨달았습니다. 남은 것은 전체 개념을 단일 아키텍처 솔루션으로 가져오고 개발 범위를 추정하는 것입니다.

새로운 시스템을 구축하는 데 필요한 작업량을 평가한 후 프로젝트를 여러 단계로 나누기로 결정했습니다.

1. 창고 프로세스에 대한 지표 수집, 지표 및 편차의 시각화 및 제어
2. 편차에 대한 프로세스 표준 자동화 및 비즈니스 서비스 서비스의 애플리케이션 등록
3. 부하 예측 및 관리자를 위한 권장 사항 생성을 통한 사전 모니터링.

첫 번째 단계에서 시스템은 단지의 모든 WMS에서 준비된 운영 데이터 조각을 수집해야 합니다. 읽기는 거의 실시간(5분 미만 간격)으로 이루어집니다. 문제는 시스템을 전체 네트워크에 구축할 때 수십 개의 창고에 있는 DBMS에서 데이터를 얻어야 한다는 점이다. 수신된 운영 데이터는 시스템 코어의 논리에 의해 처리되어 계획된 지표와의 편차를 계산하고 통계를 계산합니다. 이렇게 처리된 데이터는 관리자의 태블릿이나 창고 안내판에 이해하기 쉬운 그래프와 도표 형태로 표시되어야 합니다.

첫 번째 단계의 파일럿 구현에 적합한 시스템을 선택할 때 우리는 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를 사용하여 창고 비즈니스 프로세스 지표를 모니터링할 때 주의해야 할 주요 사항과 이를 구현하는 방법 중 하나를 설명합니다. 또한, 이 글은 보안에 관한 글이 아닙니다. 연결 보안과 제시된 방법의 사용에는 파일럿 솔루션을 생산적인 운영으로 전환하는 과정에서 추가 연구가 필요합니다.

가장 중요한 것은 이러한 시스템을 구현할 때 시스템에서 제공하는 설정을 사용하여 프로그래밍 없이도 수행할 수 있다는 것입니다.

Zabbix 모니터링 시스템은 모니터링되는 시스템에서 메트릭을 수집하기 위한 여러 옵션을 제공합니다. 이는 모니터링되는 호스트를 직접 폴링하거나 하위 수준 검색 매개 변수를 구성하는 방법을 포함하여 호스트의 zabbix_sender를 통해 서버에 데이터를 보내는 고급 방법을 통해 수행할 수 있습니다. 우리의 문제를 해결하기 위해서는 중앙 서버가 호스트를 직접 폴링하는 방법이 매우 적합합니다. 이를 통해 메트릭 획득 순서를 완전히 제어할 수 있으며 모니터링되는 각 호스트에 배포할 필요 없이 하나의 설정/스크립트 세트를 사용할 수 있습니다.

시스템 디버깅 및 설정을 위한 "테스트 대상"으로 승인 관리를 위해 WMS 워크시트를 사용합니다.

1. 접수 차량, 도착한 모든 차량: "현재 시간으로부터 - 72시간" 기간 동안의 상태를 가진 모든 차량 - SQL 쿼리 식별자: getCars.
2. 모든 차량 상태 내역: 72시간 이내에 도착하는 모든 차량의 상태 - SQL 쿼리 식별자: 자동차역사.
3. 수락 예정 차량: "예정" 상태로 도착하는 모든 차량의 상태, 현재 시간으로부터 시간 간격 "-24시간" 및 "+24시간" - SQL 쿼리 식별자: 자동차에.

따라서 일련의 웨어하우스 성능 지표를 결정한 후 WMS 데이터베이스에 대한 SQL 쿼리를 준비할 것입니다. 쿼리를 실행하려면 기본 데이터베이스가 아닌 "핫" 복사본(대기)을 사용하는 것이 좋습니다.

데이터를 수신하기 위해 대기 Oracle DBMS에 연결합니다. 테스트 데이터베이스에 연결하기 위한 IP 주소 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

준비된 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 = 스크립트 매개변수로 받은 데이터베이스 식별자입니다. 서버에서 여러 데이터베이스에 동시에 요청하는 경우 데이터베이스 식별자로 결과 파일을 분할합니다. 쿼리는 정렬된 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를 활성화합니다.

설정 → 노드 → '노드 이름' → 데이터 요소 → 하위 필터 "외부 검사". 필요한 확인 사항을 표시하고 "활성화"를 클릭하십시오.

다음으로, 한 번의 작업으로 나머지 측정항목을 활성화하여 모두 함께 선택합니다.

이제 Zabbix는 창고 비즈니스 지표를 수집하기 시작했습니다.

다음 기사에서는 Grafana를 연결하고 다양한 범주의 사용자를 위한 창고 운영 정보 대시보드를 만드는 방법을 자세히 살펴보겠습니다. Grafana는 또한 창고 운영의 편차를 모니터링하고 편차의 경계 및 빈도에 따라 API를 통해 창고 관리 서비스 센터 시스템에 사고를 등록하거나 이메일로 관리자에게 알림을 보내는 데에도 사용됩니다.

출처 : habr.com