கண்காணிப்பு இறந்துவிட்டதா? - நீண்ட கால கண்காணிப்பு

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

முறையான கண்காணிப்பு அமைப்பை ஒழுங்கமைப்பதில் சிக்கல் இருப்பதாக நான் நம்புகிறேன். எந்த பிரச்சனையும் இல்லை என்றால், எனது உரையில் ஒரு ஆய்வறிக்கை இருக்கும்: "தயவுசெய்து ப்ரோமிதியஸ் + கிராஃபானா மற்றும் செருகுநிரல்கள் 1, 2, 3 ஐ நிறுவவும்." துரதிருஷ்டவசமாக, அது இனி அப்படி வேலை செய்யாது. முக்கிய பிரச்சனை என்னவென்றால், மென்பொருள் கூறுகளின் அடிப்படையில் 2008 இல் இருந்த ஒன்றை அனைவரும் தொடர்ந்து நம்புகிறார்கள்.

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

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

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

அப்படி என்ன மாறிவிட்டது? - எல்லாம் மாறிவிட்டது!

2008 எல்லாம் நன்றாக இருக்கிறது

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

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

2010 சுமை அதிகரித்து வருகிறது

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

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

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

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

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

ஆனால் 10 ஆண்டுகளுக்கு ஒரு திட்டத்துடன் யாரும் வருவது அரிது.

கண்காணிப்பாளரின் விண்ணப்பம்

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

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

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

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

• இரும்பு உள்கட்டமைப்பின் செயல்பாட்டின் கண்காணிப்பு மற்றும் பிரத்தியேகங்களை அவர் புரிந்து கொள்ள வேண்டும்.
• குபெர்னெட்ஸைக் கண்காணிப்பதன் பிரத்தியேகங்களை அவர் புரிந்து கொள்ள வேண்டும் (மற்றும் எல்லோரும் “க்யூப்” க்கு செல்ல விரும்புகிறார்கள், ஏனென்றால் நீங்கள் எல்லாவற்றிலிருந்தும் சுருக்கவும், மறைக்கவும், மீதமுள்ளவற்றை நிர்வாகி கையாள்வார்) - தானே, அதன் உள்கட்டமைப்பு மற்றும் பயன்பாடுகளை எவ்வாறு கண்காணிப்பது என்பதைப் புரிந்துகொள்வது உள்ளே.
• சேவைகள் ஒருவருக்கொருவர் சிறப்பு வழிகளில் தொடர்பு கொள்கின்றன என்பதை அவர் புரிந்து கொள்ள வேண்டும், மேலும் சேவைகள் ஒருவருக்கொருவர் எவ்வாறு தொடர்பு கொள்கின்றன என்பதற்கான விவரங்களை அறிந்திருக்க வேண்டும். சில சேவைகள் ஒத்திசைவாகத் தொடர்பு கொள்ளும் திட்டத்தைப் பார்ப்பது மிகவும் சாத்தியம், ஏனென்றால் வேறு வழியில்லை. எடுத்துக்காட்டாக, பின்தளமானது REST வழியாக, gRPC வழியாக பட்டியல் சேவைக்கு செல்கிறது, தயாரிப்புகளின் பட்டியலைப் பெற்று அதைத் திருப்பித் தருகிறது. நீங்கள் இங்கே காத்திருக்க முடியாது. மற்ற சேவைகளுடன் இது ஒத்திசைவின்றி செயல்படுகிறது. ஆர்டரை டெலிவரி சேவைக்கு மாற்றவும், கடிதம் அனுப்பவும்.
  இவை அனைத்திலிருந்தும் நீங்கள் ஏற்கனவே நீந்தியிருக்கிறீர்களா? மேலும் இதை கண்காணிக்க வேண்டிய அட்மின் மேலும் குழப்பம் அடைந்தார்.
• அவர் சரியாகத் திட்டமிடவும் திட்டமிடவும் முடியும் - வேலை மேலும் மேலும் அதிகரிக்கும்.
• எனவே அவர் உருவாக்கிய சேவையில் இருந்து ஒரு மூலோபாயத்தை உருவாக்க வேண்டும். அவருக்கு திட்டத்தின் கட்டமைப்பு மற்றும் அதன் மேம்பாடு + வளர்ச்சியில் பயன்படுத்தப்படும் தொழில்நுட்பங்கள் பற்றிய புரிதல் தேவை.

முற்றிலும் சாதாரண விஷயத்தை நினைவில் கொள்வோம்: சில சேவைகள் PHP இல் உள்ளன, சில சேவைகள் Goவில் உள்ளன, சில சேவைகள் JS இல் உள்ளன. அவர்கள் எப்படியாவது ஒருவருக்கொருவர் வேலை செய்கிறார்கள். "மைக்ரோ சர்வீஸ்" என்ற வார்த்தை எங்கிருந்து வருகிறது: டெவலப்பர்கள் முழு திட்டத்தையும் புரிந்து கொள்ள முடியாத பல தனிப்பட்ட அமைப்புகள் உள்ளன. குழுவின் ஒரு பகுதியினர் JS இல் சேவைகளை எழுதுகிறார்கள், அது தாங்களாகவே வேலை செய்கிறது மற்றும் மீதமுள்ள கணினி எவ்வாறு செயல்படுகிறது என்று தெரியவில்லை. மற்ற பகுதி பைத்தானில் சேவைகளை எழுதுகிறது மற்றும் பிற சேவைகள் எவ்வாறு செயல்படுகின்றன என்பதில் தலையிடாது; அவர்கள் தங்கள் சொந்த பகுதியில் தனிமைப்படுத்தப்பட்டுள்ளனர். மூன்றாவது PHP அல்லது வேறு ஏதாவது சேவைகளை எழுதுவது.
இந்த 20 பேரும் 15 சர்வீஸ்களாகப் பிரிக்கப்பட்டுள்ளனர், இதையெல்லாம் புரிந்து கொள்ள வேண்டிய ஒரு நிர்வாகி மட்டுமே இருக்கிறார். நிறுத்து! 15 பேர் முழு அமைப்பையும் புரிந்து கொள்ள முடியாததால், நாங்கள் கணினியை 20 மைக்ரோ சர்வீஸ்களாகப் பிரித்துள்ளோம்.

ஆனால் அதை எப்படியாவது கண்காணிக்க வேண்டும் ...

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

நான் என்ன சொல்ல முடியும்... ஹூஸ்டன், எங்களுக்கு பிரச்சினைகள் உள்ளன.

ஒரு நவீன மென்பொருள் திட்டத்தை கண்காணிப்பது ஒரு மென்பொருள் திட்டமாகும்

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

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

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

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

முதலில், நீங்கள் திட்டமிட வேண்டும்.

பாடல் வரி விலக்கு: பெரும்பாலும் அவை உள்கட்டமைப்பு கண்காணிப்புடன் தொடங்குகின்றன. உதாரணமாக, எங்களிடம் குபெர்னெட்ஸ் உள்ளது. கிராஃபனாவுடன் ப்ரோமிதியஸை நிறுவி, “க்யூப்” ஐக் கண்காணிக்க செருகுநிரல்களை நிறுவுவதன் மூலம் தொடங்குவோம். டெவலப்பர்கள் மட்டுமல்ல, நிர்வாகிகளும் துரதிர்ஷ்டவசமான நடைமுறையைக் கொண்டுள்ளனர்: "நாங்கள் இந்த செருகுநிரலை நிறுவுவோம், ஆனால் சொருகி அதை எப்படி செய்வது என்று அறிந்திருக்கலாம்." முக்கியமான செயல்களைக் காட்டிலும் எளிமையான மற்றும் நேரடியானவற்றில் தொடங்க மக்கள் விரும்புகிறார்கள். மற்றும் உள்கட்டமைப்பு கண்காணிப்பு எளிதானது.

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

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

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

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

எல்லாம் நிலைகள் மூலம்

கண்காணிப்பு அமைப்பின் அமைப்பை நான் இப்படித்தான் பார்க்கிறேன்.

1) விண்ணப்ப நிலை:

• பயன்பாட்டு வணிக தர்க்கத்தை கண்காணித்தல்;
• சேவைகளின் சுகாதார அளவீடுகளை கண்காணித்தல்;
• ஒருங்கிணைப்பு கண்காணிப்பு.

2) உள்கட்டமைப்பு நிலை:

• ஆர்கெஸ்ட்ரேஷன் நிலை கண்காணிப்பு;
• கணினி மென்பொருள் கண்காணிப்பு;
• இரும்பு நிலை கண்காணிப்பு.

3) மீண்டும் பயன்பாட்டு நிலை - ஆனால் ஒரு பொறியியல் தயாரிப்பாக:

• விண்ணப்ப பதிவுகளை சேகரித்தல் மற்றும் கண்காணித்தல்;
• ஏபிஎம்;
• தடமறிதல்.

4) எச்சரிக்கை:

• ஒரு எச்சரிக்கை அமைப்பின் அமைப்பு;
• ஒரு கடமை அமைப்பின் அமைப்பு;
• "அறிவு தளம்" மற்றும் சம்பவ செயலாக்கத்திற்கான பணிப்பாய்வு அமைப்பு.

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

பயன்பாட்டு அடுக்கு - வணிக தர்க்க கண்காணிப்பு

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

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

தளம் செயல்படுகிறதா என்பதை உறுதிப்படுத்த முகப்புப் பக்கத்தைக் கண்காணிக்கும்படி அடிக்கடி கேட்கப்படும்போது, ​​புரோகிராமர்கள் ஒவ்வொரு முறையும் இழுக்கக்கூடிய ஒரு கைப்பிடியைக் கொடுக்கிறார்கள். இந்த நேரத்தில் புரோகிராமர்கள் /api/test/helloworld ஐ எடுத்து எழுதுகிறார்கள்
எல்லாம் செயல்படுவதை உறுதிப்படுத்த ஒரே வழி? - இல்லை!

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

தொழில்நுட்ப குறிப்புகள்:

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

பயன்பாட்டு அடுக்கு - சுகாதார அளவீடுகள் கண்காணிப்பு

இப்போது நாம் சேவைகளின் வெளிப்புற சுகாதார அளவீடுகளைப் பற்றி பேசுகிறோம்.

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

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

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

பயன்பாட்டு அடுக்கு - ஒருங்கிணைப்பு கண்காணிப்பு

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

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

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

நான் என்ன செய்ய பரிந்துரைக்கிறேன்:

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

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

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

உள்கட்டமைப்பு நிலை

உள்கட்டமைப்பு கண்காணிப்பு என்பது நீண்ட காலமாக தன்னைக் கண்காணிப்பதாகக் கருதப்படும் ஒன்று.

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

வணிகப் பிரிவாக விண்ணப்ப நிலை

முக்கிய புள்ளிகள்:

• ELK. இது தொழில் தரநிலை. சில காரணங்களால் நீங்கள் பதிவுகளை ஒருங்கிணைக்கவில்லை என்றால், உடனடியாக அதைச் செய்யத் தொடங்குங்கள்.
• ஏபிஎம். பயன்பாட்டு கண்காணிப்பை விரைவாக மூடுவதற்கான ஒரு வழியாக வெளிப்புற APMகள் (NewRelic, BlackFire, Datadog). உங்களுக்கு என்ன நடக்கிறது என்பதை எப்படியாவது புரிந்துகொள்ள தற்காலிகமாக இந்த விஷயத்தை நிறுவலாம்.
• தடமறிதல். டஜன் கணக்கான மைக்ரோ சர்வீஸ்களில், நீங்கள் எல்லாவற்றையும் கண்டுபிடிக்க வேண்டும், ஏனென்றால் கோரிக்கை இனி சொந்தமாக இருக்காது. பின்னர் சேர்ப்பது மிகவும் கடினம், எனவே வளர்ச்சியில் தடமறிவதை உடனடியாக திட்டமிடுவது நல்லது - இது டெவலப்பர்களின் வேலை மற்றும் பயன்பாடு. நீங்கள் இன்னும் செயல்படுத்தவில்லை என்றால், அதை செயல்படுத்தவும்! ஜெகர்/ஜிப்கின் பார்க்கவும்

எச்சரிக்கை

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

தொழில்நுட்ப அடுக்கு

எங்கள் ஸ்டாக் பின்வருமாறு என்று கற்பனை செய்யலாம்:

• தரவு சேகரிப்பு - Prometheus + Grafana;
• பதிவு பகுப்பாய்வு - ELK;
• APM அல்லது ட்ரேசிங்கிற்கு - ஜெகர் (ஜிப்கின்).

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

சமீபத்தில் எல்லா இடங்களிலும் நான் பார்க்கும் சில தொழில்நுட்ப புள்ளிகள்:

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

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

கண்டுபிடிப்புகள்

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

இது செயிண்ட் ஹைலோட்++ மாநாட்டின் அறிக்கையின் விரிவாக்கப்பட்ட பதிப்பாகும்.

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

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