Sistem berbasis peristiwa protokol manajemen jaringan bekerja sangat berbeda untuk sistem berbasis permintaan.
Dalam sistem berbasis peristiwa apa pun, sistem manajemen jaringan hanya mendengarkan pengumuman atau acara
yang mungkin dikirim melalui telepon.
Biasanya protokol manajemen jaringan yang memanfaatkan jenis peristiwa ini berbasis
log atau berbasis-perangkap.
Sekarang mereka dapat dikontrol dalam hal jumlah detail yang Anda terima dari perangkat di jaringan Anda.
Jadi sebagai contoh pada Cisco Rodda Anda dapat mengaktifkan debugging yang menghasilkan sejumlah besar data.
Ada banyak detail level rendah yang dihasilkan dengan debugging.
Anda mungkin tidak ingin jumlah data itu didorong ke sistem manajemen jaringan Anda.
Salah satu masalah di sini adalah jika Anda menerima sejumlah besar data yang akan menyaring
data untuk membuat keputusan yang berarti pada data yang diterima.
Jadi Anda tidak ingin itu hanya mengaktifkan banyak informasi berbasis acara yang sama untuk membantu melihat-lihat salah
satu keuntungan dari sistem berbasis acara adalah bahwa mereka dapat bereaksi dengan sangat cepat.
Dengan kata lain, jika suatu peristiwa terjadi di jaringan, sistem manajemen jaringan dapat
bertindak pada peristiwa itu dengan segera daripada menunggu jajak pendapat berakhir.
Sebagai contoh jika Anda melakukan polling antarmuka router untuk statusnya setiap lima menit maka Anda
akan tahu bahwa antarmuka akan muncul setiap kali polling dilakukan atau permintaan dilakukan dalam sistem berbasis permintaan.
Tetapi jika antarmuka turun tepat setelah Anda polling, mungkin diperlukan lima menit bagi
Anda untuk menyadari bahwa antarmuka turun ketika sistem manajemen jaringan Anda menarik router setiap lima
menit.
Ini akan menerima kembali respons positif dari Rodda yang mengonfirmasi bahwa antarmuka adalah sebagai contoh.
Itu biasanya dilakukan dengan menggunakan protokol manajemen jaringan seperti Ace dan MP.
Jadi Anda tahu antarmuka operasional karena Anda sudah menanyakan router jika Anda tidak mendapatkan respons dari
router maka Anda tahu ada masalah.
Tetapi kelemahan dari sistem berbasis permintaan adalah Anda hanya memilihnya setiap lima menit.
Jika antarmuka turun segera setelah Anda menarik router itu bisa memakan waktu hingga lima menit
bagi Anda untuk menyadari bahwa ada masalah pada antarmuka router di mana seperti dalam
sistem berbasis kejadian dan itu adalah pesan log perangkap kosong yang dikirim segera saat antarmuka turun.
Jadi dalam hal ini router menginformasikan sistem manajemen jaringan bahwa ada
masalah daripada sistem manajemen jaringan harus menunggu interval lima menit untuk meminta
Rodda untuk status antarmuka.
Sekarang ada downside ke sistem berbasis acara protokol manajemen jaringan tidak dapat diandalkan
karena sistem manajemen jaringan hanya pasif menunggu dan mendengarkan peristiwa yang akan dikirim ke sana.
Itu tidak akan tahu jika ada masalah pada jaringan jika peristiwa itu tidak mencapai
sistem manajemen jaringan.
Jadi, jika ada masalah jaringan atau kebutuhan untuk menghadap turun yang mencegah pesan
log atau jebakan kosong dari masuk ke sistem manajemen jaringan, sistem manajemen jaringan tidak
akan menyadari masalah tanpa secara eksplisit polling perangkat jaringan.
Jadi apa praktik terbaik apa yang harus Anda lakukan dalam lingkungan hidup bagaimana praktik terbaik
menyatakan bahwa Anda harus menggunakan keduanya, Anda harus menggunakan polling atau queri berbasis serta protokol manajemen jaringan berbasis
peristiwa sebagai bagian dari solusi manajemen jaringan Anda.
Sekarang tidak membantu hanya untuk menerima sejumlah besar data.
Anda perlu membuat keputusan yang berarti tentang data itu.
Jadi, Anda juga ingin membuat huruf tebal dan memanfaatkan lansiran dan laporan sehingga
Anda berdua diberi tahu saat terjadi masalah apakah itu didasarkan pada mekanisme deteksi berbasis polling atau deteksi berbasis peristiwa.
Dan di samping itu, Anda akan menginginkan semacam kemampuan pelaporan yang memberi Anda detail
kinerja tidak hanya dalam waktu nyata.
Pada titik waktu ini tetapi selama periode waktu.
Jadi Anda ingin data historis tersedia sehingga Anda dapat membuat keputusan yang berarti.
Sebagai contoh jika antarmuka pada Rodda memiliki utilisasi 70 persen itu bagus.
Apa itu buruk?
Itu sulit diketahui jika Anda tidak memiliki data historis yang memungkinkan Anda untuk membangun garis dasar dari
apa yang biasanya dijalankan oleh jaringan Anda.
Jika antarmuka dalam tiga bulan terakhir telah berjalan pada utilisasi 2 persen dan sekarang
tiba-tiba berjalan pada utilisasi 90 persen Anda akan tahu bahwa sesuatu telah terjadi pada jaringan Anda
yang telah berubah menjadi pemanfaatan antarmuka secara dramatis.
Jadi, Anda ingin laporan memberikan detail kinerja dari waktu ke waktu serta memberi tahu Anda tentang
masalah dan ketersediaan perangkat di jaringan Anda.
Anda akan ingin melihat apakah ada masalah dengan perangkat jaringan seperti
router atau jika ada masalah dengan antarmuka individual di salah satu router Anda.
Jangan lupa mengatur frekuensi pemungutan suara dan seberapa rinci pemberitahuan acara Anda.
Ini akan bervariasi dari satu lingkungan ke lingkungan lainnya dan seringkali tergantung pada jenis tipologi
bahwa Anda memiliki bandwidth yang tersedia dan sumber daya yang harus Anda deteksi dan kemudian bertindak berdasarkan informasi yang
Anda terima.
Selain itu, Anda mungkin perlu membuat keputusan tentang seberapa cepat Anda perlu bereaksi terhadap suatu masalah
pada jaringan Anda jika sesuatu terjadi pada jaringan Anda dan itu mempengaruhi seluruh bangunan untuk seluruh organisasi yang
ingin Anda tangani dengan cepat.
Tetapi jika sesuatu terjadi dan itu hanya mempengaruhi satu perangkat yang tidak penting, mungkin
tidak sepenting Anda bangun pada jam 3 pagi untuk memberi tahu Anda bahwa port pada sakelar
telah turun.