X5 provozuje 43 distribučních center a 4 029 vlastních kamionů, což zajišťuje nepřetržité dodávky produktů do 15 752 obchodů. V tomto článku se podělím o své zkušenosti s vytvářením interaktivního systému pro monitorování skladových událostí od začátku. Informace budou užitečné pro logistiky obchodních společností s několika desítkami distribučních center spravujících širokou škálu produktů.
Konstrukce systémů monitorování a řízení obchodních procesů zpravidla začíná zpracováním zpráv a incidentů. Zároveň chybí důležitý technologický bod související s možností automatizace samotného faktu vzniku obchodních událostí a zaznamenávání incidentů. Většina podnikových systémů jako WMS, TMS atd. má vestavěné nástroje pro sledování vlastních procesů. Pokud se však jedná o systémy od různých výrobců nebo funkce monitorování není dostatečně rozvinutá, musíte si objednat drahé úpravy nebo přilákat specializované konzultanty pro další nastavení.
Uvažujme přístup, ve kterém potřebujeme pouze malou část poradenství spojeného s identifikací zdrojů (tabulek) k získání indikátorů ze systému.
Specifikem našich skladů je, že v jednom logistickém komplexu funguje několik systémů řízení skladu (WMS Exceed). Sklady jsou rozděleny podle kategorií skladování zboží (suché, lihové, mražené atd.) nejen logicky. V rámci jednoho logistického komplexu se nachází několik samostatných skladových budov, z nichž každá je řízena vlastním WMS.
Pro vytvoření obecného obrazu o procesech probíhajících ve skladu manažeři několikrát denně analyzují reporting každého WMS, zpracovávají zprávy od skladníků (příjemci, vychystávaci, zakladače) a shrnují aktuální provozní ukazatele pro reflexi na informační tabuli.
Abychom ušetřili čas manažerů, rozhodli jsme se vyvinout levný systém pro operativní řízení skladových událostí. Nový systém by měl kromě zobrazování „horkých“ ukazatelů provozní výkonnosti skladových procesů pomoci manažerům také při evidenci incidentů a sledování plnění úkolů k eliminaci příčin, které dané ukazatele ovlivňují. Po provedení generálního auditu IT architektury společnosti jsme zjistili, že jednotlivé části požadovaného systému již tak či onak v naší krajině existují a existuje pro ně jak prověření nastavení, tak i potřebné podpůrné služby. Nezbývá než dovést celý koncept do jediného architektonického řešení a odhadnout rozsah zástavby.
Po vyhodnocení množství práce, kterou je třeba vykonat k vybudování nového systému, bylo rozhodnuto rozdělit projekt do několika fází:
- Sběr indikátorů pro skladové procesy, vizualizace a kontrola indikátorů a odchylek
- Automatizace procesních standardů a registrace žádostí ve službě podnikových služeb pro odchylky
- Proaktivní monitoring s prognózou zátěže a tvorbou doporučení pro manažery.
V první fázi musí systém shromáždit připravené řezy provozních dat ze všech WMS komplexu. Čtení probíhá téměř v reálném čase (intervaly kratší než 5 minut). Trik je v tom, že data musí být při nasazení systému do celé sítě získána z DBMS několika desítek skladů. Přijatá provozní data zpracovává logika jádra systému pro výpočet odchylek od plánovaných ukazatelů a výpočet statistik. Takto zpracovaná data musí být zobrazena na manažerském tabletu nebo na informační tabuli skladu ve formě srozumitelných grafů a schémat.
Při výběru vhodného systému pro pilotní implementaci první etapy jsme zvolili Zabbix. Tento systém se již používá pro sledování výkonu IT skladových systémů. Přidáním samostatné instalace pro shromažďování obchodních metrik provozu skladu můžete získat celkový obrázek o stavu skladu.
Obecná architektura systému dopadla jako na obrázku.
Každá instance WMS je definována jako hostitel pro monitorovací systém. Metriky shromažďuje centrální server v síti datového centra spuštěním skriptu s připraveným SQL dotazem. Pokud potřebujete monitorovat systém, který nedoporučuje přímý přístup k databázi (například SAP EWM), můžete použít volání skriptů dokumentovaných funkcí API k získání indikátorů nebo napsat jednoduchý program v pythonu/vbascriptu.
Instance proxy Zabbix je nasazena v síti skladu, aby distribuovala zátěž z hlavního serveru. Prostřednictvím Proxy je zajištěna práce se všemi lokálními instancemi WMS. Při příštím požadavku na parametry serveru Zabbix se na hostiteli s proxy serverem Zabbix spustí skript pro vyžádání metrik z databáze WMS.
Pro zobrazení grafů a indikátorů skladu na centrálním serveru Zabbix nasazujeme Grafana. Kromě zobrazení připravených dashboardů s infografikou skladových operací bude Grafana sloužit ke sledování odchylek ukazatelů a zasílání automatických upozornění do systému skladových služeb pro práci s obchodními incidenty.
Jako příklad uvažujme implementaci kontroly zatížení v oblasti příjmu skladu. Jako hlavní ukazatele výkonnosti procesů v této oblasti skladu byly zvoleny následující:
- počet vozidel v prostoru recepce s ohledem na stavy (plánované, přijeté, doklady, vykládka, odjezd;
- vytížení míst umístění a doplňování (dle skladovacích podmínek).
Nastavení
Instalace a konfigurace hlavních komponent systému (SQLcl, Zabbix, Grafana) je popsána v různých zdrojích a nebude zde opakována. Použití SQLcl místo SQLplus je způsobeno skutečností, že SQLcl (rozhraní příkazového řádku Oracle DBMS, napsané v jazyce Java) nevyžaduje dodatečnou instalaci klienta Oracle a funguje ihned po vybalení.
Popíšu hlavní body, kterým je třeba věnovat pozornost při používání Zabbixu pro sledování indikátorů obchodních procesů skladu, a jeden z možných způsobů jejich implementace. Toto také není příspěvek o bezpečnosti. Zabezpečení spojení a použití prezentovaných metod vyžaduje další studium v procesu převodu pilotního řešení do produktivního provozu.
Hlavní věc je, že při implementaci takového systému je možné obejít se bez programování s použitím nastavení poskytovaných systémem.
Monitorovací systém Zabbix poskytuje několik možností pro sběr metrik z monitorovaného systému. To lze provést buď přímým dotazováním monitorovaných hostitelů, nebo pokročilejší metodou odesílání dat na server prostřednictvím hostitele zabbix_sender, včetně metod pro konfiguraci nízkoúrovňových parametrů zjišťování. K vyřešení našeho problému je metoda přímého dotazování hostitelů centrálním serverem docela vhodná, protože to vám umožní získat plnou kontrolu nad posloupností získávání metrik a zajistí, že budete používat jednu sadu nastavení/skriptů, aniž byste je museli distribuovat každému monitorovanému hostiteli.
Jako „testovací subjekty“ pro ladění a nastavení systému používáme WMS list pro správu akceptace:
- Vozidla na recepci, všechna, která přijela: Všechna vozidla se stavy za období „- 72 hodin od aktuálního času“ - Identifikátor dotazu SQL: getCars.
- Historie všech stavů vozidel: Stavy všech vozidel přijíždějících do 72 hodin - Identifikátor dotazu SQL: historie automobilů.
- Naplánovaná vozidla k přejímce: Stavy všech vozidel s příjezdem ve stavu „Naplánováno“, časový interval „- 24 hodin“ a „+24 hodin“ od aktuálního času - identifikátor SQL dotazu: carsIn.
Takže poté, co jsme se rozhodli pro sadu metrik výkonu skladu, připravíme SQL dotazy pro WMS databázi. Pro provádění dotazů je vhodné používat nikoli hlavní databázi, ale její „horkou“ kopii – pohotovostní režim.
Připojujeme se k pohotovostnímu systému Oracle DBMS, abychom mohli přijímat data. IP adresa pro připojení k testovací databázi 192.168.1.106. Parametry připojení uložíme na server Zabbix do TNNames.ORA pracovní složky 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)
)
)To nám umožní spouštět dotazy SQL na každého hostitele prostřednictvím EZconnect, přičemž uvedeme pouze přihlašovací jméno/heslo a název databáze:
# sql znew/Zabmon1@WH1_1Připravené SQL dotazy uložíme do pracovní složky na serveru Zabbix:
/etc/zabbix/sqla povolit přístup uživateli zabbix našeho serveru:
# chown zabbix:zabbix -R /etc/zabbix/sqlSoubory s požadavky obdrží jedinečný identifikátor-název pro přístup ze serveru Zabbix. Každý databázový dotaz přes SQLcl nám vrací několik parametrů. S přihlédnutím ke specifikům Zabbixu, který dokáže zpracovat pouze jednu metriku na požadavek, použijeme další skripty k analýze výsledků dotazu do jednotlivých metrik.
Připravme si hlavní skript, říkejme mu wh_Metrics.sh, pro volání SQL dotazu do databáze, uložení výsledků a vrácení technické metriky s indikátory úspěšnosti načítání dat:
#!/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
fiHotový soubor se skriptem umístíme do složky pro ukládání externích skriptů v souladu s nastavením konfigurace Zabbix-proxy (ve výchozím nastavení - /usr/local/share/zabbix/externalscripts).
Jako parametr skriptu bude předána identifikace databáze, ze které bude skript přijímat výsledky. ID databáze musí odpovídat řádku nastavení v souboru TNNames.ORA.
Výsledek volání SQL dotazu se uloží do souboru jako mon_base_id_main.log kde base_id = Identifikátor databáze přijatý jako parametr skriptu. Rozdělení výsledného souboru podle databázových identifikátorů je zajištěno v případě požadavků ze serveru na několik databází současně. Dotaz vrátí seřazené dvourozměrné pole hodnot.
Následující skript, nazvěme ho getMetrica.sh, je potřeba k získání zadané metriky ze souboru s výsledkem požadavku:
#!/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
doneNyní jsme připraveni nakonfigurovat Zabbix a začít sledovat indikátory procesů přejímky na sklad.
Na každém databázovém uzlu je nainstalován a konfigurován agent Zabbix.
Na hlavním serveru definujeme všechny servery s proxy Zabbix. Pro nastavení přejděte na následující cestu:
Administrace → Proxy → Vytvořit proxy
Definujeme řízené hostitele:
Nastavení → Hostitelé → Vytvořit hostitele
Název hostitele se musí shodovat s názvem hostitele, který je uveden v konfiguračním souboru agenta.
Určíme skupinu pro uzel a také IP adresu nebo DNS jméno uzlu s databází.
Vytváříme metriky a specifikujeme jejich vlastnosti:
Nastavení → Uzly → 'název uzlu' → Datové položky>Vytvořit datovou položku
1) Vytvořte hlavní metriku pro dotazování všech parametrů z databáze
Nastavíme název datového prvku, označíme typ „Externí ověření“. V poli “Klíč” definujeme skript, kterému předáme jako parametry název databáze Oracle, název sql dotazu, login a heslo pro připojení k databázi. Nastavte interval aktualizace dotazu na 5 minut (300 sekund).
2) Vytvořte zbývající metriky pro každý stav vozidla. Hodnoty těchto metrik budou generovány na základě výsledku kontroly hlavní metriky.
Nastavíme název datového prvku, označíme typ „Externí ověření“. V poli “Klíč” definujeme skript, kterému předáme jako parametry název databáze Oracle a stavový kód, jehož hodnotu chceme sledovat. Interval aktualizace dotazu jsme nastavili o 10 sekund delší než hlavní metrika (310 sekund), aby se výsledky stihly zapsat do souboru.
Pro správné získání metrik je důležité pořadí, ve kterém jsou kontroly aktivovány. Aby nedocházelo ke konfliktům při příjmu dat, nejprve aktivujeme hlavní metriku GetCarsByStatus voláním skriptu - wh_Metrics.sh.
Nastavení → Uzly → 'název uzlu' → Datové prvky → Podfiltr „Externí kontroly“. Označte požadovanou kontrolu a klikněte na „Aktivovat“.
Dále v jedné operaci aktivujeme zbývající metriky a vybereme je všechny dohromady:
Nyní Zabbix začal shromažďovat obchodní metriky skladu.
V následujících článcích se blíže podíváme na propojení Grafany a vytváření informačních dashboardů skladových provozů pro různé kategorie uživatelů. Grafana také slouží ke sledování odchylek ve skladových operacích a v závislosti na hranicích a četnosti odchylek k evidenci incidentů v systému střediska služeb řízení skladu přes API nebo jednoduše zasílání upozornění vedoucímu e-mailem.
Zdroj: www.habr.com