X5 mengoperasikan 43 pusat distribusi dan 4 truk miliknya, memastikan pasokan produk tidak terputus ke 029 toko. Pada artikel ini saya akan berbagi pengalaman saya membuat sistem interaktif untuk memantau kejadian gudang dari awal. Informasi ini akan berguna bagi ahli logistik perusahaan perdagangan dengan beberapa lusin pusat distribusi yang mengelola berbagai macam produk.
Biasanya, pembangunan sistem pemantauan dan manajemen proses bisnis dimulai dengan pemrosesan pesan dan insiden. Pada saat yang sama, poin teknologi penting yang terkait dengan kemungkinan mengotomatiskan fakta terjadinya peristiwa bisnis dan mencatat insiden telah terlewatkan. Sebagian besar sistem bisnis seperti WMS, TMS, dll., memiliki alat bawaan untuk memantau prosesnya sendiri. Namun, jika ini adalah sistem dari produsen berbeda atau fungsi pemantauan tidak cukup berkembang, Anda harus memesan modifikasi yang mahal atau melibatkan konsultan khusus untuk pengaturan tambahan.
Mari kita pertimbangkan suatu pendekatan di mana kita hanya memerlukan sebagian kecil konsultasi yang terkait dengan identifikasi sumber (tabel) untuk memperoleh indikator dari sistem.
Kekhasan gudang kami adalah beberapa sistem manajemen gudang (WMS Exceed) beroperasi di satu kompleks logistik. Gudang dibagi menurut kategori penyimpanan barang (kering, alkohol, beku, dll) tidak hanya secara logika. Dalam satu kompleks logistik terdapat beberapa bangunan gudang terpisah yang masing-masing dikelola oleh WMS sendiri-sendiri.
Untuk membentuk gambaran umum tentang proses yang terjadi di gudang, manajer menganalisis pelaporan setiap WMS beberapa kali sehari, memproses pesan dari operator gudang (penerima, pemetik, penumpuk) dan merangkum indikator operasional aktual untuk dipantulkan di papan informasi.
Untuk menghemat waktu manajer, kami memutuskan untuk mengembangkan sistem yang murah untuk pengendalian operasional kejadian gudang. Sistem baru ini, selain menampilkan indikator “panas” dari kinerja operasional proses gudang, juga harus membantu manajer dalam mencatat insiden dan memantau pelaksanaan tugas untuk menghilangkan penyebab yang mempengaruhi indikator yang diberikan. Setelah melakukan audit umum terhadap arsitektur TI perusahaan, kami menyadari bahwa masing-masing bagian dari sistem yang diperlukan sudah ada dalam satu atau lain cara di lanskap kami dan untuk bagian tersebut terdapat pemeriksaan pengaturan dan layanan dukungan yang diperlukan. Yang tersisa hanyalah membawa seluruh konsep ke dalam satu solusi arsitektur dan memperkirakan ruang lingkup pembangunan.
Setelah menilai jumlah pekerjaan yang perlu dilakukan untuk membangun sistem baru, diputuskan untuk membagi proyek menjadi beberapa tahap:
- Pengumpulan indikator untuk proses gudang, visualisasi dan pengendalian indikator dan penyimpangan
- Otomatisasi standar proses dan pendaftaran aplikasi di layanan layanan bisnis untuk penyimpangan
- Pemantauan proaktif dengan perkiraan beban dan pembuatan rekomendasi untuk manajer.
Pada tahap pertama, sistem harus mengumpulkan potongan data operasional yang telah disiapkan dari semua WMS di kompleks. Membaca terjadi hampir secara real time (interval kurang dari 5 menit). Caranya adalah data harus diperoleh dari DBMS beberapa lusin gudang saat menyebarkan sistem ke seluruh jaringan. Data operasional yang diterima diproses oleh logika inti sistem untuk menghitung penyimpangan dari indikator yang direncanakan dan menghitung statistik. Data yang diproses dengan cara ini harus ditampilkan di tablet pengelola atau di papan informasi gudang dalam bentuk grafik dan diagram yang mudah dipahami.
Saat memilih sistem yang cocok untuk implementasi percontohan tahap pertama, kami memilih Zabbix. Sistem ini sudah digunakan untuk memantau kinerja TI sistem gudang. Dengan menambahkan instalasi terpisah untuk mengumpulkan metrik bisnis pengoperasian gudang, Anda bisa mendapatkan gambaran keseluruhan tentang kesehatan gudang.
Arsitektur umum sistem tampak seperti pada gambar.
Setiap instance WMS didefinisikan sebagai host untuk sistem pemantauan. Metrik dikumpulkan oleh server pusat di jaringan pusat data dengan menjalankan skrip dengan kueri SQL yang telah disiapkan. Jika Anda perlu memantau sistem yang tidak merekomendasikan akses langsung ke database (misalnya, SAP EWM), Anda dapat menggunakan panggilan skrip ke fungsi API yang terdokumentasi untuk mendapatkan indikator atau menulis program sederhana dengan python/vbascript.
Mesin virtual proksi Zabbix dikerahkan di jaringan gudang untuk mendistribusikan beban dari server utama. Melalui Proxy, pekerjaan dengan semua instance WMS lokal dipastikan. Saat berikutnya server Zabbix meminta parameter, skrip dijalankan pada host dengan proksi Zabbix untuk meminta metrik dari database WMS.
Untuk menampilkan grafik dan indikator gudang di server pusat Zabbix, kami menerapkan Grafana. Selain menampilkan dasbor yang telah disiapkan dengan infografis pengoperasian gudang, Grafana akan digunakan untuk memantau penyimpangan indikator dan mengirimkan peringatan otomatis ke sistem layanan gudang untuk menangani insiden bisnis.
Sebagai contoh, mari kita perhatikan penerapan pengendalian beban di area penerimaan gudang. Berikut ini dipilih sebagai indikator utama kinerja proses di area gudang ini:
- jumlah kendaraan di area penerimaan, dengan mempertimbangkan status (direncanakan, tiba, dokumen, bongkar, keberangkatan;
- beban kerja area penempatan dan pengisian ulang (sesuai dengan kondisi penyimpanan).
Pengaturan
Instalasi dan konfigurasi komponen utama sistem (SQLcl, Zabbix, Grafana) dijelaskan di berbagai sumber dan tidak akan diulangi di sini. Penggunaan SQLcl alih-alih SQLplus disebabkan oleh fakta bahwa SQLcl (antarmuka baris perintah Oracle DBMS, ditulis dalam java) tidak memerlukan instalasi tambahan dari Klien Oracle dan langsung berfungsi.
Saya akan menjelaskan poin-poin utama yang harus diperhatikan ketika menggunakan Zabbix untuk memantau indikator proses bisnis gudang, dan salah satu cara yang mungkin untuk mengimplementasikannya. Selain itu, ini bukan postingan tentang keamanan. Keamanan koneksi dan penggunaan metode yang disajikan memerlukan studi tambahan dalam proses mentransfer solusi percontohan ke dalam operasi produktif.
Hal utama adalah ketika mengimplementasikan sistem seperti itu, Anda dapat melakukannya tanpa pemrograman, menggunakan pengaturan yang disediakan oleh sistem.
Sistem pemantauan Zabbix menyediakan beberapa opsi untuk mengumpulkan metrik dari sistem yang dipantau. Hal ini dapat dilakukan baik dengan melakukan polling langsung pada host yang dipantau, atau dengan metode yang lebih canggih yaitu mengirimkan data ke server melalui zabbix_sender host, termasuk metode untuk mengonfigurasi parameter penemuan tingkat rendah. Untuk mengatasi masalah kita, metode polling langsung host oleh server pusat cukup cocok, karena ini memungkinkan Anda mendapatkan kontrol penuh atas urutan perolehan metrik dan memastikan bahwa Anda menggunakan satu set pengaturan/skrip tanpa perlu mendistribusikannya ke setiap host yang dipantau.
Sebagai "subjek uji" untuk debugging dan pengaturan sistem, kami menggunakan lembar kerja WMS untuk manajemen penerimaan:
- Kendaraan di resepsi, semua yang telah tiba: Semua kendaraan dengan status untuk periode “- 72 jam dari waktu sekarang” - Pengidentifikasi kueri SQL: dapatkan Mobil.
- Riwayat semua status kendaraan: Status semua kendaraan yang tiba dalam waktu 72 jam - Pengidentifikasi kueri SQL: sejarah mobil.
- Kendaraan terjadwal untuk penerimaan: Status semua kendaraan dengan kedatangan dalam status "Dijadwalkan", interval waktu "- 24 jam" dan "+24 jam" dari waktu saat ini - Pengidentifikasi kueri SQL: mobilDalam.
Jadi, setelah kami memutuskan serangkaian metrik kinerja gudang, kami akan menyiapkan kueri SQL untuk database WMS. Untuk mengeksekusi kueri, disarankan untuk tidak menggunakan database utama, tetapi salinan "panas" - siaga.
Kami terhubung ke Oracle DBMS siaga untuk menerima data. Alamat IP untuk menghubungkan ke database pengujian 192.168.1.106. Kami menyimpan parameter koneksi di server Zabbix di TNSNames.ORA dari folder kerja 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)
)
)Ini akan memungkinkan kita untuk menjalankan query SQL ke setiap host melalui EZconnect, hanya menentukan login/kata sandi dan nama database:
# sql znew/Zabmon1@WH1_1Kami menyimpan kueri SQL yang telah disiapkan di folder kerja di server Zabbix:
/etc/zabbix/sqldan izinkan akses ke pengguna zabbix di server kami:
# chown zabbix:zabbix -R /etc/zabbix/sqlFile dengan permintaan menerima nama pengenal unik untuk akses dari server Zabbix. Setiap kueri basis data melalui SQLcl mengembalikan beberapa parameter kepada kita. Dengan mempertimbangkan spesifikasi Zabbix, yang hanya dapat memproses satu metrik per permintaan, kami akan menggunakan skrip tambahan untuk menguraikan hasil kueri ke dalam metrik individual.
Mari kita siapkan skrip utama, sebut saja wh_Metrics.sh, untuk memanggil query SQL ke database, menyimpan hasilnya dan mengembalikan metrik teknis dengan indikator keberhasilan pengambilan data:
#!/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
fiKami menempatkan file yang sudah jadi dengan skrip di folder untuk menyimpan skrip eksternal sesuai dengan pengaturan konfigurasi Zabbix-proxy (secara default - /usr/local/share/zabbix/externalscripts).
Identifikasi database tempat skrip akan menerima hasil akan diteruskan sebagai parameter skrip. ID database harus sesuai dengan baris pengaturan di file TNSNames.ORA.
Hasil dari panggilan query SQL disimpan dalam file seperti mon_base_id_main.log dimana base_id = Pengidentifikasi database diterima sebagai parameter skrip. Pembagian file hasil berdasarkan pengidentifikasi database disediakan jika ada permintaan dari server ke beberapa database secara bersamaan. Kueri mengembalikan array nilai dua dimensi yang diurutkan.
Skrip berikut, sebut saja getMetrica.sh, diperlukan untuk mendapatkan metrik tertentu dari file dengan hasil permintaan:
#!/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
doneSekarang kami siap untuk mengkonfigurasi Zabbix dan mulai memantau indikator proses penerimaan gudang.
Agen Zabbix diinstal dan dikonfigurasi pada setiap node database.
Di server utama kami mendefinisikan semua server dengan proxy Zabbix. Untuk pengaturan, buka jalur berikut:
Administrasi → Proksi → Buat proksi
Kami mendefinisikan host yang dikontrol:
Pengaturan → Host → Buat host
Nama host harus cocok dengan nama host yang ditentukan dalam file konfigurasi agen.
Kami menentukan grup untuk node tersebut, serta alamat IP atau nama DNS dari node dengan database.
Kami membuat metrik dan menentukan propertinya:
Pengaturan → Node → 'nama simpul' → Item Data>Buat Item Data
1) Buat metrik utama untuk menanyakan semua parameter dari database
Kami menetapkan nama elemen data, menunjukkan jenis "Verifikasi eksternal". Di bidang "Kunci", kami mendefinisikan skrip yang kami lewati sebagai parameter nama database Oracle, nama kueri sql, login dan kata sandi untuk menghubungkan ke database. Atur interval pembaruan kueri menjadi 5 menit (300 detik).
2) Buat metrik yang tersisa untuk setiap status kendaraan. Nilai-nilai metrik ini akan dihasilkan berdasarkan hasil pemeriksaan metrik utama.
Kami menetapkan nama elemen data, menunjukkan jenis "Verifikasi eksternal". Di bidang "Kunci", kami mendefinisikan skrip yang kami lewati sebagai parameter nama database Oracle dan kode status yang nilainya ingin kami lacak. Kami menyetel interval pembaruan kueri menjadi 10 detik lebih lama dari metrik utama (310 detik) sehingga hasilnya memiliki waktu untuk ditulis ke file.
Untuk mendapatkan metrik dengan benar, urutan pengaktifan pemeriksaan adalah penting. Untuk menghindari konflik saat menerima data, pertama-tama kita aktifkan metrik utama GetCarsByStatus dengan memanggil skrip - wh_Metrics.sh.
Pengaturan → Node → 'nama node' → Elemen data → Subfilter “Pemeriksaan eksternal”. Tandai tanda centang yang diperlukan dan klik "Aktifkan".
Selanjutnya, kami mengaktifkan metrik yang tersisa dalam satu operasi, memilih semuanya:
Kini Zabbix sudah mulai mengumpulkan metrik bisnis gudang.
Pada artikel berikut, kita akan melihat lebih dekat cara menghubungkan Grafana dan membuat dasbor informasi pengoperasian gudang untuk berbagai kategori pengguna. Grafana juga digunakan untuk memantau penyimpangan dalam operasi gudang dan, tergantung pada batasan dan frekuensi penyimpangan, mencatat insiden dalam sistem pusat layanan manajemen gudang melalui API atau cukup mengirimkan pemberitahuan ke manajer melalui email.
Sumber: www.habr.com