SNMP या API चुनने से पहले VPN ऑब्जेक्ट परिभाषित करें

परिवहन से पहले तीन निर्णय आते हैं: अलर्ट किस ऑब्जेक्ट का वर्णन करता है, वह कौन-सी दिशा और सीमा कवर करता है, और पठन कितना ताज़ा होना चाहिए। SNMP, HTTPS API और एक एप्लिकेशन प्रोब सभी VPN के बारे में कुछ बता सकते हैं, और वे एक ही बात नहीं बताएँगे। इन तीनों को तय किए बिना प्रोटोकॉल बदलने से केवल यह बदलता है कि उलझन कहाँ इकट्ठी होती है। ऑब्जेक्ट और अलर्ट का अर्थ ही डिज़ाइन है; प्रोटोकॉल डिलीवरी है।

चार अलग-अलग अवलोकनों को एक हरे आइकन में बदलने वाले डैशबोर्ड ने वह निर्णय पहले ही बुरी तरह ले लिया है।

अलर्ट का वास्तव में क्या अर्थ होना चाहिए?

इसका अर्थ हो सकता है कि कोई पीयर प्रमाणित नहीं कर सकता, कोई संरक्षित डेटा स्थिति मौजूद नहीं है, कोई रूट गलत जगह की ओर इशारा करता है, या कोई एप्लिकेशन अपना काम पूरा नहीं कर सकता। इनमें से प्रत्येक का अपना स्वामी, अपना पहला जाँच और अपनी झूठी-सकारात्मक दर है। जो पीयर प्रमाणित नहीं कर सकता वह पहचान की समस्या है, अनुपस्थित सुरक्षा संबंध प्रोटोकॉल-स्थिति की समस्या है, रूट कॉन्फ़िगरेशन की समस्या है, और एप्लिकेशन विफलता इनमें से कोई नहीं भी हो सकती है। संग्राहक चुनने से पहले तय करें कि अलर्ट किसके लिए है।

इसे ऐसे वाक्य के रूप में लिखें जिस पर ऑन-कॉल इंजीनियर कार्य कर सके। यदि वाक्य को दो ऑब्जेक्ट चाहिए, तो वे दो अलर्ट हैं, आधा-सही एक नहीं।

TCP तालिका TCP का वर्णन करती है

RFC 4022 tcpConnectionTable निर्दिष्ट करता है, जिसकी पंक्तियाँ स्थापित TCP कनेक्शनों का वर्णन करती हैं, दोनों सिरों पर पते के प्रकार, पता और पोर्ट से कुंजीबद्ध। कनेक्शन बंद होने पर पंक्तियाँ गायब हो जाती हैं, और सुनने वाले सॉकेट किसी अन्य तालिका में दिखाई देते हैं। एक ही बॉक्स पर VPN चलाना TCP तालिका को IPsec सुरक्षा संबंधों की सूची नहीं बना देता। यह प्रबंधन सत्र, एप्लिकेशन प्रवाह या TCP पर ले जाई गई टनल का वर्णन कर सकती है, और पंक्ति स्वयं आपको नहीं बताएगी कि कौन-सी।

इंटरफ़ेस काउंटर अधिक मोटे स्तर पर वही अस्पष्टता रखते हैं: किसी इंटरफ़ेस पर बाइट्स उसका उपयोग करने वाले हर पीयर और हर प्रवाह को एक साथ जोड़ते हैं।

एक छोटा अवलोकन अनुबंध बनाएँ

प्रत्येक मीट्रिक के लिए, समर्थित ऑब्जेक्ट या API फ़ील्ड, स्वामी डिवाइस और सॉफ़्टवेयर संस्करण, पीयर या सेवा पहचानकर्ता, दिशा, संग्रह समय और अपेक्षित रीफ़्रेश व्यवहार दर्ज करें। फिर प्रोटोकॉल स्थिति के लिए गेटवे का प्रलेखित संबंध या सत्र दृश्य, पथ स्थिति के लिए रूटिंग तालिका, और एप्लिकेशन स्थिति के लिए सीमित अनुमत अनुरोध उपयोग करें। काम करने वाला प्रबंधन एंडपॉइंट साबित करता है कि प्रबंधन एंडपॉइंट काम करता है, और उसके पीछे के एप्लिकेशन के बारे में कुछ नहीं।

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

पुराना डेटा टनल विफलता नहीं है

संग्रह समय-समाप्ति, समाप्त क्रेडेंशियल या बदला हुआ API पथ गुम टेलीमेट्री उत्पन्न करते हैं। यह निगरानी विफलता है और गिरी हुई टनल से अलग घटना है। दर्ज करें कौन-सा अवलोकन कब पुराना हुआ, ताकि ऑपरेटर को टनल रीसेट के बजाय अर्थपूर्ण पहली जाँच मिले। हर समय-समाप्ति को VPN रुकावट मानना लोगों को दोनों को नज़रअंदाज़ करना सिखाता है।

संग्रह अनुमतियाँ भी संकीर्ण रखें। जो इंटरफ़ेस कॉन्फ़िगरेशन बदल सकता है या सत्र साफ़ कर सकता है, वह विशेषाधिकार सीमा रखता है जिसे निगरानी कार्य को विरासत में नहीं मिलना चाहिए, और केवल-पढ़ने वाला खाता आमतौर पर पर्याप्त है।

उपयोगी डिज़ाइन ऑब्जेक्ट, अर्थ और ताज़गी की आवश्यकता को नाम देता है। प्रोटोकॉल का चयन उन्हीं से आता है, उल्टा नहीं।