SNMP അല്ലെങ്കിൽ API തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് VPN ഒബ്ജക്ട് നിർവചിക്കുക

ഗതാഗതത്തിന് മുമ്പ് മൂന്ന് തീരുമാനങ്ങളുണ്ട്: അലേർട്ട് ഏത് ഒബ്ജക്ടിനെ വിവരിക്കുന്നു, ഏത് ദിശയും പരിധിയും അത് ഉൾക്കൊള്ളുന്നു, വായന എത്ര പുതുമയുള്ളതായിരിക്കണം. SNMP, HTTPS API, ആപ്ലിക്കേഷൻ പ്രോബ് എന്നിവയെല്ലാം VPN-നെക്കുറിച്ച് എന്തെങ്കിലും റിപ്പോർട്ട് ചെയ്യാം, ഒരേ കാര്യം അവ റിപ്പോർട്ട് ചെയ്യില്ല. ഈ മൂന്നും തീരുമാനിക്കാതെ പ്രോട്ടോക്കോളുകൾ മാറ്റുന്നത് ആശയക്കുഴപ്പം എവിടെ കൂടുന്നു എന്നത് മാത്രം മാറ്റുന്നു. ഒബ്ജക്ടും അലേർട്ടിന്റെ അർത്ഥവുമാണ് രൂപകൽപ്പന; പ്രോട്ടോക്കോൾ ഡെലിവറിയാണ്.

നാല് വ്യത്യസ്ത നിരീക്ഷണങ്ങളെ ഒരു പച്ച ഐക്കണാക്കി മാറ്റുന്ന ഡാഷ്ബോർഡ് ആ തീരുമാനം ഇതിനകം മോശമായി എടുത്തിട്ടുണ്ട്.

അലേർട്ട് യഥാർത്ഥത്തിൽ എന്താണ് അർത്ഥമാക്കേണ്ടത്?

ഒരു പീയർ പ്രാമാണീകരിക്കാൻ കഴിയില്ല, സംരക്ഷിത ഡാറ്റാ അവസ്ഥയില്ല, ഒരു റൂട്ട് തെറ്റായ സ്ഥലത്തേക്ക് ചൂണ്ടുന്നു, അല്ലെങ്കിൽ ഒരു ആപ്ലിക്കേഷന് അതിന്റെ ജോലി പൂർത്തിയാക്കാൻ കഴിയില്ല എന്ന് ഇത് അർത്ഥമാക്കാം. അവയിൽ ഓരോന്നിനും സ്വന്തം ഉടമയും സ്വന്തം ആദ്യ പരിശോധനയും സ്വന്തം വ്യാജ-പോസിറ്റീവ് നിരക്കും ഉണ്ട്. പ്രാമാണീകരിക്കാൻ കഴിയാത്ത പീയർ ഐഡന്റിറ്റി പ്രശ്നമാണ്, കാണാത്ത സെക്യൂരിറ്റി അസോസിയേഷൻ പ്രോട്ടോക്കോൾ-അവസ്ഥ പ്രശ്നമാണ്, റൂട്ട് കോൺഫിഗറേഷൻ പ്രശ്നമാണ്, ആപ്ലിക്കേഷൻ പരാജയം അവയിലൊന്നുമല്ലായിരിക്കാം. ശേഖരണ ഉപകരണം തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് അലേർട്ട് ഏതിനാണെന്ന് തീരുമാനിക്കുക.

ഓൺ-കോൾ എഞ്ചിനീയർക്ക് പ്രവർത്തിക്കാൻ കഴിയുന്ന ഒരു വാക്യമായി ഇത് എഴുതുക. വാക്യത്തിന് രണ്ട് ഒബ്ജക്ടുകൾ വേണമെങ്കിൽ, അത് രണ്ട് അലേർട്ടുകളാണ്, പകുതി-ശരിയായ ഒന്നല്ല.

TCP പട്ടിക TCP-യെ വിവരിക്കുന്നു

RFC 4022 tcpConnectionTable വ്യക്തമാക്കുന്നു, അതിന്റെ വരികൾ സ്ഥാപിത TCP കണക്ഷനുകളെ വിവരിക്കുന്നു, ഇരു അറ്റത്തും വിലാസ തരം, വിലാസം, പോർട്ട് എന്നിവ കൊണ്ട് കീ ചെയ്തിരിക്കുന്നു. കണക്ഷൻ അടയ്ക്കുമ്പോൾ വരികൾ അപ്രത്യക്ഷമാകുന്നു, കേൾക്കുന്ന സോക്കറ്റുകൾ മറ്റൊരു പട്ടികയിൽ പ്രത്യക്ഷപ്പെടുന്നു. ഒരേ ബോക്സിൽ VPN പ്രവർത്തിപ്പിക്കുന്നത് TCP പട്ടികയെ IPsec സെക്യൂരിറ്റി അസോസിയേഷനുകളുടെ ഇൻവെന്ററിയാക്കി മാറ്റില്ല. ഇത് ഒരു മാനേജ്മെന്റ് സെഷൻ, ഒരു ആപ്ലിക്കേഷൻ പ്രവാഹം, അല്ലെങ്കിൽ TCP-യിലൂടെ കൊണ്ടുപോകുന്ന ഒരു ടണൽ വിവരിക്കാം, വരി തന്നെ ഏതാണെന്ന് നിങ്ങളോട് പറയില്ല.

ഇന്റർഫേസ് കൗണ്ടറുകൾ അതേ അവ്യക്തത കൂടുതൽ പരുക്കനായ തലത്തിൽ വഹിക്കുന്നു: ഒരു ഇന്റർഫേസിലെ ബൈറ്റുകൾ അത് ഉപയോഗിക്കുന്ന എല്ലാ പീയറുകളെയും എല്ലാ പ്രവാഹങ്ങളെയും ഒരുമിച്ച് ചേർക്കുന്നു.

ഒരു ചെറിയ നിരീക്ഷണ കരാർ നിർമ്മിക്കുക

ഓരോ മെട്രിക്കിനും പിന്തുണയുള്ള ഒബ്ജക്ട് അല്ലെങ്കിൽ API ഫീൽഡ്, ഉടമസ്ഥ ഉപകരണവും സോഫ്റ്റ്വെയർ പതിപ്പും, പീയർ അല്ലെങ്കിൽ സേവന ഐഡന്റിഫയർ, ദിശ, ശേഖരണ സമയം, പ്രതീക്ഷിത പുതുക്കൽ സ്വഭാവം എന്നിവ രേഖപ്പെടുത്തുക. തുടർന്ന് പ്രോട്ടോക്കോൾ അവസ്ഥയ്ക്ക് ഗേറ്റ്വേയുടെ രേഖപ്പെടുത്തിയ അസോസിയേഷൻ അല്ലെങ്കിൽ സെഷൻ കാഴ്ച, പാത അവസ്ഥയ്ക്ക് റൂട്ടിംഗ് പട്ടിക, ആപ്ലിക്കേഷൻ അവസ്ഥയ്ക്ക് ഇടുങ്ങിയ അനുവദനീയ അഭ്യർത്ഥന എന്നിവ ഉപയോഗിക്കുക. പ്രവർത്തിക്കുന്ന മാനേജ്മെന്റ് എൻഡ്പോയിന്റ് മാനേജ്മെന്റ് എൻഡ്പോയിന്റ് പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, അതിന് പിന്നിലെ ആപ്ലിക്കേഷനെക്കുറിച്ച് ഒന്നുമല്ല.

ഇൻസ്റ്റാൾ ചെയ്ത ഏജന്റിൽ ആവശ്യമായ ഒബ്ജക്ടുകൾ ഇല്ലെങ്കിൽ, വ്യക്തമായി പിന്തുണയുള്ള മറ്റൊരു വായന-മാത്ര ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുക. OID കെട്ടിച്ചമയ്ക്കുക, പൊതുവായ TCP എണ്ണം ടണൽ എണ്ണമായി വായിക്കുക, അല്ലെങ്കിൽ പഴയ വെണ്ടർ API സഹോദര ഉൽപ്പന്നത്തിൽ മാറ്റമില്ലാതെ നിലനിൽക്കുമെന്ന് പ്രതീക്ഷിക്കുക—ഇവയെല്ലാം അവസാനിക്കുന്ന വഴികളാണ്.

പഴയ ഡാറ്റ ടണൽ പരാജയമല്ല

ശേഖരണ ടൈംഔട്ട്, കാലഹരണപ്പെട്ട ക്രെഡൻഷ്യൽ അല്ലെങ്കിൽ മാറിയ API പാത എന്നിവ കാണാത്ത ടെലിമെട്രി സൃഷ്ടിക്കുന്നു. അത് മോണിറ്ററിംഗ് പരാജയമാണ്, വീണ ടണലിൽ നിന്ന് വ്യത്യസ്തമായ സംഭവമാണ്. ഏത് നിരീക്ഷണം എപ്പോൾ പഴയതായി എന്ന് രേഖപ്പെടുത്തുക, ഓപ്പറേറ്റർക്ക് ടണൽ റീസെറ്റിന് പകരം അർത്ഥവത്തായ ആദ്യ പരിശോധന ലഭിക്കാൻ. ഓരോ ടൈംഔട്ടിനെയും VPN തടസ്സമായി കാണുന്നത് ആളുകളെ രണ്ടും അവഗണിക്കാൻ പഠിപ്പിക്കുന്നു.

ശേഖരണ അനുമതികളും ഇടുങ്ങിയതായി സൂക്ഷിക്കുക. കോൺഫിഗറേഷൻ മാറ്റാനോ സെഷനുകൾ മായ്ക്കാനോ കഴിയുന്ന ഇന്റർഫേസ്, മോണിറ്ററിംഗ് ജോലി അവകാശമായി പിന്തുടരാൻ പാടില്ലാത്ത ഒരു പ്രിവിലേജ് അതിർത്തി വഹിക്കുന്നു, വായന-മാത്ര അക്കൗണ്ട് സാധാരണയായി മതിയാകും.

ഉപയോഗപ്രദമായ രൂപകൽപ്പന ഒബ്ജക്ട്, അർത്ഥം, പുതുമ ആവശ്യകത എന്നിവയെ പേരിടുന്നു. പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുപ്പ് അവയിൽ നിന്നാണ് വരുന്നത്, തിരിച്ചല്ല.