X5 mengelola 43 pusat distribusi dan 4.029 truk sendiri, mereka menyediakan pasokan produk tanpa gangguan di 15.752 toko. Dalam artikel ini saya akan berbagi pengalaman membuat dari awal sistem interaktif untuk memantau acara gudang. Informasi ini akan berguna untuk logistik perusahaan dagang dengan puluhan pusat distribusi yang mengelola berbagai macam produk.
Sebagai aturan, konstruksi pemantauan dan sistem manajemen proses bisnis dimulai dengan pemrosesan pesan dan insiden. Pada saat yang sama, momen teknologi penting terlewatkan terkait dengan kemungkinan mengotomatiskan fakta terjadinya peristiwa bisnis dan merekam insiden. Sebagian besar sistem bisnis kelas WMS, TMS, dll., Memiliki alat bawaan untuk memantau proses mereka sendiri. Tetapi, jika ini adalah sistem dari pabrikan yang berbeda atau fungsi pemantauan tidak cukup berkembang, Anda harus memesan perbaikan yang mahal atau melibatkan konsultan khusus untuk pengaturan tambahan.
Pertimbangkan suatu pendekatan di mana kita hanya memerlukan sebagian kecil dari konsultasi terkait dengan penentuan sumber (tabel) untuk mendapatkan indikator dari sistem.
Kekhususan gudang kami terletak pada kenyataan bahwa beberapa sistem manajemen gudang (WMS Exceed) beroperasi pada kompleks logistik yang sama. Gudang dibagi sesuai dengan kategori penyimpanan barang (kering, alkohol, beku, dll.) Tidak hanya secara logis. Dalam satu kompleks logistik adalah beberapa bangunan gudang yang terpisah, operasi pada masing-masing dikelola oleh WMS mereka sendiri.
Untuk membentuk gambaran umum tentang proses yang terjadi di gudang, manajer menganalisis laporan masing-masing WMS beberapa kali sehari, memproses pesan dari operator gudang (penerima, pemetik, penumpuk) dan merangkum indikator operasi aktual untuk ditampilkan di papan informasi.
Untuk menghemat waktu manajer, kami memutuskan untuk mengembangkan sistem yang tidak mahal untuk pengendalian operasional acara gudang. Sistem baru, selain menampilkan indikator "panas" dari pekerjaan operasional proses gudang, juga harus membantu manajer dalam memperbaiki insiden dan tugas pemantauan untuk menghilangkan penyebab yang mempengaruhi indikator yang diberikan. Setelah melakukan audit umum arsitektur TI perusahaan, kami menyadari bahwa bagian-bagian tertentu dari sistem yang diperlukan sudah ada di lanskap kami dan bagi mereka ada pemeriksaan pengaturan dan layanan dukungan yang diperlukan. Tetap hanya untuk mengurangi keseluruhan konsep menjadi solusi arsitektur tunggal dan mengevaluasi ruang lingkup pengembangan.
Setelah menilai jumlah pekerjaan yang perlu dilakukan untuk membangun sistem baru, diputuskan untuk membagi proyek menjadi beberapa tahap:
- Pengumpulan indikator pada proses gudang, visualisasi dan kontrol indikator dan penyimpangan
- Otomatisasi standar proses dan pendaftaran aplikasi dalam layanan layanan bisnis untuk penyimpangan
- Pemantauan proaktif dengan peramalan beban dan membuat rekomendasi kepada manajer.
Pada tahap pertama, sistem harus mengumpulkan potongan data operasional yang disiapkan dari semua kompleks WMS. Membaca berlangsung hampir dalam waktu nyata (interval kurang dari 5 menit). Kuncinya adalah bahwa data harus diperoleh dari DBMS dari beberapa lusin gudang ketika 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 manajer atau di papan informasi gudang dalam bentuk grafik dan diagram yang jelas.
Ketika memilih sistem yang cocok untuk implementasi uji coba tahap pertama, kami memilih Zabbix. Sistem ini sudah digunakan untuk memantau kinerja TI sistem gudang. Dengan menambahkan instalasi terpisah untuk mengumpulkan metrik bisnis untuk operasi gudang, Anda bisa mendapatkan gambaran menyeluruh tentang kesehatan gudang.
Arsitektur umum sistem adalah seperti yang ditunjukkan 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 disiapkan. Jika Anda perlu memantau sistem yang tidak merekomendasikan akses langsung ke database (misalnya, SAP EWM), Anda dapat menggunakan panggilan skrip untuk fungsi API terdokumentasi untuk menulis indikator atau menulis program python / vbascript sederhana.
Proxy Zabbix dikerahkan ke jaringan gudang untuk mendistribusikan beban dari server utama. Melalui Proxy, bekerja dengan semua instance WMS lokal disediakan. Pada permintaan parameter berikutnya oleh server Zabbix di host dengan proksi Zabbix, sebuah skrip dijalankan untuk meminta metrik dari basis data WMS.
Untuk menampilkan grafik dan indikator gudang di server Zabbix pusat, gunakan Grafana. Selain menghasilkan dashboard yang disiapkan dengan infografis gudang, Grafana akan digunakan untuk mengontrol penyimpangan indikator dan mentransfer peringatan otomatis ke sistem layanan gudang untuk bekerja dengan insiden bisnis.
Sebagai contoh, perhatikan penerapan kontrol pemuatan zona penerimaan gudang. Sebagai indikator utama dari proses di bagian gudang yang dipilih:
- jumlah kendaraan di area penerimaan, dengan mempertimbangkan status (direncanakan, tiba, dokumen, bongkar, keberangkatan;
- kemacetan zona penempatan dan pengisian ulang (sesuai dengan kondisi penyimpanan).
Pengaturan
Instalasi dan konfigurasi komponen utama sistem (SQLcl, Zabbix, Grafana) dijelaskan dalam berbagai sumber dan kami tidak akan mengulanginya di sini. Penggunaan SQLcl bukan SQLplus adalah karena fakta bahwa SQLcl (antarmuka baris perintah Oracle DBMS ditulis dalam java) tidak memerlukan instalasi tambahan dari Oracle Client dan bekerja di luar kotak.
Saya akan menjelaskan poin-poin utama yang harus diperhatikan ketika menggunakan Zabbix untuk memantau kinerja proses bisnis gudang, dan salah satu cara yang mungkin untuk mengimplementasikannya. Juga, posting ini bukan tentang keamanan. Keamanan koneksi dan penggunaan metode yang disajikan membutuhkan elaborasi tambahan dalam proses transfer solusi percontohan untuk operasi yang produktif.
Hal utama adalah bahwa ketika mengimplementasikan sistem seperti itu, dimungkinkan untuk dilakukan tanpa pemrograman, menggunakan pengaturan yang disediakan oleh sistem.
Sistem pemantauan Zabbix menyediakan beberapa opsi untuk mengumpulkan metrik dari sistem yang dipantau. Ini dapat dilakukan dengan secara langsung polling host yang dipantau, atau dengan metode pengiriman data yang lebih maju ke server melalui zabbix_sender host, termasuk metode untuk menetapkan parameter penemuan tingkat rendah. Untuk mengatasi masalah kami, metode polling langsung dari host oleh server pusat cukup cocok. ini memungkinkan Anda untuk mendapatkan kontrol penuh atas urutan mendapatkan metrik dan memastikan penggunaan satu paket pengaturan / skrip tanpa perlu mendistribusikannya ke setiap host yang dikendalikan.
Sebagai "eksperimental" untuk debugging dan tuning sistem, kami menggunakan lembar kerja WMS untuk mengontrol penerimaan:
- TS pada penerimaan, semua yang tiba: Semua TS dengan status untuk periode "- 72 jam dari waktu saat ini" - pengidentifikasi permintaan SQL: getCars .
- Sejarah semua status kendaraan: Status semua kendaraan dengan kedatangan 72 jam - Pengidentifikasi kueri SQL: carsHistory .
- Kendaraan terjadwal untuk penerimaan: Status semua kendaraan dengan status "Dijadwalkan", interval waktu " -24 jam" dan "+24 jam" dari waktu saat ini - pengidentifikasi permintaan SQL: carsIn .
Jadi, setelah kami memutuskan satu set metrik gudang, kami akan menyiapkan pertanyaan SQL untuk database WMS. Untuk menjalankan kueri, disarankan untuk tidak menggunakan database utama, tetapi salinan "panas" - siaga.
Kami terhubung ke Oracle DBMS siaga untuk akuisisi data. Alamat IP untuk menghubungkan ke basis uji
192.168.1.106 . Parameter koneksi disimpan di server Zabbix di TNSNames.ORA dari folder SQLcl yang berfungsi:
# 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 kami untuk menjalankan kueri SQL ke setiap host melalui EZconnect, yang hanya menentukan nama pengguna / kata sandi dan basis data:
# sql znew/Zabmon1@WH1_1
Kueri SQL yang disiapkan disimpan di folder yang berfungsi di server Zabbix:
/etc/zabbix/sql
dan memungkinkan akses ke pengguna zabbix dari server kami:
# chown zabbix:zabbix -R /etc/zabbix/sql
File permintaan menerima nama pengenal unik untuk akses dari server Zabbix. Setiap permintaan basis data melalui SQLcl mengembalikan beberapa parameter kepada kami. Dengan adanya spesifikasi Zabbix, yang hanya dapat memproses satu metrik dalam kueri, kami akan menggunakan skrip tambahan untuk mengurai hasil kueri ke dalam metrik individual.
Kami sedang mempersiapkan skrip utama, sebut saja wh_Metrics.sh, untuk memanggil kueri SQL ke basis data, menyimpan hasilnya, dan mengembalikan metrik teknis dengan indikator keberhasilan 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 fi
Kami menempatkan file yang sudah selesai dengan skrip di folder untuk hosting skrip eksternal sesuai dengan pengaturan konfigurasi proxy Zabbix (secara default -
/ usr / lokal / share / zabbix / skrip
eksternal ).
Identifikasi database dari mana skrip akan menerima hasil akan dikirimkan oleh parameter skrip. Pengidentifikasi basis data harus sesuai dengan baris pengaturan dalam file TNSNames.ORA.
Hasil dari permintaan query SQL disimpan dalam file dari bentuk
mon_base_id_main.log, di mana base_id = DB identifier diperoleh sebagai parameter skrip. Pemisahan file hasil oleh pengidentifikasi database disediakan jika ada permintaan dari server secara bersamaan ke beberapa database. Kueri mengembalikan array nilai dua dimensi yang diurutkan.
Skrip berikut, sebut saja getMetrica.sh, diperlukan untuk mendapatkan metrik yang ditentukan 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 done
Sekarang kami siap untuk menyiapkan Zabbix dan mulai memantau kinerja proses penerimaan gudang.
Pada setiap simpul basis data, agen Zabbix diinstal dan dikonfigurasi.
Di server utama, kami mendefinisikan semua server dengan proksi Zabbix. Untuk pengaturan, pergi ke jalur berikut:
Administrasi → Proxy → Buat Proxy
Tentukan host yang dikendalikan:
Pengaturan → Hosts → Buat host
Nama host harus cocok dengan nama host yang ditentukan dalam file konfigurasi agen.
Kami menunjukkan grup untuk node, serta alamat IP atau nama DNS dari node dari database.
Kami membuat metrik dan menentukan propertinya:
Pengaturan → Node →
'nama simpul' → Item data> Buat item data
1) Buat metrik dasar untuk menanyakan semua parameter dari database
Kami menetapkan nama elemen data, menunjukkan jenis "Verifikasi eksternal". Di bidang "Kunci", kami mendefinisikan skrip tempat kami mentransfer nama database Oracle, nama kueri sql, login, dan kata sandi untuk menghubungkan ke database sebagai parameter. Atur interval pembaruan untuk permintaan menjadi 5 menit (300 detik).
2) Buat metrik yang tersisa untuk setiap status kendaraan. Nilai-nilai metrik ini akan dibentuk berdasarkan hasil pemeriksaan metrik utama.
Kami menetapkan nama elemen data, menunjukkan jenis "Verifikasi eksternal". Di bidang "Kunci", kami mendefinisikan skrip tempat kami mentransfer nama database Oracle dan kode status, nilai yang ingin kami lacak sebagai parameter. Kami menetapkan interval pembaruan untuk permintaan 10 detik lebih lama dari metrik utama (310 detik) sehingga hasilnya dapat ditulis ke file.
Untuk mendapatkan metrik dengan benar, urutan pemeriksaan diaktifkan adalah penting. Untuk menghindari konflik saat menerima data, pertama-tama, aktifkan metrik utama GetCarsByStatus dengan panggilan skrip - wh_Metrics.sh.
Pengaturan → Node → 'nama simpul' → Elemen data → Subfilter “Pemeriksaan eksternal”. Kami menandai centang yang diperlukan dan klik "Aktifkan".
Selanjutnya, aktifkan metrik yang tersisa dalam satu operasi, pilih semuanya bersama-sama:
Zabbix kini telah mulai mengumpulkan metrik bisnis gudang.
Dalam artikel berikut, kami akan memeriksa secara lebih terperinci koneksi Grafana dan pembentukan dasbor informasi untuk operasi gudang untuk berbagai kategori pengguna. Grafana juga memantau penyimpangan di gudang dan, tergantung pada batas dan frekuensi penyimpangan, mencatat insiden dalam sistem pusat layanan manajemen gudang melalui API atau hanya mengirim pemberitahuan kepada manajer melalui email.
