Tentukan objek VPN sebelum memilih SNMP atau API

Tiga keputusan mendahului transportasi: objek apa yang dijelaskan peringatan, arah dan cakupan mana yang dicakupnya, dan seberapa baru pembacaan harus ada. SNMP, API HTTPS, dan probe aplikasi semuanya dapat melaporkan sesuatu tentang VPN, dan mereka tidak akan melaporkan hal yang sama. Mengganti protokol tanpa menyelesaikan ketiganya hanya mengubah tempat kebingungan dikumpulkan. Objek dan makna peringatan adalah desain; protokol adalah pengiriman.

Dasbor yang mengubah empat pengamatan berbeda menjadi satu ikon hijau sudah membuat keputusan itu dengan buruk.

Apa yang seharusnya benar-benar berarti dari peringatan itu?

Itu bisa berarti rekan tidak dapat mengautentikasi, tidak ada status data terlindungi, rute menunjuk ke tempat yang salah, atau aplikasi tidak dapat menyelesaikan pekerjaannya. Masing-masing memiliki pemiliknya sendiri, pemeriksaan pertamanya sendiri dan tingkat positif palsunya sendiri. Rekan yang tidak dapat mengautentikasi adalah masalah identitas, asosiasi keamanan yang hilang adalah masalah status protokol, rute adalah masalah konfigurasi, dan kegagalan aplikasi mungkin bukan salah satu dari itu. Putuskan untuk yang mana peringatan itu sebelum memilih kolektor.

Tulis sebagai kalimat yang dapat ditindaklanjuti oleh insinyur jaga. Jika kalimat itu membutuhkan dua objek, itu dua peringatan, bukan satu yang setengah benar.

Tabel TCP menjelaskan TCP

RFC 4022 menetapkan tcpConnectionTable, yang barisnya menjelaskan koneksi TCP yang terbentuk, dikunci berdasarkan jenis alamat, alamat, dan porta di kedua ujung. Baris hilang saat koneksi ditutup, dan soket mendengarkan muncul di tabel lain. Menjalankan VPN di kotak yang sama tidak mengubah tabel TCP menjadi inventaris asosiasi keamanan IPsec. Tabel itu mungkin menjelaskan sesi manajemen, aliran aplikasi, atau terowongan yang dibawa melalui TCP, dan barisnya sendiri tidak akan memberi tahu Anda yang mana.

Penghitung antarmuka membawa ambiguitas yang sama pada tingkat yang lebih kasar: byte pada antarmuka mengagregasi setiap rekan dan setiap aliran yang menggunakannya.

Bangun kontrak pengamatan kecil

Untuk setiap metrik, catat objek atau bidang API yang didukung, perangkat dan versi perangkat lunak pemiliknya, pengenal rekan atau layanan, arah, waktu pengumpulan, dan perilaku penyegaran yang diharapkan. Lalu gunakan tampilan asosiasi atau sesi gateway yang terdokumentasi untuk status protokol, tabel perutean untuk status jalur, dan permintaan sempit yang diizinkan untuk status aplikasi. Titik akhir manajemen yang berfungsi membuktikan bahwa titik akhir manajemen berfungsi, dan tidak ada apa pun tentang aplikasi di belakangnya.

Jika agen yang terpasang tidak memiliki objek yang diperlukan, pilih antarmuka hanya-baca lain yang didukung secara eksplisit. Menciptakan OID, membaca hitungan TCP generik sebagai hitungan terowongan, atau mengharapkan API vendor lama bertahan tanpa perubahan di produk saudara semuanya jalan buntu.

Data basi bukan kegagalan terowongan

Batas waktu pengumpulan, kredensial kedaluwarsa, atau jalur API yang berubah menghasilkan telemetri yang hilang. Itu adalah kegagalan pemantauan dan insiden yang berbeda dari terowongan yang putus. Catat pengamatan mana yang menjadi basi dan kapan, sehingga operator mendapat pemeriksaan pertama yang bermakna alih-alih pengaturan ulang terowongan. Memperlakukan setiap batas waktu sebagai gangguan VPN melatih orang untuk mengabaikan keduanya.

Jaga izin pengumpulan tetap sempit juga. Antarmuka yang dapat mengubah konfigurasi atau menghapus sesi membawa batas hak istimewa yang tidak boleh diwarisi oleh pekerjaan pemantauan, dan akun hanya-baca biasanya cukup.

Desain yang berguna menyebutkan objek, makna, dan persyaratan kebaruan. Pilihan protokol mengikuti dari itu, bukan sebaliknya.