Live:CloudOps Webinars & Hands-on Workshops ·Register ↗
Skip to main content

Anti-patterns and common pitfalls

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

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

Observability ஐ ஒரு முறை முயற்சியாக கருதுதல்

Observability ஐ வரையறுக்கப்பட்ட முடிவு தேதியுடன் ஒரு வரையறுக்கப்பட்ட திட்டமாக நிலைநிறுத்துவது பழைய டாஷ்போர்டுகள், தவறாக இணைக்கப்பட்ட அல்லது அமைதியான அலாரங்கள் மற்றும் புதிய சேவைகள், சூழல்கள் மற்றும் AWS கணக்குகள் அறிமுகப்படுத்தப்படும்போது முழுமையற்ற கவரேஜுக்கு வழிவகுக்கிறது. Observability ஒரு நிலையான திறனாக நிர்வகிக்கப்பட வேண்டும், கட்டமைப்பு பரிணாமம், டிப்ளாய்மென்ட் முறைகள் மற்றும் மாறும் வணிக மற்றும் இணக்கத் தேவைகளுடன் இணைக்கப்பட்ட வழக்கமான மதிப்பாய்வுகள் மற்றும் செயற்கூறான மேம்பாடுகளுடன்.

படிப்படியான crawl-walk-run அணுகுமுறையைப் பின்பற்றாதது

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

தெளிவான நோக்கங்கள் இல்லாமல் உயர்-அளவு டெலிமெட்ரியை சேகரித்தல்

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

வரையறுக்கப்பட்ட Observability பயன்பாட்டு வழக்குகள் இல்லாமல் அனைத்து லாக்குகள், மெட்ரிக்குகள் மற்றும் ட்ரேஸ்களை முழு நம்பகத்தன்மையுடன் உள்ளெடுப்பது, குறிப்பாக உயர்-த்ரூபுட் AWS பணிச்சுமைகளில், அதிகப்படியான cardinality, குறைந்த வினவல் செயல்திறன் மற்றும் அதிக சேமிப்பு மற்றும் உள்ளீட்டு செலவுகளை ஏற்படுத்துகிறது.

ஒரே Observability விற்பனையாளருடன் முன்கூட்டிய பிணைப்பு

ஆரம்ப கட்டங்களில் கருவியாக்க நூலகங்கள், தரவு திட்டங்கள் மற்றும் runbook-களை ஒரே Observability விற்பனையாளருடன் இணைப்பது இடம்பெயர்வு அபாயத்தை அதிகரிக்கிறது. தரவு அளவு வளரும்போது செலவு மற்றும் கட்டமைப்பு நெகிழ்வுத்தன்மையையும் கட்டுப்படுத்துகிறது.

தொழில்நுட்ப மற்றும் பொருளாதார விருப்பங்களை பராமரிக்க, ஸ்டார்ட்அப்கள் கருவியாக்கம் மற்றும் தரவு போக்குவரத்துக்கு OpenTelemetry போன்ற திறந்த தரநிலைகளைப் பின்பற்றும் நிர்வகிக்கப்பட்ட சேவைகளைப் பயன்படுத்தத் தொடங்க வேண்டும். அவர்கள் போர்ட்டபிள் டெலிமெட்ரி திட்டங்களை தழுவி பல அல்லது மாற்று பின்தளங்களுக்கு தரவை அனுப்பும் விருப்பத்தை வைத்திருக்க வேண்டும்.

கருவி-மையமான Observability மாதிரியை ஏற்றுக்கொள்வது கலாச்சார-மையமான மாதிரிக்கு பதிலாக

Amazon CloudWatch, AWS X-Ray அல்லது மூன்றாம் தரப்பு APM (Application Performance Monitoring) ஒருங்கிணைப்புகள் போன்ற சேவைகள் மற்றும் அம்சங்களை செயல்படுத்துவது மட்டுமே, பொறியியல் குழுக்கள் குறியீட்டு பாதைகளை செயலில் கருவியாக்கம் செய்து தங்கள் பணிப்பாய்வுகளில் டெலிமெட்ரியைப் பயன்படுத்தாவிட்டால், திறமையான Observability ஐ அளிக்காது.

டெலிமெட்ரி மற்றும் மெட்டாடேட்டா தரநிலைகளுக்கான ஆளுகை இல்லாமை

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

வாடிக்கையாளர்-மையமான மற்றும் பயனர் அனுபவ குறிகாட்டிகளை புறக்கணித்தல்

CPU, நினைவகம் மற்றும் டிஸ்க் மெட்ரிக்குகள் போன்ற உள்கட்டமைப்பு-நிலை சிக்னல்களில் முதன்மையாக கவனம் செலுத்துவது, பயனர்-மையமான மற்றும் வணிக KPI-களை விட்டுவிடுவது சம்பவங்களின் உண்மையான வாடிக்கையாளர் தாக்கத்தை மறைக்கிறது.

வரையறுக்கப்பட்ட தரவு தக்கவைப்பு மற்றும் அடுக்கு கொள்கைகள் இல்லாமை

லாக்குகள் மற்றும் மெட்ரிக்குகளுக்கு இயல்புநிலை அல்லது வரம்பற்ற தக்கவைப்பை நம்புவது சேமிப்பு மற்றும் பகுப்பாய்வு செலவுகளில் கட்டுப்பாடற்ற வளர்ச்சிக்கு வழிவகுக்கிறது மற்றும் காலப்போக்கில் வினவல்கள் மற்றும் டாஷ்போர்டுகளின் செயல்திறனை குறைக்கலாம். ஸ்டார்ட்அப்கள் ஒவ்வொரு டெலிமெட்ரி வகுப்புக்கும் அடுக்கு தக்கவைப்பு கொள்கைகளை வரையறுக்க வேண்டும்.