பதிவுகள் கணினியின் ஒரு முக்கிய பகுதியாகும், இது எதிர்பார்த்தபடி வேலை செய்கிறது (அல்லது வேலை செய்யவில்லை) என்பதை நீங்கள் புரிந்து கொள்ள அனுமதிக்கிறது. மைக்ரோ சர்வீஸ் கட்டமைப்பில், பதிவுகளுடன் பணிபுரிவது ஒரு சிறப்பு ஒலிம்பியாடுக்கான தனித் துறையாக மாறும். ஒரு சில கேள்விகள் ஒரே நேரத்தில் தீர்க்கப்பட வேண்டும்:
- பயன்பாட்டிலிருந்து பதிவுகளை எழுதுவது எப்படி;
- பதிவுகளை எங்கே எழுதுவது;
- சேமிப்பு மற்றும் செயலாக்கத்திற்கான பதிவுகளை எவ்வாறு வழங்குவது;
- பதிவுகளை எவ்வாறு செயலாக்குவது மற்றும் சேமிப்பது.
தற்போது பிரபலமான கொள்கலன்மயமாக்கல் தொழில்நுட்பங்களின் பயன்பாடு சிக்கலைத் தீர்ப்பதற்கான விருப்பத் துறையில் ரேக்கின் மேல் மணலைச் சேர்க்கிறது.
யூரி புஷ்மெலெவின் "பதிவுகளை சேகரித்து வழங்கும் துறையில் உள்ள ரேக்குகளின் வரைபடம்" என்ற அறிக்கையின் டிரான்ஸ்கிரிப்ட் இதைப் பற்றியது.
ஆர்வமுள்ளவர்கள், பூனையைப் பார்க்கவும்.
என் பெயர் யூரி புஷ்மெலெவ். நான் லாசாடாவில் வேலை செய்கிறேன். இன்று நான் எங்கள் பதிவுகளை எவ்வாறு உருவாக்கினோம், அவற்றை எவ்வாறு சேகரித்தோம், அங்கு என்ன எழுதுகிறோம் என்பதைப் பற்றி பேசுவேன்.
நாங்கள் எங்கிருந்து வருகிறோம்? நாம் யார்? லாசாடா தென்கிழக்கு ஆசியாவில் உள்ள ஆறு நாடுகளில் நம்பர் 1 ஆன்லைன் சில்லறை விற்பனையாளராக உள்ளது. இந்த நாடுகள் அனைத்தும் எங்கள் தரவு மையங்களில் விநியோகிக்கப்படுகின்றன. தற்போது மொத்தம் 4 தரவு மையங்கள் உள்ளன. இது ஏன் முக்கியமானது? ஏனெனில் மையங்களுக்கு இடையே மிகவும் பலவீனமான இணைப்பு இருப்பதால் சில முடிவுகள் எடுக்கப்பட்டன. எங்களிடம் மைக்ரோ சர்வீஸ் ஆர்கிடெக்சர் உள்ளது. எங்களிடம் ஏற்கனவே 80 மைக்ரோ சர்வீஸ்கள் இருப்பதைக் கண்டு நான் ஆச்சரியப்பட்டேன். நான் பதிவுகளுடன் பணியைத் தொடங்கியபோது, அவற்றில் 20 மட்டுமே இருந்தன. மேலும் PHP பாரம்பரியத்தின் ஒரு பெரிய பகுதி உள்ளது, அதை நானும் வாழ வேண்டும் மற்றும் பொறுத்துக்கொள்ள வேண்டும். இவை அனைத்தும் தற்போது ஒரு நிமிடத்திற்கு 6 மில்லியனுக்கும் அதிகமான செய்திகளை கணினிக்கு உருவாக்குகின்றன. அடுத்து நாம் இதை எப்படி வாழ முயற்சிக்கிறோம், இது ஏன் என்று காட்டுகிறேன்.
இந்த 6 மில்லியன் செய்திகளுடன் நீங்கள் எப்படியாவது வாழ வேண்டும். அவர்களை நாம் என்ன செய்ய வேண்டும்? உங்களுக்கு தேவையான 6 மில்லியன் செய்திகள்:
- பயன்பாட்டிலிருந்து அனுப்பவும்
- விநியோகத்திற்கு ஏற்றுக்கொள்
- பகுப்பாய்வு மற்றும் சேமிப்பிற்காக வழங்கவும்.
- பகுப்பாய்வு
- எப்படியாவது சேமிக்கவும்.
மூன்று மில்லியன் செய்திகள் தோன்றியபோது, நான் அதைப் பற்றி பார்த்தேன். ஏனென்றால் நாங்கள் ஒரு சில காசுகளில் தொடங்கினோம். விண்ணப்பப் பதிவுகள் அங்கு எழுதப்பட்டுள்ளன என்பது தெளிவாகிறது. எடுத்துக்காட்டாக, என்னால் தரவுத்தளத்துடன் இணைக்க முடியவில்லை, தரவுத்தளத்துடன் இணைக்க முடிந்தது, ஆனால் என்னால் எதையும் படிக்க முடியவில்லை. ஆனால் இது தவிர, எங்கள் மைக்ரோ சர்வீஸ்கள் ஒவ்வொன்றும் ஒரு அணுகல் பதிவையும் எழுதுகின்றன. மைக்ரோ சர்வீஸில் வரும் ஒவ்வொரு கோரிக்கையும் பதிவில் பதிவு செய்யப்பட்டுள்ளது. நாம் ஏன் இதைச் செய்கிறோம்? டெவலப்பர்கள் ட்ரேஸ் செய்ய விரும்புகிறார்கள். ஒவ்வொரு அணுகல் பதிவிலும் ஒரு ட்ரேசிட் புலம் உள்ளது, இதைப் பயன்படுத்தி ஒரு சிறப்பு இடைமுகம் முழு சங்கிலியையும் பிரித்து, சுவடுகளை அழகாகக் காட்டுகிறது. கோரிக்கை எவ்வாறு சென்றது என்பதை ட்ரேஸ் காட்டுகிறது, மேலும் இது அடையாளம் தெரியாத குப்பைகளை விரைவாகச் சமாளிக்க எங்கள் டெவலப்பர்களுக்கு உதவுகிறது.
இதை வைத்து எப்படி வாழ்வது? இப்போது நான் விருப்பங்களின் புலத்தை சுருக்கமாக விவரிப்பேன் - இந்த சிக்கல் பொதுவாக எவ்வாறு தீர்க்கப்படுகிறது. பதிவுகளை சேகரித்தல், கடத்துதல் மற்றும் சேமிப்பது போன்ற பிரச்சனைகளை எவ்வாறு தீர்ப்பது.
விண்ணப்பத்திலிருந்து எழுதுவது எப்படி? வெவ்வேறு வழிகள் உள்ளன என்பது தெளிவாகிறது. குறிப்பாக, எங்கள் நாகரீகமான தோழர்கள் சொல்வது போல், சிறந்த நடைமுறை உள்ளது. எங்கள் தாத்தா சொன்னது போல் இரண்டு வகையான பழைய பள்ளிகள் உள்ளன. வேறு வழிகள் உள்ளன.
பதிவுகள் சேகரிக்கும் நிலைமை தோராயமாக அதே தான். இந்த குறிப்பிட்ட பகுதியைத் தீர்ப்பதற்கு பல விருப்பங்கள் இல்லை. அவற்றில் ஏற்கனவே அதிகமானவை உள்ளன, ஆனால் இன்னும் பல இல்லை.
ஆனால் விநியோகம் மற்றும் அடுத்தடுத்த பகுப்பாய்வு மூலம், மாறுபாடுகளின் எண்ணிக்கை வெடிக்கத் தொடங்குகிறது. ஒவ்வொரு விருப்பத்தையும் நான் இப்போது விவரிக்க மாட்டேன். தலைப்பில் ஆர்வமுள்ள அனைவருக்கும் முக்கிய விருப்பங்கள் நன்கு தெரியும் என்று நான் நினைக்கிறேன்.
லாசாடாவில் நாங்கள் அதை எப்படி செய்தோம், அது எப்படி தொடங்கியது என்பதை நான் உங்களுக்குக் காண்பிப்பேன்.
ஒரு வருடம் முன்பு நான் லாசாடாவுக்கு வந்தேன், பதிவுகள் பற்றிய திட்டத்திற்கு அனுப்பப்பட்டேன். இது இப்படி இருந்தது. விண்ணப்பப் பதிவு stdout மற்றும் stderrக்கு எழுதப்பட்டது. எல்லாம் ஒரு நாகரீகமான முறையில் செய்யப்பட்டது. ஆனால் பின்னர் டெவலப்பர்கள் அதை நிலையான ஓட்டங்களுக்கு வெளியே எறிந்தனர், பின்னர் எப்படியாவது உள்கட்டமைப்பு வல்லுநர்கள் அதைக் கண்டுபிடிப்பார்கள். உள்கட்டமைப்பு நிபுணர்கள் மற்றும் டெவலப்பர்களுக்கு இடையில், "ஓ... சரி, அவற்றை ஒரு ஷெல் மூலம் ஒரு கோப்பில் மடிக்கலாம், அவ்வளவுதான்" என்று கூறிய வெளியீட்டாளர்களும் உள்ளனர். இவை அனைத்தும் ஒரு கொள்கலனில் இருந்ததால், அவர்கள் அதை சரியான கொள்கலனிலேயே போர்த்தி, அட்டவணையை உள்ளே வரைபடமாக்கி அங்கே வைத்தார்கள். அதில் என்ன வந்தது என்பது அனைவருக்கும் தெளிவாகத் தெரியும் என்று நினைக்கிறேன்.
இப்போதைக்கு இன்னும் கொஞ்சம் பார்க்கலாம். இந்த பதிவுகளை நாங்கள் எவ்வாறு வழங்கினோம்? யாரோ ஒருவர் td-agent ஐத் தேர்ந்தெடுத்தார், அது உண்மையில் சரளமாக இருக்கிறது, ஆனால் மிகவும் சரளமாக இல்லை. இந்த இரண்டு திட்டங்களுக்கிடையிலான தொடர்பு எனக்கு இன்னும் புரியவில்லை, ஆனால் அவை ஒரே விஷயத்தைப் பற்றியதாகத் தெரிகிறது. மேலும் இந்த சரளமாக, ரூபியில் எழுதப்பட்டு, பதிவுக் கோப்புகளைப் படித்து, சில வகையான முறைகளைப் பயன்படுத்தி அவற்றை JSON இல் பாகுபடுத்தியது. பின்னர் நான் அவர்களை காஃப்காவிற்கு அனுப்பினேன். மேலும், காஃப்காவில் ஒவ்வொரு APIக்கும் 4 தனித்தனி தலைப்புகள் இருந்தன. ஏன் 4? நேரலை இருப்பதால், அரங்கேற்றம் உள்ளது, மேலும் stdout மற்றும் stderr இருப்பதால். டெவலப்பர்கள் அவற்றை உருவாக்குகிறார்கள், மேலும் உள்கட்டமைப்பு டெவலப்பர்கள் அவற்றை காஃப்காவில் உருவாக்க வேண்டும். மேலும், காஃப்கா மற்றொரு துறையால் கட்டுப்படுத்தப்பட்டது. எனவே, ஒவ்வொரு ஏபிக்கும் 4 தலைப்புகளை உருவாக்கும் வகையில் ஒரு டிக்கெட்டை உருவாக்க வேண்டியது அவசியம். எல்லோரும் அதை மறந்துவிட்டார்கள். பொதுவாக, குப்பை மற்றும் வம்பு இருந்தது.
இதை வைத்து அடுத்து என்ன செய்தோம்? நாங்கள் அதை காஃப்காவுக்கு அனுப்பினோம். பின்னர் காஃப்காவிலிருந்து பாதி மரக்கட்டைகள் லாக்ஸ்டாஷிற்கு பறந்தன. மற்ற பாதி பதிவுகள் பிரிக்கப்பட்டன. சிலர் ஒரு கிரேலாக்கிற்கும், சிலர் மற்றொரு கிரேலாக்கிற்கும் பறந்தனர். இதன் விளைவாக, இவை அனைத்தும் ஒரு மீள் தேடல் கிளஸ்டருக்குள் சென்றன. அதாவது, இந்த குழப்பம் அனைத்தும் அங்கேயே முடிந்தது. அதை செய்யாதே!
மேலே இருந்து பார்த்தால் இப்படித்தான் தெரிகிறது. அதை செய்யாதே! இங்கே சிக்கல் பகுதிகள் உடனடியாக எண்களால் குறிக்கப்படுகின்றன. அவற்றில் உண்மையில் அதிகமானவை உள்ளன, ஆனால் 6 மிகவும் சிக்கலானவை, அவற்றைப் பற்றி ஏதாவது செய்ய வேண்டும். அவற்றைப் பற்றி இப்போது தனித்தனியாகச் சொல்கிறேன்.
இங்கே (1,2,3) நாங்கள் கோப்புகளை எழுதுகிறோம், அதன்படி, ஒரே நேரத்தில் மூன்று ரேக்குகள் உள்ளன.
முதல் (1) நாம் அவற்றை எங்காவது எழுத வேண்டும். ஒரு கோப்பில் நேரடியாக எழுதும் திறனை API க்கு வழங்குவது எப்போதும் விரும்பத்தக்கதாக இருக்காது. ஏபிஐ ஒரு கொள்கலனில் தனிமைப்படுத்தப்படுவது விரும்பத்தக்கது, அல்லது இன்னும் சிறப்பாக, அது படிக்க மட்டுமே. நான் ஒரு சிஸ்டம் அட்மினிஸ்ட்ரேட்டர், எனவே இந்த விஷயங்களில் எனக்கு சற்று மாற்றுக் கருத்து உள்ளது.
இரண்டாவது புள்ளி (2,3) எங்களிடம் ஏபிஐக்கு நிறைய கோரிக்கைகள் வருகின்றன. API ஆனது ஒரு கோப்பில் நிறைய தரவுகளை எழுதுகிறது. கோப்புகள் வளர்ந்து வருகின்றன. நாம் அவற்றை சுழற்ற வேண்டும். ஏனெனில் இல்லையெனில் நீங்கள் எந்த வட்டுகளிலும் சேமித்து வைக்க முடியாது. அவற்றைச் சுழற்றுவது மோசமானது, ஏனெனில் அவை ஷெல் மூலம் கோப்பகத்திற்குத் திருப்பி விடப்படுகின்றன. அதை நாம் மறுபரிசீலனை செய்ய வழியில்லை. கைப்பிடிகளை மீண்டும் திறக்குமாறு பயன்பாட்டை நீங்கள் கூற முடியாது. ஏனென்றால் டெவலப்பர்கள் உங்களை ஒரு முட்டாள் போல் பார்ப்பார்கள்: “என்ன விளக்கங்கள்? நாங்கள் பொதுவாக stdout க்கு எழுதுகிறோம். உள்கட்டமைப்பு டெவலப்பர்கள் லாக்ரோடேட் செய்ய நகல் ட்ரங்கேட்டை உருவாக்கினர், இது கோப்பின் நகலை உருவாக்கி அசலைப் படியெடுக்கிறது. அதன்படி, இந்த நகலெடுக்கும் செயல்முறைகளுக்கு இடையில் வட்டு இடம் வழக்கமாக இயங்கும்.
(4) வெவ்வேறு APIகளில் வெவ்வேறு வடிவங்களைக் கொண்டிருந்தோம். அவை சற்று வித்தியாசமாக இருந்தன, ஆனால் regexp வேறுவிதமாக எழுதப்பட வேண்டும். இவை அனைத்தும் பப்பட் மூலம் கட்டுப்படுத்தப்பட்டதால், தங்கள் சொந்த கரப்பான் பூச்சிகளுடன் ஒரு பெரிய கொத்து வகுப்புகள் இருந்தன. கூடுதலாக, பெரும்பாலான நேரங்களில் td-ஏஜென்ட் நினைவகத்தை சாப்பிடலாம், முட்டாள்தனமாக இருக்கலாம், அது வேலை செய்வதாக பாசாங்கு செய்யலாம் மற்றும் எதுவும் செய்யாது. வெளியில் இருந்து பார்த்தால் அவர் ஒன்றும் செய்யவில்லை என்பதை புரிந்து கொள்ள முடியவில்லை. சிறப்பாக, அவர் விழுந்துவிடுவார், யாரோ அவரை பின்னர் எடுப்பார்கள். இன்னும் துல்லியமாக, ஒரு எச்சரிக்கை வரும், யாராவது சென்று அதை தங்கள் கைகளால் உயர்த்துவார்கள்.
(6) மேலும் குப்பைகள் மற்றும் கழிவுகள் மீள் தேடல் ஆகும். ஏனென்றால் அது பழைய பதிப்பு. ஏனென்றால், அப்போது எங்களிடம் அர்ப்பணிப்புள்ள மாஸ்டர்கள் இல்லை. எங்களிடம் பலவிதமான பதிவுகள் இருந்தன, அவற்றின் புலங்கள் ஒன்றுடன் ஒன்று சேரலாம். வெவ்வேறு பயன்பாடுகளிலிருந்து வெவ்வேறு பதிவுகள் ஒரே புலப் பெயர்களுடன் எழுதப்படலாம், ஆனால் உள்ளே வெவ்வேறு தரவு இருக்கலாம். அதாவது, ஒரு பதிவு புலத்தில் முழு எண்ணுடன் வருகிறது, எடுத்துக்காட்டாக, நிலை. மற்றொரு பதிவு நிலை புலத்தில் சரத்துடன் வருகிறது. நிலையான மேப்பிங் இல்லாத நிலையில், இது ஒரு அற்புதமான விஷயம். எலாஸ்டிக் தேடலில் குறியீட்டை சுழற்றிய பிறகு, முதலில் ஒரு சரத்துடன் ஒரு செய்தி வந்தால், நாம் சாதாரணமாக வாழ்கிறோம். ஆனால் முதல் ஒன்று முழு எண்ணிலிருந்து வந்திருந்தால், சரத்திலிருந்து வந்த அனைத்து அடுத்தடுத்த செய்திகளும் வெறுமனே நிராகரிக்கப்படும். ஏனெனில் புல வகை பொருந்தவில்லை.
இந்தக் கேள்விகளைக் கேட்க ஆரம்பித்தோம். குற்றவாளிகளைத் தேட வேண்டாம் என்று நாங்கள் முடிவு செய்தோம்.
ஆனால் ஏதாவது செய்ய வேண்டும்! வெளிப்படையான விஷயம் என்னவென்றால், நாம் தரநிலைகளை நிறுவ வேண்டும். எங்களிடம் ஏற்கனவே சில தரநிலைகள் இருந்தன. சிறிது நேரம் கழித்து சிலவற்றை ஆரம்பித்தோம். அதிர்ஷ்டவசமாக, அனைத்து API களுக்கும் ஒரு பதிவு வடிவம் ஏற்கனவே அந்த நேரத்தில் அங்கீகரிக்கப்பட்டது. இது சேவைகளுக்கு இடையிலான தொடர்புக்கான தரநிலைகளில் நேரடியாக எழுதப்பட்டுள்ளது. அதன்படி, பதிவுகளைப் பெற விரும்புவோர் இந்த வடிவத்தில் அவற்றை எழுத வேண்டும். இந்த வடிவத்தில் யாராவது பதிவுகளை எழுதவில்லை என்றால், நாங்கள் எதற்கும் உத்தரவாதம் அளிக்க மாட்டோம்.
அடுத்து, பதிவுகளை பதிவு செய்தல், வழங்குதல் மற்றும் சேகரிக்கும் முறைகளுக்கு ஒரு ஒருங்கிணைந்த தரநிலையை உருவாக்க விரும்புகிறேன். உண்மையில், அவற்றை எங்கே எழுதுவது, எப்படி வழங்குவது. திட்டங்கள் ஒரே நூலகத்தைப் பயன்படுத்தும் போது சிறந்த சூழ்நிலை. Go விற்கு தனி பதிவு நூலகமும், PHP க்கு தனி நூலகமும் உள்ளது. நம்மிடம் உள்ள அனைவரும் அவற்றைப் பயன்படுத்த வேண்டும். இதில் 80 சதவீதம் வெற்றி பெற்றுள்ளோம் என்றே தற்போது கூறுவேன். ஆனால் சிலர் கற்றாழையை தொடர்ந்து சாப்பிடுவார்கள்.
அங்கு (ஸ்லைடில்) "பதிவுகளை வழங்குவதற்கான SLA" அரிதாகவே தோன்றத் தொடங்குகிறது. இது இன்னும் இல்லை, ஆனால் நாங்கள் அதைச் செய்து வருகிறோம். ஏனென்றால், நீங்கள் ஒரு வினாடிக்கு N செய்திகளுக்கு மேல் எழுதினால், அத்தகைய மற்றும் அத்தகைய வடிவத்தில் நீங்கள் எழுதினால், நாங்கள் அதை அத்தகைய இடத்திற்கு வழங்குவோம் என்று உள்கட்டமைப்பு கூறும்போது இது மிகவும் வசதியானது. இதனால் பல தலைவலிகள் நீங்கும். ஒரு SLA இருந்தால், இது முற்றிலும் அற்புதம்!
பிரச்சனையை எப்படி தீர்க்க ஆரம்பித்தோம்? முக்கிய பிரச்சனை td-agent உடன் இருந்தது. எங்கள் பதிவுகள் எங்கே போனது என்று தெரியவில்லை. அவை வழங்கப்பட்டதா? அவர்கள் செல்கிறார்களா? எப்படியும் அவர்கள் எங்கே? எனவே, முதல் புள்ளி td-agent ஐ மாற்ற முடிவு செய்யப்பட்டது. அதை எதை மாற்றுவது என்பதற்கான விருப்பங்களை சுருக்கமாக இங்கே கோடிட்டுக் காட்டியுள்ளேன்.
சரளமாக. முதலில், நான் அவரை முந்தைய வேலையில் சந்தித்தேன், அவரும் அவ்வப்போது அங்கே விழுந்தார். இரண்டாவதாக, இது அதே விஷயம், சுயவிவரத்தில் மட்டுமே.
கோப்பு பீட். எங்களுக்கு எப்படி வசதியாக இருந்தது? ஏனெனில் அது கோவில் உள்ளது, மேலும் கோவில் எங்களுக்கு நிறைய நிபுணத்துவம் உள்ளது. அதன்படி, ஏதாவது நடந்தால், அதை எப்படியாவது நாமே சேர்த்துக் கொள்ளலாம். அதனால் தான் எடுக்கவில்லை. அதனால் உங்களுக்காக அதை மீண்டும் எழுதத் தொடங்க எந்த சலனமும் கூட இல்லை.
சிஸ்டம் அட்மினிஸ்ட்ரேட்டருக்கான தெளிவான தீர்வு இந்த அளவில் உள்ள அனைத்து வகையான syslogs ஆகும் (syslog-ng/rsyslog/nxlog).
அல்லது சொந்தமாக ஏதாவது எழுதுங்கள், ஆனால் இதையும் கோப்பு பீட்டையும் நிராகரித்தோம். எதையாவது எழுதினால் வணிகத்திற்கு உபயோகமான ஒன்றை எழுதுவது நல்லது. பதிவுகளை வழங்க, ஆயத்தமான ஒன்றை எடுத்துக்கொள்வது நல்லது.
எனவே, தேர்வு உண்மையில் syslog-ng மற்றும் rsyslog க்கு இடையேயான தேர்வுக்கு வந்தது. பப்பட்டில் ஏற்கனவே rsyslogக்கான வகுப்புகள் இருந்ததாலும், அவற்றுக்கிடையே தெளிவான வேறுபாட்டைக் காணாததாலும் நான் rsyslog பக்கம் சாய்ந்தேன். சிஸ்லாக் என்றால் என்ன, சிஸ்லாக் என்றால் என்ன. ஆம், சிலவற்றில் மோசமான ஆவணங்கள் உள்ளன, சில சிறந்தவை. இவரை இப்படி செய்யலாம், மற்றவர் வித்தியாசமாக செய்யலாம்.
மற்றும் rsyslog பற்றி கொஞ்சம். முதலாவதாக, இது நிறைய தொகுதிகளைக் கொண்டிருப்பதால் இது குளிர்ச்சியாக இருக்கிறது. மனிதர்கள் படிக்கக்கூடிய ரெய்னர்ஸ்கிரிப்ட் (நவீன உள்ளமைவு மொழி) உள்ளது. நிலையான கருவிகளைப் பயன்படுத்தி td-ஏஜெண்டின் நடத்தையைப் பின்பற்றுவதற்கு இது ஒரு அற்புதமான போனஸ் ஆகும், மேலும் பயன்பாடுகளுக்கு எதுவும் மாற்றப்படவில்லை. அதாவது, td-agent ஐ rsyslog என மாற்றி, மற்ற அனைத்தையும் இப்போதைக்கு விட்டுவிடுகிறோம். நாங்கள் உடனடியாக வேலை விநியோகத்தைப் பெறுகிறோம். அடுத்து, mmnormalize என்பது rsyslogல் ஒரு அற்புதமான விஷயம். இது பதிவுகளை அலச அனுமதிக்கிறது, ஆனால் Grok மற்றும் regexp ஐப் பயன்படுத்துவதில்லை. இது ஒரு சுருக்க தொடரியல் மரத்தை உருவாக்குகிறது. ஒரு கம்பைலர் மூலங்களைப் பாகுபடுத்துவது போலவே இது பதிவுகளையும் பாகுபடுத்துகிறது. இது மிக விரைவாக வேலை செய்ய உங்களை அனுமதிக்கிறது, சிறிய CPU ஐ உட்கொள்ளலாம், பொதுவாக, இது மிகவும் அருமையான விஷயம். மற்ற போனஸ்கள் உள்ளன. நான் அவர்கள் மீது தங்க மாட்டேன்.
rsyslog பல குறைபாடுகளையும் கொண்டுள்ளது. அவை போனஸ்களைப் போலவே இருக்கும். முக்கிய சிக்கல்கள் என்னவென்றால், அதை எப்படி சமைக்க வேண்டும் என்பதை நீங்கள் தெரிந்து கொள்ள வேண்டும், மேலும் நீங்கள் பதிப்பைத் தேர்ந்தெடுக்க வேண்டும்.
யுனிக்ஸ் சாக்கெட்டில் பதிவுகளை எழுதுவது என்று முடிவு செய்தோம். மேலும் /dev/log இல் இல்லை, ஏனெனில் அங்கு கணினி பதிவுகளின் குழப்பம் உள்ளது, journald இந்த பைப்லைனில் உள்ளது. எனவே தனிப்பயன் சாக்கெட்டுக்கு எழுதுவோம். நாங்கள் அதை ஒரு தனி விதியுடன் இணைப்போம். எதிலும் தலையிட வேண்டாம். எல்லாம் வெளிப்படையாகவும் புரிந்துகொள்ளக்கூடியதாகவும் இருக்கும். அதைத்தான் நாங்கள் செய்தோம். இந்த சாக்கெட்டுகள் கொண்ட அடைவு தரப்படுத்தப்பட்டு அனைத்து கொள்கலன்களுக்கும் அனுப்பப்படுகிறது. கொள்கலன்கள் தங்களுக்குத் தேவையான சாக்கெட்டைப் பார்க்கலாம், திறந்து அதில் எழுதலாம்.
ஏன் ஒரு கோப்பு இல்லை? ஏனென்றால் எல்லோரும் படித்தார்கள் , இது ஒரு கோப்பை டோக்கருக்கு அனுப்ப முயற்சித்தது, மேலும் rsyslog ஐ மறுதொடக்கம் செய்த பிறகு, கோப்பு விளக்கம் மாறியது மற்றும் டோக்கர் இந்த கோப்பை இழந்தது கண்டுபிடிக்கப்பட்டது. இது வேறு எதையாவது திறந்து வைத்திருக்கிறது, ஆனால் அவர்கள் எழுதும் சாக்கெட் அல்ல. இந்தச் சிக்கலைச் சரிசெய்வோம், அதே நேரத்தில், தடுப்புச் சிக்கலைச் சுற்றிலும் செயல்படுவோம் என்று முடிவு செய்தோம்.
Rsyslog ஸ்லைடில் சுட்டிக்காட்டப்பட்ட செயல்களைச் செய்கிறது மற்றும் பதிவுகளை ரிலே அல்லது காஃப்காவிற்கு அனுப்புகிறது. காஃப்கா பழைய வழியைப் பின்பற்றுகிறார். ரிலே - பதிவுகளை வழங்குவதற்கு தூய rsyslog ஐப் பயன்படுத்த முயற்சித்தேன். செய்தி வரிசை இல்லாமல், நிலையான rsyslog கருவிகளைப் பயன்படுத்தி. அடிப்படையில், அது வேலை செய்கிறது.
ஆனால் இந்த பகுதிக்குள் அவற்றை எவ்வாறு தள்ளுவது என்பதில் நுணுக்கங்கள் உள்ளன (Logstash/Graylog/ES). இந்த பகுதி (rsyslog-rsyslog) தரவு மையங்களுக்கு இடையே பயன்படுத்தப்படுகிறது. இங்கே ஒரு சுருக்கப்பட்ட tcp இணைப்பு உள்ளது, இது அலைவரிசையைச் சேமிக்க அனுமதிக்கிறது, அதன்படி, சேனல் அடைக்கப்படும்போது மற்றொரு தரவு மையத்திலிருந்து சில பதிவுகளைப் பெறுவதற்கான வாய்ப்பை எப்படியாவது அதிகரிக்கும். ஏனென்றால் எங்களிடம் இந்தோனேசியா உள்ளது, அங்கு எல்லாம் மோசமாக உள்ளது. இங்குதான் நிலையான பிரச்சனை உள்ளது.
பயன்பாட்டிலிருந்து நாங்கள் பதிவுசெய்த பதிவுகள் முடிவை அடையும் சாத்தியக்கூறுகளை எவ்வாறு கண்காணிக்கலாம் என்று யோசித்தோம்? அளவீடுகளை உருவாக்க முடிவு செய்தோம். rsyslog அதன் சொந்த புள்ளியியல் சேகரிப்பு தொகுதியைக் கொண்டுள்ளது, அதில் சில வகையான கவுண்டர்கள் உள்ளன. எடுத்துக்காட்டாக, இது உங்களுக்கு வரிசையின் அளவைக் காண்பிக்கும் அல்லது அத்தகைய செயலில் எத்தனை செய்திகள் வந்துள்ளன என்பதைக் காண்பிக்கும். நீங்கள் ஏற்கனவே அவர்களிடமிருந்து ஏதாவது எடுக்கலாம். கூடுதலாக, இது கட்டமைக்கக்கூடிய தனிப்பயன் கவுண்டர்களைக் கொண்டுள்ளது, மேலும் இது உங்களுக்குக் காண்பிக்கும், எடுத்துக்காட்டாக, சில API பதிவுசெய்த செய்திகளின் எண்ணிக்கை. அடுத்து, நான் பைத்தானில் rsyslog_exporter ஐ எழுதினேன், அதையெல்லாம் Prometheus க்கு அனுப்பி வரைபடங்களை உருவாக்கினோம். நாங்கள் உண்மையில் கிரேலாக் அளவீடுகளை விரும்பினோம், ஆனால் அவற்றை அமைக்க இன்னும் நேரம் கிடைக்கவில்லை.
என்ன பிரச்சனைகள் இருந்தன? எங்கள் லைவ் APIகள் வினாடிக்கு 50 ஆயிரம் செய்திகளை எழுதுவதை (திடீரென்று!) கண்டறிந்தபோது சிக்கல்கள் எழுந்தன. இது ஸ்டேஜிங் இல்லாத லைவ் ஏபிஐ மட்டுமே. மேலும் கிரேலாக் ஒரு வினாடிக்கு 12 ஆயிரம் செய்திகளை மட்டுமே காட்டுகிறது. ஒரு நியாயமான கேள்வி எழுந்தது: எச்சங்கள் எங்கே? அதிலிருந்து கிரேலாக் வெறுமனே சமாளிக்க முடியாது என்று முடிவு செய்தோம். நாங்கள் பார்த்தோம், உண்மையில், Graylog மற்றும் Elasticsearch இந்த ஓட்டத்தைக் கையாள முடியவில்லை.
அடுத்து, நாங்கள் வழியில் செய்த பிற கண்டுபிடிப்புகள்.
சாக்கெட்டுக்கான எழுத்துகள் தடுக்கப்பட்டுள்ளன. அது நடந்தது எப்படி? நான் டெலிவரிக்காக rsyslog ஐப் பயன்படுத்தும்போது, ஒரு கட்டத்தில் தரவு மையங்களுக்கு இடையே உள்ள சேனல் உடைந்தது. விநியோகம் ஒரு இடத்தில் நிறுத்தப்பட்டது, மற்றொரு இடத்தில் விநியோகம் நிறுத்தப்பட்டது. இவை அனைத்தும் rsyslog சாக்கெட்டில் எழுதும் APIகள் கொண்ட இயந்திரத்தை அடைந்துள்ளது. அங்கே ஒரு வரிசை இருந்தது. யூனிக்ஸ் சாக்கெட்டில் எழுதுவதற்கான வரிசை, இயல்பாக 128 பாக்கெட்டுகளாக இருக்கும். மேலும் பயன்பாட்டில் உள்ள அடுத்த எழுத்து() தடுக்கப்பட்டது. கோ அப்ளிகேஷன்களில் நாம் பயன்படுத்தும் லைப்ரரியைப் பார்த்தபோது, சாக்கெட்டுக்கு எழுதுவது தடையற்ற முறையில் நிகழ்கிறது என்று எழுதப்பட்டிருந்தது. எதுவும் தடுக்கப்படவில்லை என்பதில் உறுதியாக இருந்தோம். ஏனென்றால் நாம் படிக்கிறோம் அதைப் பற்றி எழுதியவர். ஆனால் ஒரு கணம் இருக்கிறது. இந்த அழைப்பைச் சுற்றி ஒரு எல்லையற்ற வளையம் இருந்தது, அதில் ஒரு செய்தியை சாக்கெட்டுக்குள் தள்ளும் முயற்சி தொடர்ந்து இருந்தது. நாங்கள் அவரை கவனிக்கவில்லை. நான் நூலகத்தை மீண்டும் எழுத வேண்டியிருந்தது. அதன் பிறகு இது பல முறை மாறிவிட்டது, ஆனால் இப்போது எல்லா துணை அமைப்புகளிலும் தடுப்பை அகற்றிவிட்டோம். எனவே, நீங்கள் rsyslog ஐ நிறுத்தலாம், மேலும் எதுவும் செயலிழக்காது.
வரிசைகளின் அளவைக் கண்காணிக்க வேண்டியது அவசியம், இது இந்த ரேக்கில் அடியெடுத்து வைப்பதைத் தவிர்க்க உதவுகிறது. முதலில், நாம் எப்போது செய்திகளை இழக்கத் தொடங்குகிறோம் என்பதைக் கண்காணிக்கலாம். இரண்டாவதாக, டெலிவரி செய்வதில் எங்களுக்கு சிக்கல்கள் இருப்பதைக் கண்காணிக்கலாம்.
மற்றொரு விரும்பத்தகாத தருணம் - மைக்ரோ சர்வீஸ் கட்டமைப்பில் 10 மடங்கு பெருக்கம் மிகவும் எளிதானது. எங்களிடம் பல உள்வரும் கோரிக்கைகள் இல்லை, ஆனால் இந்த செய்திகள் மேலும் பயணிக்கும் வரைபடத்தின் காரணமாக, அணுகல் பதிவுகள் காரணமாக, நாங்கள் உண்மையில் பதிவு சுமையை சுமார் பத்து மடங்கு அதிகரிக்கிறோம். துரதிர்ஷ்டவசமாக, சரியான எண்களைக் கணக்கிட எனக்கு நேரம் இல்லை, ஆனால் மைக்ரோ சர்வீஸ்கள் தான் அவை. இதை மனதில் கொள்ள வேண்டும். இந்த நேரத்தில் பதிவு சேகரிப்பு துணை அமைப்பு லாசாடாவில் அதிகம் ஏற்றப்பட்டுள்ளது என்று மாறிவிடும்.
மீள் தேடல் சிக்கலை எவ்வாறு தீர்ப்பது? ஒரே இடத்தில் பதிவுகளை விரைவாகப் பெற வேண்டும் என்றால், எல்லா இயந்திரங்களுக்கும் சென்று அவற்றைச் சேகரிக்காமல் இருக்க, கோப்பு சேமிப்பகத்தைப் பயன்படுத்தவும். இது வேலை செய்யும் உத்தரவாதம். இது எந்த சேவையகத்திலிருந்தும் செய்யப்படலாம். நீங்கள் அங்கு வட்டுகளை ஒட்டிக்கொண்டு syslog ஐ நிறுவ வேண்டும். இதற்குப் பிறகு, அனைத்து பதிவுகளையும் ஒரே இடத்தில் வைத்திருப்பது உறுதி. பின்னர் நீங்கள் மெதுவாக elasticsearch, graylog மற்றும் வேறு ஏதாவது உள்ளமைக்கலாம். ஆனால் உங்களிடம் ஏற்கனவே அனைத்து பதிவுகளும் இருக்கும், மேலும், போதுமான வட்டு வரிசைகள் இருக்கும் வரை அவற்றை நீங்கள் சேமிக்கலாம்.
எனது அறிக்கையின் போது, திட்டம் இப்படி இருக்கத் தொடங்கியது. கோப்பில் எழுதுவதை நடைமுறையில் நிறுத்திவிட்டோம். இப்போது, பெரும்பாலும், மீதமுள்ளவற்றை அணைப்போம். API இயங்கும் உள்ளூர் கணினிகளில், கோப்புகளுக்கு எழுதுவதை நிறுத்துவோம். முதலில், கோப்பு சேமிப்பு உள்ளது, இது நன்றாக வேலை செய்கிறது. இரண்டாவதாக, இந்த இயந்திரங்கள் தொடர்ந்து இடம் இல்லாமல் இயங்குகின்றன; இது தொடர்ந்து கண்காணிக்கப்பட வேண்டும்.
லாக்ஸ்டாஷ் மற்றும் கிரேலாக் கொண்ட இந்த பகுதி, அது உண்மையில் வெளியேறுகிறது. எனவே, அதிலிருந்து விடுபட வேண்டும். நீங்கள் ஒன்றைத் தேர்ந்தெடுக்க வேண்டும்.
லாக்ஸ்டாஷையும் கிபானாவையும் தூக்கி எறிய முடிவு செய்தோம். ஏனென்றால் எங்களிடம் பாதுகாப்புத் துறை உள்ளது. என்ன தொடர்பு? எக்ஸ்-பேக் மற்றும் ஷீல்ட் இல்லாத கிபானா பதிவுகளுக்கான அணுகல் உரிமைகளை வேறுபடுத்த உங்களை அனுமதிக்காது. அதனால்தான் கிரேலாக் எடுத்தோம். அது அனைத்தையும் கொண்டுள்ளது. எனக்கு அது பிடிக்கவில்லை, ஆனால் அது வேலை செய்கிறது. நாங்கள் புதிய வன்பொருளை வாங்கி, அங்கு புதிய கிரேலாக்கை நிறுவி, கடுமையான வடிவங்களைக் கொண்ட அனைத்து பதிவுகளையும் தனி கிரேலாக்கிற்கு மாற்றினோம். பல்வேறு வகையான ஒரே மாதிரியான துறைகளில் உள்ள பிரச்சனையை நிறுவன ரீதியாக தீர்த்தோம்.
புதிய கிரேலாக்கில் சரியாக என்ன சேர்க்கப்பட்டுள்ளது. நாங்கள் எல்லாவற்றையும் டாக்கரில் எழுதினோம். நாங்கள் பல சேவையகங்களை எடுத்து, மூன்று காஃப்கா நிகழ்வுகளை வெளியிட்டோம், 7 கிரேலாக் சர்வர்கள் பதிப்பு 2.3 (எனக்கு எலாஸ்டிக் தேடல் பதிப்பு 5 தேவை என்பதால்). இவை அனைத்தும் HDD யின் சோதனைகளின் போது எடுக்கப்பட்டது. வினாடிக்கு 100 ஆயிரம் செய்திகள் வரை அட்டவணைப்படுத்தல் விகிதத்தைக் கண்டோம். வாரத்திற்கு 140 டெராபைட் டேட்டா என்ற எண்ணிக்கையைப் பார்த்தோம்.
மீண்டும் ரேக்! எங்களிடம் இரண்டு விற்பனைகள் உள்ளன. நாங்கள் 6 மில்லியன் செய்திகளைத் தாண்டிவிட்டோம். கிரேலாக் மெல்ல நேரம் இல்லை. எப்படியாவது மீண்டும் உயிர் பிழைக்க வேண்டும்.
இப்படித்தான் பிழைத்தோம். இன்னும் சில சர்வர்கள் மற்றும் SSDகளைச் சேர்த்துள்ளோம். தற்போது நாம் இப்படித்தான் வாழ்கிறோம். இப்போது நாம் ஏற்கனவே ஒரு வினாடிக்கு 160k செய்திகளை மெல்லுகிறோம். நாங்கள் இன்னும் வரம்பை எட்டவில்லை, எனவே இதிலிருந்து உண்மையில் எவ்வளவு வெளியேற முடியும் என்பது தெளிவாகத் தெரியவில்லை.
இவை எதிர்காலத்திற்கான எங்கள் திட்டங்கள். இவற்றில், மிக முக்கியமானது அநேகமாக அதிக அளவில் கிடைக்கும். எங்களிடம் அது இன்னும் இல்லை. பல கார்கள் ஒரே மாதிரியாக கட்டமைக்கப்பட்டுள்ளன, ஆனால் இதுவரை அனைத்தும் ஒரு கார் வழியாக செல்கிறது. அவர்களுக்கு இடையே தோல்வியை அமைக்க நேரம் எடுக்கும்.
Graylog இலிருந்து அளவீடுகளை சேகரிக்கவும்.
விகித வரம்பை உருவாக்குங்கள், இதன் மூலம் எங்களின் அலைவரிசை மற்றும் மற்ற அனைத்தையும் அழிக்காத ஒரு கிரேஸி ஏபிஐ எங்களிடம் உள்ளது.
இறுதியாக, டெவலப்பர்களுடன் சில வகையான SLA இல் கையொப்பமிடுங்கள், இதனால் நாங்கள் இவ்வளவு சேவை செய்யலாம். இன்னும் எழுதினால் மன்னிக்கவும்.
மற்றும் ஆவணங்களை எழுதுங்கள்.
சுருக்கமாக, நாம் அனுபவித்த அனைத்தின் முடிவுகள். முதலில், தரநிலைகள். இரண்டாவதாக, சிஸ்லாக் கேக். மூன்றாவதாக, rsyslog ஸ்லைடில் எழுதப்பட்டதைப் போலவே செயல்படுகிறது. மற்றும் கேள்விகளுக்கு செல்லலாம்.
உங்கள் கேள்விகள்.
உங்கள் கேள்வி: ஏன் எடுக்க வேண்டாம் என்று முடிவு செய்தீர்கள்... (ஃபைல்பீட்?)
பதில்: நாம் ஒரு கோப்பில் எழுத வேண்டும். நான் உண்மையில் விரும்பவில்லை. உங்கள் API வினாடிக்கு ஆயிரக்கணக்கான செய்திகளை எழுதும் போது, நீங்கள் அதை ஒரு மணி நேரத்திற்கு ஒரு முறை சுழற்றினாலும், இது இன்னும் ஒரு விருப்பமாக இல்லை. பைப்பில் எழுதலாம். டெவலப்பர்கள் என்னிடம் கேட்டார்கள்: "நாங்கள் எழுதும் செயல்முறை செயலிழந்தால் என்ன நடக்கும்?" அவர்களுக்கு என்ன பதிலளிப்பது என்று எனக்குப் புரியவில்லை, "சரி, சரி, அதைச் செய்ய வேண்டாம்."
உங்கள் கேள்வி: நீங்கள் ஏன் HDFS க்கு பதிவுகளை எழுதக்கூடாது?
பதில்: இது அடுத்த கட்டம். நாங்கள் ஆரம்பத்தில் இதைப் பற்றி யோசித்தோம், ஆனால் இந்த நேரத்தில் இதைச் செய்வதற்கான ஆதாரங்கள் இல்லை என்பதால், அது எங்கள் நீண்ட கால தீர்வில் தொங்குகிறது.
உங்கள் கேள்வி: நெடுவரிசை வடிவம் மிகவும் பொருத்தமானதாக இருக்கும்.
பதில்: எனக்கு புரிகிறது. அதற்காக நாங்கள் இரு கரங்களுடனும் இருக்கிறோம்.
உங்கள் கேள்வி: நீங்கள் rsyslogக்கு எழுதுகிறீர்கள். அங்கு நீங்கள் TCP மற்றும் UDP இரண்டையும் பயன்படுத்தலாம். ஆனால் UDP என்றால், டெலிவரிக்கு எப்படி உத்தரவாதம் அளிப்பீர்கள்?
பதில்: இரண்டு புள்ளிகள் உள்ளன. முதலாவதாக, பதிவுகளை வழங்குவதற்கு நாங்கள் உத்தரவாதம் அளிக்க மாட்டோம் என்று நான் உடனடியாக அனைவருக்கும் சொல்கிறேன். ஏனென்றால், டெவலப்பர்கள் வந்து, “அங்கே நிதித் தரவை எழுதத் தொடங்குவோம், ஏதாவது நடந்தால் அதை எங்காவது எங்களுக்காக வைப்பீர்கள்” என்று கூறும்போது, “அருமை! சாக்கெட்டுக்கு எழுதுவதைத் தடுப்பதைத் தொடங்குவோம், மேலும் பரிவர்த்தனைகளில் இதைச் செய்யுங்கள், இதன்மூலம் நீங்கள் அதை எங்களுக்காக சாக்கெட்டில் வைத்து மறுபக்கத்தில் இருந்து அதைப் பெறுவதை உறுதிசெய்வீர்கள். இந்த நேரத்தில், அனைவருக்கும் உடனடியாக இது தேவையில்லை. இது தேவையில்லை என்றால், நாம் என்ன கேள்விகளைக் கேட்க வேண்டும்? சாக்கெட்டில் எழுதுவதற்கு நீங்கள் உத்தரவாதம் அளிக்க விரும்பவில்லை என்றால், நாங்கள் ஏன் டெலிவரிக்கு உத்தரவாதம் அளிக்க வேண்டும்? எங்களால் முடிந்த முயற்சியை செய்து வருகிறோம். நாங்கள் உண்மையில் முடிந்தவரை மற்றும் சிறந்த முறையில் வழங்க முயற்சிக்கிறோம், ஆனால் நாங்கள் 100% உத்தரவாதத்தை வழங்கவில்லை. எனவே, அங்கு நிதி தரவுகளை எழுத வேண்டிய அவசியமில்லை. இதற்கான பரிவர்த்தனைகளுடன் தரவுத்தளங்கள் உள்ளன.
உங்கள் கேள்வி: ஏபிஐ பதிவில் சில செய்திகளை உருவாக்கி, மைக்ரோ சர்வீஸுக்கு கட்டுப்பாட்டை மாற்றும் போது, வெவ்வேறு மைக்ரோ சர்வீஸ்களில் இருந்து வரும் செய்திகள் தவறான வரிசையில் வரும் என்ற சிக்கலை எதிர்கொண்டீர்களா? இதனால் குழப்பம் ஏற்படுகிறது.
பதில்: அவை வெவ்வேறு வரிசைகளில் வருவது இயல்பானது. இதற்கு நீங்கள் தயாராக இருக்க வேண்டும். ஏனெனில் எந்த நெட்வொர்க் டெலிவரியும் ஆர்டருக்கு உத்தரவாதம் அளிக்காது, அல்லது இதற்கு சிறப்பு ஆதாரங்களை நீங்கள் செலவிட வேண்டும். நாம் கோப்பு சேமிப்பகங்களை எடுத்துக் கொண்டால், ஒவ்வொரு ஏபிஐயும் அதன் சொந்த கோப்பில் பதிவுகளைச் சேமிக்கிறது. அல்லது மாறாக, rsyslog அவற்றை அடைவுகளாக வரிசைப்படுத்துகிறது. ஒவ்வொரு API க்கும் அதன் சொந்த பதிவுகள் உள்ளன, அங்கு நீங்கள் சென்று பார்க்கலாம், பின்னர் இந்த பதிவில் உள்ள நேர முத்திரையைப் பயன்படுத்தி அவற்றை ஒப்பிடலாம். அவர்கள் கிரேலாக்கில் பார்க்கச் சென்றால், அவை நேர முத்திரை மூலம் வரிசைப்படுத்தப்படும். அங்கே எல்லாம் சரியாகிவிடும்.
உங்கள் கேள்வி: நேரமுத்திரை மில்லி விநாடிகளில் மாறுபடலாம்.
பதில்: நேரமுத்திரை API ஆல் உருவாக்கப்படுகிறது. இது, உண்மையில், முழு புள்ளி. எங்களிடம் என்டிபி உள்ளது. ஏபிஐ செய்தியில் நேர முத்திரையை உருவாக்குகிறது. rsyslog அதைச் சேர்க்கவில்லை.
உங்கள் கேள்வி: தரவு மையங்களுக்கு இடையிலான தொடர்பு மிகவும் தெளிவாக இல்லை. தரவு மையத்திற்குள், பதிவுகள் எவ்வாறு சேகரிக்கப்பட்டு செயலாக்கப்பட்டன என்பது தெளிவாக உள்ளது. தரவு மையங்களுக்கு இடையிலான தொடர்பு எவ்வாறு நடைபெறுகிறது? அல்லது ஒவ்வொரு தரவு மையமும் அதன் சொந்த வாழ்க்கையை வாழ்கிறதா?
பதில்: கிட்டத்தட்ட. நம் நாட்டில், ஒவ்வொரு நாடும் ஒரு தரவு மையத்தில் அமைந்துள்ளது. இந்த நேரத்தில், ஒரு நாடு வெவ்வேறு தரவு மையங்களில் அமைந்திருக்கும் வகையில் எங்களிடம் பரவல் இல்லை. எனவே, அவற்றை இணைக்க வேண்டிய அவசியமில்லை. ஒவ்வொரு மையத்திற்கும் உள்ளே ஒரு பதிவு ரிலே உள்ளது. இது Rsyslog சேவையகம். உண்மையில் இரண்டு மேலாண்மை இயந்திரங்கள். அவர்களும் அதே மனப்பான்மை கொண்டவர்கள். ஆனால் தற்போது, அவற்றில் ஒன்றின் வழியாகத்தான் போக்குவரத்து செல்கிறது. இது அனைத்து பதிவுகளையும் ஒருங்கிணைக்கிறது. அவளிடம் வட்டு வரிசை உள்ளது. இது பதிவுகளை பதிவிறக்கம் செய்து, மத்திய தரவு மையத்திற்கு (சிங்கப்பூர்) அனுப்புகிறது, பின்னர் அவை கிரேலாக்கிற்கு அனுப்பப்படும். ஒவ்வொரு தரவு மையத்திற்கும் அதன் சொந்த கோப்பு சேமிப்பு உள்ளது. எங்கள் இணைப்பு துண்டிக்கப்பட்டால், எங்களிடம் அனைத்து பதிவுகளும் உள்ளன. அங்கேயே இருப்பார்கள். அவை அங்கு சேமிக்கப்படும்.
உங்கள் கேள்வி: அசாதாரண சூழ்நிலைகள் ஏற்பட்டால், அங்கிருந்து பதிவுகளைப் பெறுகிறீர்களா?
பதில்: நீங்கள் அங்கு (கோப்பு சேமிப்பகத்திற்கு) சென்று பார்க்கலாம்.
உங்கள் கேள்வி: நீங்கள் பதிவுகளை இழக்கவில்லை என்பதை எவ்வாறு கண்காணிப்பது?
பதில்: நாங்கள் உண்மையில் அவற்றை இழந்து வருகிறோம், அதை நாங்கள் கண்காணித்து வருகிறோம். ஒரு மாதத்திற்கு முன் கண்காணிப்பு துவங்கப்பட்டது. Go APIகள் பயன்படுத்தும் லைப்ரரியில் அளவீடுகள் உள்ளன. ஒரு சாக்கெட்டில் எத்தனை முறை எழுத முடியவில்லை என்பதை அவளால் எண்ண முடியும். தற்போது அங்கு ஒரு புத்திசாலித்தனமான ஹூரிஸ்டிக் உள்ளது. அங்கே ஒரு தாங்கல் உள்ளது. அது சாக்கெட்டில் இருந்து ஒரு செய்தியை எழுத முயற்சிக்கிறது. இடையகம் நிரம்பி வழிந்தால், அது அவற்றைக் கைவிடத் தொடங்குகிறது. அவற்றில் எத்தனை கைவிட்டன என்பதை அவர் கணக்கிடுகிறார். அங்கே மீட்டர்கள் நிரம்பி வழிய ஆரம்பித்தால், அது நமக்குத் தெரியும். அவர்கள் இப்போது ப்ரோமிதியஸுக்கும் வருகிறார்கள், நீங்கள் கிராஃபனாவில் உள்ள வரைபடங்களைக் காணலாம். நீங்கள் விழிப்பூட்டல்களை அமைக்கலாம். ஆனால் அவற்றை யாருக்கு அனுப்புவது என்பது இன்னும் தெளிவாகத் தெரியவில்லை.
உங்கள் கேள்வி: மீள் தேடலில் நீங்கள் பணிநீக்கத்துடன் பதிவுகளை சேமிக்கிறீர்கள். உங்களிடம் எத்தனை பிரதிகள் உள்ளன?
பதில்: ஒரு வரி.
உங்கள் கேள்வி: இது ஒரு வரி மட்டும்தானா?
பதில்: இது மாஸ்டர் மற்றும் பிரதி. தரவு இரண்டு பிரதிகளில் சேமிக்கப்படுகிறது.
உங்கள் கேள்வி: rsyslog இடையக அளவை எப்படியாவது சரிசெய்தீர்களா?
பதில்: தனிப்பயன் யூனிக்ஸ் சாக்கெட்டில் டேட்டாகிராம்களை எழுதுகிறோம். இது உடனடியாக நமக்கு 128 கிலோபைட் வரம்பை விதிக்கிறது. இதற்கு மேல் நாம் எழுத முடியாது. இதை நாங்கள் தரநிலையில் எழுதியுள்ளோம். சேமிப்பில் சேர விரும்புபவர்கள் 128 கிலோபைட் எழுதுகிறார்கள். நூலகங்கள், மேலும், துண்டிக்கப்பட்டு, செய்தி துண்டிக்கப்பட்டதாக ஒரு கொடி வைக்கப்படுகிறது. செய்திக்கான எங்கள் தரநிலையானது, பதிவு செய்யும் போது அது துண்டிக்கப்பட்டதா இல்லையா என்பதைக் காட்டும் சிறப்புப் புலத்தைக் கொண்டுள்ளது. எனவே இந்த தருணத்தையும் கண்காணிக்க எங்களுக்கு வாய்ப்பு உள்ளது.
கேள்வி: உடைந்த JSON என்று எழுதுகிறீர்களா?
பதில்: பாக்கெட் மிகப் பெரியதாக இருப்பதால், ரிலேயின் போது உடைந்த JSON நிராகரிக்கப்படும். அல்லது கிரேலாக் நிராகரிக்கப்படும், ஏனெனில் அது JSON பாகுபடுத்த முடியாது. ஆனால் சரி செய்யப்பட வேண்டிய நுணுக்கங்கள் உள்ளன, மேலும் அவை பெரும்பாலும் rsyslog உடன் பிணைக்கப்பட்டுள்ளன. நான் ஏற்கனவே அங்கு பல சிக்கல்களை பூர்த்தி செய்துள்ளேன், அவை இன்னும் வேலை செய்ய வேண்டும்.
கேள்வி: ஏன் காஃப்கா? நீங்கள் RabbitMQ ஐ முயற்சித்தீர்களா? அத்தகைய சுமைகளின் கீழ் கிரேலாக் தோல்வியடைகிறதா?
பதில்: கிரேலாக் மூலம் இது எங்களுக்கு வேலை செய்யவில்லை. கிரேலாக் எங்களுக்காக வடிவம் பெறுகிறது. அவர் உண்மையில் பிரச்சனைக்குரியவர். அவர் ஒரு வித்தியாசமான விஷயம். மற்றும், உண்மையில், அது தேவையில்லை. நான் rsyslog இலிருந்து நேரடியாக elasticsearch க்கு எழுத விரும்புகிறேன், பின்னர் கிபானாவைப் பார்க்க விரும்புகிறேன். ஆனால் நாங்கள் பாதுகாப்பு அதிகாரிகளுடன் பிரச்சினையை தீர்க்க வேண்டும். கிரேலாக்கை தூக்கி எறிந்துவிட்டு கிபானாவைப் பயன்படுத்தும் போது, இது நமது வளர்ச்சிக்கான சாத்தியமான விருப்பமாகும். Logstash ஐப் பயன்படுத்துவதில் எந்தப் பயனும் இல்லை. ஏனெனில் rsyslog மூலம் என்னால் அதையே செய்ய முடியும். மேலும் இது மீள் தேடலுக்கு எழுதுவதற்கான ஒரு தொகுதியைக் கொண்டுள்ளது. நாங்கள் கிரேலாக் உடன் எப்படியாவது வாழ முயற்சிக்கிறோம். நாங்கள் அதை கொஞ்சம் டியூன் செய்தோம். ஆனால் இன்னும் முன்னேற்றத்திற்கு இடம் இருக்கிறது.
காஃப்கா பற்றி. வரலாற்றில் இப்படித்தான் நடந்தது. நான் வந்தபோது, அது ஏற்கனவே இருந்தது, அதற்கு ஏற்கனவே பதிவுகள் எழுதப்பட்டன. நாங்கள் எங்கள் கிளஸ்டரை உயர்த்தி, அதில் பதிவுகளை நகர்த்தினோம். நாங்கள் அவருடைய நிர்வாகம், அவர் எப்படி உணருகிறார் என்பது எங்களுக்குத் தெரியும். RabbitMQ ஐப் பொறுத்தவரை... RabbitMQ மூலம் அது நமக்கு வேலை செய்யாது. மேலும் RabbitMQ எங்களுக்காக வடிவம் பெறுகிறது. நாங்கள் அதை தயாரிப்பில் வைத்திருக்கிறோம், அதில் சிக்கல்கள் இருந்தன. இப்போது, விற்பனைக்கு முன், அவர்கள் அவரை வசீகரிப்பார்கள், அவர் சாதாரணமாக வேலை செய்யத் தொடங்குவார். ஆனால் அதற்கு முன் அதை தயாரிப்பில் வெளியிட நான் தயாராக இல்லை. இன்னும் ஒரு புள்ளி உள்ளது. கிரேலாக் பதிப்பு AMQP 0.9 ஐப் படிக்க முடியும், மேலும் rsyslog பதிப்பு AMQP 1.0 ஐ எழுத முடியும். இரண்டையும் செய்யக்கூடிய ஒரு தீர்வும் நடுவில் இல்லை. அது ஒன்று அல்லது மற்றொன்று. எனவே, தற்போது காஃப்கா மட்டுமே. ஆனால் இது அதன் சொந்த நுணுக்கங்களையும் கொண்டுள்ளது. ஏனெனில் நாம் பயன்படுத்தும் rsyslog பதிப்பின் omkafka ஆனது, rsyslog இலிருந்து வெளியேற்றப்பட்ட முழு செய்தி இடையகத்தையும் இழக்க நேரிடும். இப்போதைக்கு சகித்துக் கொண்டோம்.
கேள்வி: நீங்கள் ஏற்கனவே காஃப்காவை வைத்திருந்ததால் அதைப் பயன்படுத்துகிறீர்களா? இனி எந்த நோக்கத்திற்காகவும் பயன்படுத்தப்படவில்லையா?
பதில்: காஃப்கா, தரவு அறிவியல் குழுவால் பயன்படுத்தப்பட்டது. இது முற்றிலும் தனியான திட்டமாகும், இது பற்றி, துரதிருஷ்டவசமாக, நான் எதுவும் சொல்ல முடியாது. எனக்கு தெரியாது. இது தரவு அறிவியல் குழுவால் நடத்தப்பட்டது. பதிவுகள் உருவாக்கப்பட்ட போது, சொந்தமாக நிறுவாதபடி அதைப் பயன்படுத்த முடிவு செய்தோம். இப்போது நாங்கள் கிரேலாக்கைப் புதுப்பித்துள்ளோம், மேலும் காஃப்காவின் பழைய பதிப்பைக் கொண்டிருப்பதால் இணக்கத்தன்மையை இழந்துவிட்டோம். நாங்கள் சொந்தமாக தொடங்க வேண்டியிருந்தது. அதே நேரத்தில், ஒவ்வொரு ஏபிஐக்கும் இந்த நான்கு தலைப்புகளை அகற்றிவிட்டோம். அனைவருக்கும் நேரலையில் ஒரு பரந்த தலைப்பை உருவாக்கினோம், எல்லா மேடைகளுக்கும் ஒரு பரந்த தலைப்பை உருவாக்கி, எல்லாவற்றையும் அங்கேயே வைத்துள்ளோம். கிரேலாக் இவை அனைத்தையும் இணையாக ஸ்கிராப் செய்கிறது.
கேள்வி: சாக்கெட்டுகளுடன் கூடிய இந்த ஷாமனிசம் நமக்கு ஏன் தேவை? கொள்கலன்களுக்கு syslog பதிவு இயக்கியைப் பயன்படுத்த முயற்சித்தீர்களா?
பதில்: இந்த கேள்வியை நாங்கள் கேட்ட நேரத்தில், டாக்கருடன் எங்கள் உறவு பதட்டமாக இருந்தது. இது டோக்கர் 1.0 அல்லது 0.9 ஆகும். டோக்கரே விசித்திரமாக இருந்தது. இரண்டாவதாக, நீங்களும் அதில் பதிவுகளை அழுத்தினால்... அது அனைத்து பதிவுகளையும் டாக்கர் டீமான் மூலம் கடந்து செல்கிறதா என்று எனக்கு சரிபார்க்கப்படாத சந்தேகம் உள்ளது. ஒரு API பைத்தியம் பிடித்தால், மீதமுள்ள APIகள் stdout மற்றும் stderr ஐ அனுப்ப முடியாது என்பதில் சிக்கித் தவிக்கின்றன. இது எங்கு கொண்டு செல்லும் என்று தெரியவில்லை. இந்த இடத்தில் Docker syslog இயக்கியை பயன்படுத்த வேண்டிய அவசியமில்லை என்ற உணர்வு மட்டத்தில் எனக்கு ஒரு சந்தேகம் உள்ளது. எங்கள் செயல்பாட்டு சோதனைத் துறை பதிவுகளுடன் அதன் சொந்த கிரேலாக் கிளஸ்டரைக் கொண்டுள்ளது. அவர்கள் டோக்கர் பதிவு இயக்கிகளைப் பயன்படுத்துகிறார்கள், அங்கு எல்லாம் நன்றாக இருக்கிறது. ஆனால் அவர்கள் உடனடியாக GELF க்கு கிரேலாக் என்று எழுதுகிறார்கள். இதையெல்லாம் நாங்கள் தொடங்கிய நேரத்தில், வேலை செய்ய எங்களுக்கு இது தேவைப்பட்டது. ஒருவேளை பிறகு, யாராவது வந்து நூறு ஆண்டுகளாக இது நன்றாக வேலை செய்கிறது என்று சொன்னால், முயற்சிப்போம்.
கேள்வி: நீங்கள் rsyslog ஐப் பயன்படுத்தி தரவு மையங்களுக்கு இடையே டெலிவரி செய்கிறீர்கள். ஏன் காஃப்கா இல்லை?
பதில்: நாங்கள் இரண்டையும் உண்மையில் செய்கிறோம். இரண்டு காரணங்களுக்காக. சேனல் முற்றிலும் இறந்துவிட்டால், எங்கள் எல்லா பதிவுகளும், சுருக்கப்பட்ட வடிவத்தில் கூட, அதன் வழியாக வலம் வராது. காஃப்கா செயல்பாட்டில் அவற்றை இழக்க உங்களை அனுமதிக்கிறது. இப்படித்தான் இந்த மரத்துண்டுகள் சிக்கிக் கொள்வதில் இருந்து விடுபடுவோம். இந்த விஷயத்தில் நாங்கள் நேரடியாக காஃப்காவைப் பயன்படுத்துகிறோம். எங்களிடம் ஒரு நல்ல சேனல் இருந்தால், அதை விடுவிக்க விரும்பினால், நாங்கள் அவர்களின் rsyslog ஐப் பயன்படுத்துகிறோம். ஆனால் உண்மையில், நீங்கள் அதை கட்டமைக்க முடியும், இதனால் அது பொருந்தாததைக் குறைக்கும். இந்த நேரத்தில், நாங்கள் நேரடியாக எங்காவது rsyslog டெலிவரியையும், எங்காவது காஃப்காவையும் பயன்படுத்துகிறோம்.
ஆதாரம்: www.habr.com