X5 posiada 43 centra dystrybucyjne i 4 własnych samochodów ciężarowych, zapewniając nieprzerwane dostawy produktów do 029 15 sklepów. W tym artykule podzielę się swoim doświadczeniem w tworzeniu od podstaw interaktywnego systemu monitorowania zdarzeń magazynowych. Informacje te przydadzą się logistykom firm handlowych posiadających kilkadziesiąt centrów dystrybucyjnych zarządzających szeroką gamą produktów.
Z reguły budowę systemów monitorowania i zarządzania procesami biznesowymi rozpoczyna się od przetwarzania komunikatów i incydentów. Jednocześnie pominięto ważny punkt technologiczny związany z możliwością automatyzacji samego faktu wystąpienia zdarzeń biznesowych i rejestracji incydentów. Większość systemów biznesowych typu WMS, TMS itp. posiada wbudowane narzędzia umożliwiające monitorowanie własnych procesów. Jeśli jednak są to systemy różnych producentów lub funkcjonalność monitorowania nie jest wystarczająco rozwinięta, trzeba zamówić kosztowne modyfikacje lub pozyskać wyspecjalizowanych konsultantów w celu uzyskania dodatkowych ustawień.
Rozważmy podejście, w którym potrzebujemy jedynie niewielkiej części doradztwa związanego z identyfikacją źródeł (tablic), aby uzyskać wskaźniki z systemu.
Specyfiką naszych magazynów jest to, że w jednym kompleksie logistycznym funkcjonuje kilka systemów zarządzania magazynem (WMS Exceed). Magazyny podzielone są ze względu na kategorie przechowywania towarów (suche, alkoholowe, mrożone itp.) nie tylko logicznie. W ramach jednego kompleksu logistycznego znajduje się kilka odrębnych budynków magazynowych, z których każdy zarządzany jest własnym systemem WMS.
Aby uzyskać ogólny obraz procesów zachodzących w magazynie, menedżerowie kilka razy dziennie analizują raportowanie każdego systemu WMS, przetwarzają komunikaty od operatorów magazynu (odbiorcy, kompletatorzy, układacze) i podsumowują rzeczywiste wskaźniki operacyjne do odzwierciedlenia na tablicy informacyjnej.
Aby zaoszczędzić czas menadżerów, postanowiliśmy opracować niedrogi system operacyjnej kontroli zdarzeń magazynowych. Nowy system oprócz wyświetlania „gorących” wskaźników operacyjnego wykonania procesów magazynowych powinien także pomóc menedżerom w rejestrowaniu incydentów i monitorowaniu realizacji zadań w celu eliminacji przyczyn mających wpływ na dane wskaźniki. Po przeprowadzeniu ogólnego audytu architektury IT firmy zdaliśmy sobie sprawę, że poszczególne części wymaganego systemu już w taki czy inny sposób istnieją w naszym krajobrazie i dla nich konieczne jest zarówno sprawdzenie ustawień, jak i niezbędnych usług wsparcia. Pozostaje tylko sprowadzić całą koncepcję do jednego rozwiązania architektonicznego i oszacować zakres realizacji.
Po oszacowaniu ilości pracy, jaką trzeba wykonać, aby zbudować nowy system, zdecydowano podzielić projekt na kilka etapów:
- Gromadzenie wskaźników dla procesów magazynowych, wizualizacja i kontrola wskaźników i odchyleń
- Automatyzacja standardów procesów i rejestracja wniosków w serwisie usług biznesowych pod kątem odchyleń
- Proaktywny monitoring z prognozowaniem obciążenia i tworzeniem rekomendacji dla menadżerów.
W pierwszym etapie system musi zebrać przygotowane wycinki danych operacyjnych ze wszystkich systemów WMS kompleksu. Odczyt odbywa się niemal w czasie rzeczywistym (w odstępach krótszych niż 5 minut). Sztuczka polega na tym, że przy wdrażaniu systemu w całej sieci należy pozyskać dane z DBMS kilkudziesięciu hurtowni. Otrzymane dane eksploatacyjne przetwarzane są przez logikę rdzenia systemu w celu wyliczenia odchyleń od zaplanowanych wskaźników oraz wyliczenia statystyk. Przetworzone w ten sposób dane muszą zostać wyświetlone na tablecie menadżera lub na tablicy informacyjnej magazynu w formie zrozumiałych wykresów i diagramów.
Wybierając odpowiedni system do pilotażowego wdrożenia pierwszego etapu, wybraliśmy Zabbix. System ten jest już wykorzystywany do monitorowania wydajności informatycznej systemów magazynowych. Dodając oddzielną instalację do zbierania wskaźników biznesowych dotyczących funkcjonowania magazynu, można uzyskać ogólny obraz stanu magazynu.
Ogólna architektura systemu wyglądała jak na rysunku.
Każda instancja WMS jest zdefiniowana jako host dla systemu monitorowania. Metryki zbierane są przez centralny serwer w sieci data center poprzez uruchomienie skryptu z przygotowanym zapytaniem SQL. Jeśli potrzebujesz monitorować system, który nie zaleca bezpośredniego dostępu do bazy danych (np. SAP EWM), możesz użyć skryptowych wywołań udokumentowanych funkcji API w celu uzyskania wskaźników lub napisać prosty program w python/vbascript.
Instancja proxy Zabbix jest wdrażana w sieci hurtowni w celu dystrybucji obciążenia z głównego serwera. Dzięki Proxy zapewniona jest współpraca ze wszystkimi lokalnymi instancjami WMS. Następnym razem, gdy serwer Zabbix zażąda parametrów, na hoście z serwerem proxy Zabbix zostanie wykonany skrypt w celu zażądania metryk z bazy danych WMS.
Aby wyświetlać wykresy i wskaźniki magazynowe na centralnym serwerze Zabbix, wdrażamy Grafanę. Oprócz wyświetlania przygotowanych dashboardów z infografikami operacji magazynowych, Grafana będzie wykorzystywana do monitorowania odchyleń wskaźników oraz wysyłania automatycznych alertów do systemu obsługi magazynu w celu pracy z incydentami biznesowymi.
Jako przykład rozważmy wdrożenie kontroli ładunku w strefie przyjęcia magazynu. Jako główne wskaźniki realizacji procesów w tym obszarze magazynu wybrano:
- ilość pojazdów na terenie recepcji z uwzględnieniem statusów (planowany, przyjechał, dokumenty, rozładunek, wyjazd;
- obciążenie pracą obszarów rozmieszczania i uzupełniania (zgodnie z warunkami przechowywania).
Ustawienia
Instalacja i konfiguracja głównych komponentów systemu (SQLcl, Zabbix, Grafana) jest opisana w różnych źródłach i nie będzie tutaj powtarzana. Użycie SQLcl zamiast SQLplus wynika z faktu, że SQLcl (interfejs wiersza poleceń Oracle DBMS, napisany w Javie) nie wymaga dodatkowej instalacji Klienta Oracle i działa od razu po wyjęciu z pudełka.
Opiszę główne punkty, na które należy zwrócić uwagę, wykorzystując Zabbix do monitorowania wskaźników procesów biznesowych w magazynie, oraz jeden z możliwych sposobów ich wdrożenia. Poza tym nie jest to post poświęcony bezpieczeństwu. Bezpieczeństwo połączeń i zastosowanie przedstawionych metod wymaga dodatkowych badań w procesie wdrażania pilotażowego rozwiązania do eksploatacji produkcyjnej.
Najważniejsze jest to, że wdrażając taki system, można obejść się bez programowania, korzystając z ustawień dostarczonych przez system.
System monitorowania Zabbix zapewnia kilka opcji gromadzenia metryk z monitorowanego systemu. Można tego dokonać albo bezpośrednio odpytując monitorowane hosty, albo stosując bardziej zaawansowaną metodę wysyłania danych do serwera za pośrednictwem zabbix_sender hosta, włączając metody konfigurowania parametrów wykrywania niskiego poziomu. Aby rozwiązać nasz problem, całkiem odpowiednia jest metoda bezpośredniego odpytywania hostów przez serwer centralny, ponieważ pozwala to uzyskać pełną kontrolę nad kolejnością pozyskiwania metryk i gwarantuje użycie jednego zestawu ustawień/skryptów bez konieczności dystrybucji ich do każdego monitorowanego hosta.
Jako „obiekty testowe” do debugowania i konfiguracji systemu wykorzystujemy arkusz WMS do zarządzania akceptacjami:
- Pojazdy w recepcji, wszystkie, które przyjechały: Wszystkie pojazdy ze statusami za okres „- 72 godziny od aktualnego czasu” - Identyfikator zapytania SQL: getCars.
- Historia wszystkich statusów pojazdów: Statusy wszystkich pojazdów przyjeżdżających w ciągu 72 godzin - Identyfikator zapytania SQL: samochodyHistoria.
- Pojazdy zaplanowane do przyjęcia: Statusy wszystkich pojazdów z przyjazdem w stanie „Zaplanowane”, przedział czasowy „- 24 godziny” i „+24 godziny” od aktualnego czasu - identyfikator zapytania SQL: samochodyW.
Zatem po ustaleniu zestawu wskaźników wydajności magazynu przygotujemy zapytania SQL do bazy WMS. Do wykonywania zapytań zaleca się korzystanie nie z głównej bazy danych, ale z jej „gorącej” kopii – gotowości.
Łączymy się z rezerwowym systemem Oracle DBMS w celu odbioru danych. Adres IP do połączenia z testową bazą danych 192.168.1.106. Parametry połączenia zapisujemy na serwerze Zabbix w pliku TNSNames.ORA folderu roboczego 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)
)
)Umożliwi nam to uruchamianie zapytań SQL do każdego hosta za pośrednictwem EZconnect, podając jedynie login/hasło i nazwę bazy danych:
# sql znew/Zabmon1@WH1_1Przygotowane zapytania SQL zapisujemy w folderze roboczym na serwerze Zabbix:
/etc/zabbix/sqli zezwól na dostęp użytkownikowi Zabbix na naszym serwerze:
# chown zabbix:zabbix -R /etc/zabbix/sqlPliki z żądaniami otrzymują unikalną nazwę-identyfikatora umożliwiającą dostęp z serwera Zabbix. Każde zapytanie do bazy danych za pośrednictwem SQLcl zwraca nam kilka parametrów. Biorąc pod uwagę specyfikę Zabbixa, który może przetwarzać tylko jedną metrykę na żądanie, użyjemy dodatkowych skryptów, aby rozłożyć wyniki zapytania na poszczególne metryki.
Przygotujmy główny skrypt, nazwijmy go wh_Metrics.sh, który wywoła zapytanie SQL do bazy danych, zapisze wyniki i zwróci metrykę techniczną ze wskaźnikami powodzenia wyszukiwania danych:
#!/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
fiGotowy plik ze skryptem umieszczamy w folderze do przechowywania zewnętrznych skryptów zgodnie z ustawieniami konfiguracyjnymi Zabbix-proxy (domyślnie - /usr/local/share/zabbix/externalscripts).
Jako parametr skryptu zostanie przekazana identyfikacja bazy danych, z której skrypt będzie pobierał wyniki. Identyfikator bazy danych musi być zgodny z wierszem ustawień w pliku TNSNames.ORA.
Wynik wywołania zapytania SQL jest zapisywany w pliku takim jak mon_base_id_main.log gdzie base_id = Identyfikator bazy danych otrzymany jako parametr skryptu. Podział pliku wynikowego według identyfikatorów baz danych jest zapewniony w przypadku żądań z serwera do kilku baz danych jednocześnie. Zapytanie zwraca posortowaną dwuwymiarową tablicę wartości.
Aby uzyskać określoną metrykę z pliku zawierającego wynik żądania, potrzebny jest następujący skrypt, nazwijmy go 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
doneTeraz jesteśmy gotowi skonfigurować Zabbix i rozpocząć monitorowanie wskaźników procesów akceptacji magazynowych.
Agent Zabbix jest instalowany i konfigurowany w każdym węźle bazy danych.
Na serwerze głównym definiujemy wszystkie serwery z proxy Zabbix. Aby uzyskać ustawienia, przejdź do następującej ścieżki:
Administracja → Proxy → Utwórz proxy
Definiujemy kontrolowane hosty:
Ustawienia → Hosty → Utwórz hosta
Nazwa hosta musi być zgodna z nazwą hosta określoną w pliku konfiguracyjnym agenta.
Podajemy grupę dla węzła, a także adres IP lub nazwę DNS węzła z bazą danych.
Tworzymy metryki i określamy ich właściwości:
Ustawienia → Węzły → „nazwa węzła” → Elementy danych>Utwórz element danych
1) Utwórz główną metrykę, aby wysłać zapytanie o wszystkie parametry z bazy danych
Ustawiamy nazwę elementu danych, wskazujemy typ „Weryfikacja zewnętrzna”. W polu „Klucz” definiujemy skrypt, do którego przekazujemy jako parametry nazwę bazy danych Oracle, nazwę zapytania sql, login i hasło do połączenia z bazą danych. Ustaw interwał aktualizacji zapytania na 5 minut (300 sekund).
2) Utwórz pozostałe metryki dla każdego stanu pojazdu. Wartości tych metryk zostaną wygenerowane na podstawie wyniku sprawdzenia metryki głównej.
Ustawiamy nazwę elementu danych, wskazujemy typ „Weryfikacja zewnętrzna”. W polu „Klucz” definiujemy skrypt, do którego przekazujemy jako parametry nazwę bazy danych Oracle oraz kod statusu, którego wartość chcemy śledzić. Ustawiamy interwał aktualizacji zapytania na 10 sekund dłuższy niż główna metryka (310 sekund), aby wyniki miały czas na zapisanie do pliku.
Aby poprawnie uzyskać metryki, ważna jest kolejność aktywacji kontroli. Aby uniknąć konfliktów przy odbiorze danych, w pierwszej kolejności aktywujemy główną metrykę GetCarsByStatus wywołując skrypt - wh_Metrics.sh.
Ustawienia → Węzły → „Nazwa węzła” → Elementy danych → Filtr podrzędny „Kontrole zewnętrzne”. Zaznacz wymagane zaznaczenie i kliknij „Aktywuj”.
Następnie w jednej operacji aktywujemy pozostałe metryki, wybierając je wszystkie razem:
Teraz Zabbix rozpoczął zbieranie wskaźników biznesowych magazynu.
W kolejnych artykułach przyjrzymy się bliżej podłączaniu Grafany i tworzeniu dashboardów informacyjnych operacji magazynowych dla różnych kategorii użytkowników. Grafana służy także do monitorowania odchyleń w pracy magazynu oraz w zależności od granic i częstotliwości odchyleń, rejestrowania incydentów w systemie centrum obsługi magazynu poprzez API lub po prostu wysyłania powiadomień do menadżera drogą mailową.
Źródło: www.habr.com