SRE (தள நம்பகத்தன்மை பொறியியல்) என்பது வலைத் திட்டங்களின் கிடைக்கும் தன்மையை உறுதி செய்வதற்கான அணுகுமுறையாகும். இது DevOps க்கான கட்டமைப்பாகக் கருதப்படுகிறது மற்றும் DevOps நடைமுறைகளைப் பயன்படுத்துவதில் வெற்றியை எவ்வாறு அடைவது என்பது பற்றி பேசுகிறது. இந்த கட்டுரையில் மொழிபெயர்ப்பு அத்தியாயங்கள் 6 விநியோகிக்கப்பட்ட அமைப்புகள் கண்காணிப்பு புத்தகங்கள் தளத்தின் நம்பகத்தன்மை பொறியியல் Google இலிருந்து. இந்த மொழிபெயர்ப்பை நானே தயார் செய்து, கண்காணிப்பு செயல்முறைகளைப் புரிந்து கொள்வதில் எனது சொந்த அனுபவத்தை நம்பியிருந்தேன். டெலிகிராம் சேனலில் @monitorim_it и மீடியத்தில் வலைப்பதிவு சேவை நிலை இலக்குகள் பற்றிய அதே புத்தகத்தின் 4 ஆம் அத்தியாயத்தின் மொழிபெயர்ப்பிற்கான இணைப்பையும் வெளியிட்டேன்.

பூனையின் மொழிபெயர்ப்பு. படித்து மகிழுங்கள்!

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

வரையறுக்க

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

கண்காணிப்பு

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

வெள்ளை பெட்டி கண்காணிப்பு

பதிவுகள், ஜாவா விர்ச்சுவல் மெஷின் விவரக்குறிப்பு அளவீடுகள் அல்லது உள் புள்ளிவிவரங்களை உருவாக்கும் HTTP ஹேண்ட்லர் அளவீடுகள் உள்ளிட்ட உள் அமைப்பு கூறுகளால் காட்டப்படும் அளவீடுகளின் அடிப்படையில் கண்காணிப்பு.

கருப்பு பெட்டி கண்காணிப்பு

பயனரின் பார்வையில் இருந்து பயன்பாட்டு நடத்தை சோதனை.

டாஷ்போர்டு

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

எச்சரிக்கை (அறிவிப்பு)

மின்னஞ்சல் அல்லது பிற வழிகளில் ஒருவரால் பெறப்படும் அறிவிப்புகள், பிழைகள் அல்லது கோரிக்கை வரிசையின் அதிகரிப்பால் தூண்டப்படலாம். அறிவிப்புகள் பின்வருமாறு வகைப்படுத்தப்படுகின்றன: டிக்கெட்டுகள், மின்னஞ்சல் விழிப்பூட்டல்கள் மற்றும் உடனடி தூதர் செய்திகள்.

மூல காரணம்

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

முனை மற்றும் இயந்திரம் (முனை மற்றும் இயந்திரம்)

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

• ஒன்றோடொன்று இணைக்கப்பட்டுள்ளது: எடுத்துக்காட்டாக, கேச்சிங் சர்வர் மற்றும் வெப் சர்வர்;
• ஒரு வன்பொருளில் தொடர்பில்லாத சேவைகள்: எடுத்துக்காட்டாக, ஒரு குறியீடு களஞ்சியம் மற்றும் உள்ளமைவு அமைப்பிற்கான வழிகாட்டி, பப்பட் அல்லது செஃப்.

புஷ்

மென்பொருள் உள்ளமைவில் ஏதேனும் மாற்றம்.

கண்காணிப்பு ஏன் தேவைப்படுகிறது?

பயன்பாடுகள் கண்காணிக்கப்படுவதற்கு பல காரணங்கள் உள்ளன:

நீண்ட கால போக்குகளின் பகுப்பாய்வு

தரவுத்தளம் எவ்வளவு பெரியது மற்றும் எவ்வளவு வேகமாக வளர்ந்து வருகிறது? தினசரி பயனர்களின் எண்ணிக்கை எவ்வாறு மாறுகிறது?

செயல்திறன் ஒப்பீடு

Ajax DB 2.72 உடன் ஒப்பிடும்போது Acme Bucket of Bytes 3.14 இல் கோரிக்கைகள் வேகமாக உள்ளதா? கூடுதல் முனை தோன்றிய பிறகு கோரிக்கைகள் எவ்வளவு சிறப்பாக சேமிக்கப்படுகின்றன? கடந்த வாரத்துடன் ஒப்பிடும்போது தளம் மெதுவாக இயங்குகிறதா?

எச்சரிக்கை (அறிவிப்புகள்)

ஏதோ உடைந்துவிட்டது, யாராவது அதை சரிசெய்ய வேண்டும். அல்லது ஏதாவது விரைவில் உடைந்துவிடும், யாராவது அதை விரைவில் சரிபார்க்க வேண்டும்.

டாஷ்போர்டுகளை உருவாக்குதல்

டாஷ்போர்டுகள் அடிப்படைக் கேள்விகளுக்குப் பதிலளிக்க வேண்டும் மற்றும் ஏதாவது ஒன்றைச் சேர்க்க வேண்டும் "4 தங்க சமிக்ஞைகள்" — தாமதங்கள் (தாமதம்), போக்குவரத்து (போக்குவரத்து), பிழைகள் (பிழைகள்) மற்றும் சுமை அளவு (செறிவு).

பின்னோக்கி பகுப்பாய்வு நடத்துதல் (பிழைத்திருத்தம்)

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

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

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

கண்காணிப்பு அமைப்புக்கான நியாயமான எதிர்பார்ப்புகளை அமைத்தல்

சிக்கலான பயன்பாட்டிற்கான கண்காணிப்பை அமைப்பது சிக்கலான பொறியியல் பணியாகும். சேகரிப்பு, காட்சி மற்றும் விழிப்பூட்டல் கருவிகளின் குறிப்பிடத்தக்க உள்கட்டமைப்புடன் கூட, 10-12 உறுப்பினர்களைக் கொண்ட Google SRE குழு பொதுவாக ஒன்று அல்லது இரண்டு நபர்களை உள்ளடக்கியது, அவர்களின் முதன்மை நோக்கம் கண்காணிப்பு அமைப்புகளை உருவாக்குவதும் பராமரிப்பதும் ஆகும். கண்காணிப்பு உள்கட்டமைப்பை ஒருங்கிணைத்து மையப்படுத்துவதால் காலப்போக்கில் இந்த எண்ணிக்கை குறைந்துள்ளது, ஆனால் ஒவ்வொரு SRE குழுவிலும் குறைந்தபட்சம் ஒருவரையாவது கண்காணிப்பதற்காக மட்டுமே அர்ப்பணிக்கிறார்கள். கண்காணிப்பு சிஸ்டம் டாஷ்போர்டுகள் பார்ப்பதற்கு மிகவும் சுவாரஸ்யமாக இருக்கும் அதே வேளையில், SRE குழுக்கள் சிக்கலைக் கண்காணிக்க யாராவது திரையைப் பார்க்க வேண்டிய சூழ்நிலைகளை கவனமாகத் தவிர்க்கின்றன.

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

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

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

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

அறிகுறிகள் மற்றும் காரணங்கள்

உங்கள் கண்காணிப்பு அமைப்பு இரண்டு கேள்விகளுக்கு பதிலளிக்க வேண்டும்: "என்ன உடைந்தது" மற்றும் "ஏன் உடைந்தது."
"என்ன உடைந்தது" அறிகுறியைப் பற்றி பேசுகிறது, மேலும் "ஏன் உடைந்தது" காரணம் பற்றி பேசுகிறது. கீழே உள்ள அட்டவணை அத்தகைய இணைப்புகளின் எடுத்துக்காட்டுகளைக் காட்டுகிறது.

ஒரு அறிகுறி
காரணம்

HTTP பிழை 500 அல்லது 404 ஐப் பெறுகிறது
தரவுத்தள சேவையகங்கள் இணைப்புகளை நிராகரிக்கின்றன

மெதுவான சேவையக பதில்கள்
உயர் CPU பயன்பாடு அல்லது சேதமடைந்த ஈதர்நெட் கேபிள்

அண்டார்டிகாவில் உள்ள பயனர்கள் பூனை GIFகளைப் பெறுவதில்லை
உங்கள் CDN விஞ்ஞானிகள் மற்றும் பூனைகளை வெறுக்கிறது, எனவே சில IP முகவரிகள் தடுப்புப்பட்டியலில் முடிந்தது

எல்லா இடங்களிலிருந்தும் தனிப்பட்ட உள்ளடக்கம் கிடைக்கிறது
புதிய மென்பொருள் வெளியீட்டின் வெளியீடு ஃபயர்வால் அனைத்து ACLகளையும் மறந்து அனைவரையும் உள்ளே அனுமதித்தது

"என்ன" மற்றும் "ஏன்" என்பது அதிகபட்ச சமிக்ஞை மற்றும் குறைந்தபட்ச சத்தத்துடன் ஒரு நல்ல கண்காணிப்பு அமைப்பை உருவாக்குவதற்கான மிக முக்கியமான கட்டுமானத் தொகுதிகள் ஆகும்.

கருப்பு பெட்டி vs வெள்ளை பெட்டி

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

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

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

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

நான்கு தங்க சமிக்ஞைகள்

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

தாமதம்

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

போக்குவரத்து

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

பிழைகள்

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

செறிவூட்டல்

உங்கள் சேவை எவ்வளவு தீவிரமாகப் பயன்படுத்தப்படுகிறது என்பதை மெட்ரிக் காட்டுகிறது. இது மிகவும் கட்டுப்படுத்தப்பட்ட வளங்களை அடையாளம் காணும் ஒரு கணினி கண்காணிப்பு நடவடிக்கையாகும் (உதாரணமாக, நினைவக-கட்டுப்படுத்தப்பட்ட கணினியில், நினைவகத்தைக் காட்டுகிறது, I/O-கட்டுப்படுத்தப்பட்ட கணினியில், I/Os எண்ணிக்கையைக் காட்டுகிறது). பல அமைப்புகள் 100% பயன்பாட்டை அடைவதற்கு முன்பே செயல்திறனைக் குறைக்கின்றன, எனவே பயன்பாட்டு இலக்கைக் கொண்டிருப்பது முக்கியம்.

சிக்கலான அமைப்புகளில், செறிவூட்டலை உயர்-நிலை சுமை அளவீடுகள் மூலம் பூர்த்தி செய்ய முடியும்: உங்கள் சேவையானது இரட்டை போக்குவரத்தை சரியாகக் கையாள முடியுமா, 10% கூடுதல் போக்குவரத்தை மட்டுமே கையாள முடியுமா அல்லது தற்போது இருப்பதை விட குறைவான போக்குவரத்தைக் கையாள முடியுமா? கோரிக்கையின் சிக்கலான தன்மையை மாற்றும் அளவுருக்கள் இல்லாத எளிய சேவைகளுக்கு (எடுத்துக்காட்டுக்கு, "எனக்கு ஒன்றும் கொடு" அல்லது "எனக்கு ஒரு தனித்துவமான ஒற்றை மோனோடோனிக் முழு எண் தேவை"), இது அரிதாகவே உள்ளமைவை மாற்றும், நிலையான சுமை சோதனை மதிப்பு போதுமானதாக இருக்கலாம். இருப்பினும், முந்தைய பத்தியில் விவாதிக்கப்பட்டபடி, பெரும்பாலான சேவைகள் CPU பயன்பாடு அல்லது பிணைய அலைவரிசை போன்ற மறைமுக சமிக்ஞைகளைப் பயன்படுத்த வேண்டும், அவை அறியப்பட்ட மேல் வரம்பைக் கொண்டுள்ளன. தாமதத்தை அதிகரிப்பது பெரும்பாலும் செறிவூட்டலின் முன்னணி குறிகாட்டியாகும். ஒரு சிறிய சாளரத்தில் (எ.கா., ஒரு நிமிடம்) 99வது சதவீத மறுமொழி நேரத்தை அளவிடுவது, செறிவூட்டலின் ஆரம்ப சமிக்ஞையை வழங்க முடியும்.

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

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

"வால்" (அல்லது கருவி மற்றும் செயல்திறன்) பற்றிய கவலைகள்

புதிதாக ஒரு கண்காணிப்பு அமைப்பை உருவாக்கும் போது, ​​சராசரி மதிப்புகளின் அடிப்படையில் ஒரு அமைப்பை உருவாக்க ஒரு தூண்டுதல் உள்ளது: சராசரி தாமதம், சராசரி CPU பயன்பாடு முனைகள் அல்லது சராசரி தரவுத்தள முழுமை. கடைசி இரண்டு எடுத்துக்காட்டுகளின் ஆபத்து வெளிப்படையானது: செயலிகள் மற்றும் தரவுத்தளங்கள் மிகவும் கணிக்க முடியாத வகையில் அகற்றப்படுகின்றன. தாமதத்திற்கும் இது பொருந்தும். வினாடிக்கு 100 கோரிக்கைகளுடன் சராசரியாக 1000ms தாமதத்துடன் இணைய சேவையை இயக்கினால், 1% கோரிக்கைகளுக்கு 5 வினாடிகள் ஆகலாம். பயனர்கள் இது போன்ற பல இணையச் சேவைகளைச் சார்ந்திருந்தால், ஒரு பின்தளத்தின் 99வது சதவீதம் எளிதாக முன்பக்கத்தின் சராசரி மறுமொழி நேரமாக மாறும்.

கோரிக்கைகளின் மெதுவான சராசரி மற்றும் மிகவும் மெதுவான கோரிக்கைகளை வேறுபடுத்துவதற்கான எளிய வழி, உண்மையான தாமதங்களை விட புள்ளிவிவரங்களில் வெளிப்படுத்தப்பட்ட கோரிக்கைகளின் அளவீடுகளை சேகரிப்பதாகும் (காட்டுவதற்கான ஒரு நல்ல கருவி ஹிஸ்டோகிராம்கள்) மற்றும் 0 ms, 10 ms மற்றும் 10 ms இடையே, 30 ms மற்றும் 30 ms இடையே, 100 ms மற்றும் 100 ms, முதலியன கோரிக்கைகள்.

அளவீடுகளுக்கு சரியான அளவிலான விவரங்களைத் தேர்ந்தெடுப்பது

கணினியின் வெவ்வேறு கூறுகள் வெவ்வேறு நிலைகளில் அளவிடப்பட வேண்டும். உதாரணத்திற்கு:

• ஒரு குறிப்பிட்ட காலப்பகுதியில் CPU பயன்பாட்டைக் கண்காணிப்பது அதிக தாமதங்களுக்கு வழிவகுக்கும் நீண்ட கால ஸ்பைக்களைக் காட்டாது.
• மறுபுறம், வருடத்திற்கு 9 மணிநேரத்திற்கு மேல் வேலையில்லா நேரத்தை (99,9% வருடாந்திர இயக்க நேரம்) இலக்காகக் கொண்ட ஒரு இணைய சேவைக்கு, HTTP 200 பதிலை நிமிடத்திற்கு ஒன்று அல்லது இரண்டு முறைக்கு மேல் சரிபார்ப்பது தேவையில்லாமல் அடிக்கடி இருக்கும்.
• அதேபோல, 99,9-1 நிமிடங்களுக்கு ஒரு முறைக்கு மேல் 2% கிடைக்கும் ஹார்ட் டிரைவ் இடத்தைச் சரிபார்ப்பது அவசியமில்லை.

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

1. ஒவ்வொரு நொடியும் CPU சுமையை அளவிடவும்.
2. விவரங்களை 5% ஆகக் குறைக்கவும்.
3. ஒவ்வொரு நிமிடமும் அளவீடுகளை ஒருங்கிணைக்கவும்.

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

முடிந்தவரை எளிமையானது, ஆனால் எளிமையானது அல்ல

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

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

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

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

• உண்மை சம்பவங்களை அடிக்கடி பிடிக்கும் விதிகள் முடிந்தவரை எளிமையாகவும், யூகிக்கக்கூடியதாகவும், நம்பகமானதாகவும் இருக்க வேண்டும்.
• எப்போதாவது செய்யப்படும் தரவு சேகரிப்பு, திரட்டுதல் மற்றும் விழிப்பூட்டலுக்கான உள்ளமைவு (உதாரணமாக, சில SRE குழுக்களுக்கு காலாண்டுக்கு குறைவானது) அகற்றப்பட வேண்டும்.
• சேகரிக்கப்பட்ட ஆனால் எந்த மாதிரிக்காட்சி டாஷ்போர்டிலும் காட்டப்படாத அல்லது எந்த விழிப்பூட்டலாலும் பயன்படுத்தப்படும் அளவீடுகள் நீக்கப்படுவதற்கு தகுதியானவை.

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

கொள்கைகளை ஒன்றாக இணைத்தல்

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

கண்காணிப்பு மற்றும் எச்சரிக்கை விதிகளை உருவாக்கும் போது, ​​பின்வரும் கேள்விகளைக் கேட்பது தவறான நேர்மறைகள் மற்றும் தேவையற்ற விழிப்பூட்டல்களைத் தவிர்க்க உதவும்:

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

இந்த கேள்விகள் விழிப்பூட்டல்கள் மற்றும் எச்சரிக்கை அமைப்புகளின் அடிப்படை தத்துவத்தை பிரதிபலிக்கின்றன:

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

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

நீண்ட கால கண்காணிப்பு

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

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

பிக்டேபிள் SRE: எ டேல் ஆஃப் ஓவர்-அலர்ட்

கூகிளின் உள்கட்டமைப்பு பொதுவாக வழங்கப்பட்டு சேவை நிலைக்கு (SLO) எதிராக அளவிடப்படுகிறது. பல ஆண்டுகளுக்கு முன்பு, பிக்டேபிளின் சேவை SLO ஆனது நேரடி கிளையண்டை உருவகப்படுத்தும் செயற்கை பரிவர்த்தனையின் சராசரி செயல்திறனை அடிப்படையாகக் கொண்டது. பிக்டேபிள் மற்றும் சேமிப்பக அடுக்கின் கீழ் நிலைகளில் உள்ள சிக்கல்கள் காரணமாக, சராசரி செயல்திறன் "பெரிய" வால் மூலம் இயக்கப்படுகிறது: மோசமான 5% வினவல்கள் மற்றவற்றை விட கணிசமாக மெதுவாக இருந்தன.

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

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

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

ஜிமெயில்: கணிக்கக்கூடிய, அல்காரிதமிக் மனித பதில்கள்

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

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

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

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

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

நீண்ட கால

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

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

முடிவுக்கு

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

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

மொழிபெயர்ப்பை இறுதிவரை படித்ததற்கு நன்றி. கண்காணிப்பு பற்றி எனது டெலிகிராம் சேனலுக்கு குழுசேரவும் @monitorim_it и மீடியத்தில் வலைப்பதிவு.

ஆதாரம்: www.habr.com