ஹைப்ரிட் மற்றும் மல்டிகிளவுட்டுக்கான சிறந்த நடைமுறைகள்
அறிமுகம்
ஒன்றுக்கும் மேற்பட்ட கிளவுட் சேவை வழங்குநரை ஒரே நேரத்தில் பயன்படுத்தி உங்கள் சொந்த பணிச்சுமைகளை இயக்குவதை மல்டிகிளவுட் என்று கருதுகிறோம், மற்றும் ஹைப்ரிட் என்பது உங்கள் பணிச்சுமைகளை ஆன்-பிரமிஸ் மற்றும் கிளவுட் சூழல்கள் இரண்டிலும் விரிவுபடுத்துவது ஆகும். ஹைப்ரிட் மற்றும் மல்டிகிளவுட் சூழல்களில் Observability கருவி வேறுபாடு, தாமதம் மற்றும் பன்முகப்பட்ட பணிச்சுமைகள் காரணமாக குறிப்பிடத்தக்க சிக்கலை சேர்க்கலாம். இருப்பினும், டெவலப்மென்ட் மற்றும் வணிகப் பயனர்கள் இருவருக்கும் இது ஒரு பொதுவான இலக்காக உள்ளது. இதை நிவர்த்தி செய்யும் தயாரிப்புகள் மற்றும் சேவைகளின் வளமான சூழல்தொகுப்பு உள்ளது.
இருப்பினும், கிளவுட்-நேட்டிவ் பணிச்சுமைகளுக்கான observability கருவிகளின் பயனுள்ளமை வியத்தகு முறையில் மாறுபடலாம். கண்டெய்னர்மயமான பேட்ச் செயலாக்க பணிச்சுமையை கண்காணிப்பதன் வேறுபட்ட தேவைகளை, சர்வர்லெஸ் கட்டமைப்பைப் பயன்படுத்தும் நிகழ்நேர வங்கி பயன்பாட்டுடன் ஒப்பிடுங்கள்: இரண்டிலும் லாக்குகள், மெட்ரிக்குகள் மற்றும் ட்ரேஸ்கள் உள்ளன; இருப்பினும், அவற்றை கண்காணிப்பதற்கான கருவித்தொகுப்பு மாறுபடும், பல கிளவுட்-நேட்டிவ், திறந்த மூல மற்றும் ISV தயாரிப்புகள் கிடைக்கின்றன. Prometheus போன்ற திறந்த மூல கருவி ஒன்றுக்கு சிறந்த பொருத்தமாக இருக்கலாம், அதே சமயம் நிர்வகிக்கப்படும் சேவையாக வழங ்கப்படும் கிளவுட்-நேட்டிவ் கருவி உங்கள் தேவைகளை சிறப்பாக பூர்த்தி செய்யலாம்.
இதற்கு மல்டிகிளவுட் மற்றும் ஹைப்ரிட்டின் சிக்கலையும் சேர்த்தால், உங்கள் பயன்பாடுகளிலிருந்து நுண்ணறிவுகளைப் பெறுவது கணிசமாக கடினமாகிறது.
இந்த கூடுதல் பரிமாணங்களை கையாளவும் observability-க்கான அணுகுமுறைகளை எளிதாக்கவும், வாடிக்கையாளர்கள் ஒரு ஒருங்கிணைந்த இடைமுகத்துடன் ஒரு கருவித்தொகுப்பில் முதலீடு செய்கின்றனர். எல்லாவற்றிற்கும் மேலாக, சிக்னல்-இரைச்சல் விகிதத்தை குறைப்பது பொதுவாக நல்லது! இருப்பினும், ஒரு அணுகுமுறை அனைத்து பயன்பாட்டு நிகழ்வுகளுக்கும் வேலை செய்யாது, மேலும் பல்வேறு தளங்களின் செயல்பாட்டு மாதிரிகள் குழப்பத்தை சேர்க்கலாம். எங்கள் இலக்கு உங்கள் தேவைகளை பூர்த்தி செய்யும் தகவலறிந்த முடிவுகளை எடுக்க உங்களுக்கு உதவுவதும், சிக்கல்கள் ஏற்படும்போது உங்கள் சராசரி தீர்வு நேரத்தை குறைப்பதும் ஆகும். அனைத்து அளவிலான வாடிக்கையாளர்களுடனும், ஒவ்வொரு தொழிற்துறையிலும் பணிபுரிவதன் மூலம் நாங்கள் கற்ற சிறந்த நடைமுறைகள் கீழே உள்ளன.
இந்த சிறந்த நடைமுறைகள் பரந்த பாத்திரங்களுக்கு நோக்கமானவை: நிறுவன கட்டமைப்பாளர்கள், டெவலப்பர்கள், DevOps மற்றும் பலர். உங்கள் நிறுவனத்தின் வணிகத் தேவைகள் மற்றும் விநியோகிக்கப்பட்ட சூழல்களில் observability எவ்வாறு அதிகபட்ச மதிப்பை வழங்க முடியும் என்ற கோணத்தில் அவற்றை மதிப்பிடுமாறு பரிந்துரைக்கிறோம்.
உங்கள் கருவிகள் உங்கள் முடிவுகளை ஆணையிட விடாதீர்கள்
உங்கள் பயன்பாடுகள், கருவிகள் மற்றும் செயல்முறைகள் விற்பனையை அதிகரித்தல் மற்றும் வாடிக்கையாளர் திருப்தி போன்ற வணிக விளைவுகளை அடைய உதவ உள்ளன. நன்கு ஆலோசனை பெற்ற தொழில்நுட்ப உத்தி என்பது அந்த வணிக இலக்குகளை அடைய உங்களுக்கு உதவ அனைத்தையும் செய்வது ஆகும். ஆனால் அங்கு செல்ல உதவும் விஷயங்கள் வெறும் கருவிகள், அவை உங்கள் உத்தியை ஆதரிக்க வேண்டும் - உத்தியாக இருக்கக்கூடாது. ஒரு ஒப்புமை செய்ய, நீங்கள் ஒரு வீட்டை கட்ட வேண்டுமென்றால், அதை எவ்வாறு வடிவமைத்து கட்டுவது என்று உங்கள் கருவிகளிடம் கேட்க மாட்டீர்கள். மாறாக, உங்கள் கருவிகள் ஒரு இலக்கை அடைவதற்கான வழிமுறை.
ஒற்றை, ஒருபடித்தான சூழலில், கருவிகள் பற்றிய முடிவுகள் எளிதானவை. எ ல்லாவற்றிற்கும் மேலாக, நீங்கள் ஒரு சூழலில் ஒரு பயன்பாட்டை இயக்கினால், உங்கள் கருவிகள் எல்லா இடங்களிலும் ஒரே மாதிரியாக இருக்கலாம். ஆனால் ஹைப்ரிட் மற்றும் மல்டிகிளவுட் சூழல்களுக்கு விஷயங்கள் குறைவாக தெளிவாக உள்ளன, உங்கள் வணிக விளைவுகளில் கவனம் செலுத்துவது - மற்றும் இந்த சூழல்களில் உங்கள் பணிச்சுமைகளை கண்காணிப்பதன் மூலம் சேர்க்கப்படும் மதிப்பு - முக்கியமானது. ஒவ்வொரு கிளவுட் சேவை வழங்குநரும் (CSP) தங்கள் சொந்த நேட்டிவ் observability தீர்வுகளையும், நீங்கள் பயன்படுத்தக்கூடிய பங்காளிகள் மற்றும் சுயாதீன மென்பொருள் விற்பனையாளர்களின் (ISVs) வளமான தொகுப்பையும் கொண்டுள்ளனர்.
நீங்கள் பல சூழல்களில் செயல்படுவதால் ஒவ்வொரு பணிச்சுமைக்கும் ஒரு கருவி பரிந்துரைக்கத்தக்கது அல்ல, பரிந்துரைக்கப்படுவதும் இல்லை. இது உங்கள் பணிச்சுமைகளை கண் காணிக்க பல சேவைகள், கட்டமைப்புகள் அல்லது வழங்குநர்களைப் பயன்படுத்துவதாக இருக்கலாம். உங்கள் பணிச்சுமையின் சூழல் ஒரு ஒற்றை பலகத்தை விட முக்கியம் என்பதற்கான விவரங்களை கீழே "ஒற்றை பலகம் உங்கள் பணிச்சுமையின் சூழலை விட குறைவான முக்கியத்துவம்" பிரிவில் பாருங்கள். எதுவாக இருந்தாலும், உங்கள் கருவிகளை செயல்படுத்தும்போது, எதிர்காலத்தில் உங்கள் observability தீர்வை மேம்படுத்த "இருவழிக் கதவுகளை" உருவாக்குவதை நினைவில் கொள்ளுங்கள்.
தவிர்க்க வேண்டிய "கருவி-முதல்" விளைவுகளின் சில எடுத்துக்காட்டுக ள்:
- எதிர்காலத்தில் மேம்படுத்த அல்லது புதிய தீர்வுக்கு மாற இருவழிக் கதவு இல்லாமல் ஒரு கருவியை செயல்படுத்துவதில் கவனம் செலுத்துவது, இல்லையெனில் தவிர்க்கக்கூடிய தொழில்நுட்ப கடனை உருவாக்கலாம். கருவி தீர்வாக இருக்கும்போது இது நிகழலாம், ஒரு நாள் நீங்கள் தீர்க்க வேண்டிய சிக்கலாக மாறலாம்.
- அளவு தள்ளுபடி காரணமாக ஒரு கருவியைப் பயன்படுத்துவதற்கான நிறுவன தரநிலை, பயனளிக்கும் அம்சங்கள் இல்லாமல் போகலாம். இது "தரத்தை விட செலவு" ஆக இருக்கலாம், மற்றும் கவனமின்றி ஒரு ஒற்றை-கட்டமைப்பு எதிர்-பாணியை உருவாக்குகிறது. அளவு வரம்புக்குள் இருக்க டெலிமெட்ரி சேகரிப்பை ஊக்கப்படுத்தாமல் போகலாம், இதனால் observability கருவிகளின் பயன்பாட்டை ஊக்கமிழக்கலாம்.
- ஏற்கனவே உள்ள ட்ரேஸ் சேகரிப்பு உள்கட்டமைப்பு இல்லாததால், ஆனால் லாக் மற்றும் மெட்ரிக் சேகரிப்பாளர்களின் வளமான தொகு ப்பு இருப்பதால், முழு வகை டெலிமெட்ரியை (பொதுவாக ட்ரேஸ்கள்) சேகரிக்காமல் இருப்பது, அபூர்ணமான observability தீர்வுக்கு வழிவகுக்கலாம்.
- உழைப்பு மற்றும் பயிற்சி செலவுகளைக் குறைக்கும் விருப்பத்தில், ஆதரவு ஊழியர்கள் ஒரு கருவித்தொகுப்பில் மட்டுமே பயிற்சி பெற்றிருப்பது, பிற observability வடிவங்களின் சாத்தியமான மதிப்பைக் குறைக்கிறது.
உங்கள் கருவிகள் உங்கள் observability உத்தியை ஆணையிடுகின்றன என்றால், அணுகுமுறையை தலைகீழாக மாற்ற வேண்டும். கருவிகள் observability-ஐ இயக்கவும் வலுப்படுத்தவும் உள்ளன, உங்கள் தேர்வுகளை கட்டுப்படுத்த அல்ல.
கருவி பரவல் என்பது நிறுவனங்கள் போராடும் மிகவும் உண்மையான சிக்கல், இருப்பினும் ஒரு தீவிரமான மாற்றம் ஒற்றை கருவித்தொகுப்புக்கு உங்கள் observability தீர்வின் பயனுள்ளமையை குறைக்கலாம். ஹைப்ரிட் மற்றும் மல்டிகிளவுட் பணிச்சுமைகள் ஒவ்வொரு தளத்திற்கும் தனித்துவமான தொழில்நுட்பங்களைக் கொண்டுள்ளன, மேலும் ஒவ்வொரு CSP-யிலிருந்தும் உயர்-நிலை சேவைகள் பயனுள்ளவை - இருப்பினும் ஒற்றை-ஆதாரத் தயாரிப்பைப் பயன்படுத்துவதில் உள்ள சமரசங்களுக்கு மதிப்பு-அடிப்படையிலான பகுப்பாய்வு தேவை. இந்த அபாயங்களில் சிலவற்றை குறைக்கும் அணுகுமுறைக்கு "OpenTelemetry-இல் முதலீடு செய்யுங்கள்" பாருங்கள்.
(Observability) தரவுக்கு ஈர்ப்பு விசை உள்ளது
அனைத்து தரவுக்கும் ஈர்ப்பு விசை உள்ளது - அதாவது அது பணிச்சுமைகள், தீர்வுகள், கருவிகள், நபர்கள், செயல்முறைகள் மற்றும் திட்டங்களை தன்னைச் சுற்றி ஈர்க்கிறது. எடுத்துக்காட்டாக, உங்கள் வாடிக்கையாளர் பரிவர்த்தனைகள் உள்ள தரவுத்தளம் கம்ப்யூட் மற்றும் அனலிட்டிக்ஸ் பணிச்சுமைகளை தன்னிடம் கொண்டுவரும் ஈர்ப்பு விசையாக இருக்கும். உங்கள் பணிச்சுமைகளை எங்கு வைக்கிறீர்கள், எந்த சூழலில், எதிர்காலத்தில் எவ்வாறு இயக்குகிறீர்கள் என்பதற்கு இது நேரடி தாக்கங்களைக் கொண்டுள்ளது. Observability சிக்னல்களுக்கும் இதுவே உண்மை, இருப்பினும் இந்த தரவு உருவாக்கும் ஈர்ப்பு விசை உங்கள் பணிச்சுமை மற்றும் நிறுவன சூழலுடன் இணைக்கப்பட்டுள்ளது (கீழே "ஒற்றை பலகம் உங்கள் பணிச்சுமையின் சூழலை விட குறைவான முக்கியத்துவம்" பாருங்கள்).
உங்கள் observability டெலிமெட்ரியின் சூழலை அது தொடர்புடைய அடிப்படை பணிச்சுமை மற்றும் தரவிலிருந்து முழுமையாக பிரிக்க முடியாது. அதே விதி இங்கும் பொருந்தும்: உங்கள் டெலிமெட்ரி தரவு, அதற்கு ஈர்ப்பு விசை உள்ளது. உங்கள் டெலிமெட்ரி ஏஜெண்ட்கள், சேகரிப்பாளர்கள் அல்லது சிக்னல்களை திரட்டி பகுப்பாய்வு செய்யும் அமைப்புகளை எங்கு வைக்கிறீர்கள் என்பதை இது பாதிக்க வேண்டும்.
காலப்போக்கில் observability தரவின் மதிப்பு மற்ற தரவு வகைகளை விட கணிசமாக குறைவானது. நீங்கள் அதை observability தரவின் "அரை-ஆயுள்" என்று அழைக்கலாம். டெலிமெட்ரியை மற்றொரு சூழலுக்கு அனுப்புவதில் உள்ள கூடுதல் தாமதத்தை, இந்த தரவின் சாத்தியமான பயன்பாட்டிற்கு முன் கட்டாய மதிப்பிழப்பாக கருதுங்கள், பிறகு சிக்கல்கள் ஏற்படும்போது எச்சரிக்கைக்கான உங்கள் தேவைகளுக்கு எதிராக அதை எடை போடுங்கள்.
சிறந்த நடைமுறை என்னவென்றால், இந்த திரட்டலிலிருந்து பெறப்படும் வணிக மதிப்பு இருக்கும்போது மட்டுமே சூழல்களுக்கிடையே தரவை வெளியிடுவது. தரவை வினவுவதற்கான ஒற்றை ஆதாரம் வைத்திருப்பது தனியாக பல வணிகத் தேவைகளைத் தீர்க்காது, மேலும் விரும்பியதை விட அதிக விலையான தீர்வை உருவாக்கலாம், அதிக தோல்வி புள்ளிகளுடன்.
ஒற்றை பலகம் உங்கள் பணிச்சுமையின் சூழலை விட குறைவான முக்கியத்துவம்
உங்கள் அனைத்து பணிச்சுமைகளையும் கண்காணிக்க "ஒற்றை பலகம்" என்பது ஒரு பொதுவான கோரிக்கை. இது முடிந்தவரை அதிக தரவைப் பார்க்க, ஆனால் முடிந்தவரை எளிமையான வழியில் அடைய, மற்றும் குழப்பம், விரக்தி மற்றும் கண்டறிதல் நேரத்தை குறைக்க விரும்பும் இயற்கையான விருப்பத்திலிருந்து எழுகிறது. உங்கள் முழு observability தீர்வையும் ஒரே நேரத்தில் பார்க்க இந்த ஒரு இடைமுகத்தை உருவாக்குவது பயனுள்ளது, ஆனால் உங்கள் டெலிமெட்ரியை அது வந்த சூழலிலிருந்து பிரிப்பதன் சமரசத்துடன் வரலாம்.
எடுத்துக்காட்டாக, நூறு சர்வர்களின் CPU பயன்பாட்டுடன் கூடிய டாஷ்போர்டு நுகர்வில் சில அசாதாரண உயர்வுகளைக் காட்டலாம், ஆனால் இது ஏன் நிகழ்ந்தது அல்லது இந்த நடத்தைக்கு பங்களிக்கும் காரணிகள் என்ன என்பதை விளக்காது. மேலும் இந்த மெட்ரிக்கின் முக்கியத்துவம் உடனடியாக தெளிவாக இருக்காமல் போகலாம்.
சில நேரங்களில் வாடிக்கையாளர்கள் ஒற்றை பலகத்தை மிகவும் ஆக்ரோஷமாக பின்தொடர்வதை நாங்கள் கண்டிருக்கிறோம், அனைத்து வணிக சூழலும் இழக்கப்படுகிறது, ஒரு கருவியில் எல்லாவற்றையும் பார்க்க முயற்சிப்பது உண்மையில் அந்த தரவின் மதிப்பை நீர்க்கலாம். உங்கள் டாஷ்போர்டுகளும், உங்கள் கருவிகளும் ஒரு கதையை சொல்ல வேண்டும். இந்த கதையில் உங்கள் பணிச்சுமைகளில் உள்ள நிகழ்வுகளால் பாதிக்கப்படும் வணிக மெட்ரிக்குகள் மற்றும் விளைவுகள் அடங்க வேண்டும்.
மேலும், உங்கள் கருவிகள் உங்கள் செயல்பாட்டு மாதிரிக்கு ஒத்திருக்க வேண்டும். உங்கள் ஆதரவு குழுக்கள் உங்கள் அனைத்து சூழல்களுக்கும் அணுகலுடன் உலகளாவியதாக இருக்கும்போது ஒற்றை பலகம் மதிப்பை சேர்க்கலாம், ஆனால் அவர்கள் ஒரு CSP அல்லது ஹைப்ரிட் சூழலில் ஒரு பணிச்சுமையை மட்டுமே அணுக முடிந்தால், இந்த அணுகுமுறையால் எந்த மதிப்பும் சேர்க்க ப்படாது. இந்த நிகழ்வுகளில், ஒவ்வொரு சூழலிலும் நேட்டிவாக டாஷ்போர்டுகளை உருவாக்க குழுக்களை அனுமதிப்பது மதிப்புக்கான நேரத்தை விரைவுபடுத்தலாம், எதிர்காலத்தில் மாற்றங்களுக்கு மிகவும் நெகிழ்வானதாக இருக்கலாம்.
Observability தரவின் மதிப்பு அது வந்த பயன்பாட்டில் ஆழமாக ஒருங்கிணைக்கப்பட்டுள்ளது. உங்கள் டெலிமெட்ரிக்கு அதன் சூழலிலிருந்து வரும் சூழல் விழிப்புணர்வு தேவை. ஹைப்ரிட் மற்றும் மல்டிகிளவுட் சூழல்களில், தொழில்நுட்பங்களுக்கிடையேயான வேறுபாடுகள் சூழலின் தேவையை இன்னும் அதிகமாக்குகின்றன (இருப்பினும் Kubernetes போன்ற அமைப்புகள் வெவ்வேறு கிளவுட் வழங்குநர்கள் மற்றும் ஆன்-பிரமிஸ் இடையே ஒத்ததாக இருக்கலாம்).
விநியோகிக்கப்பட்ட அமைப்புக்கான ஒற்றை பலகத்தை உருவாக்கும்போது, உங்கள் வணிக மெட்ரிக்குகள் மற்றும் சேவை நிலை இலக்குகளை (SLOs) இந்த SLO-களுக்கு பங்களிக்கும் பிற தரவுகளுடன் (உள்கட்டமைப்பு மெட்ரிக்குகள் போன்றவை) ஒரே பார்வையில் காட்டுங்கள். இது இல்லையென்றால் இல்லாத சூழலை வழங்குகிறது.
ஒற்றை பலகம் சிக் கல்களை விரைவாக கண்டறியவும் கண்டறிதல் நேரத்தை (MTTD) குறைக்கவும், இதனால் சராசரி தீர்வு நேரத்தை (MTTR) குறைக்கவும் உதவும், ஆனால் டெலிமெட்ரி தரவின் பொருள் பாதுகாக்கப்பட்டால் மட்டுமே. இது இல்லாமல், ஒற்றை பலகம் அணுகுமுறை மதிப்புக்கான நேரத்தை அதிகரிக்கலாம், அல்லது செயல்பாட்டு குழுக்களுக்கு நிகர-எதிர்மறையாக மாறலாம்.
ஒற்றை பலகத்தின் மதிப்பை தீர்மானிக்க முடியவில்லை என்றால், அல்லது பணிச்சுமைகள் முற்றிலும் ஒரு CSP அல்லது ஆன்-பிரமிஸ் சூழலுடன் பிணைக்கப்பட்டிருந்தால், உயர்மட்ட வணிக மெட்ரிக்குகளை மட்டும் ஒற்றை பலகத்திற்கு உருட்டுவதை கருதுங்கள், மூல மெட்ரிக்குகள் மற்றும் பிற பங்களிக்கும் கார ணிகளை அவற்றின் அசல் சூழல்களில் விட்டுவிடுங்கள்.
OpenTelemetry-இல் முதலீடு செய்யுங்கள்
Observability விற்பனையாளர் நிலப்பரப்பு முழுவதும், OpenTelemetry (OTel) நடைமுறை தரநிலையாக மாறியுள்ளது. OTel உங்கள் ஒவ்வொரு டெலிமெட்ரி வகைகளையும் ஒன்று அல்லது பல சேகரிப்பாளர்களுக்கு ஒருங்கிணைக்க முடியும், இதில் கிளவுட்-நேட்டிவ் சேவைகள் அல்லது பல்வேறு SaaS மற்றும் ISV தயாரிப்புகள் அடங்கும். OTel ஏஜெண்ட்கள் மற்றும் சேகரிப்பாளர்கள் OpenTelemetry Protocol (OTLP) பயன்படுத்தி தொடர்பு கொள்கின்றன, இது பல்வேறு டிப்ளாய்மென்ட் வடிவங்களை அனுமதிக்கும் வடிவத்தில் சிக்னல்களை இணைக்கிறது.
அதிக மதிப்புடன், உங்கள் வணிக மற்றும் உள்கட்டமைப்பு சூழலுடன் பரிவர்த்தனை ட்ரேஸ்களை சேகரிக்க, நீங்கள் ட்ரேஸ் சேகரிப்பை உங்கள் பயன்பாட்டில் ஒருங்கிணைக்க வேண்டும். சில தானியங்கி-இன்ஸ்ட்ரூமென்டேஷன் ஏஜெண்ட்கள் இதை கிட்டத்தட்ட எந்த முயற்சியும் இல்லாமல் செய்ய முடியும். இருப்பினும், மிகவும் நுட்பமான பயன்பாட்டு நிகழ்வுகளுக்கு பரிவர்த்தனை ட்ரேஸ்களை ஆதரிக்க உங்கள் சார்பில் குறியீடு மாற்றங்கள் தேவை. இது சில தொழில்நுட்ப கடனை உருவாக்கி உங்கள் பணிச்சுமையை ஒரு குறிப்பிட்ட தொழில்நுட்பத்துடன் இணைக்கிறது.
OTel span என்ற கருத்தைப் பயன்படுத்தி லாக்குகள், மெட்ரிக்குகள் மற்றும் ட்ரேஸ்களை சேகரிக்கிறது. Spans ஒரு பரிவர்த்தனையிலிருந்து இந்த சிக்னல்களை ஒன்றாக தொகுத்து, சூழல்படுத்தப்பட்ட, தேடக்கூடிய பொருளாக தொகுக்கிறது. இதன் பொருள் நீங்கள் ஒரு பயன்பாட்டு நிகழ்விலிருந்து உங்கள் சிக்னல்களை ஒரு எளிய நிறுவனத்தில் பார்க்கலாம். எடுத்துக்காட்டாக, ஒரு பயனர் வலைத்தளத்தில் உள்நுழைவது, இது ஒருங்கிணைக்கும் அனைத்து கீழ்நிலை சேவைகளுக்கும் உருவாக்கும் கோரிக்கைகள், ஒரு span ஆக வழங்கப்படலாம்.
OTel பயன்பாட்டு ட்ரேஸ்களுக்கு மட்டுப்படுத்தப்படவில்லை, லாக்குகள் மற்றும் மெட்ரிக்குகளுக்கும் பரவலாக பயன்படுத்தப்படுகிறது. மேலும் பல ISV தயாரிப்புகள் இன்று நேரடியாக OTLP-ஐ ஏற்கின்றன.
OTel பயன்படுத்தி உங்கள் பயன்பாடுகளை இன்ஸ்ட்ரூமென்ட் செய்வதன் மூலம், எதிர்காலத்தில் ஒரு observability தளத்திலிருந்து மற்றொன்றுக்கு மாற நீங்கள் தேர்வுசெய்தால், பயன்பாட்டு அடுக்கில் இந்த இன்ஸ்ட்ரூமென்டேஷனை மாற்ற வேண்டிய அவசியத்தை நீக்குகிறீர்கள். இது உங்கள் observability தீர்வின் ஒரு பகுதியை இருவழிக் கதவாக மாற்றுகிறது.
OTel எதிர்கால-பாதுகாப்பு, அளவிடக்கூடியது, பயன்பாட்டு குறியீட்டை மாற்றாமல் எதிர்காலத்தில் உங்கள் சேகரிப்பு மற்றும் பகுப்பாய்வு அமைப்புகளை மாற்றுவதை எளிதாக்குகிறது, இது ஒரு திறமையான இடதுக்கு நகர்வு ஆகும்.