SNMP किंवा API निवडण्यापूर्वी VPN ऑब्जेक्ट परिभाषित करा

वाहतुकीपूर्वी तीन निर्णय येतात: अलर्ट कोणत्या ऑब्जेक्टचे वर्णन करतो, तो कोणती दिशा आणि व्याप्ती व्यापतो, आणि वाचन किती ताजे असावे। SNMP, HTTPS API आणि ॲप्लिकेशन प्रोब सर्व VPN बद्दल काहीतरी कळवू शकतात, आणि ते एकच गोष्ट कळवणार नाहीत। हे तीन न ठरवता प्रोटोकॉल बदलल्याने गोंधळ कुठे जमा होतो एवढेच बदलते। ऑब्जेक्ट आणि अलर्टचा अर्थ हीच रचना आहे; प्रोटोकॉल वितरण आहे।

चार वेगवेगळ्या निरीक्षणांना एका हिरव्या चिन्हात बदलणाऱ्या डॅशबोर्डने तो निर्णय आधीच वाईटपणे घेतला आहे।

अलर्टचा खरोखर काय अर्थ असावा?

याचा अर्थ असा असू शकतो की एखादा पीअर प्रमाणीकरण करू शकत नाही, संरक्षित डेटा स्थिती नाही, मार्ग चुकीच्या ठिकाणी निर्देश करतो, किंवा ॲप्लिकेशनला त्याचे काम पूर्ण करता येत नाही। यापैकी प्रत्येकाकडे स्वतःचा मालक, स्वतःची पहिली तपासणी आणि स्वतःचा खोटा-सकारात्मक दर आहे। प्रमाणीकरण करू न शकणारा पीअर ओळखीची समस्या आहे, गहाळ सुरक्षा संस्था प्रोटोकॉल-स्थितीची समस्या आहे, मार्ग संरचनेची समस्या आहे, आणि ॲप्लिकेशन अयशस्वीता यापैकी काहीही नसू शकते। संग्राहक निवडण्यापूर्वी अलर्ट कोणासाठी आहे ते ठरवा।

ऑन-कॉल अभियंता त्यावर कार्य करू शकेल अशा वाक्यात ते लिहा। वाक्याला दोन ऑब्जेक्ट आवश्यक असतील तर ते दोन अलर्ट आहेत, अर्धे-बरोबर एक नाही।

TCP तक्ता TCP चे वर्णन करतो

RFC 4022 tcpConnectionTable निर्दिष्ट करते, ज्याच्या ओळी स्थापित TCP कनेक्शनचे वर्णन करतात, दोन्ही टोकांवर पत्त्याचा प्रकार, पत्ता आणि पोर्टने किल्ली केलेल्या। कनेक्शन बंद झाल्यावर ओळी अदृश्य होतात, आणि ऐकणारे सॉकेट वेगळ्या तक्त्यात दिसतात। एकाच बॉक्सवर VPN चालवल्याने TCP तक्ता IPsec सुरक्षा संस्थांची यादी होत नाही। तो व्यवस्थापन सत्र, ॲप्लिकेशन प्रवाह, किंवा TCP वरून नेले जाणारे टनेल वर्णन करू शकतो, आणि ओळ स्वतः कोणते ते सांगणार नाही।

इंटरफेस काउंटर अधिक ढोबळ पातळीवर तीच अस्पष्टता बाळगतात: इंटरफेसवरील बाइट्स त्याचा वापर करणारे प्रत्येक पीअर आणि प्रत्येक प्रवाह एकत्र करतात।

एक छोटा निरीक्षण करार तयार करा

प्रत्येक मेट्रिकसाठी, समर्थित ऑब्जेक्ट किंवा API फील्ड, मालकीचे उपकरण आणि सॉफ्टवेअर आवृत्ती, पीअर किंवा सेवा ओळखकर्ता, दिशा, संग्रह वेळ आणि अपेक्षित रीफ्रेश वर्तन नोंदवा। नंतर प्रोटोकॉल स्थितीसाठी गेटवेचे दस्तऐवजीकृत संस्था किंवा सत्र दृश्य, मार्ग स्थितीसाठी राउटिंग तक्ता, आणि ॲप्लिकेशन स्थितीसाठी अरुंद परवानगी असलेली विनंती वापरा। कार्यरत व्यवस्थापन एंडपॉइंट हे सिद्ध करते की व्यवस्थापन एंडपॉइंट कार्यरत आहे, आणि त्यामागील ॲप्लिकेशनबद्दल काहीही नाही।

जर स्थापित एजंटमध्ये आवश्यक ऑब्जेक्ट नसतील, तर स्पष्टपणे समर्थित दुसरे केवळ-वाचनीय इंटरफेस निवडा। OID तयार करणे, सामान्य TCP संख्या टनेल संख्या म्हणून वाचणे, किंवा जुन्या विक्रेता API सहोदर उत्पादनात अपरिवर्तित राहील अशी अपेक्षा करणे—हे सर्व बंद मार्ग आहेत।

जुना डेटा टनेल अयशस्वीता नाही

संग्रह कालबाह्यता, कालबाह्य झालेली ओळखपत्रे किंवा बदललेला API मार्ग गहाळ टेलिमेट्री निर्माण करतात। ही देखरेख अयशस्वीता आहे आणि पडलेल्या टनेलपेक्षा वेगळी घटना आहे। कोणते निरीक्षण कधी जुने झाले ते नोंदवा, जेणेकरून ऑपरेटरला टनेल रीसेटऐवजी अर्थपूर्ण पहिली तपासणी मिळेल। प्रत्येक कालबाह्यता VPN खंड म्हणून पाहणे लोकांना दोन्हीकडे दुर्लक्ष करायला शिकवते।

संग्रह परवानग्याही संकुचित ठेवा। जो इंटरफेस संरचना बदलू शकतो किंवा सत्रे साफ करू शकतो त्यात अशी विशेषाधिकार सीमा असते जी देखरेख कार्याने वारसा म्हणून घेऊ नये, आणि केवळ-वाचनीय खाते सहसा पुरेसे असते।

उपयुक्त रचना ऑब्जेक्ट, अर्थ आणि ताजेपणाची आवश्यकता नावाने सांगते। प्रोटोकॉलची निवड त्यातून येते, उलट नाही।