යූරි බුෂ්මෙලෙව් "ලොග් එකතු කිරීමේ සහ බෙදා හැරීමේ ක්ෂේත්‍රයේ රේක් සිතියම" - වාර්තාවේ පිටපත

ලඝු-සටහන් පද්ධතියේ වැදගත් අංගයක් වන අතර, එය අපේක්ෂිත පරිදි ක්‍රියා කරන (හෝ ක්‍රියා නොකරන) බව ඔබට තේරුම් ගැනීමට ඉඩ සලසයි. ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පය තුළ, ලොග් සමඟ වැඩ කිරීම විශේෂ ඔලිම්පියාඩ් සඳහා වෙනම විනයක් බවට පත්වේ. ප්‍රශ්න සමූහයක් එකවර විසඳිය යුතුය:

• යෙදුමකින් ලඝු-සටහන් ලියන්නේ කෙසේද;
• ලඝු-සටහන් ලිවිය යුතු ස්ථානය;
• ගබඩා කිරීම සහ සැකසීම සඳහා ලඝු-සටහන් ලබා දෙන්නේ කෙසේද;
• ලොග් සැකසීම සහ ගබඩා කරන්නේ කෙසේද.

දැනට ප්‍රචලිත බහාලුම්කරණ තාක්ෂණයන් භාවිතයෙන් ගැටලුව විසඳීම සඳහා විකල්ප ක්ෂේත්‍රයට පෝරකයට ඉහළින් වැලි එක් කරයි.

යූරි බුෂ්මෙලෙව්ගේ “ලොග් එකතු කිරීමේ සහ බෙදා හැරීමේ ක්‍ෂේත්‍රයේ රේක් සිතියම” යන වාර්තාවේ පිටපත හරියටම මෙයයි.

කවුද ගණන් ගන්නේ, කරුණාකර පූසා යට.

මගේ නම යූරි බුෂ්මෙලෙව්. මම Lazada එකේ වැඩ කරනවා. අද මම කතා කරන්නේ අපි අපේ ලඝු-සටහන් සෑදූ ආකාරය, අපි ඒවා එකතු කළ ආකාරය සහ අප එහි ලියන දේ ගැන ය.

අපි කොහෙන්ද? අපි කවුද? Lazada යනු අග්නිදිග ආසියාවේ රටවල් හයක අංක 1 අන්තර්ජාල සිල්ලර වෙළෙන්දා වේ. මෙම සියලු රටවල් අපගේ දත්ත මධ්‍යස්ථාන අතර බෙදා හැරේ. දැනට මුළු දත්ත මධ්‍යස්ථාන 4ක් ඇත.මෙය වැදගත් වන්නේ ඇයි? මක්නිසාද යත් සමහර තීරණ වලට හේතු වූයේ කේන්ද්‍රස්ථාන අතර ඉතා දුර්වල සම්බන්ධයක් පැවතීමයි. අපට ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයක් ඇත. අප සතුව දැනටමත් ක්ෂුද්‍ර සේවා 80 ක් ඇති බව දැකීමෙන් මම පුදුමයට පත් විය. මම ලඝු-සටහන් සමඟ කර්තව්‍යය ආරම්භ කරන විට, ඒවායින් 20 ක් පමණි. ඊට අමතරව, තරමක් විශාල PHP උරුමයක් ඇත, එය මට ජීවත් වීමට සහ ඉවසා සිටීමට සිදු වේ. මේ සියල්ල දැනට සමස්ත පද්ධතිය සඳහා මිනිත්තුවකට පණිවිඩ මිලියන 6 කට වඩා ජනනය කරයි. ඊළඟට මම පෙන්වන්නම් අපි මේ සමඟ ජීවත් වීමට උත්සාහ කරන්නේ කෙසේද සහ මෙය එසේ වන්නේ ඇයි?

ඔබට මෙම මිලියන 6 පණිවිඩ සමඟ කෙසේ හෝ ජීවත් විය යුතුය. අපි ඔවුන් සමඟ කළ යුත්තේ කුමක්ද? ඔබට අවශ්‍ය පණිවිඩ මිලියන 6ක්:

• යෙදුමෙන් යවන්න
• භාරදීම සඳහා පිළිගන්න
• විශ්ලේෂණය සහ ගබඩා කිරීම සඳහා ලබා දෙන්න.
• විශ්ලේෂණය කරන්න
• එය කෙසේ හෝ ගබඩා කරන්න.

මිලියන තුනක් පණිවිඩයක් දිස් වූ විට, මම එයම බැලුවෙමි. මොකද අපි පටන් ගත්තේ සත කිහිපයකින්. යෙදුම් ලඝු-සටහන් එහි ලියා ඇති බව පැහැදිලිය. උදාහරණයක් ලෙස, මට දත්ත සමුදායට සම්බන්ධ වීමට නොහැකි විය, මට දත්ත සමුදායට සම්බන්ධ වීමට හැකි වූ නමුත් මට කිසිවක් කියවිය නොහැක. නමුත් මෙයට අමතරව, අපගේ සෑම ක්ෂුද්‍ර සේවාවක්ම ප්‍රවේශ ලොගයක් ද ලියයි. microservice වෙත පැමිණෙන සෑම ඉල්ලීමක්ම ලොගයේ සටහන් වේ. ඇයි අපි මෙහෙම කරන්නේ? සංවර්ධකයින්ට සොයා ගැනීමට හැකි වීමට අවශ්‍යයි. සෑම ප්‍රවේශ ලොගයකම ලුහුබැඳීම් ක්ෂේත්‍රයක් අඩංගු වන අතර, එය භාවිතා කරමින් විශේෂ අතුරු මුහුණතක් සම්පූර්ණ දාමය දිගහැර, හෝඩුවාව අලංකාර ලෙස පෙන්වයි. ඉල්ලීම සිදු වූ ආකාරය හෝඩුවාවක් පෙන්වයි, මෙය අපගේ සංවර්ධකයින්ට ඕනෑම හඳුනා නොගත් කසළ සමඟ ඉක්මනින් කටයුතු කිරීමට උපකාරී වේ.

මෙය සමඟ ජීවත් වන්නේ කෙසේද? දැන් මම විකල්ප ක්ෂේත්‍රය කෙටියෙන් විස්තර කරමි - මෙම ගැටළුව සාමාන්‍යයෙන් විසඳන ආකාරය. ලඝු-සටහන් එකතු කිරීම, සම්ප්රේෂණය කිරීම සහ ගබඩා කිරීම පිළිබඳ ගැටළුව විසඳන්නේ කෙසේද?

යෙදුමකින් ලියන්නේ කෙසේද? විවිධ ක්රම ඇති බව පැහැදිලිය. විශේෂයෙන්, අපගේ විලාසිතාමය සහෝදරවරු අපට පවසන පරිදි හොඳම භාවිතයක් ඇත. අපේ සීයලා කියපු විදියට පරණ ඉස්කෝලේ වර්ග දෙකක් තියෙනවා. වෙනත් ක්රම තිබේ.

ලඝු-සටහන් එකතු කිරීමේ තත්වය ආසන්න වශයෙන් සමාන වේ. මෙම විශේෂිත කොටස විසඳීම සඳහා බොහෝ විකල්ප නොමැත. ඒවායින් දැනටමත් වැඩි ගණනක් ඇත, නමුත් තවමත් බොහෝ නොවේ.

නමුත් බෙදා හැරීම සහ පසුව විශ්ලේෂණය සමඟ, වෙනස්කම් ගණන පුපුරා යාමට පටන් ගනී. මම දැන් එක් එක් විකල්පය විස්තර නොකරමි. මාතෘකාව ගැන උනන්දුවක් දක්වන සෑම කෙනෙකුටම ප්රධාන විකල්පයන් හොඳින් දන්නා බව මම සිතමි.

අපි Lazada හිදී එය කළ ආකාරය සහ එය සැබවින්ම ආරම්භ වූ ආකාරය මම ඔබට පෙන්වන්නම්.

වසරකට පෙර මම Lazada වෙත පැමිණි අතර ලොග් ගැන ව්යාපෘතියකට යවන ලදි. එය මේ වගේ දෙයක් විය. යෙදුම් ලොගය stdout සහ stderr වෙත ලියා ඇත. සෑම දෙයක්ම විලාසිතාවට අනුව සිදු කරන ලදී. නමුත් පසුව සංවර්ධකයින් එය සම්මත ප්‍රවාහයෙන් ඉවතට විසි කළ අතර, කෙසේ හෝ යටිතල පහසුකම් විශේෂඥයින් එය සොයා ගනු ඇත. යටිතල පහසුකම් විශේෂඥයින් සහ සංවර්ධකයින් අතර, නිකුත් කරන්නන් ද සිටිති: "ආ... හරි, අපි ඒවා කවචයක් සහිත ගොනුවක ඔතා ගනිමු, එපමණයි." මේ සියල්ල කන්ටේනරයක තිබූ බැවින්, ඔවුන් එය කන්ටේනරය තුළම ඔතා, නාමාවලිය ඇතුළත සිතියම්ගත කර එහි තැබීය. මම හිතන්නේ ඒකෙන් වුණේ මොකක්ද කියලා හැමෝටම පැහැදිලියි.

අපි දැනට ටිකක් ඉදිරියට බලමු. අපි මෙම ලඝු-සටහන් ලබා දුන්නේ කෙසේද? කවුරුහරි td-agent තෝරා ගත්තා, එය ඇත්තෙන්ම චතුර, නමුත් එතරම් චතුර නොවේ. මෙම ව්‍යාපෘති දෙක අතර සම්බන්ධය මට තවමත් වැටහෙන්නේ නැත, නමුත් ඒවා එකම දෙයක් ගැන බව පෙනේ. රූබි භාෂාවෙන් ලියා ඇති මෙම චතුර, ලොග් ලිපිගොනු කියවා, යම් ආකාරයක විධිමත් භාවයක් භාවිතා කරමින් ඒවා JSON වෙත විග්‍රහ කළේය. ඊට පස්සේ මම ඔවුන්ව කෆ්කා වෙත යැව්වා. එපමණක් නොව, කෆ්කා හි අපට එක් එක් API සඳහා වෙනම මාතෘකා 4ක් තිබුණි. ඇයි 4? සජීවීව ඇති නිසා, වේදිකාගත කිරීම සහ stdout සහ stderr ඇති නිසා. සංවර්ධකයින් ඒවා නිර්මාණය කරන අතර යටිතල පහසුකම් සංවර්ධකයින් ඒවා Kafka හි නිර්මාණය කළ යුතුය. එපමණක් නොව, කෆ්කා වෙනත් දෙපාර්තමේන්තුවකින් පාලනය විය. ඒ නිසා ඔවුන් එක් එක් api සඳහා මාතෘකා 4 ක් නිර්මාණය කරන පරිදි ටිකට් පතක් නිර්මාණය කිරීම අවශ්ය විය. හැමෝටම ඒක අමතක වුණා. පොදුවේ ගත් කල, කසළ හා කලබල විය.

අපි මේකෙන් ඊළඟට මොකද කළේ? අපි එය කෆ්කා වෙත යැව්වා. එවිට කෆ්කා වෙතින් ලොග් ලොග්ස්ටාෂ් වෙත පියාසර කරන ලදී. ලොගවලින් අනෙක් භාගය බෙදී ගියේය. සමහරු ග්‍රේලොග් එකකට, සමහරු තවත් ග්‍රේලොග් එකකට පියාසර කළා. එහි ප්‍රතිඵලයක් වශයෙන්, මේ සියල්ල එක් ඉලාස්ටික් සෙවුම් පොකුරකට ගියේය. එනම් මේ සියලු අවුල් එතැනින් කෙළවර විය. එහෙම කරන්න එපා!

උඩ ඉඳන් බැලුවොත් මෙහෙමයි. එහෙම කරන්න එපා! මෙහිදී ගැටළු සහිත ප්රදේශ වහාම අංක වලින් සලකුණු කර ඇත. ඇත්ත වශයෙන්ම ඒවායින් වැඩි ගණනක් ඇත, නමුත් 6 සැබවින්ම ගැටළු සහගත ඒවා වන අතර ඒවා ගැන යමක් කළ යුතුය. මම දැන් ඔවුන් ගැන වෙන වෙනම කියන්නම්.

මෙන්න (1,2,3) අපි ලිපිගොනු ලියන අතර, ඒ අනුව, මෙහි එකවර රේක් තුනක් ඇත.

පළමු (1) එක තමයි අපි ඒවා කොහේ හරි ලියන්න ඕන. ගොනුවකට කෙලින්ම ලිවීමේ හැකියාව API වෙත ලබා දීම සැමවිටම සුදුසු නොවේ. API කන්ටේනරයක හුදකලා කිරීම යෝග්‍ය වේ, නැතහොත් එය කියවීමට පමණක් වීම වඩා හොඳය. මම පද්ධති පරිපාලකයෙක්, ඒ නිසා මට මේ දේවල් ගැන ටිකක් විකල්ප අදහසක් තියෙනවා.

දෙවන කරුණ (2,3) අපට API වෙත බොහෝ ඉල්ලීම් පැමිණේ. API ගොනුවකට දත්ත ගොඩක් ලියයි. ලිපිගොනු වර්ධනය වෙමින් පවතී. අපි ඒවා කරකවන්න ඕන. මන්ද එසේ නොමැතිනම් ඔබට එහි කිසිදු තැටි ගබඩා කිරීමට නොහැකි වනු ඇත. ඒවා භ්‍රමණය කිරීම නරකයි, මන්ද ඒවා සෑදී ඇත්තේ shell එක හරහා නාමාවලියට හරවා යැවීමෙනි. අපිට ඒක සංශෝධනය කරන්න විදිහක් නෑ. ඔබට හැන්ඩ්ල් නැවත විවෘත කිරීමට යෙදුමට පැවසිය නොහැක. මන්ද සංවර්ධකයින් ඔබ දෙස බලන්නේ ඔබ මෝඩයෙකු ලෙසිනි: "මොන විස්තරද? අපි සාමාන්‍යයෙන් ලියන්නේ stdout ට.” යටිතල පහසුකම් සංවර්ධකයින් විසින් ලොග්‍රෝටේට් කිරීමට පිටපත් කප්පාදු කරන ලදී, එය ගොනුවේ පිටපතක් සාදා මුල් පිටපත පිටපත් කරයි. ඒ අනුව, මෙම පිටපත් කිරීමේ ක්‍රියාවලීන් අතර සාමාන්‍යයෙන් තැටි අවකාශය අවසන් වේ.

(4) අපට විවිධ API වල විවිධ ආකෘති තිබුණි. ඒවා තරමක් වෙනස් වූ නමුත් regexp වෙනස් ලෙස ලිවීමට සිදු විය. මේ සියල්ල රූකඩ විසින් පාලනය කරන ලද බැවින්, ඔවුන්ගේම කැරපොත්තන් සහිත විශාල පන්ති සමූහයක් එහි විය. Plus, බොහෝ විට td-agent හට මතකය අනුභව කළ හැකිය, මෝඩ විය හැකිය, එය ක්‍රියා කරන බව මවාපාමින් කිසිවක් නොකර සිටිය හැකිය. ඔහු කිසිවක් නොකරන බව පිටතින් තේරුම් ගැනීමට නොහැකි විය. හොඳම දෙය නම්, ඔහු වැටෙනු ඇති අතර පසුව යමෙකු ඔහුව රැගෙන යනු ඇත. වඩාත් නිවැරදිව, අනතුරු ඇඟවීමක් පැමිණෙනු ඇත, යමෙකු ගොස් එය තම දෑතින් ඔසවනු ඇත.

(6) වැඩිපුරම කුණු හා අපද්‍රව්‍ය වූයේ ඉලාස්ටික් සෙවුමයි. එය පැරණි අනුවාදයක් වූ බැවිනි. මොකද අපිට ඒ කාලේ කැපවුණු ස්වාමිවරු හිටියේ නැහැ. ක්ෂේත්‍ර අතිච්ඡාදනය විය හැකි විෂමජාතීය ලොග අප සතුව තිබුණි. විවිධ යෙදුම්වල විවිධ ලඝු-සටහන් එකම ක්ෂේත්‍ර නාමයෙන් ලිවිය හැකි නමුත් ඇතුළත විවිධ දත්ත තිබිය හැක. එනම්, එක් ලඝු-සටහනක් ක්ෂේත්රයේ Integer සමඟ පැමිණේ, උදාහරණයක් ලෙස, මට්ටම. Level field එකේ String එක්ක තව log එකක් එනවා. ස්ථිතික සිතියම්කරණයක් නොමැති විට, මෙය එතරම් අපූරු දෙයකි. elasticsearch හි දර්ශකය කරකැවීමෙන් පසු, නූලක් සහිත පණිවිඩයක් පළමුව පැමිණේ නම්, අපි සාමාන්‍යයෙන් ජීවත් වෙමු. නමුත් පළමු එක Integer වලින් පැමිණියේ නම්, පසුව String වෙතින් පැමිණි සියලුම පණිවිඩ සරලව ඉවත දමනු ලැබේ. ක්ෂේත්‍ර වර්ගය නොගැලපෙන බැවිනි.

අපි මේ ප්‍රශ්න අහන්න පටන් ගත්තා. වැරදි කරන අය ගැන හොයන්නේ නැහැ කියලා අපි තීරණය කළා.

නමුත් යමක් කළ යුතුයි! පැහැදිළි කාරණය තමයි අපි ප්‍රමිතීන් ස්ථාපිත කළ යුතුයි. අපිට දැනටමත් යම් ප්‍රමිතීන් තිබුණා. අපි ටිකක් පස්සේ පටන් ගත්තා. වාසනාවකට මෙන්, සියලුම API සඳහා තනි ලොග් ආකෘතියක් ඒ වන විටත් අනුමත කර ඇත. එය සේවා අතර අන්තර්ක්‍රියා සඳහා වන ප්‍රමිතීන්ට කෙලින්ම ලියා ඇත. ඒ අනුව, ලඝු-සටහන් ලබා ගැනීමට කැමති අය ඒවා මෙම ආකෘතියෙන් ලිවිය යුතුය. යමෙක් මෙම ආකෘතියේ ලඝු-සටහන් නොලියන්නේ නම්, අපි කිසිවක් සහතික නොකරමු.

ඊළඟට, ලොග් පටිගත කිරීම, බෙදා හැරීම සහ එකතු කිරීමේ ක්‍රම සඳහා ඒකාබද්ධ ප්‍රමිතියක් නිර්මාණය කිරීමට මම කැමතියි. ඇත්ත වශයෙන්ම, ඒවා ලියන්නේ කොතැනද සහ ඒවා ලබා දෙන්නේ කෙසේද. හොඳම තත්ත්වය වන්නේ ව්‍යාපෘති එකම පුස්තකාලය භාවිතා කරන විටය. Go සඳහා වෙනම logging library එකක් සහ PHP සඳහා වෙනම පුස්තකාලයක් ඇත. අප සතුව ඇති සෑම කෙනෙකුම ඒවා භාවිතා කළ යුතුය. මේ මොහොතේ මම කියන්නේ අපි සියයට 80ක් සාර්ථකයි කියලා. නමුත් සමහර අය දිගටම පතොක් අනුභව කරති.

එහි (විනිවිදකයේ) "ලඝු-සටහන් බෙදා හැරීම සඳහා SLA" යන්තම් පෙනෙන්නට පටන් ගනී. එය තවමත් නොපවතී, නමුත් අපි එය මත වැඩ කරමින් සිටිමු. මක්නිසාද යත්, ඔබ එවැනි සහ එවැනි ස්ථානයකට එවැනි ආකෘතියකින් ලියන්නේ නම් සහ තත්පරයට N පණිවිඩ වලට වඩා වැඩි නොවේ නම්, අපි එය බොහෝ විට එවැනි ස්ථානයකට ලබා දෙන බව යටිතල පහසුකම් පවසන විට එය ඉතා පහසු වේ. මෙය බොහෝ හිසරදය සමනය කරයි. SLA එකක් තිබේ නම්, මෙය නියත වශයෙන්ම අපූරුයි!

අපි ගැටලුව විසඳීමට පටන් ගත්තේ කෙසේද? ප්රධාන ගැටළුව වූයේ td-agent සමඟය. අපේ ලොග් කොහේ ගියාද කියලා පැහැදිලි නැහැ. ඒවා භාර දෙනවාද? ඔවුන් යනවද? කෙසේ වෙතත් ඔවුන් කොහෙද? එබැවින්, පළමු කරුණ td-agent ප්රතිස්ථාපනය කිරීමට තීරණය විය. එය ප්‍රතිස්ථාපනය කළ යුතු දේ සඳහා විකල්ප මම කෙටියෙන් මෙහි දක්වා ඇත.

චතුර ලෙස. පළමුවෙන්ම, මට ඔහුව පෙර රැකියාවකදී හමු වූ අතර, ඔහු ද වරින් වර එහි වැටුණි. දෙවනුව, මෙය එකම දෙයකි, පැතිකඩෙහි පමණි.

ෆයිල්බීට්. එය අපට පහසු වූයේ කෙසේද? එය Go හි ඇති නිසාත්, Go හි අපට බොහෝ විශේෂඥ දැනුමක් ඇති නිසාත් ය. ඒ අනුව, යමක් සිදු වූවා නම්, අපට එය කෙසේ හෝ එකතු කර ගත හැකිය. ඒකයි අපි ගත්තේ නැත්තේ. එබැවින් එය ඔබම නැවත ලිවීමට පටන් ගැනීමට පෙළඹවීමක් පවා ඇති නොවේ.

පද්ධති පරිපාලක සඳහා පැහැදිලි විසඳුම මෙම ප්‍රමාණයේ ඇති සියලුම වර්ගවල syslogs වේ (syslog-ng/rsyslog/nxlog).

නැතහොත් ඔබේම දෙයක් ලියන්න, නමුත් අපි මෙය මෙන්ම ෆයිල්බීට් ද ඉවත දැමුවෙමු. ඔබ යමක් ලියනවා නම්, ව්‍යාපාරයට ප්‍රයෝජනවත් දෙයක් ලිවීම වඩා හොඳය. ලඝු-සටහන් ලබා දීම සඳහා, සූදානම් කළ දෙයක් ගැනීම වඩා හොඳය.

එබැවින්, තේරීම ඇත්ත වශයෙන්ම syslog-ng සහ rsyslog අතර තේරීම වෙත පැමිණියේය. මම rsyslog වෙත නැඹුරු වූයේ අපට දැනටමත් රූකඩයේ rsyslog සඳහා පන්ති තිබූ නිසාත්, ඒවා අතර පැහැදිලි වෙනසක් මට හමු නොවූ නිසාත් ය. සිස්ලොග් යනු කුමක්ද, සිස්ලොග් යනු කුමක්ද. ඔව්, සමහරුන්ට වඩා නරක ලියකියවිලි තිබේ, සමහරුන්ට වඩා හොඳයි. මේක මේ විදියට කරන්න පුළුවන්, අනිත් කෙනාට ඒක වෙනස් විදියට කරන්න පුළුවන්.

සහ rsyslog ගැන ටිකක්. මුලින්ම කියන්න ඕන මොඩියුල් ගොඩක් තියෙන නිසා නියමයි. එහි මිනිසුන්ට කියවිය හැකි RainerScript (නවීන වින්‍යාස භාෂාවක්) ඇත. එය අපට සම්මත මෙවලම් භාවිතයෙන් td-agent ගේ හැසිරීම අනුකරණය කළ හැකි විශිෂ්ට ප්‍රසාද දීමනාවක් වන අතර යෙදුම් සඳහා කිසිවක් වෙනස් නොවේ. එනම්, අපි td-agent rsyslog ලෙස වෙනස් කර, දැනට අනෙක් සියල්ල තනිකරමු. සහ අපි වහාම වැඩ බෙදාහැරීම ලබා ගනිමු. මීළඟට, mmnormalize යනු rsyslog හි නියම දෙයකි. එය ඔබට ලඝු-සටහන් විග්‍රහ කිරීමට ඉඩ සලසයි, නමුත් Grok සහ regexp භාවිතා නොකරයි. එය වියුක්ත සින්ටැක්ස් ගසක් සාදයි. එය සම්පාදකයක් මූලාශ්‍ර විග්‍රහ කරන ආකාරයටම ලොග් විග්‍රහ කරයි. මෙය ඔබට ඉතා ඉක්මනින් වැඩ කිරීමට ඉඩ සලසයි, කුඩා CPU පරිභෝජනය, සහ, සාමාන්යයෙන්, එය ඇත්තෙන්ම සිසිල් දෙයක්. තවත් බෝනස් පොකුරක් ඇත. මම ඔවුන් මත රැඳී නොසිටිමි.

rsyslog වල තවත් අවාසි ගොඩක් තියෙනවා. ඒවා බෝනස් වලට සමානයි. ප්රධාන ගැටළු වන්නේ ඔබ එය පිසීමට ආකාරය දැන ගැනීමට අවශ්ය වන අතර, ඔබ අනුවාදය තෝරා ගැනීමට අවශ්ය වේ.

යුනික්ස් සොකට් එකකට ලඝු-සටහන් ලිවීමට අපි තීරණය කළෙමු. සහ /dev/log හි නොවේ, එහි අපට පද්ධති ලොග් අවුල් ඇති නිසා, journald මෙම නල මාර්ගයේ ඇත. ඉතින් අපි custom socket එකකට ලියමු. අපි එය වෙනම නීති මාලාවකට අමුණන්නෙමු. කිසිම දේකට මැදිහත් නොවී ඉමු. සෑම දෙයක්ම විනිවිද පෙනෙන හා තේරුම්ගත හැකි වනු ඇත. ඒක තමයි අපි හරියටම කළේ. මෙම සොකට් සහිත නාමාවලිය ප්‍රමිතිගත කර සියලුම බහාලුම් වෙත යවනු ලැබේ. බහාලුම්වලට ඔවුන්ට අවශ්‍ය සොකට් එක දැකීමට, විවෘත කිරීමට සහ එයට ලිවීමට හැකිය.

ගොනුවක් නැත්තේ ඇයි? මොකද හැමෝම කියෙව්වා Badushechka පිළිබඳ ලිපිය, එය ගොනුවක් ඩොකර් වෙත යොමු කිරීමට උත්සාහ කළ අතර, rsyslog නැවත ආරම්භ කිරීමෙන් පසුව, ගොනු විස්තරය වෙනස් වූ බවත්, ඩොකර්ට මෙම ගොනුව නැති වූ බවත් සොයා ගන්නා ලදී. එය වෙනත් දෙයක් විවෘතව තබයි, නමුත් ඔවුන් ලියන සොකට් එක නොවේ. අපි මෙම ගැටලුව සමඟ කටයුතු කිරීමට තීරණය කළෙමු, ඒ සමඟම, අපි අවහිර කිරීමේ ගැටලුව වටා වැඩ කරන්නෙමු.

Rsyslog ස්ලයිඩයේ දක්වා ඇති ක්‍රියා සිදු කරන අතර රිලේ හෝ කෆ්කා වෙත ලඝු-සටහන් යවයි. කෆ්කා පැරණි ක්‍රමය අනුගමනය කරයි. Relay - මම ලඝු-සටහන් ලබා දීම සඳහා pure rsyslog භාවිතා කිරීමට උත්සාහ කළෙමි. පණිවිඩ පෝලිමකින් තොරව, සම්මත rsyslog මෙවලම් භාවිතයෙන්. මූලික වශයෙන්, එය ක්රියා කරයි.

නමුත් ඒවා මෙම කොටසට තල්ලු කරන්නේ කෙසේද යන්න පිළිබඳ සූක්ෂ්මතා ඇත (Logstash/Graylog/ES). මෙම කොටස (rsyslog-rsyslog) දත්ත මධ්‍යස්ථාන අතර භාවිතා වේ. මෙන්න සම්පීඩිත tcp සබැඳියක්, එමඟින් අපට කලාප පළල සුරැකීමට ඉඩ සලසයි, ඒ අනුව, නාලිකාව අවහිර වූ විට වෙනත් දත්ත මධ්‍යස්ථානයකින් අපට ලොග් කිහිපයක් ලැබීමේ සම්භාවිතාව කෙසේ හෝ වැඩි කරයි. මොකද අපිට තියෙන්නේ ඉන්දුනීසියාව, හැම දෙයක්ම නරකයි. නිරන්තර ගැටලුව පවතින්නේ මෙහිදීය.

යෙදුමෙන් අප විසින් පටිගත කරන ලද ලඝු-සටහන් අවසානයට ළඟා වීමට ඇති ඉඩකඩ කොපමණ දැයි අපට සැබවින්ම නිරීක්ෂණය කළ හැක්කේ කෙසේදැයි අපි සිතුවෙමු. අපි මිනුම් නිර්මාණය කිරීමට තීරණය කළා. rsyslog සතුව තමන්ගේම සංඛ්‍යාලේඛන එකතු කිරීමේ මොඩියුලයක් ඇත, එහි යම් ආකාරයක කවුන්ටර අඩංගු වේ. උදාහරණයක් ලෙස, එය ඔබට පෝලිමේ ප්‍රමාණය පෙන්විය හැකිය, නැතහොත් එවැනි සහ එවැනි ක්‍රියාවකදී පණිවිඩ කීයක් පැමිණ තිබේද යන්න පෙන්විය හැක. ඔබට දැනටමත් ඔවුන්ගෙන් යමක් ගත හැකිය. ඊට අමතරව, එය වින්‍යාසගත කළ හැකි අභිරුචි කවුන්ටර ඇති අතර, එය ඔබට පෙන්වනු ඇත, උදාහරණයක් ලෙස, සමහර API වාර්තා කර ඇති පණිවිඩ ගණන. ඊළඟට, මම Python හි rsyslog_exporter ලිව්වා, අපි ඒ සියල්ල Prometheus වෙත යවා ප්‍රස්ථාර ගොඩනඟමු. අපට ඇත්තටම ග්‍රේලොග් ප්‍රමිතික අවශ්‍ය විය, නමුත් අපට ඒවා පිහිටුවීමට තවම කාලය ලැබී නැත.

ගැටලු මොනවාද? අපගේ සජීවී API තත්පරයකට පණිවිඩ 50k ලියන බව අපි (හදිසියේ!) සොයා ගත් විට ගැටළු ඇති විය. මෙය වේදිකාගත නොවී සජීවී API එකක් පමණි. ඒ වගේම Graylog අපට පෙන්වන්නේ තත්පරයකට පණිවිඩ 12ක් පමණයි. සාධාරණ ප්‍රශ්නයක් මතු විය: දේහය කොහේද? එයින් අපි නිගමනය කළේ ග්‍රේලොග්ට සරලව මුහුණ දිය නොහැකි බවයි. අපි බැලුවා, ඇත්ත වශයෙන්ම, Graylog සහ Elasticsearch මෙම ප්‍රවාහය හැසිරවිය නොහැකි විය.

ඊළඟට, අපි මඟදී කළ වෙනත් සොයාගැනීම්.

සොකට් එකට ලිවීම් අවහිර කර ඇත. එය සිදුවූයේ කොහොමද? මම බෙදා හැරීම සඳහා rsyslog භාවිතා කරන විට, යම් අවස්ථාවක දී දත්ත මධ්‍යස්ථාන අතර නාලිකාව බිඳ වැටුණි. බෙදාහැරීම එක තැනක නතර වුණා, බෙදාහැරීම තවත් තැනක නතර වුණා. මේ සියල්ල rsyslog සොකට් එකට ලියන API සහිත යන්ත්‍රය වෙත පැමිණ ඇත. එතන පෝලිමක් තිබුණා. ඉන්පසු පෙරනිමියෙන් පැකට් 128ක් වන unix සොකට් එකට ලිවීමේ පෝලිම පිරී ගියේය. යෙදුමේ ඊළඟ ලිවීම () අවහිර කර ඇත. අපි Go යෙදුම්වල භාවිතා කරන පුස්තකාලය දෙස බැලූ විට, සොකට් වෙත ලිවීම අවහිර නොවන ආකාරයෙන් සිදුවන බව එහි ලියා ඇත. කිසිවක් අවහිර නොවන බව අපට විශ්වාසයි. අපි කියවන නිසා Badushechka පිළිබඳ ලිපියකවුද ඒ ගැන ලිව්වේ. නමුත් මොහොතක් තිබේ. මෙම ඇමතුම වටා අසීමිත ලූපයක් ද විය, එහි සොකට් එකට පණිවිඩයක් තල්ලු කිරීමට නිරන්තර උත්සාහයක් විය. අපි ඔහුව දැක්කේ නැහැ. මට පුස්තකාලය නැවත ලිවීමට සිදු විය. එතැන් සිට එය කිහිප වතාවක් වෙනස් වී ඇත, නමුත් දැන් අපි සියලු උප පද්ධතිවල අවහිර කිරීම් ඉවත් කර ඇත. එමනිසා, ඔබට rsyslog නැවැත්විය හැකි අතර, කිසිවක් බිඳ වැටෙන්නේ නැත.

පෝලිම්වල විශාලත්වය නිරීක්ෂණය කිරීම අවශ්ය වන අතර, මෙම පෝරකය මත පා තැබීම වළක්වා ගැනීමට උපකාරී වේ. පළමුව, අපට පණිවිඩ අහිමි වීමට පටන් ගන්නා විට අපට නිරීක්ෂණය කළ හැකිය. දෙවනුව, අපට බෙදා හැරීමේ ගැටළු ඇති බව අපට නිරීක්ෂණය කළ හැකිය.

සහ තවත් අප්රසන්න මොහොතක් - ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පය තුළ 10 ගුණයකින් විස්තාරණය කිරීම ඉතා පහසු වේ. අපට බොහෝ ලැබෙන ඉල්ලීම් නොමැත, නමුත් මෙම පණිවිඩ තවදුරටත් ගමන් කරන ප්‍රස්ථාරය නිසා, ප්‍රවේශ ලොග නිසා, අපි ඇත්ත වශයෙන්ම ලොග් භාරය දස ගුණයකින් පමණ වැඩි කරමු. අවාසනාවකට, මට නිශ්චිත සංඛ්යා ගණනය කිරීමට කාලය නොතිබුණි, නමුත් ක්ෂුද්ර සේවා යනු ඒවා වේ. මෙය මතක තබා ගත යුතුය. මේ මොහොතේ ලොග් එකතු කිරීමේ උප පද්ධතිය Lazada හි වැඩිපුරම පටවා ඇති බව පෙනේ.

ඉලාස්ටික් සෙවුම් ගැටළුව විසඳන්නේ කෙසේද? ඔබට ඉක්මනින් එක් ස්ථානයක ලොග් ලබා ගැනීමට අවශ්‍ය නම්, සියලුම යන්ත්‍ර වෙත දිව ගොස් ඒවා එහි එකතු නොකිරීමට, ගොනු ගබඩාව භාවිතා කරන්න. මෙය වැඩ කිරීමට සහතිකයි. එය ඕනෑම සේවාදායකයකින් කළ හැකිය. ඔබට අවශ්‍ය වන්නේ එහි තැටි ඇලවීම සහ syslog ස්ථාපනය කිරීමයි. මෙයින් පසු, සියලුම ලොග් එක තැනක ඇති බවට ඔබට සහතික වේ. එවිට ඔබට elasticsearch, graylog සහ වෙනත් දෙයක් සෙමින් වින්‍යාසගත කළ හැක. නමුත් ඔබට දැනටමත් සියලුම ලඝු-සටහන් ඇති අතර, එපමනක් නොව, ප්රමාණවත් තැටි අරා ඇති පරිදි ඔබට ඒවා ගබඩා කළ හැකිය.

මගේ වාර්තාව ඉදිරිපත් කරන විට, යෝජනා ක්රමය මේ ආකාරයෙන් පෙනෙන්නට පටන් ගත්තේය. අපි ගොනුවට ලිවීම ප්‍රායෝගිකව නැවැත්තුවා. දැන්, බොහෝ දුරට, අපි ඉතිරිය නිවා දමමු. API ධාවනය වන දේශීය යන්ත්‍රවල, අපි ගොනුවලට ලිවීම නවත්වන්නෙමු. පළමුව, ගොනු ගබඩාව ඇත, එය ඉතා හොඳින් ක්රියා කරයි. දෙවනුව, මෙම යන්ත්‍රවල අවකාශය නිරන්තරයෙන් ක්‍රියාත්මක වේ; එය නිරන්තරයෙන් නිරීක්ෂණය කළ යුතුය.

ලොග්ස්ටාෂ් සහ ග්‍රේලොග් සමඟ මෙම කොටස, එය සැබවින්ම ඉවත් වේ. ඒ නිසා අපි එයින් මිදෙන්න ඕන. ඔබ එක් දෙයක් තෝරා ගත යුතුය.

අපි ලොග්ස්ටාෂ් සහ කිබානා ඉවතට විසි කිරීමට තීරණය කළා. මොකද අපිට ආරක්ෂක අංශයක් තියෙනවා. කුමන සම්බන්ධයක්ද? සම්බන්ධය වන්නේ X-Pack නොමැතිව සහ Shield නොමැතිව Kibana ඔබට ලඝු-සටහන් වෙත ප්‍රවේශ අයිතිවාසිකම් වෙනස් කිරීමට ඉඩ නොදෙන බවයි. ඒකයි අපි ග්‍රේලොග් ගත්තෙ. ඒකේ ඔක්කොම තියෙනවා. මම එයට කැමති නැත, නමුත් එය ක්රියා කරයි. අපි නව දෘඩාංග මිල දී ගෙන, එහි නැවුම් ග්‍රේලොග් ස්ථාපනය කර දැඩි ආකෘති සහිත සියලුම ලොග් වෙනම ග්‍රේලොග් එකකට මාරු කළෙමු. අපි සංවිධානාත්මකව විවිධ වර්ගයේ සමාන ක්ෂේත්‍ර සමඟ ගැටලුව විසඳා ගත්තෙමු.

නව ග්‍රේලොග් හි හරියටම ඇතුළත් වන්නේ කුමක්ද? අපි හැම දෙයක්ම ඩොකර් එකට ලිව්වා. අපි සේවාදායකයන් පොකුරක් ගෙන, Kafka අවස්ථා තුනක්, 7 Graylog servers අනුවාදය 2.3 (අපට Elasticsearch අනුවාදය 5 අවශ්‍ය වූ නිසා). මේ සියල්ල HDD වෙතින් වැටලීම් වලදී අහුලා ගන්නා ලදී. තත්පරයකට පණිවිඩ 100 ක් දක්වා සුචිගත කිරීමේ අනුපාතයක් අපි දුටුවෙමු. සතියකට ටෙරා බයිට් 140ක දත්ත ප්‍රමාණයක් ලැබෙන බව අපි දුටුවෙමු.

නැවතත් පෝරකය! අපි ළඟ විකුණුම් දෙකක් තියෙනවා. අපි පණිවිඩ මිලියන 6කට එහා ගියා. ග්‍රේලොග්ට හපන්නට වෙලාවක් නැත. කොහොම හරි අපි ආයෙත් බේරෙන්න ඕන.

අපි බේරුනේ මෙහෙමයි. අපි තවත් සේවාදායකයන් සහ SSD කිහිපයක් එකතු කළෙමු. මේ මොහොතේ අපි ජීවත් වන්නේ මේ ආකාරයටයි. දැන් අපි දැනටමත් තත්පරයකට පණිවිඩ 160k හපමින් සිටිමු. අපි තවමත් සීමාවට පැමිණ නැත, එබැවින් අපට මෙයින් කොපමණ ප්‍රමාණයක් ලබා ගත හැකිද යන්න පැහැදිලි නැත.

මේවා අනාගතය සඳහා අපගේ සැලසුම් වේ. මේවායින්, වඩාත්ම වැදගත් වන්නේ බොහෝ විට ඉහළ ලබා ගැනීමේ හැකියාවයි. අපට එය තවම නැත. මෝටර් රථ කිහිපයක් එකම ආකාරයකින් වින්‍යාස කර ඇත, නමුත් මෙතෙක් සෑම දෙයක්ම එක් මෝටර් රථයක් හරහා ගමන් කරයි. ඔවුන් අතර අසාර්ථකත්වය සැකසීමට කාලය ගතවේ.

ග්‍රේලොග් වෙතින් ප්‍රමිතික එකතු කරන්න.

අපගේ කලාප පළල සහ අනෙකුත් සියල්ල විනාශ නොකරන එක් පිස්සු API එකක් ඇති වන පරිදි අනුපාත සීමාවක් සාදන්න.

අවසාන වශයෙන්, අපට මෙතරම් සේවය කිරීමට හැකි වන පරිදි සංවර්ධකයින් සමඟ යම් ආකාරයක SLA අත්සන් කරන්න. තව ලිව්වොත් මට සමාවෙන්න.

සහ ලියකියවිලි ලියන්න.

කෙටියෙන් කිවහොත්, අප අත්විඳින ලද සෑම දෙයකම ප්රතිඵල. පළමුව, සම්මතයන්. දෙවනුව, සිස්ලොග් යනු කේක් ය. තෙවනුව, rsyslog එය විනිවිදකයේ ලියා ඇති ආකාරයටම ක්‍රියා කරයි. සහ අපි ප්‍රශ්න වෙත යමු.

ඔබගේ ප්රශ්න.

ඔබේ ප්රශ්නය: ඇයි ඔබ නොගැනීමට තීරණය කළේ... (filebeat?)

පිළිතුර: අපි ගොනුවකට ලිවිය යුතුයි. ඇත්තටම මට ඕන වුණේ නැහැ. ඔබගේ API තත්පරයකට පණිවිඩ දහස් ගණනක් ලියන විට, ඔබ එය පැයකට වරක් කරකවන විට පවා, මෙය තවමත් විකල්පයක් නොවේ. ඔබට පයිප්පයකින් ලිවිය හැකිය. එයට සංවර්ධකයින් මගෙන් ඇසුවා: “අපි ලියන ක්‍රියාවලිය බිඳ වැටුණොත් කුමක් සිදුවේද?” මම ඔවුන්ට පිළිතුරු දිය යුත්තේ කුමක්දැයි සොයා නොගත් අතර, “හොඳයි, හරි, අපි එය නොකරමු.”

ඔබේ ප්රශ්නය: ඇයි ඔබ HDFS වෙත ලොග් ලියන්නේ නැත්තේ?

පිළිතුර: මෙය ඊළඟ අදියරයි. අපි ආරම්භයේදීම ඒ ගැන සිතුවෙමු, නමුත් මේ මොහොතේ මෙය කිරීමට සම්පත් නොමැති නිසා, එය අපගේ දිගුකාලීන විසඳුමේ එල්ලී ඇත.

ඔබේ ප්රශ්නය: තීරු ආකෘතිය වඩාත් සුදුසු වනු ඇත.

පිළිතුර: මට තේරෙනවා. අපි ඒකට අත් දෙකෙන්ම ඉන්නවා.

ඔබේ ප්රශ්නය: ඔබ ලියන්නේ rsyslog වෙතයි. එහිදී ඔබට TCP සහ UDP යන දෙකම භාවිතා කළ හැකිය. නමුත් UDP නම්, ඔබ භාරදීම සහතික කරන්නේ කෙසේද?

පිළිතුර: කරුණු දෙකක් තිබේ. පළමුව, මම ලොග් බෙදා හැරීම සහතික නොකරන බව මම වහාම සෑම කෙනෙකුටම කියමි. මක්නිසාද යත් සංවර්ධකයින් පැමිණ “අපි එහි මූල්‍ය දත්ත ලිවීමට පටන් ගනිමු, යමක් සිදු වුවහොත් ඔබ එය අප වෙනුවෙන් කොතැනක හෝ තබනු ඇත” යැයි පැවසූ විට අපි ඔවුන්ට පිළිතුරු දෙමු, “නියමයි! අපි සොකට් එකට ලිවීම අවහිර කිරීම ආරම්භ කරමු, සහ ගනුදෙනු වලදී මෙය කරන්න, එවිට ඔබට එය අප වෙනුවෙන් සොකට් එක මත තැබීමට සහතික වන අතර අපට එය අනෙක් පැත්තෙන් ලැබෙන බවට වග බලා ගන්න. මේ මොහොතේ, සෑම කෙනෙකුටම වහාම එය තවදුරටත් අවශ්ය නොවේ. එය අවශ්ය නොවේ නම්, අප ඇසිය යුතු ප්රශ්න මොනවාද? ඔබට සොකට් එකකට ලිවීම සහතික කිරීමට අවශ්‍ය නැතිනම්, අපි බෙදා හැරීම සහතික කළ යුත්තේ ඇයි? අපි අපේ උපරිම උත්සාහය කරනවා. අපි ඇත්ත වශයෙන්ම හැකි තරම් සහ හොඳම ආකාරයෙන් ලබා දීමට උත්සාහ කරමු, නමුත් අපි 100% සහතිකයක් ලබා නොදෙමු. එබැවින්, එහි මූල්ය දත්ත ලිවීමට අවශ්ය නොවේ. මේ සඳහා ගනුදෙනු සහිත දත්ත සමුදායන් ඇත.

ඔබේ ප්රශ්නය: API විසින් ලොගයේ යම් පණිවිඩයක් ජනනය කර පාලනය ක්ෂුද්‍ර සේවා වෙත මාරු කරන විට, විවිධ ක්ෂුද්‍ර සේවා වලින් පණිවිඩ වැරදි අනුපිළිවෙලකට පැමිණීමේ ගැටලුවට ඔබ මුහුණ දී තිබේද? මෙය ව්යාකූලත්වයට හේතු වේ.

පිළිතුර: ඒවා විවිධ ඇණවුම් වලින් එන එක සාමාන්‍ය දෙයක්. මේ සඳහා ඔබ සූදානම් විය යුතුය. ඕනෑම ජාල බෙදා හැරීමක් ඇණවුම සහතික නොකරන නිසා, නැතහොත් ඔබට මේ සඳහා විශේෂ සම්පත් වියදම් කිරීමට සිදු වේ. අපි ගොනු ගබඩා කරන්නේ නම්, සෑම API එකක්ම තමන්ගේම ගොනුවට ලොග් සුරකියි. එසේත් නැතිනම්, rsyslog ඒවා නාමාවලි වලට වර්ග කරයි. සෑම API එකකටම තමන්ගේම ලඝු-සටහන් ඇත, එහිදී ඔබට ගොස් බැලිය හැක, පසුව ඔබට මෙම ලොගයේ ඇති වේලා මුද්‍රාව භාවිතයෙන් ඒවා සංසන්දනය කළ හැක. ඔවුන් ග්‍රේලොග් හි බැලීමට ගියහොත්, ඒවා එහි කාල මුද්‍රාව අනුව වර්ග කරනු ලැබේ. එතන හැම දෙයක්ම හොඳින් වේවි.

ඔබේ ප්රශ්නය: කාල මුද්‍රාව මිලි තත්පර වලින් වෙනස් විය හැක.

පිළිතුර: කාල මුද්‍රාව API විසින්ම ජනනය වේ. ඇත්ත වශයෙන්ම, මෙය සමස්ත කාරණයයි. අපිට NTP තියෙනවා. API පණිවිඩය තුළම කාල මුද්‍රාවක් ජනනය කරයි. rsyslog එය එකතු නොකරයි.

ඔබේ ප්රශ්නය: දත්ත මධ්‍යස්ථාන අතර අන්තර්ක්‍රියා ඉතා පැහැදිලි නැත. දත්ත මධ්‍යස්ථානය තුළ, ලඝු-සටහන් එකතු කර සකස් කළ ආකාරය පැහැදිලිය. දත්ත මධ්‍යස්ථාන අතර අන්තර්ක්‍රියා සිදු වන්නේ කෙසේද? නැතහොත් සෑම දත්ත මධ්‍යස්ථානයක්ම තමන්ගේම ජීවිතයක් ගත කරනවාද?

පිළිතුර: පාහේ. අපේ රටේ සෑම රටක්ම එක් දත්ත මධ්‍යස්ථානයක පිහිටා ඇත. මේ මොහොතේ, අපට එක් රටක් විවිධ දත්ත මධ්‍යස්ථානවල පිහිටා ඇති පරිදි පැතිරීමක් නොමැත. එබැවින් ඒවා ඒකාබද්ධ කිරීම අවශ්ය නොවේ. සෑම මධ්‍යස්ථානයක්ම ඇතුළත ලොග් රිලේ එකක් ඇත. මෙය Rsyslog සේවාදායකයකි. ඇත්තටම කළමනාකරණ යන්ත්‍ර දෙකක්. ඔවුන්ට ඇත්තේ එකම ආකල්පයකි. නමුත් දැනට වාහන ගමනාගමනය යන්නේ ඉන් එකක් හරහා පමණි. එය සියලුම ලොග් එකතු කරයි. ඇයට තැටි පෝලිමක් තිබේ. එය ලඝු-සටහන් බාගත කර ඒවා මධ්‍යම දත්ත මධ්‍යස්ථානයට (සිංගප්පූරුව) යවයි, එහිදී ඒවා ග්‍රේලොග් වෙත යවනු ලැබේ. තවද සෑම දත්ත මධ්‍යස්ථානයක්ම තමන්ගේම ගොනු ගබඩාවක් ඇත. අපගේ සම්බන්ධතාවය නැති වුවහොත්, අප සතුව සියලුම ලොග් තිබේ. ඔවුන් එහි පවතිනු ඇත. ඔවුන් එහි ගබඩා කරනු ඇත.

ඔබේ ප්රශ්නය: අසාමාන්‍ය අවස්ථාවන්හිදී, ඔබට එතැනින් ලඝු-සටහන් ලැබෙන්නේද?

පිළිතුර: ඔතනට (ගොනු ගබඩාවට) ගිහින් බලන්න පුළුවන්.

ඔබේ ප්රශ්නය: ඔබට ලඝු-සටහන් අහිමි නොවන බව ඔබ නිරීක්ෂණය කරන්නේ කෙසේද?

පිළිතුර: අපි ඇත්තටම ඒවා නැති කරනවා, අපි එය නිරීක්ෂණය කරනවා. මාසයකට පෙර නිරීක්ෂණ දියත් කරන ලදී. Go API භාවිත කරන පුස්තකාලයට ප්‍රමිතික ඇත. ඇයට සොකට් එකකට ලිවීමට නොහැකි වූ වාර ගණන ගණන් කළ හැකිය. එහි දැනට දක්ෂ හූරිස්ටික් ඇත. එතන බෆරයක් තියෙනවා. එයින් සොකට් එකට පණිවිඩයක් ලිවීමට උත්සාහ කරයි. බෆරය පිටාර ගලන්නේ නම්, එය ඒවා වැටීමට පටන් ගනී. තවද ඔහු ඒවායින් කීයක් අතහැර දැමුවාද යන්න ගණන් කරයි. එතන මීටර් උතුරන්න පටන් ගත්තොත් අපි ඒ ගැන දැනගන්නවා. ඔවුන් දැන් ප්‍රොමිතියස් වෙතද පැමිණෙමින් සිටින අතර ඔබට ග්‍රැෆානා හි ප්‍රස්ථාර දැකිය හැකිය. ඔබට ඇඟවීම් සැකසිය හැක. නමුත් ඒවා යවන්නේ කාටද යන්න තවමත් පැහැදිලි නැත.

ඔබේ ප්රශ්නය: ප්‍රත්‍යාස්ථ සෙවීමේදී ඔබ අතිරික්ත ලොග ගබඩා කරයි. ඔබට අනුරූ කීයක් තිබේද?

පිළිතුර: එක පේළියක්.

ඔබේ ප්රශ්නය: මේක එක පේළියක් විතරද?

පිළිතුර: මෙය ස්වාමියා සහ අනුරුවයි. දත්ත පිටපත් දෙකකින් ගබඩා කර ඇත.

ඔබේ ප්රශ්නය: ඔබ කෙසේ හෝ rsyslog බෆර ප්‍රමාණය සීරුමාරු කළාද?

පිළිතුර: අපි custom unix socket එකකට datagrams ලියනවා. මෙය වහාම කිලෝබයිට් 128 ක සීමාවක් අප මත පනවා ඇත. අපිට ඒකට වැඩිය ලියන්න බෑ. අපි මෙය සම්මතයට ලියා ඇත. ගබඩාවට ඇතුළු වීමට කැමති අය කිලෝබයිට් 128 ක් ලියන්න. පුස්තකාල, එපමනක් නොව, කපා ඇත, සහ පණිවිඩය කපා ඇති බව ධජයක් තබා ඇත. පණිවිඩය සඳහා වන අපගේ ප්‍රමිතිය පටිගත කිරීමේදී එය කපා හරින ලද්දේද නැද්ද යන්න පෙන්වන විශේෂ ක්ෂේත්‍රයක් ඇත. එබැවින් මේ මොහොතද නිරීක්ෂණය කිරීමට අපට අවස්ථාව තිබේ.

ප්රශ්නය: ඔබ කැඩුණු JSON ලියන්නේද?

පිළිතුර: පැකට්ටුව විශාල වැඩි නිසා රිලේ අතරතුර කැඩී ගිය JSON ඉවත දමනු ඇත. නැතහොත් GSON විග්‍රහ කළ නොහැකි නිසා Greylog ඉවත දමනු ඇත. නමුත් සවි කළ යුතු සූක්ෂ්මතා ඇති අතර ඒවා බොහෝ විට rsyslog සමඟ බැඳී ඇත. මම දැනටමත් එහි ගැටළු කිහිපයක් පුරවා ඇත, ඒවා තවමත් වැඩ කිරීමට අවශ්‍ය වේ.

ප්රශ්නය: ඇයි කෆ්කා? ඔබ RabbitMQ උත්සාහ කර තිබේද? එවැනි බරක් යටතේ Graylog අසමත් වේද?

පිළිතුර: එය අපට ග්‍රේලොග් සමඟ ක්‍රියා නොකරයි. ඒ වගේම Graylog අපි වෙනුවෙන් හැඩ ගැහෙනවා. ඔහු ඇත්තටම ගැටළු සහගතයි. ඔහු විශේෂ දෙයක්. තවද, ඇත්ත වශයෙන්ම, එය අවශ්ය නොවේ. මම කැමති rsyslog සිට කෙලින්ම elasticsearch වෙත ලිවීමට සහ පසුව Kibana දෙස බැලීමට. නමුත් අපි ආරක්ෂක නිලධාරීන් සමඟ ප්‍රශ්නය විසඳා ගත යුතුයි. අපි ග්‍රේලොග් ඉවතට විසි කර කිබානා භාවිතා කරන විට මෙය අපගේ සංවර්ධනය සඳහා හැකි විකල්පයකි. Logstash භාවිතා කිරීමේ තේරුමක් නැත. මොකද මට rsyslog එකෙන් කරන්න පුලුවන් එකම දේ. තවද එය elasticsearch වෙත ලිවීම සඳහා මොඩියුලයක් ඇත. අපි ග්‍රේලොග් එක්ක කොහොම හරි ජීවත් වෙන්නයි හදන්නේ. අපි එය පවා ටිකක් සුසර කළා. නමුත් වැඩිදියුණු කිරීමට තවමත් ඉඩ තිබේ.

කෆ්කා ගැන. එය ඓතිහාසිකව සිදුවූයේ එලෙසය. මම පැමිණෙන විට, එය දැනටමත් එහි තිබූ අතර, ඒ වන විටත් එහි ලඝු-සටහන් ලියා ඇත. අපි සරලව අපේ පොකුර ඉහළට ගෙන එයට ලඝු-සටහන් ගෙන ගියෙමු. අපි ඔහුගේ කළමනාකරණය, ඔහුට හැඟෙන ආකාරය අපි දනිමු. RabbitMQ ගැන නම්... RabbitMQ එකෙන් අපිට හරියන්නේ නැහැ. සහ RabbitMQ අප වෙනුවෙන් හැඩගැසෙමින් පවතී. අපට එය නිෂ්පාදනයේ ඇති අතර, එහි ගැටළු ඇති විය. දැන්, විකිණීමට පෙර, ඔවුන් ඔහුව ආකර්ෂණය කරනු ඇත, ඔහු සාමාන්යයෙන් වැඩ කිරීමට පටන් ගනී. නමුත් ඊට කලින් මම එය නිෂ්පාදනයට නිකුත් කරන්න සූදානම් වුණේ නැහැ. තව එක කරුණක් තියෙනවා. Graylog හට AMQP 0.9 අනුවාදය කියවිය හැකි අතර rsyslog හට AMQP 1.0 අනුවාදය ලිවිය හැක. ඒ වගේම ඒ දෙකම කරන්න පුළුවන් එක විසඳුමක් මැද නැහැ. එය එක්කෝ එකක් හෝ අනෙකකි. ඒ නිසා දැනට කෆ්කා විතරයි. නමුත් එයට තමන්ගේම සූක්ෂ්මතා ද ඇත. මක්නිසාද යත් අප භාවිතා කරන rsyslog අනුවාදයේ omkafka හට එය rsyslog වෙතින් ඉවත් කළ සම්පූර්ණ පණිවිඩ බෆරය අහිමි විය හැකි බැවිනි. දැනට අපි එය ඉවසා සිටිමු.

ප්රශ්නය: ඔබ කෆ්කා භාවිතා කරන්නේ ඔබට එය දැනටමත් තිබූ නිසාද? තවදුරටත් කිසිදු අරමුණක් සඳහා භාවිතා නොවේද?

පිළිතුර: Data Science කණ්ඩායම විසින් භාවිතා කරන ලද Kafka. මෙය සම්පූර්ණයෙන්ම වෙනම ව්යාපෘතියක් වන අතර, අවාසනාවකට මෙන්, මට කිසිවක් පැවසිය නොහැක. මම දන්නේ නැහැ. එය මෙහෙයවනු ලැබුවේ දත්ත විද්‍යා කණ්ඩායම විසිනි. ලඝු-සටහන් නිර්මාණය කළ විට, අපගේම ස්ථාපනය නොකිරීමට එය භාවිතා කිරීමට අපි තීරණය කළෙමු. දැන් අපි Graylog යාවත්කාලීන කර ඇති අතර, එහි Kafka හි පැරණි අනුවාදයක් ඇති නිසා අපට ගැළපුම නැති වී ඇත. අපිට අපේම කියලා පටන් ගන්න තිබුණා. ඒ සමගම, අපි එක් එක් API සඳහා මෙම මාතෘකා හතර ඉවත් කළෙමු. අපි සියලු දෙනාටම සජීවීව එක් පුළුල් මාතෘකාවක්, සියලු වේදිකා සඳහා එක් පුළුල් මාතෘකාවක් සාදා සියල්ල එහි තැබුවෙමු. ග්‍රේලොග් මේ සියල්ල සමාන්තරව සීරීමට ලක් කරයි.

ප්රශ්නය: ඇයි අපට සොකට් සහිත මෙම shamanism අවශ්ය වන්නේ? ඔබ බහාලුම් සඳහා syslog log ධාවකය භාවිතා කිරීමට උත්සාහ කර තිබේද?

පිළිතුර: අපි මේ ප්‍රශ්නය අහන වෙලාවේ ඩොකර් එක්ක අපේ සම්බන්ධය නොසන්සුන් වුණා. එය ඩොකර් 1.0 හෝ 0.9 විය. ඩොකර් ම අමුතු විය. දෙවනුව, ඔබ ද එයට ලොග් තල්ලු කළහොත් ... මට තහවුරු නොකළ සැකයක් ඇත, එය ඩොකර් ඩීමන් හරහා එය සියලු ලොගයන් තමා හරහා ගමන් කරයි. එක API එකකට පිස්සු හැදුනොත් stdout සහ stderr යවන්න බැරි එකේ ඉතුරු API ටික හිරවෙලා. මම දන්නේ නැහැ මේක කොහේට ගෙනියයිද කියලා. මෙම ස්ථානයේ Docker syslog ධාවකය භාවිතා කිරීමට අවශ්‍ය නැතැයි හැඟෙන මට්ටමේ මට සැකයක් ඇත. අපගේ ක්‍රියාකාරී පරීක්ෂණ දෙපාර්තමේන්තුවට ලඝු-සටහන් සහිත තමන්ගේම ග්‍රේලොග් පොකුරක් ඇත. ඔවුන් භාවිතා කරන්නේ ඩොකර් ලොග් ඩ්‍රයිවර්ස් සහ එහි සියල්ල හොඳින් ඇති බව පෙනේ. නමුත් ඔවුන් වහාම GELF ග්‍රේලොග් වෙත ලියයි. අපි මේ සියල්ල ආරම්භ කරන විට, අපට එය වැඩ කිරීමට අවශ්‍ය විය. සමහර විට ඊට පස්සේ කවුරුහරි ඇවිත් අවුරුදු සියයක් තිස්සේ හොඳින් වැඩ කරනවා කිව්වම අපි උත්සාහ කරමු.

ප්රශ්නය: ඔබ rsyslog භාවිතයෙන් දත්ත මධ්‍යස්ථාන අතර බෙදා හැරීම සිදු කරයි. ඇයි කෆ්කා නැත්තේ?

පිළිතුර: ඇත්තටම අපි දෙකම කරනවා. හේතු දෙකක් නිසා. නාලිකාව සම්පූර්ණයෙන්ම මිය ගොස් ඇත්නම්, අපගේ සියලුම ලොග්, සම්පීඩිත ආකාරයෙන් වුවද, එය හරහා බඩගා නොයනු ඇත. තවද Kafka ඔබට එම ක්‍රියාවලියේදී ඒවා නැති කර ගැනීමට ඉඩ සලසයි. මේ ලොග් හිරවෙන එකෙන් අපි ගැලවෙන්නෙ මෙහෙමයි. අපි මෙම නඩුවේදී කෙලින්ම Kafka භාවිතා කරනවා. අපට හොඳ නාලිකාවක් තිබේ නම් සහ එය නිදහස් කිරීමට අවශ්‍ය නම්, අපි ඔවුන්ගේ rsyslog භාවිතා කරමු. නමුත් ඇත්ත වශයෙන්ම, ඔබට එය වින්‍යාසගත කළ හැකි අතර එමඟින් නොගැලපෙන දේ පහත වැටෙනු ඇත. මේ මොහොතේ, අපි කෙලින්ම කොහේ හරි rsyslog බෙදාහැරීම සහ කොහේ හරි Kafka භාවිතා කරමු.

මූලාශ්රය: www.habr.com