SNMP və ya API seçməzdən əvvəl VPN obyektini müəyyənləşdirin

Nəqldən əvvəl üç qərar gəlir: xəbərdarlığın hansı obyekti təsvir etdiyi, hansı istiqaməti və əhatəni tutduğu və oxunuşun nə qədər təzə olmalı olduğu. SNMP, HTTPS API və tətbiq zondları hamısı VPN haqqında bir şey bildirə bilər və eyni şeyi bildirməyəcəklər. Bu üçünü həll etmədən protokolları dəyişmək yalnız çaşqınlığın harada toplandığını dəyişir. Obyekt və xəbərdarlığın mənası dizayndır; protokol isə çatdırılmadır.

Dörd fərqli müşahidəni bir yaşıl ikona çevirən panel artıq bu qərarı pis verib.

Xəbərdarlıq əslində nə deməli?

Bu, həmkarın autentifikasiya edə bilməməsi, qorunan məlumat vəziyyətinin olmaması, marşrutun yanlış yerə işarə etməsi və ya tətbiqin işini bitirə bilməməsi demək ola bilər. Bunların hər birinin öz sahibi, öz ilk yoxlaması və öz yalançı-müsbət dərəcəsi var. Autentifikasiya edə bilməyən həmkar kimlik problemidir, itkin təhlükəsizlik assosiasiyası protokol vəziyyəti problemidir, marşrut konfiqurasiya problemidir, tətbiq nasazlığı isə bunların heç biri ola bilməz. Kollektor seçməzdən əvvəl xəbərdarlığın hansına aid olduğunu qərar verin.

Onu növbətçi mühəndisin hərəkət edə biləcəyi bir cümlə kimi yazın. Cümlə iki obyekt tələb edirsə, bu iki xəbərdarlıqdır, yarım-düzgün bir xəbərdarlıq deyil.

TCP cədvəli TCP-ni təsvir edir

RFC 4022 tcpConnectionTable spesifikasiya edir; onun sətirləri qurulmuş TCP bağlantılarını təsvir edir və hər iki tərəfdə ünvan növü, ünvan və portla açarlanır. Bağlantı bağlandıqda sətirlər yox olur, dinləyən soketlər isə başqa cədvəldə görünür. Eyni qutuda VPN işə salmaq TCP cədvəlini IPsec təhlükəsizlik assosiasiyalarının inventarına çevirmir. O, idarəetmə sessiyasını, tətbiq axınını və ya TCP üzərindən daşınan tuneli təsvir edə bilər və sətir özü hansının olduğunu deməyəcək.

İnterfeys sayğacları eyni qeyri-müəyyənliyi daha qaba səviyyədə daşıyır: interfeysdəki baytlar ondan istifadə edən hər həmkarı və hər axını birləşdirir.

Kiçik müşahidə müqaviləsi qurun

Hər metrik üçün dəstəklənən obyekti və ya API sahəsini, sahib cihazı və proqram versiyasını, həmkar və ya xidmət identifikatorunu, istiqaməti, toplama vaxtını və gözlənilən yenilənmə davranışını qeyd edin. Sonra protokol vəziyyəti üçün şlüzün sənədləşdirilmiş assosiasiya və ya sessiya görünüşündən, yol vəziyyəti üçün marşrut cədvəlindən, tətbiq vəziyyəti üçün isə dar icazəli sorğudan istifadə edin. İşləyən idarəetmə son nöqtəsi idarəetmə son nöqtəsinin işlədiyini sübut edir və arxasındakı tətbiq haqqında heç nə demir.

Quraşdırılmış agent tələb olunan obyektlərə malik deyilsə, açıq şəkildə dəstəklənən başqa yalnız-oxuma interfeysi seçin. OID uydurmaq, ümumi TCP sayını tunel sayı kimi oxumaq və ya köhnə satıcı API-nin qardaş məhsulda dəyişməz qalacağını gözləmək hamısı çıxılmaz yollardır.

Köhnəlmiş məlumat tunel nasazlığı deyil

Toplama vaxt aşımı, vaxtı keçmiş etimadnamə və ya dəyişmiş API yolu itkin telemetriya yaradır. Bu, monitorinq nasazlığıdır və düşmüş tuneldən fərqli hadisədir. Hansı müşahidənin nə vaxt köhnəldiyini qeyd edin ki, operator tunelin sıfırlanması əvəzinə mənalı ilk yoxlama əldə etsin. Hər vaxt aşımını VPN kəsilməsi kimi qəbul etmək insanları hər ikisini görməməzliyə öyrədir.

Toplama icazələrini də dar saxlayın. Konfiqurasiyanı dəyişə bilən və ya sessiyaları təmizləyə bilən interfeys monitorinq işinin miras almamalı olduğu imtiyaz sərhədi daşıyır və yalnız-oxuma hesabı adətən kifayətdir.

Faydalı dizayn obyekti, mənanı və təzəlik tələbini adlandırır. Protokol seçimi bunlardan irəli gəlir, tərsinə deyil.