DIY: quomodo nos automate CELLA vigilantia?

X5 43 centra distributionis et 4029 currus proprios gerit, ita ut continuas res ad 15752 tabernas distribuat. In hoc articulo, experientiam meam in aedificando systemate interactivo monitorio eventuum horreorum ex nihilo communicabo. Haec informatio utilis erit peritis logisticis apud societates venditionum cum multis centris distributionis amplam varietatem rerum administrantibus.

Typice, aedificatio systematum monitoriarum et administrationis processuum negotialium incipit cum nuntiis et incidentibus tractandis. Attamen, hoc aspectum technologicum magni momenti neglegit, qui ad facultatem ipsam eventuum negotialium et incidentium notationem automatizandi pertinet. Pleraque systemata negotialia, ut WMS, TMS, et alia, facultates monitoriarum processuum insitas habent. Attamen, si haec systemata a diversis venditoribus sunt vel functiones monitoriarum non satis evolutae sunt, customizationes sumptuosae vel participatio consultorum specialium ad configurationem additam requiruntur.

Consideremus modum quo parva tantum parte consultationis ad fontes (tabulas) definiendos ad indicatores ex systemate obtinendos indigebimus.

Horrea nostra eo singularia sunt quod plura systemata administrationis horreorum (WMS Exceed) intra unum complexum logisticum operantur. Horrea secundum categorias repositionis (merces siccas, alcohol, congelatas, etc.) dividuntur non solum logice sed etiam intra unum complexum logisticum, ubi plura aedificia horreorum separata sita sunt, singula suo WMS administrata.

Ut imaginem plenam processuum horrei evolvant, administratores relationes ex unoquoque WMS pluries in die examinant, nuntia ab operatoribus horrei (recipientibus, selectoribus, et accumulantibus) tractant, et indices operationis actuales ad exhibendum in tabula instrumentorum summatim exponunt.

Ut tempus curatorum conservaremus, systema minoris pretii ad monitorationem operationum eventuum horreorum excogitare decrevimus. Praeter ostentationem indicum "calidorum" processuum operationum horreorum, novum systema etiam curatoribus auxilium ferre debet in incidentiis notandis et progressu operum observandis, ut causae quae indices destinatos afficiunt tollantur. Postquam generalem recognitionem architecturae IT societatis peractam est, intelleximus quasdam partes systematis requisiti iam in nostro ambitu exstare, et peritiam configurationis et necessaria officia auxiliaria praesto esse. Reliquum erat totum conceptum in unam solutionem architecturae consolidare et ambitum progressionis aestimare.

Postquam amplitudinem operis ad novum systema construendum requisiti aestimata est, statutum est opus in plures partes dividere:

1. Collectio indicatorum processus horrei, visualisatio et moderatio indicatorum et deviationum
2. Automatio normarum processuum et registratio petitionum in sectione servitiorum negotialium de deviationibus.
3. Monitorium proactivum cum praedictione oneris et creatione commendationum pro administratoribus.

In primo gradu, systema debet imagines praeparatas datorum operationum ex omnibus systematibus WMS (Systema Administrationis Domus) in complexo colligere. Lectio fit fere tempore reali (intervallis minus quam quinque minutorum). Ars est quod data ex Systemate Administrationis Domus (DBMS) plurium decenarum horreorum extrahi debent cum systema per totam retem distribuitur. Data operationum accepta a logica principali systematis tractantur ut deviationes ab indicatoribus designatis calculentur et statistica generentur. Data tractata in tabula computatrali moderatoris vel in tabula informationis horrei sub forma graphorum et diagrammatum perspicuorum exhiberi debent.

Cum systema idoneum pro primo gradu implementationis experimentalis eligendum est, Zabbix elegimus. Hoc systema iam ad monitorandas mensuras IT systematum horreorum adhibetur. Addendo installationem separatam ad colligendas mensuras negotiales horreorum, imaginem generalem sanitatis horreorum consequi possumus.

Architectura generalis systematis ut in figura demonstratur evenit.

Quaeque instantia WMS ut hospes systematis monitorii designatur. Metrica a servo centrali in reti centri datorum colliguntur per scriptum cum interrogatione SQL praeparata exsecutum. Si systema monitorium est quod accessum directum ad basim datorum non praebet (e.g., SAP EWM), metrica recuperari possunt per invocationes scriptorum ad functiones API documentatas vel per scribendum simplicem programma Python/VBAScript.

Instantia procuratoris Zabbix in reti horrei collocatur ad onus a servo principali distribuendum. Procurator aditum ad omnes instantias WMS locales praebet. Quotiescumque servus Zabbix parametra petit, scriptum in computatro procuratorem Zabbix currens exsequitur ad mensuras ex basi datorum WMS recuperandas.

Ad graphica et indices horrei in centrali exhibendos server Grafana in Zabbix adhibemus. Praeter tabulas instrumentorum praeparatas cum infographiis effectuum horrei ostendendas, Grafana ad deviationes metricas monitorandas et admonitiones automaticas ad systema servitii horrei mittendas ad administrationem incidentium negotialium adhibebitur.

Exempli gratia, consideremus institutionem moderationis oneris in area receptionis horrei. Haec selecta sunt ut indices clavis perfunctionis pro processibus in hac area horrei:

• numerus vehiculorum in area receptionis, habita ratione statuum (constitutorum, adventorum, documentorum, exonerationis, discessus);
• onus laboris zonarum collocationis et supplementi (secundum condiciones repositionis).

occasus

Installatio et configuratio principalium partium systematis (SQLcl, Zabbix, Grafana) in variis fontibus describuntur et hic non iterabuntur. Usus SQLcl loco SQLplus fit quia SQLcl (interfacies lineae mandatorum Oracle DBMS, scripta lingua Java) non requirit installationem additam Oracle Client et statim operatur.

Puncta principalia consideranda cum Zabbix ad monitorandas mensuras processuum negotialium horreorum adhibetur, necnon unam possibilem methodum implementationis describam. Haec scriptio non de securitate agit. Securitas connexionis et usus methodorum praesentatarum ulteriorem considerationem requirunt dum solutio experimentalis ad productionem transit.

Praecipuum est, cum tale systema instituitur, sine programmatione agere posse, optionibus a systemate provisis utendo.

Systema monitorium Zabbix plures optiones offert ad mensuras ex systemate monitorio colligendas. Hoc fieri potest vel per interrogationem directam machinarum monitoriarum vel per modum provectiorem mittendi notitias ad servitorem per zabbix_sender machinae, inter quas modos ad configurandos parametros inventionis humilis gradus. Interrogatio directa machinarum a servo centrali facta solutio apta est pro nostro opere, cum potestatem plenam super seriem collectionis mensurarum permittit et usum unius fasciculi configurationis/scripturae sine necessitate distribuendi eas ad singulas machinas monitorias curat.

Quasi "caviae" ad systema corrigendum et configurandum, schedas WMS ad administrationem acceptationis utimur:

1. Vehicula in receptione, omnia quae advenerunt: Omnia vehicula cum statu pro periodo "- 72 horae ab tempore currenti" - Identificator interrogationis SQL: AccipeAutos.
2. Historia omnium statuum vehiculorum: Status omnium vehiculorum cum advenis intra horas 72 — Identificator interrogationis SQL: historia curruum.
3. Vehicula ad acceptationem designata: Status omnium vehiculorum cum statu adventus "Designatum", intervallo temporis "- horae 24" et "+ horae 24" a tempore currenti - identificator interrogationis SQL: autocineta.

Postquam igitur mensuras effectuum horrei constituimus, interrogationes SQL pro basi datorum WMS paremus. Optimum est exemplar "calidum" — subsidiarium — ad interrogationes exsequendas uti, potius quam basi datorum principali.

Coniunctio ad DBMS Oracle subsidiarium ad notitias recuperandas. Inscriptio IP ad connexionem ad basim datorum probationis. 192.168.1.106Parametros connexionis servamus in server Zabbix in TNSNames.ORA directorii operantis 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)
    )
  )

Hoc nobis permittet ut interrogationes SQL ad singulos hospites per EZconnect exsequamur, tantum inscriptionem/tesseram et nomen basis datorum specificando:

# sql znew/Zabmon1@WH1_1

Quaestiones SQL paratas in fasciculo laboris in servo Zabbix servamus:

/etc/zabbix/sql

et aditum usori zabbix in servo nostro permitte:

# chown zabbix:zabbix -R /etc/zabbix/sql

Fasciculis interrogationum nomen/identificatorium unicum a servo Zabbix assignatur ad referentiam. Quaeque interrogatio basis datorum per SQLcl plures parametros reddit. Data natura specifica Zabbix, quae tantum unum metricum per interrogationem tractare potest, scripta addita utemur ad eventus interrogationum in singula metrica resolvendos.

Scriptum principale, quod "wh_Metrics.sh" appellabimus, parabimus ut interrogationem SQL ad basim datorum evocet, eventus servet, et metricam technicam, quae successum recuperationis datorum indicat, reddat:

#!/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

Fasciculum perfectum cum scripto in fasciculo ad scripta externa servanda colloca secundum configurationem Zabbix-proxy (praedefinite - `/usr/local/share/zabbix/externalscripts`).

Identificator basis datorum, ex quo scriptum eventus recuperabit, ut parametrus scripti transmittetur. Identificator basis datorum cum serie configurationum in fasciculo TNSNames.ORA congruere debet.

Exitus vocationis interrogationis SQL in fasciculo huius generis servatur: `mon_base_id_main.log` ubi `base_id` = ` Identificator basis datorum ut parametrum scripti acceptus. Divisio fasciculi eventuum per identificatores basis datorum praebetur pro interrogationibus simul factis a servo ad plures basis datorum. Interrogatio seriem valorum bidimensionalem ordinatam reddit.

Hoc scriptum, quod `getMetrica.sh` nominemus, requiritur ad mensuram datam ex fasciculo qui exitum quaestionis continet obtinendam:

#!/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

Nunc parati sumus Zabbix configurare et mensuras processus receptionis horrei monitorare.

In unoquoque nodo basis datorum, agens Zabbix installatur et configuratur.

In servo principali, omnes servores cum procuratoribus Zabbix definimus. Ad eos configurandos, hanc viam sequere:

Administratio → Procurator → Crea procuratorem

Hospites moderatos definimus:

Optiones → Hospites Retiales → Hospitem Retiale Crea

Nomen hospitis nomini nodi in fasciculo configurationis agentis specificato congruere debet.

Gregem nodi, necnon inscriptionem IP vel nomen DNS nodi cum basi datorum, specificamus.

Metricas creamus et earum proprietates specificamus:

Optiones → Nodi → nomen nodi → Elementa Datorum>Creare Elementum Datorum

1) Mensuram principalem crea ut omnes parametros ex basi datorum perscrutetur.

Nomen elemento datorum specificamus et genus "Validationis Externae" eligimus. In agro "Clavis", scriptum definimus cui nomen basis datorum Oracle, nomen interrogationis SQL, et nomen usoris ac tesserae ad connexionem cum basi datorum ut parametros tradimus. Intervallum renovationis interrogationis ad quinque minuta (trecentos secundos) statuimus.

2) Reliquas mensuras pro singulis statubus vehiculi crea. Valores harum mensurarum ex eventibus primae probationis mensurae generabuntur.

Nomen elementi datorum specificamus et genus "Validationis Externae" eligimus. In agro "Clavis", scriptum definimus cui nomen basis datorum Oracle et codicem status quem sequi volumus ut parametros tradimus. Intervallum renovationis interrogationis ad decem secundas maius quam mensura primaria (trecentis decem secundis) statuimus ut tempus detur quo eventus in fasciculum scribantur.

Ad accuratam recuperationem metricorum, ordo quo probationes activantur magni momenti est. Ne conflictus in recuperatione datorum oriantur, primum metricam primariam GetCarsByStatus activamus per scriptum wh_Metrics.sh vocandum.

Optiones → Nodi → 'nomen nodi' → Elementa Datorum → Subfiltrum "Scrutationes Externae." Scrutationem desideratam elige et "Activa" preme.

Deinde, reliquas mensuras una operatione activamus, omnes simul eligentes:

Nunc Zabbix mensuras negotiorum horreorum colligere coepit.

In sequentibus articulis, propius inspiciemus quomodo Grafana conectere et tabulas instrumentorum horrei creare pro variis categoriis usorum. Grafana etiam permittit monitorationem deviationum horrei et, pro limitibus et frequentia deviationis, incidentias in systemate centri servitii horrei per API vel simpliciter notificationes electronicas ad administratorem mittere.

Source: www.habr.com