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 વિક્ષેપ તરીકે ગણવાથી લોકો બંનેને અવગણતા શીખે છે.
સંગ્રહ પરવાનગીઓ પણ સાંકડી રાખો. જે ઇન્ટરફેસ રૂપરેખાંકન બદલી શકે અથવા સત્રો સાફ કરી શકે તે એવી વિશેષાધિકાર સીમા ધરાવે છે જે મોનિટરિંગ કાર્યને વારસામાં ન મળવી જોઈએ, અને ફક્ત-વાંચવાનું ખાતું સામાન્ય રીતે પૂરતું છે.
ઉપયોગી ડિઝાઇન ઑબ્જેક્ટ, અર્થ અને તાજગીની જરૂરિયાતને નામ આપે છે. પ્રોટોકોલની પસંદગી તેમાંથી આવે છે, ઊંધું નહીં.