SNMP वा API छान्नु अघि VPN वस्तु परिभाषित गर्नुहोस्
TCP जडान तालिका टनेलको सूची होइन। SNMP, API वा प्रोब छान्नु अघि अलर्टलाई चाहिने वस्तु, दिशा र ताजगी परिभाषित गर्नुहोस्।
यातायात अघि तीन निर्णय आउँछन्: अलर्टले कुन वस्तुको वर्णन गर्छ, यसले कुन दिशा र दायरा ढाक्छ, र पढाइ कति ताजा हुनुपर्छ। SNMP, HTTPS API र एप्लिकेसन प्रोब सबैले VPN को बारेमा केही रिपोर्ट गर्न सक्छन्, र तिनीहरू एउटै कुरा रिपोर्ट गर्दैनन्। यी तीन नटुंग्याई प्रोटोकल बदल्नाले अलमल कहाँ जम्मा हुन्छ त्यो मात्र बदलिन्छ। वस्तु र अलर्टको अर्थ नै डिजाइन हो; प्रोटोकल डेलिभरी हो।
चार फरक अवलोकनलाई एउटै हरियो आइकनमा बदल्ने ड्यासबोर्डले त्यो निर्णय पहिले नै नराम्रोसँग गरिसकेको छ।
अलर्टले वास्तवमा के अर्थ दिनुपर्छ?
यसको अर्थ कुनै पीयरले प्रमाणीकरण गर्न नसक्ने, कुनै सुरक्षित डेटा अवस्था नभएको, कुनै मार्ग गलत ठाउँमा सङ्केत गरेको, वा कुनै एप्लिकेसनले आफ्नो काम सक्न नसकेको हुन सक्छ। यीमध्ये प्रत्येकसँग आफ्नै मालिक, आफ्नै पहिलो जाँच र आफ्नै झुटो-सकारात्मक दर छ। प्रमाणीकरण गर्न नसक्ने पीयर पहिचानको समस्या हो, हराएको सुरक्षा संघ प्रोटोकल-अवस्थाको समस्या हो, मार्ग कन्फिगरेसनको समस्या हो, र एप्लिकेसन असफलता तीमध्ये कुनै पनि नहुन सक्छ। सङ्कलक छान्नु अघि अलर्ट कुनको लागि हो निर्णय गर्नुहोस्।
यसलाई अन-कल इन्जिनियरले काम गर्न सक्ने वाक्यका रूपमा लेख्नुहोस्। यदि वाक्यलाई दुई वस्तु चाहिन्छ भने ती दुई अलर्ट हुन्, आधा-सही एउटा होइन।
TCP तालिकाले TCP को वर्णन गर्छ
RFC 4022 tcpConnectionTable निर्दिष्ट गर्छ, जसका पङ्क्तिहरू स्थापित TCP जडानहरूको वर्णन गर्छन्, दुवै छेउमा ठेगानाको प्रकार, ठेगाना र पोर्टले कुञ्जी गरिएका। जडान बन्द हुँदा पङ्क्तिहरू हराउँछन्, र सुन्ने सकेटहरू अर्को तालिकामा देखा पर्छन्। एउटै बक्समा VPN चलाउनाले TCP तालिका IPsec सुरक्षा संघहरूको सूची बन्दैन। यसले व्यवस्थापन सत्र, एप्लिकेसन प्रवाह, वा TCP माथि बोकिएको टनेल वर्णन गर्न सक्छ, र पङ्क्ति आफैंले कुन हो भनेर बताउँदैन।
इन्टरफेस काउन्टरहरूले अझ मोटो तहमा त्यही अस्पष्टता बोक्छन्: इन्टरफेसमा बाइटहरूले यसलाई प्रयोग गर्ने हरेक पीयर र हरेक प्रवाह एकै ठाउँमा जोड्छन्।
एउटा सानो अवलोकन सम्झौता बनाउनुहोस्
प्रत्येक मेट्रिकका लागि, समर्थित वस्तु वा API फिल्ड, मालिक उपकरण र सफ्टवेयर संस्करण, पीयर वा सेवा पहिचानकर्ता, दिशा, सङ्कलन समय र अपेक्षित रिफ्रेस व्यवहार रेकर्ड गर्नुहोस्। त्यसपछि प्रोटोकल अवस्थाका लागि गेटवेको कागजात गरिएको संघ वा सत्र दृश्य, मार्ग अवस्थाका लागि राउटिङ तालिका, र एप्लिकेसन अवस्थाका लागि साँघुरो अनुमति दिइएको अनुरोध प्रयोग गर्नुहोस्। काम गर्ने व्यवस्थापन अन्त्य बिन्दुले व्यवस्थापन अन्त्य बिन्दु काम गर्छ भनी प्रमाणित गर्छ, र यसको पछाडिको एप्लिकेसनबारे केही पनि होइन।
यदि स्थापित एजेन्टमा आवश्यक वस्तुहरू छैनन् भने, स्पष्ट रूपमा समर्थित अर्को पढ्ने-मात्र इन्टरफेस छान्नुहोस्। OID बनाउनु, सामान्य TCP गणनालाई टनेल गणनाका रूपमा पढ्नु, वा पुरानो विक्रेता API सहोदर उत्पादनमा अपरिवर्तित रहन्छ भनी अपेक्षा गर्नु—सबै बन्द बाटोहरू हुन्।
पुरानो डेटा टनेल असफलता होइन
सङ्कलन समय-समाप्ति, म्याद सकिएको प्रमाण-पत्र वा बदलिएको API मार्गले हराएको टेलिमेट्री उत्पन्न गर्छ। त्यो निगरानी असफलता हो र खसेको टनेलभन्दा फरक घटना हो। कुन अवलोकन कहिले पुरानो भयो रेकर्ड गर्नुहोस्, ताकि अपरेटरले टनेल रिसेटको सट्टा अर्थपूर्ण पहिलो जाँच पाओस्। हरेक समय-समाप्तिलाई VPN अवरोध मान्नाले मानिसहरूलाई दुवैलाई बेवास्ता गर्न सिकाउँछ।
सङ्कलन अनुमतिहरू पनि साँघुरा राख्नुहोस्। कन्फिगरेसन बदल्न वा सत्रहरू खाली गर्न सक्ने इन्टरफेसले यस्तो विशेषाधिकार सीमा बोक्छ जो निगरानी कार्यले उत्तराधिकारमा पाउनु हुँदैन, र पढ्ने-मात्र खाता सामान्यतया पर्याप्त हुन्छ।
उपयोगी डिजाइनले वस्तु, अर्थ र ताजगीको आवश्यकतालाई नाम दिन्छ। प्रोटोकलको छनोट त्यिनैबाट आउँछ, उल्टो होइन।