சிறந்த நடைமுறைகள் கண்ணோட்டம்

Observability என்பது முதிர்ந்த கருவிகளின் நிலப்பரப்பைக் கொண்ட ஒரு பரந்த தலைப்பு. ஒவ்வொரு கருவியும் ஒவ்வொரு தீர்வுக்கும் சரியானது அல்ல! உங்கள் observability தேவைகள், கட்டமைப்பு மற்றும் இறுதி வரிசைப்படுத்தல் மூலம் செல்ல உங்களுக்கு உதவ, உங்கள் Observability உத்தி குறித்த முடிவெடுக்கும் செயல்முறையை தெரிவிக்கும் ஐந்து முக்கிய சிறந்த நடைமுறைகளை நாங்கள் சுருக்கமாகக் கூறியுள்ளோம்.

முக்கியமானவற்றைக் கண்காணியுங்கள்

Observability-ல் மிக முக்கியமான கருத்தில் உங்கள் சர்வர்கள், நெட்வொர்க், பயன்பாடுகள் அல்லது வாடிக்கையாளர்கள் அல்ல. அது உங்களுக்கு, உங்கள் வணிகத்திற்கு, உங்கள் திட்டத்திற்கு அல்லது உங்கள் பயனர்களுக்கு முக்கியமானது.

முதலில் உங்கள் வெற்றி அளவுகோல்கள் என்ன என்பதில் தொடங்குங்கள். உதாரணமாக, நீங்கள் ஒரு e-commerce பயன்பாட்டை இயக்கினால், உங்கள் வெற்றியின் அளவீடுகள் கடந்த மணி நேரத்தில் செய்யப்பட்ட வாங்குதல்களின் எண்ணிக்கையாக இருக்கலாம். நீங்கள் ஒரு இலாப நோக்கமற்ற அமைப்பை இயக்கினால், அது மாதத்திற்கான உங்கள் இலக்கிற்கு எதிரான நன்கொடைகளாக இருக்கலாம். ஒரு கட்டண செயலி பரிவர்த்தனை செயலாக்க நேரத்தைக் கவனிக்கலாம், அதேசமயம் பல்கலைக்கழகங்கள் மாணவர் வருகையை அளவிட விரும்பும்.

tip

வெற்றி மெட்ரிக்குகள் ஒவ்வொருவருக்கும் வேறுபட்டவை! நாங்கள் இங்கே ஒரு e-commerce பயன்பாட்டை உதாரணமாகப் பயன்படுத்தலாம், ஆனால் உங்கள் திட்டங்கள் மிகவும் வேறுபட்ட அளவீட்டைக் கொண்டிருக்கலாம். எப்படியிருந்தாலும், ஆலோசனை அதேதான்: நல்லது எப்படி இருக்கும் என்பதை அறிந்து அதற்காக அளவிடுங்கள்.

உங்கள் பயன்பாட்டைப் பொருட்படுத்தாமல், உங்கள் முக்கிய மெட்ரிக்குகளை அடையாளம் காண்பதில் தொடங்க வேண்டும். பின்னர் அதிலிருந்து பின்னோக்கி வேலை செய்து¹ பயன்பாட்டு அல்லது உள்கட்டமைப்பு கண்ணோட்டத்தில் அதை என்ன பாதிக்கிறது என்பதைப் பாருங்கள். உதாரணமாக, உங்கள் வலை சர்வர்களில் அதிக CPU வாடிக்கையாளர் திருப்தியை ஆபத்தில் ஆழ்த்தினால், அதன் விளைவாக உங்கள் விற்பனையை பாதித்தால், CPU பயன்பாட்டைக் கண்காணிப்பது முக்கியம்!

உங்கள் குறிக்கோள்களை அறிந்து, அவற்றை அளவிடுங்கள்!

உங்கள் முக்கியமான உயர்நிலை KPIகளை அடையாளம் கண்ட பிறகு, உங்கள் அடுத்த வேலை அவற்றை தானியங்கு முறையில் கண்காணிக்கவும் அளவிடவும் ஒரு வழியை வைத்திருப்பதாகும். ஒரு முக்கியமான வெற்றி காரணி, உங்கள் பணிச்சுமையின் செயல்பாடுகளை கவனிக்கும் அதே அமைப்பில் அவ்வாறு செய்வதாகும். எங்கள் e-commerce பணிச்சுமை உதாரணத்திற்கு இது அர்த்தப்படலாம்:

• விற்பனை தரவை ஒரு நேரத் தொடர்-ல் வெளியிடுதல்
• இதே அமைப்பில் பயனர் பதிவுகளைக் கண்காணித்தல்
• வாடிக்கையாளர்கள் வலைப்பக்கங்களில் எவ்வளவு நேரம் தங்குகிறார்கள் என்பதை அளவிடுதல், மற்றும் (மீண்டும்) இந்த தரவை நேரத் தொடருக்கு அனுப்புதல்

பெரும்பாலான வாடிக்கையாளர்களிடம் இந்த தரவு ஏற்கனவே உள்ளது, ஆனால் observability கண்ணோட்டத்தில் சரியான இடங்களில் இருக்காது. விற்பனை தரவை பொதுவாக relational databases அல்லது business intelligence reporting systems-ல் காணலாம், பயனர் பதிவுகளும் அவ்வாறே. வருகை காலத்திலிருந்து தரவை லாக்குகளிலிருந்து அல்லது Real User Monitoring மூலம் பிரித்தெடுக்கலாம்.

உங்கள் மெட்ரிக் தரவின் அசல் இருப்பிடம் அல்லது வடிவமைப்பைப் பொருட்படுத்தாமல், அது ஒரு நேரத் தொடர் ஆக பராமரிக்கப்பட வேண்டும். உங்களுக்கு மிகவும் முக்கியமான ஒவ்வொரு முக்கிய மெட்ரிக்கும், அது வணிகம், தனிப்பட்டது, கல்வி அல்லது வேறு எந்த நோக்கத்திற்கானதாக இருந்தாலும், பிற observability தரவுகளுடன் (சில நேரங்களில் சிக்னல்கள் அல்லது டெலிமெட்ரி என்று அறியப்படும்) தொடர்புபடுத்த நேரத் தொடர் வடிவத்தில் இருக்க வேண்டும்.

படம் 1: நேரத் தொடரின் உதாரணம்

சூழல் பரப்புதல் மற்றும் கருவி தேர்வு

கருவி தேர்வு முக்கியமானது, நீங்கள் எவ்வாறு செயல்படுத்துகிறீர்கள் மற்றும் சிக்கல்களை சரிசெய்கிறீர்கள் என்பதில் ஆழமான வேறுபாட்டைக் கொண்டுள்ளது. ஆனால் உகந்ததல்லாத கருவியைத் தேர்ந்தெடுப்பதை விட மோசமானது அனைத்து அடிப்படை சிக்னல் வகைகளுக்கான கருவிகளைக் கொண்டிருப்பதாகும். உதாரணமாக, ஒரு பணிச்சுமையிலிருந்து அடிப்படை லாக்குகளை சேகரிப்பது, ஆனால் பரிவர்த்தனை ட்ரேஸ்களை இழப்பது, உங்களுக்கு ஒரு இடைவெளியை விட்டுவிடும். இதன் விளைவு உங்கள் முழு பயன்பாட்டு அனுபவத்தின் ஒத்திசைவற்ற பார்வையாகும். Observability-க்கான அனைத்து நவீன அணுகுமுறைகளும் application traces மூலம் "புள்ளிகளை இணைப்பதை" சார்ந்துள்ளன.

உங்கள் ஆரோக்கியம் மற்றும் செயல்பாடுகளின் முழுமையான படத்திற்கு லாக்குகள், மெட்ரிக்குகள், மற்றும் ட்ரேஸ்கள் சேகரிக்கும், பின்னர் correlation, analysis, anomaly detection, dashboarding, alarms மற்றும் பலவற்றை செய்யும் கருவிகள் தேவை.

info

சில observability தீர்வுகள் மேலே உள்ள அனைத்தையும் கொண்டிருக்காது, ஆனால் ஏற்கனவே உள்ள அமைப்புகளை விரிவாக்க, நீட்டிக்க அல்லது கூடுதல் மதிப்பை வழங்க நோக்கம் கொண்டவை. எல்லா நிகழ்வுகளிலும், ஒரு observability திட்டத்தைத் தொடங்கும் போது கருவி இடைச்செயல்பாட்டுத்தன்மை மற்றும் விரிவாக்கத்தன்மை ஒரு முக்கியமான கருத்தில் ஆகும்.

ஒவ்வொரு பணிச்சுமையும் வேறுபட்டது, ஆனால் பொதுவான கருவிகள் வேகமான முடிவுகளை அளிக்கின்றன

ஒவ்வொரு பணிச்சுமையிலும் ஒரு பொதுவான கருவித் தொகுப்பைப் பயன்படுத்துவது செயல்பாட்டு உராய்வு மற்றும் பயிற்சியைக் குறைப்பது போன்ற கூடுதல் நன்மைகளைக் கொண்டுள்ளது, பொதுவாக குறைக்கப்பட்ட எண்ணிக்கையிலான கருவிகள் அல்லது விற்பனையாளர்களுக்கு நீங்கள் முயற்சிக்க வேண்டும். இவ்வாறு செய்வது ஏற்கனவே உள்ள observability தீர்வுகளை புதிய சூழல்கள் அல்லது பணிச்சுமைகளுக்கு விரைவாக வரிசைப்படுத்தவும், தவறுகள் ஏற்படும்போது விரைவான தீர்வு நேரத்துடனும் அனுமதிக்கிறது.

உங்கள் கருவிகள் உங்கள் பணிச்சுமையின் ஒவ்வொரு அடுக்கையும் கவனிக்க போதுமான அளவு பரந்ததாக இருக்க வேண்டும்: அடிப்படை உள்கட்டமைப்பு, பயன்பாடுகள், வலைத்தளங்கள் மற்றும் இடையில் உள்ள அனைத்தும். ஒரு கருவி சாத்தியமில்லாத இடங்களில், திறந்த தரநிலையைக் கொண்ட, திறந்த மூலமான, எனவே பரந்த குறுக்கு-தளம் ஒருங்கிணைப்பு சாத்தியங்களைக் கொண்ட கருவிகளைப் பயன்படுத்துவது சிறந்த நடைமுறையாகும்.

ஏற்கனவே உள்ள கருவிகள் மற்றும் செயல்முறைகளுடன் ஒருங்கிணையுங்கள்

சக்கரத்தை மீண்டும் கண்டுபிடிக்காதீர்கள்! "வட்டம்" ஏற்கனவே ஒரு சிறந்த வடிவம், நாம் எப்போதும் கூட்டு மற்றும் திறந்த அமைப்புகளை உருவாக்க வேண்டும், தரவு சிலோக்களை அல்ல.

• ஏற்கனவே உள்ள அடையாள வழங்குநர்களுடன் ஒருங்கிணையுங்கள் (எ.கா. Active Directory, SAML அடிப்படையிலான IdPs).
• உங்களிடம் ஏற்கனவே IT சிக்கல் கண்காணிப்பு அமைப்பு இருந்தால் (எ.கா. JIRA, ServiceNow) சிக்கல்கள் எழும்போது விரைவாக நிர்வகிக்க அதனுடன் ஒருங்கிணையுங்கள்.
• உங்களிடம் ஏற்கனவே பணிச்சுமை மேலாண்மை மற்றும் escalation கருவிகள் (எ.கா. PagerDuty, OpsGenie) இருந்தால் அவற்றைப் பயன்படுத்துங்கள்!
• Ansible, SaltStack, CloudFormation, TerraForm மற்றும் CDK போன்ற Infrastructure as code கருவிகள் அனைத்தும் சிறந்த கருவிகள். உங்கள் observability-ஐ மற்றவற்றுடன் நிர்வகிக்க அவற்றைப் பயன்படுத்துங்கள், நீங்கள் இன்று ஏற்கனவே பயன்படுத்தும் அதே infrastructure as code கருவிகளுடன் உங்கள் observability தீர்வை உருவாக்குங்கள் (முதல் நாளிலிருந்தே observability-ஐ சேர்க்கவும் பார்க்கவும்).

தன்னியக்கம் மற்றும் machine learning-ஐ பயன்படுத்துங்கள்

கணினிகள் வடிவங்களைக் கண்டுபிடிப்பதிலும், தரவு ஒரு வடிவத்தைப் பின்பற்றாதபோது கண்டுபிடிப்பதிலும் திறமையானவை! உங்களிடம் நூற்றுக்கணக்கான, ஆயிரக்கணக்கான அல்லது மில்லியன் கணக்கான தரவு புள்ளிகள் கண்காணிக்கப்பட வேண்டும் என்றால், அவை ஒவ்வொன்றிற்கும் ஆரோக்கியமான வரம்புகளைப் புரிந்துகொள்வது சாத்தியமற்றதாக இருக்கும். ஆனால் பல observability தீர்வுகள் உங்கள் தரவை அடிப்படையாக அமைக்கும் வேறுபடுத்தப்படாத கனரக வேலையை நிர்வகிக்கும் anomaly detection மற்றும் machine learning திறன்களைக் கொண்டுள்ளன.

இதை நாங்கள் "நல்லது எப்படி இருக்கும் என்பதை அறிவது" என்று குறிப்பிடுகிறோம். உங்கள் பணிச்சுமையை முழுமையாக load-test செய்திருந்தால், இந்த ஆரோக்கியமான செயல்திறன் மெட்ரிக்குகளை நீங்கள் ஏற்கனவே அறிந்திருக்கலாம், ஆனால் ஒரு சிக்கலான விநியோகிக்கப்பட்ட பயன்பாட்டிற்கு ஒவ்வொரு மெட்ரிக்கிற்கும் அடிப்படைகளை உருவாக்குவது கடினமாக இருக்கலாம். இங்குதான் anomaly detection, automation மற்றும் machine learning மதிப்பிடமுடியாதவை.

உங்கள் சார்பாக பயன்பாடுகளின் ஆரோக்கியத்தை அடிப்படையாக அமைக்கும் மற்றும் எச்சரிக்கும் கருவிகளைப் பயன்படுத்துங்கள், அதன் மூலம் உங்கள் குறிக்கோள்களில் கவனம் செலுத்தவும், முக்கியமானவற்றைக் கண்காணிக்கவும் அனுமதிக்கும்.

உங்கள் பணிச்சுமையின் அனைத்து அடுக்குகளிலிருந்தும் டெலிமெட்ரியை சேகரியுங்கள்

உங்கள் பயன்பாடுகள் தனிமையில் இல்லை, உங்கள் நெட்வொர்க் உள்கட்டமைப்பு, கிளவுட் வழங்குநர்கள், இணைய சேவை வழங்குநர்கள், SaaS பங்காளிகள் மற்றும் உங்கள் கட்டுப்பாட்டிற்குள்ளும் வெளியேயும் உள்ள பிற கூறுகளுடனான தொடர்புகள் உங்கள் விளைவுகளை பாதிக்கலாம். உங்கள் முழு பணிச்சுமையின் முழுமையான பார்வை இருப்பது முக்கியம்.

ஒருங்கிணைப்புகளில் கவனம் செலுத்துங்கள்

Instrument செய்ய ஒரு பகுதியை நீங்கள் தேர்ந்தெடுக்க வேண்டும் என்றால், அது சந்தேகமின்றி கூறுகளுக்கிடையேயான உங்கள் ஒருங்கிணைப்புகளாக இருக்கும். Observability-ன் சக்தி இங்குதான் மிகவும் தெளிவாகத் தெரிகிறது. ஒரு விதியாக, ஒரு கூறு அல்லது சேவை மற்றொன்றை அழைக்கும் ஒவ்வொரு முறையும், அந்த அழைப்பு குறைந்தபட்சம் இந்த தரவு புள்ளிகளை அளவிட வேண்டும்:

1. கோரிக்கை மற்றும் பதிலின் கால அளவு
2. பதிலின் நிலை

மேலும் observability-க்கு தேவையான ஒத்திசைவான, முழுமையான பார்வையை உருவாக்க, முழு கோரிக்கை சங்கிலிக்கும் ஒரு ஒற்றை தனித்துவ அடையாளங்காட்டி சேகரிக்கப்படும் சிக்னல்களில் சேர்க்கப்பட வேண்டும்.

இறுதிப் பயனர் அனுபவத்தை மறக்காதீர்கள்

உங்கள் பணிச்சுமையின் முழுமையான பார்வை, இறுதிப் பயனர்கள் அதை எவ்வாறு அனுபவிக்கிறார்கள் என்பது உட்பட, அனைத்து அடுக்குகளிலும் அதைப் புரிந்துகொள்வதாகும். மோசமான பயனர் அனுபவத்தால் உங்கள் குறிக்கோள்கள் எப்போது ஆபத்தில் உள்ளன என்பதை அளவிடுதல், அளவிடுதல் மற்றும் புரிந்துகொள்வது, இலவச வட்டு இடம் அல்லது CPU பயன்பாட்டைக் கவனிப்பது போலவே முக்கியம் - அதை விட முக்கியமானது!

உங்கள் பணிச்சுமைகள் இறுதிப் பயனருடன் நேரடியாக தொடர்பு கொள்பவை (வலைத்தளம் அல்லது மொபைல் ஆப்பாக வழங்கப்படும் எந்த பயன்பாடும்) என்றால் Real User Monitoring பயனருக்கு "கடைசி மைல்" விநியோகத்தை மட்டுமல்ல, அவர்கள் உண்மையில் உங்கள் பயன்பாட்டை எவ்வாறு அனுபவித்தார்கள் என்பதையும் கண்காணிக்கிறது. இறுதியில், உங்கள் பயனர்கள் உண்மையில் உங்கள் சேவைகளைப் பயன்படுத்த முடியாவிட்டால் observability பயணத்தில் எதுவும் முக்கியமில்லை.

தரவு சக்தி, ஆனால் சிறிய விஷயங்களுக்கு கவலைப்படாதீர்கள்

உங்கள் பயன்பாட்டின் அளவைப் பொறுத்து, சிக்னல்களை சேகரிக்க உங்களிடம் மிக அதிக எண்ணிக்கையிலான கூறுகள் இருக்கலாம். அவ்வாறு செய்வது முக்கியம் மற்றும் அதிகாரமளிக்கும் போது, உங்கள் முயற்சிகளிலிருந்து குறைந்த வருமானம் இருக்கலாம். இதனால்தான் முக்கியமானவற்றைக் கண்காணிப்பது என்பதில் தொடங்குவது, உங்கள் முக்கியமான ஒருங்கிணைப்புகள் மற்றும் முக்கியமான கூறுகளை வரைபடமாக்க இதைப் பயன்படுத்துவது மற்றும் சரியான விவரங்களில் கவனம் செலுத்துவது சிறந்த நடைமுறையாகும்.

முதல் நாளிலிருந்தே observability-ஐ சேர்க்கவும்

பாதுகாப்பைப் போலவே, observability-ம் உங்கள் மேம்பாடு அல்லது செயல்பாடுகளுக்கு பிந்தைய சிந்தனையாக இருக்கக்கூடாது. சிறந்த நடைமுறை என்னவென்றால், பாதுகாப்பைப் போலவே observability-ஐ உங்கள் திட்டமிடலில் முன்கூட்டியே வைப்பதாகும், இது மக்கள் வேலை செய்வதற்கான ஒரு மாதிரியை உருவாக்குகிறது மற்றும் உங்கள் பயன்பாட்டின் ஒளிபுகாத மூலைகளைக் குறைக்கிறது. முக்கிய மேம்பாட்டு வேலை முடிந்த பிறகு transaction tracing-ஐ சேர்ப்பது, auto-instrumentation கொண்டு கூட நேரம் எடுக்கும். முயற்சி மிகவும் அதிக வருமானத்தை அளிக்கிறது! ஆனால் உங்கள் மேம்பாட்டு சுழற்சியின் பிற்பகுதியில் அவ்வாறு செய்வது சில மறுவேலைகளை உருவாக்கலாம்.

உங்கள் பணிச்சுமையில் observability-ஐ பின்னர் இணைப்பதற்கு பதிலாக, உங்கள் வேலையை துரிதப்படுத்த அதைப் பயன்படுத்துங்கள். சரியான logging, metric, மற்றும் trace சேகரிப்பு வேகமான பயன்பாட்டு மேம்பாட்டை செயல்படுத்துகிறது, நல்ல நடைமுறைகளை வளர்க்கிறது, மற்றும் எதிர்காலத்தில் விரைவான சிக்கல் தீர்வுக்கான அடித்தளத்தை அமைக்கிறது.

Footnotes

1. Amazon working backwards செயல்முறையை எங்கள் வாடிக்கையாளர்கள் மற்றும் அவர்களின் விளைவுகள் மீது ஆர்வம் கொள்ள ஒரு வழியாக விரிவாகப் பயன்படுத்துகிறது, observability தீர்வுகளில் பணிபுரியும் எவரும் தங்கள் சொந்த குறிக்கோள்களிலிருந்து அதே வழியில் பின்னோக்கி வேலை செய்ய நாங்கள் மிகவும் பரிந்துரைக்கிறோம். Working backwards பற்றி மேலும் Werner Vogels இன் வலைப்பதிவில் படிக்கலாம். ↩