එය 2019 වන අතර, අපට තවමත් Kubernetes හි ලොග් එකතු කිරීම සඳහා සම්මත විසඳුමක් නොමැත. මෙම ලිපියෙන්, සැබෑ භාවිතයේ උදාහරණ භාවිතා කරමින්, අපගේ සෙවීම්, මුහුණ දුන් ගැටළු සහ ඒවාට විසඳුම් බෙදා ගැනීමට අපි කැමැත්තෙමු.
කෙසේ වෙතත්, පළමුව, මම ලඝු-සටහන් එකතු කිරීමෙන් විවිධ පාරිභෝගිකයින් වෙනස් දේ තේරුම් ගන්නා ලෙස වෙන් කරවා ගන්නෙමි:
- යමෙකුට ආරක්ෂාව සහ විගණන ලඝු-සටහන් දැකීමට අවශ්‍යයි;
- යමෙකු - සමස්ත යටිතල පහසුකම් මධ්යගත ලොග් කිරීම;
- සහ සමහරුන්ට, උදාහරණයක් ලෙස, balancers හැර, යෙදුම් ලොග් පමණක් එකතු කිරීම ප්‍රමාණවත් වේ.
පහත දැක්වෙන්නේ අපි විවිධ “කැමති ලැයිස්තු” ක්‍රියාත්මක කළ ආකාරය සහ අප මුහුණ දුන් දුෂ්කරතා මොනවාද යන්න පිළිබඳව පහත කප්පාදුවයි.
න්යාය: ලොග් කිරීමේ මෙවලම් ගැන
ලොග් පද්ධතියක සංරචක පිළිබඳ පසුබිම
ලොග් කිරීම දිගු ගමනක් පැමිණ ඇත, එහි ප්‍රතිඵලයක් ලෙස ලඝු එකතු කිරීම සහ විශ්ලේෂණය කිරීමේ ක්‍රමවේදයන් වර්ධනය කර ඇත, එය අද අප භාවිතා කරයි. 1950 ගණන්වලදී, Fortran විසින් සම්මත ආදාන/ප්‍රතිදාන ප්‍රවාහවල ප්‍රතිසමයක් හඳුන්වා දුන් අතර, එය ක්‍රමලේඛකයාට ඔහුගේ වැඩසටහන දෝෂහරණය කිරීමට උපකාරී විය. එකල ක්‍රමලේඛකයින්ට ජීවිතය පහසු කළ පළමු පරිගණක ලොග් මේවාය. අද අපි ඔවුන් තුළ ලොග් කිරීමේ පද්ධතියේ පළමු අංගය දකිමු - ලඝු-සටහන් වල මූලාශ්රය හෝ "නිෂ්පාදකයා".
පරිගණක විද්යාව නිශ්චලව නොසිටියේය: පරිගණක ජාල දර්ශනය විය, පළමු පොකුරු ... පරිගණක කිහිපයකින් සමන්විත සංකීර්ණ පද්ධති වැඩ කිරීමට පටන් ගත්තේය. දැන් පද්ධති පරිපාලකයින්ට යන්ත්‍ර කිහිපයකින් ලඝු-සටහන් එකතු කිරීමට බල කෙරී ඇති අතර, විශේෂ අවස්ථා වලදී ඔවුන්ට පද්ධතියේ අසාර්ථක වීමක් විමර්ශනය කිරීමට අවශ්ය වූ විට OS කර්නල් පණිවිඩ එක් කළ හැක. මධ්යගත ලොග් එකතු කිරීමේ පද්ධති විස්තර කිරීම සඳහා, 2000 ගණන්වල මුල් භාගයේදී එය ප්රකාශයට පත් කරන ලදී , remote_syslog ප්‍රමිතිගත කරන ලදී. තවත් වැදගත් අංගයක් දර්ශනය වූ ආකාරය මෙයයි: ලඝු එකතු කරන්නා සහ ඔවුන්ගේ ගබඩා කිරීම.
ලඝු-සටහන් වල පරිමාව වැඩිවීම සහ වෙබ් තාක්ෂණයන් පුළුල් ලෙස හඳුන්වාදීමත් සමඟ, පරිශීලකයින්ට පහසුවෙන් පෙන්විය යුතු ලොග් මොනවාද යන ප්රශ්නය මතු විය. සරල කොන්සෝල මෙවලම් (awk/sed/grep) වඩා දියුණු ඒවා මගින් ප්‍රතිස්ථාපනය කර ඇත ලොග් බලන්නන් - තුන්වන සංරචකය.
ලඝු-සටහන් පරිමාව වැඩිවීම නිසා තවත් දෙයක් පැහැදිලි විය: ලඝු-සටහන් අවශ්ය වේ, නමුත් ඒවා සියල්ලම නොවේ. සහ විවිධ ලඝු-සටහන් සඳහා විවිධ මට්ටමේ සංරක්ෂණය අවශ්ය වේ: සමහරක් දිනක් තුළ අහිමි විය හැකි අතර අනෙක් ඒවා වසර 5 ක් සඳහා ගබඩා කළ යුතුය. එබැවින්, දත්ත ප්‍රවාහයන් පෙරීම සහ මාර්ගගත කිරීම සඳහා සංරචකයක් ලොග් කිරීමේ පද්ධතියට එක් කරන ලදී - අපි එය අමතන්නෙමු පෙරහන.
ආචයනය ද විශාල පිම්මක් ඇති කර ඇත: සාමාන්‍ය ලිපිගොනු වල සිට සම්බන්ධතා දත්ත සමුදායන් දක්වා, පසුව ලේඛන-නැඹුරු ආචයනය දක්වා (උදාහරණයක් ලෙස, ඉලාස්ටික් සෙවුම්). එබැවින් ගබඩාව එකතු කරන්නාගෙන් වෙන් කරන ලදී.
අවසානයේදී, ලොගයක් පිළිබඳ සංකල්පය අපට ඉතිහාසය සඳහා සුරැකීමට අවශ්ය වියුක්ත සිදුවීම් ප්‍රවාහයක් දක්වා පුළුල් වී ඇත. එසේත් නැතිනම්, ඔබට පරීක්ෂණයක් පැවැත්වීමට හෝ විශ්ලේෂණ වාර්තාවක් සැකසීමට අවශ්ය නම් ...
එහි ප්‍රතිඵලයක් වශයෙන්, සාපේක්ෂ වශයෙන් කෙටි කාලයක් තුළ, ලොග් එකතු කිරීම වැදගත් උප පද්ධතියක් බවට වර්ධනය වී ඇති අතර, එය Big Data හි උප වගන්ති වලින් එකක් ලෙස නිවැරදිව හැඳින්විය හැක.
වරක් සාමාන්‍ය මුද්‍රණ "ලොග් පද්ධතියක්" සඳහා ප්‍රමාණවත් විය හැකි නම්, දැන් තත්වය බොහෝ වෙනස් වී ඇත.
කුබර්නෙට්ස් සහ ලඝු-සටහන්
Kubernetes යටිතල පහසුකම් වෙත පැමිණි විට, ලඝු-සටහන් එකතු කිරීමේ දැනටමත් පවතින ගැටළුව එය මග හැරියේ නැත. යම් ආකාරයකින්, එය වඩාත් වේදනාකාරී විය: යටිතල පහසුකම් වේදිකාව කළමනාකරණය කිරීම සරල කිරීම පමණක් නොව, ඒ සමඟම සංකීර්ණ විය. බොහෝ පැරණි සේවාවන් ක්ෂුද්‍ර සේවා වෙත සංක්‍රමණය වීමට පටන් ගෙන ඇත. ලඝු-සටහන් වල සන්දර්භය තුළ, මෙය ලොග් මූලාශ්‍රවල වර්ධනය වන සංඛ්‍යාව, ඒවායේ විශේෂ ජීවන චක්‍රය සහ ලඝු-සටහන් හරහා සියලුම පද්ධති සංරචකවල සම්බන්ධතා නිරීක්ෂණය කිරීමේ අවශ්‍යතාවයෙන් පිළිබිඹු වේ.
ඉදිරිය දෙස බලන විට, අවාසනාවකට මෙන්, අනෙක් සියල්ලන් සමඟ වාසිදායක ලෙස සැසඳිය හැකි ප්‍රමිතිගත ලොග් කිරීමේ විකල්පයක් Kubernetes සඳහා නොමැති බව මට ප්‍රකාශ කළ හැකිය. ප්රජාව තුළ වඩාත් ජනප්රිය යෝජනා ක්රම පහත පරිදි වේ:
- කවුරුහරි තොගය දිගහරිනවා EFK (Elasticsearch, Fluentd, Kibana);
- කවුරුහරි මෑතකදී නිකුත් කිරීමට උත්සාහ කරයි හෝ භාවිතා කරයි ;
- нас (සමහර විට අපි පමණක් නොවේද? ..) මගේ සංවර්ධනය ගැන මම බොහෝ දුරට සෑහීමකට පත්වෙමි - ...
රීතියක් ලෙස, අපි K8s පොකුරු වල පහත මිටි භාවිතා කරමු (ස්වයං-සත්කාරක විසඳුම් සඳහා):
- ;
- .
කෙසේ වෙතත්, මම ඔවුන්ගේ ස්ථාපනය සහ වින්යාසය සඳහා උපදෙස් මත රැඳී නොසිටිමි. ඒ වෙනුවට, මම සාමාන්යයෙන් ලඝු-සටහන් සමඟ තත්වය පිළිබඳ ඔවුන්ගේ අඩුපාඩු සහ වඩාත් ගෝලීය නිගමන කෙරෙහි අවධානය යොමු කරමි.
K8s හි ලඝු-සටහන් සමඟ පුහුණු වන්න
"එදිනෙදා ලඝු-සටහන්", ඔබගෙන් කී දෙනෙක් එහි සිටිනවාද?..
තරමක් විශාල යටිතල ව්‍යුහයකින් ලඝු මධ්යගත එකතුවකට සැලකිය යුතු සම්පත් අවශ්ය වන අතර, එය ලඝු එකතු කිරීම, ගබඩා කිරීම සහ සැකසීම සඳහා වැය කරනු ලැබේ. විවිධ ව්‍යාපෘති ක්‍රියාත්මක කිරීමේදී විවිධ අවශ්‍යතා සහ ඒවායින් පැන නගින මෙහෙයුම් ගැටළු වලට අප මුහුණ දුන්නා.
අපි ClickHouse උත්සාහ කරමු
තරමක් සක්‍රීයව ලඝු-සටහන් ජනනය කරන යෙදුමක් සහිත ව්‍යාපෘතියක මධ්යගත ගබඩාවක් දෙස බලමු: තත්පරයකට පේළි 5000කට වඩා. අපි ඔහුගේ ලොග් සමඟ වැඩ කිරීමට පටන් ගනිමු, ඒවා ClickHouse වෙත එකතු කරන්න.
උපරිම තත්‍ය කාලීන අවශ්ය වූ වහාම, ClickHouse සහිත 4-core සේවාදායකය දැනටමත් තැටි උපපද්ධතිය මත අධිකව පටවනු ලැබේ:
අපි හැකි ඉක්මනින් ClickHouse හි ලිවීමට උත්සාහ කිරීම නිසා මෙම ආකාරයේ පැටවීම සිදු වේ. දත්ත සමුදාය වැඩි තැටි භාරයක් සමඟ මෙයට ප්‍රතික්‍රියා කරයි, එමඟින් පහත දෝෂ ඇති විය හැක:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
කාරණය එයයි ClickHouse හි (ඒවායේ ලොග් දත්ත අඩංගු වේ) ලිවීමේ මෙහෙයුම් වලදී ඔවුන්ගේම දුෂ්කරතා ඇත. ඒවාට ඇතුල් කරන ලද දත්ත තාවකාලික කොටසක් ජනනය කරයි, පසුව එය ප්රධාන වගුව සමඟ ඒකාබද්ධ වේ. එහි ප්‍රතිඵලයක් වශයෙන්, පටිගත කිරීම තැටියේ ඉතා ඉල්ලුමක් ඇති බවට හැරෙන අතර, එය අපට ඉහත දැනුම් දීමේ සීමාවට ද යටත් වේ: තත්පර 1 කින් උප කොටස් 300 කට වඩා ඒකාබද්ධ කළ නොහැක (ඇත්ත වශයෙන්ම, මෙය ඇතුළු කිරීම් 300 කි. තත්පරයට).
මෙම හැසිරීම වළක්වා ගැනීම සඳහා, හැකි තරම් විශාල කෑලි සහ සෑම තත්පර 1 කට වරක් 2 වතාවකට වඩා වැඩි නොවේ. කෙසේ වෙතත්, විශාල පිපිරුම් වලින් ලිවීමෙන් ඇඟවෙන්නේ අපි ClickHouse හි අඩුවෙන් ලිවිය යුතු බවයි. මෙය, අනෙක් අතට, බෆරය පිටාර ගැලීමට සහ ලොග් නැති වීමට හේතු විය හැක. විසඳුම Fluentd බෆරය වැඩි කිරීම, නමුත් එවිට මතක පරිභෝජනය ද වැඩි වේ.
අදහස් දැක්වීම්: ClickHouse සමඟ අපගේ විසඳුමේ තවත් ගැටළුකාරී අංගයක් වූයේ අපගේ නඩුවේ (ලොග්හවුස්) කොටස් කිරීම සම්බන්ධිත බාහිර වගු හරහා ක්‍රියාත්මක වීමයි. . මෙය විශාල කාල පරතරයන් නියැදීමේදී අධික RAM අවශ්ය වේ, මන්ද මෙටාටබල් සියලුම කොටස් හරහා පුනරාවර්තනය වේ - පැහැදිලිවම අවශ්ය දත්ත අඩංගු නොවන ඒවා පවා. කෙසේ වෙතත්, දැන් මෙම ප්‍රවේශය ClickHouse හි වත්මන් අනුවාද සඳහා යල්පැන ඇති බව ආරක්ෂිතව ප්‍රකාශ කළ හැක (c ).
එහි ප්‍රතිඵලයක් වශයෙන්, සෑම ව්‍යාපෘතියකටම ClickHouse හි තථ්‍ය කාලය තුළ ලඝු-සටහන් එකතු කිරීමට ප්‍රමාණවත් සම්පත් නොමැති බව පැහැදිලි වේ (වඩාත් නිවැරදිව, ඒවායේ බෙදා හැරීම සුදුසු නොවේ). ඊට අමතරව, ඔබ භාවිතා කිරීමට අවශ්ය වනු ඇත බැටරිය, ඒ සඳහා අපි පසුව ආපසු එන්නෙමු. ඉහත විස්තර කර ඇති නඩුව සැබෑ ය. තවද පාරිභෝගිකයාට ගැළපෙන සහ අවම ප්‍රමාදයකින් ලොග් එකතු කිරීමට අපට ඉඩ සලසන විශ්වාසනීය සහ ස්ථාවර විසඳුමක් ලබා දීමට එම අවස්ථාවේදී අපට නොහැකි විය...
Elasticsearch ගැන කුමක් කිව හැකිද?
ප්‍රත්‍යාස්ථ සෙවීම අධික වැඩ බර හැසිරවීමට දන්නා කරුණකි. අපි එය එම ව්‍යාපෘතියේම උත්සාහ කරමු. දැන් පැටවීම මේ වගේ ය:
Elasticsearch හට දත්ත ප්‍රවාහය දිරවීමට හැකි විය, කෙසේ වෙතත්, එවැනි වෙළුම් එයට ලිවීමෙන් CPU විශාල වශයෙන් භාවිතා වේ. පොකුරක් සංවිධානය කිරීමෙන් මෙය තීරණය වේ. තාක්ෂණික වශයෙන්, මෙය ගැටළුවක් නොවේ, නමුත් ලොග් එකතු කිරීමේ පද්ධතිය ක්‍රියාත්මක කිරීම සඳහා අපි දැනටමත් මධ්‍ය 8 ක් පමණ භාවිතා කරන අතර පද්ධතියේ අතිරේක ඉහළ පටවන ලද සංරචකයක් ඇති බව පෙනේ.
පහළ රේඛාව: මෙම විකල්පය යුක්ති සහගත කළ හැකි නමුත්, ව්යාපෘතිය විශාල නම් සහ එහි කළමනාකාරිත්වය මධ්යගත ලොග් පද්ධතියක් මත සැලකිය යුතු සම්පත් වියදම් කිරීමට සූදානම් නම් පමණි.
එවිට ස්වභාවික ප්රශ්නයක් පැන නගී:
ඇත්තටම අවශ්ය ලොග් මොනවාද?
ප්‍රවේශයම වෙනස් කිරීමට උත්සාහ කරමු: ලඝු-සටහන් එකවර තොරතුරු සහිත විය යුතු අතර ආවරණය නොකළ යුතුය සෑම පද්ධතියේ සිදුවීම.
අපි හිතමු අපිට සාර්ථක අන්තර්ජාල වෙළඳසැලක් තියෙනවා කියලා. වැදගත් ලොග් මොනවාද? නිදසුනක් වශයෙන්, ගෙවීම් දොරටුවකින් හැකි තරම් තොරතුරු රැස් කිරීම ඉතා හොඳ අදහසකි. නමුත් නිෂ්පාදන නාමාවලියෙහි රූප කැපීමේ සේවාවේ සියලුම ලොග් අපට තීරණාත්මක නොවේ: දෝෂ සහ උසස් අධීක්ෂණ පමණක් ප්‍රමාණවත් වේ (උදාහරණයක් ලෙස, මෙම සංරචකය ජනනය කරන දෝෂ 500 ක ප්‍රතිශතය).
ඒ නිසා අපි නිගමනයට පැමිණ තිබෙනවා මධ්යගත ලොග් කිරීම සැමවිටම යුක්ති සහගත නොවේ. බොහෝ විට සේවාදායකයාට සියලුම ලඝු-සටහන් එක තැනකට එකතු කිරීමට අවශ්ය වේ, නමුත් ඇත්ත වශයෙන්ම, සම්පූර්ණ ලොගයෙන්, ව්‍යාපාරය සඳහා තීරණාත්මක පණිවිඩ වලින් කොන්දේසි සහිත 5% ක් පමණක් අවශ්ය වේ:
- සමහර විට එය වින්‍යාස කිරීමට ප්‍රමාණවත් වේ, කියන්න, බහාලුම් ලොගයේ ප්‍රමාණය සහ දෝෂ එකතු කරන්නා (උදාහරණයක් ලෙස, Sentry).
- සිද්ධීන් විමර්ශනය කිරීමට දෝෂ දැනුම්දීමක් සහ විශාල දේශීය ලොගයක් බොහෝ විට ප්‍රමාණවත් විය හැක.
- අපට තනිකරම ක්‍රියාකාරී පරීක්ෂණ සහ දෝෂ එකතු කිරීමේ පද්ධති සමඟ කළ ව්‍යාපෘති තිබුණි. සංවර්ධකයාට ලඝු-සටහන් අවශ්ය නොවීය - ඔවුන් දෝෂ හෝඩුවාවන් වලින් සියල්ල දුටුවේය.
ජීවිතයෙන් නිදර්ශනය
තවත් කතාවක් හොඳ උදාහරණයක් විය හැකිය. Kubernetes හඳුන්වාදීමට බොහෝ කලකට පෙර සංවර්ධනය කරන ලද වාණිජ විසඳුමක් දැනටමත් භාවිතා කරන අපගේ සේවාදායකයෙකුගේ ආරක්ෂක කණ්ඩායමෙන් අපට ඉල්ලීමක් ලැබුණි.
ආයතනික ගැටළු හඳුනාගැනීමේ සංවේදකය - QRadar සමඟ මධ්යගත ලොග් එකතු කිරීමේ පද්ධතියේ “මිතුරන් ඇති කර ගැනීම” අවශ්ය විය. මෙම පද්ධතියට syslog ප්‍රොටෝකෝලය හරහා ලඝු-සටහන් ලබා ගත හැකි අතර ඒවා FTP වෙතින් ලබා ගත හැක. කෙසේ වෙතත්, එය fluentd සඳහා remote_syslog ප්ලගිනය සමඟ ඒකාබද්ධ කිරීමට වහාම නොහැකි විය. (එය සිදු වූ පරිදි, ). QRadar පිහිටුවීමේ ගැටළු සේවාදායකයාගේ ආරක්ෂක කණ්ඩායමේ පැත්තේ විය.
එහි ප්‍රතිඵලයක් වශයෙන්, ව්‍යාපාර-විවේචනාත්මක ලඝු-සටහන් වලින් කොටසක් FTP QRadar වෙත උඩුගත කරන ලද අතර, අනෙක් කොටස nodes වෙතින් සෘජුවම දුරස්ථ syslog හරහා හරවා යවන ලදී. මේ සඳහා අපි පවා ලිව්වා - සමහර විට එය සමාන ගැටළුවක් විසඳීමට යමෙකුට උපකාරී වනු ඇත ... ප්‍රතිඵලය වූ යෝජනා ක්‍රමයට ස්තූතිවන්ත වන්නට, සේවාදායකයා විසින්ම විවේචනාත්මක ලඝු-සටහන් (ඔහුගේ ප්‍රියතම මෙවලම් භාවිතා කරමින්) ලබා ගෙන විශ්ලේෂණය කළ අතර, ලොග් කිරීමේ පද්ධතියේ පිරිවැය අඩු කිරීමට අපට හැකි විය, ඉතිරි කර ඇත්තේ පසුගිය මාසයේ.
තවත් උදාහරණයක් නම් නොකළ යුතු දේ පිළිබඳ මනාව ඇඟවුම් කරයි. සැකසීම සඳහා අපගේ සේවාදායකයින්ගෙන් කෙනෙක් එකිනෙකා පරිශීලකයාගෙන් එන සිදුවීම්, බහු රේඛා සාදන ලදී ව්‍යුහගත නොවන ප්‍රතිදානය ලොගයේ තොරතුරු. ඔබ අනුමාන කළ හැකි පරිදි, එවැනි ලඝු-සටහන් කියවීම සහ ගබඩා කිරීම යන දෙකටම අතිශයින් අපහසු විය.
ලඝු-සටහන් සඳහා නිර්ණායක
එවැනි උදාහරණ මගින් ලොග් එකතු කිරීමේ පද්ධතියක් තෝරාගැනීමට අමතරව, ඔබට අවශ්ය බව නිගමනය කරයි ලඝු-සටහන් තමන් විසින්ම සැලසුම් කරන්න! මෙහි අවශ්‍යතා මොනවාද?
- ලඝු-සටහන් යන්ත්‍ර කියවිය හැකි ආකෘතියෙන් තිබිය යුතුය (උදාහරණයක් ලෙස, JSON).
- ලඝු-සටහන් සංයුක්ත විය යුතු අතර විය හැකි ගැටළු නිදොස් කිරීම සඳහා ලොග් වීමේ මට්ටම වෙනස් කිරීමට හැකියාව ඇත. ඒ අතරම, නිෂ්පාදන පරිසරයන් තුළ ඔබ වැනි ලොග් මට්ටමක් සහිත පද්ධති ධාවනය කළ යුතුය අවවාදයයි හෝ දෝෂ.
- ලඝු-සටහන් සාමාන්‍යකරණය කළ යුතුය, එනම් ලොග් වස්තුවක, සියලුම රේඛා එකම ක්ෂේත්‍ර වර්ගයක් තිබිය යුතුය.
ව්‍යුහගත නොවන ලඝු-සටහන් ගබඩාවට ලොග් පැටවීම හා ඒවායේ සැකසීම සම්පූර්ණයෙන්ම නතර කිරීම සම්බන්ධ ගැටළු වලට තුඩු දිය හැක. නිදර්ශනයක් ලෙස, 400 දෝෂ සහිත උදාහරණයක් මෙහි ඇත, බොහෝ දෙනෙක් චතුර ලඝු-සටහන් වල නියත වශයෙන්ම හමු වී ඇත:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
දෝෂය යනු ඔබ සූදානම් කළ සිතියම්කරණයක් සහිත දර්ශකයට අස්ථායී ආකාරයේ ක්ෂේත්‍රයක් යවන බවයි. සරලම උදාහරණය වන්නේ විචල්‍යයක් සහිත nginx ලොගයේ ඇති ක්ෂේත්‍රයකි $upstream_status. එහි අංකයක් හෝ තන්තුවක් අඩංගු විය හැක. උදාහරණ වශයෙන්:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
10.100.0.10 සේවාදායකය 404 දෝෂයකින් ප්‍රතිචාර දැක්වූ අතර ඉල්ලීම වෙනත් අන්තර්ගත ගබඩාවකට යවන ලද බව ලඝු-සටහන් පෙන්වයි. එහි ප්‍රතිඵලයක් වශයෙන්, ලඝු-සටහන් වල අගය මෙසේ විය:
"upstream_response_time": "0.001, 0.007"
මෙම තත්වය කොතරම් සුලභද යත් එය වෙනමම සුදුසුයි .
විශ්වසනීයත්වය ගැන කුමක් කිව හැකිද?
ව්යතිරේකයකින් තොරව සියලුම ලොග් ඉතා වැදගත් වන අවස්ථා තිබේ. මේ සමඟ, ඉහත යෝජිත/සාකච්ඡා කර ඇති K8s සඳහා සාමාන්‍ය ලොග් එකතු කිරීමේ යෝජනා ක්‍රමවල ගැටලු ඇත.
උදාහරණයක් ලෙස, fluentd හට කෙටි කාලීන බහාලුම් වලින් ලඝු එකතු කළ නොහැක. අපගේ එක් ව්‍යාපෘතියක, දත්ත සමුදා සංක්‍රමණ බහාලුම තත්පර 4කට වඩා අඩු කාලයක් ජීවත් වූ අතර පසුව මකා දමන ලදී - අනුරූප විවරණයට අනුව:
"helm.sh/hook-delete-policy": hook-succeeded
මේ නිසා, සංක්‍රමණ ක්‍රියාත්මක කිරීමේ ලොගය ගබඩාවට ඇතුළත් කර නොමැත. මේ අවස්ථාවේ දී දේශපාලනය උදව් කළ හැකිය. before-hook-creation.
තවත් උදාහරණයක් නම් Docker log rotation. අපි හිතමු ලොග් වලට සක්‍රියව ලියන යෙදුමක් තියෙනවා කියලා. සාමාන්‍ය තත්ව යටතේ, අපි සියලුම ලඝු-සටහන් සැකසීමට කළමනාකරණය කරමු, නමුත් ගැටළුවක් ඇති වූ වහාම - උදාහරණයක් ලෙස, ඉහත විස්තර කර ඇති පරිදි වැරදි ආකෘතියකින් - සැකසීම නතර වන අතර, ඩොකර් ගොනුව කරකවයි. එහි ප්‍රතිඵලය වන්නේ ව්‍යාපාර-විවේචනාත්මක ලඝු-සටහන් නැති විය හැකි බවයි.
ඒ නිසයි ලඝු ධාරා වෙන් කිරීම වැදගත් වේ, ඔවුන්ගේ ආරක්ෂාව සහතික කිරීම සඳහා වඩාත්ම වටිනා ඒවා කෙලින්ම යෙදුමට යැවීම. ඊට අමතරව, සමහරක් නිර්මාණය කිරීම අතිරික්ත නොවේ ලඝු-සටහන් "ඇකියුමුලේටර්", තීරනාත්මක පණිවිඩ සුරකින අතරතුර කෙටි ගබඩා නොලැබීමෙන් බේරී සිටිය හැක.
අවසාන වශයෙන්, අප එය අමතක නොකළ යුතුය ඕනෑම උප පද්ධතියක් නිසි ලෙස නිරීක්ෂණය කිරීම වැදගත් වේ. එසේ නොමැති නම්, චතුර ලෙස හැසිරෙන තත්වයකට පත්වීම පහසුය CrashLoopBackOff සහ කිසිවක් නොයවන අතර, මෙය වැදගත් තොරතුරු නැතිවීම පොරොන්දු වේ.
සොයා ගැනීම්
මෙම ලිපියෙන් අපි Datadog වැනි SaaS විසඳුම් දෙස බලන්නේ නැත. මෙහි විස්තර කර ඇති බොහෝ ගැටළු දැනටමත් ලොග් එකතු කිරීමේ විශේෂිත වාණිජ සමාගම් විසින් එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් විසඳා ඇත, නමුත් විවිධ හේතු නිසා සෑම කෙනෙකුටම SaaS භාවිතා කළ නොහැක. (ප්රධාන ඒවා වන්නේ පිරිවැය සහ 152-FZ සමඟ අනුකූල වීමයි).
මධ්යගත ලඝු-සටහන් එකතුව මුලදී සරල කාර්යයක් සේ පෙනේ, නමුත් එය කිසිසේත්ම නොවේ. එය මතක තබා ගැනීම වැදගත්ය:
- තීරනාත්මක සංරචක පමණක් සවිස්තරාත්මකව ලොග් විය යුතු අතර, අධීක්ෂණය සහ දෝෂ එකතු කිරීම අනෙකුත් පද්ධති සඳහා වින්‍යාස කළ හැක.
- අනවශ්ය බරක් එකතු නොකිරීමට නිෂ්පාදනයේ ලොග් අවම වශයෙන් තබා ගත යුතුය.
- ලඝු-සටහන් යන්ත්‍රයෙන් කියවිය හැකි, සාමාන්‍යකරණය කළ, සහ දැඩි ආකෘතියක් තිබිය යුතුය.
- ඇත්ත වශයෙන්ම විවේචනාත්මක ලඝු-සටහන් වෙනම ධාරාවකින් යැවිය යුතු අතර, එය ප්රධාන ඒවායින් වෙන් කළ යුතුය.
- ලොග් ඇකියුලේටරයක් සලකා බැලීම වටී, එමඟින් ඉහළ බරක් පුපුරා යාමෙන් ඔබව ගලවා ගත හැකි අතර ගබඩාවේ බර වඩාත් ඒකාකාරී වේ.
මෙම සරල නීති, සෑම තැනකම ක්‍රියාත්මක කරන්නේ නම්, ඉහත විස්තර කර ඇති පරිපථ ක්‍රියා කිරීමට ඉඩ සලසයි - ඒවායේ වැදගත් සංරචක (බැටරිය) නැති වුවද. ඔබ එවැනි මූලධර්මවලට අනුගත නොවන්නේ නම්, කාර්යය පහසුවෙන් ඔබව සහ යටිතල පහසුකම් පද්ධතියේ තවත් අධික ලෙස පටවා ඇති (සහ ඒ සමඟම අකාර්යක්ෂම) සංරචකයකට ගෙන යනු ඇත.
ප්රාදේශීය සභා
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «»;
- «»;
- «".
මූලාශ්රය: www.habr.com