මගේ නම ඇන්ටන් බඩරින්. මම උසස් තාක්ෂණ මධ්‍යස්ථානයේ සේවය කරන අතර පද්ධති පරිපාලනය කරමි. මාසයකට පෙර, අපගේ ආයතනික සම්මන්ත්‍රණය අවසන් වූ අතර, එහිදී අපි අපගේ සමුච්චිත අත්දැකීම් අපගේ නගරයේ තොරතුරු තාක්ෂණ ප්‍රජාව සමඟ බෙදා ගත්තෙමු. මම වෙබ් යෙදුම් අධීක්ෂණය ගැන කතා කළා. මෙම ක්‍රියාවලිය මුල සිටම ගොඩනඟා නොගත් කනිෂ්ඨ හෝ මධ්‍යම මට්ටම සඳහා ද්‍රව්‍යය අදහස් කරන ලදී.
ඕනෑම අධීක්ෂණ පද්ධතියකට යටින් ඇති මූලික ගල වන්නේ ව්‍යාපාරික ගැටළු විසඳීමයි. අධීක්ෂණය සඳහා අධීක්ෂණය කිරීම කිසිවෙකුට උනන්දුවක් නොදක්වයි. ව්‍යාපාරයට අවශ්‍ය කුමක්ද? එවිට සෑම දෙයක්ම ඉක්මනින් හා දෝෂයකින් තොරව ක්රියා කරයි. ව්‍යාපාරවලට ක්‍රියාශීලී වීමට අවශ්‍ය වේ, එවිට අප විසින්ම සේවාවේ ගැටලු හඳුනාගෙන ඒවා හැකි ඉක්මනින් විසඳා ගනිමු. ඇත්ත වශයෙන්ම, මේවා අපගේ පාරිභෝගිකයෙකු සඳහා වූ ව්‍යාපෘතියක් මත පසුගිය වසරේ මා විසඳූ ගැටළු වේ.
ව්යාපෘතිය ගැන
මෙම ව්යාපෘතිය රටේ විශාලතම ලෝයල්ටි වැඩසටහනකි. ප්‍රසාද කාඩ්පත් වැනි විවිධ අලෙවිකරණ මෙවලම් හරහා විකුණුම් වාර ගණන වැඩි කිරීමට අපි සිල්ලර දාමයන්ට උදව් කරමු. සමස්තයක් වශයෙන්, මෙම ව්‍යාපෘතියට සේවාදායක දහයකින් ක්‍රියාත්මක වන යෙදුම් 14ක් ඇතුළත් වේ.
සම්මුඛ පරීක්ෂණ ක්‍රියාවලිය අතරතුර, පරිපාලකයින් සැමවිටම අධීක්ෂණ වෙබ් යෙදුම් වෙත නිවැරදිව ප්‍රවේශ නොවන බව මම නැවත නැවතත් දුටුවෙමි: බොහෝ දෙනෙක් තවමත් මෙහෙයුම් පද්ධති ප්‍රමිතික කෙරෙහි අවධානය යොමු කරන අතර ඉඳහිට සේවා අධීක්ෂණය කරති.
මගේ නඩුවේදී, පාරිභෝගිකයාගේ නිරීක්ෂණ පද්ධතිය මීට පෙර Icinga මත පදනම් විය. එය කිසිදු ආකාරයකින් ඉහත ගැටලු විසඳුවේ නැත. බොහෝ විට සේවාදායකයා විසින්ම ගැටළු පිළිබඳව අපට දැනුම් දුන් අතර, බොහෝ විට, හේතුවේ පහළට යාමට අපට ප්‍රමාණවත් දත්ත නොතිබුණි.
ඊට අමතරව, එහි තවදුරටත් සංවර්ධනයේ නිෂ්ඵලභාවය පිළිබඳ පැහැදිලි අවබෝධයක් විය. මම හිතන්නේ ඉසිංග ගැන දන්න අය මාව තේරුම් ගනීවි. එබැවින්, ව්යාපෘතිය සඳහා වෙබ් යෙදුම් අධීක්ෂණ පද්ධතිය සම්පූර්ණයෙන්ම ප්‍රතිනිර්මාණය කිරීමට අපි තීරණය කළෙමු.
Prometheus
ප්රධාන දර්ශක තුනක් මත පදනම්ව අපි ප්‍රොමිතියස් තෝරා ගත්තෙමු:
- පවතින ප්‍රමිතික විශාල සංඛ්‍යාවක්. අපගේ නඩුවේදී ඔවුන්ගෙන් 60 දහසක් ඇත. ඇත්ත වශයෙන්ම, අපි ඔවුන්ගෙන් අතිමහත් බහුතරයක් (සමහර විට 95% ක් පමණ) භාවිතා නොකරන බව සඳහන් කිරීම වටී. අනෙක් අතට, ඒවා සියල්ලම සාපේක්ෂව ලාභදායී වේ. අපට නම්, මෙය කලින් භාවිතා කළ Icinga හා සසඳන විට අනෙක් අන්තයයි. එහි, ප්‍රමිතික එකතු කිරීම විශේෂ වේදනාවක් විය: පවතින ඒවා මිල අධික විය (ඕනෑම ප්ලගිනයක ප්‍රභව කේතය දෙස බලන්න). ඕනෑම ප්ලගිනයක් Bash හෝ Python හි ස්ක්‍රිප්ට් එකක් විය, එය දියත් කිරීම පරිභෝජනය කරන සම්පත් අනුව මිල අධික වේ.
- මෙම පද්ධතිය සාපේක්ෂව කුඩා සම්පත් ප්රමාණයක් පරිභෝජනය කරයි. අපගේ සියලු ප්‍රමිතික සඳහා 600 MB RAM, එක් හරයකින් 15% සහ IOPS දුසිම් කිහිපයක් ප්‍රමාණවත් වේ. ඇත්ත වශයෙන්ම, ඔබ ප්‍රමිතික අපනයනකරුවන් ක්‍රියාත්මක කළ යුතුය, නමුත් ඒවා සියල්ලම Go හි ලියා ඇති අතර ඒවා ඉතා බල තණ්හාවක් නොවේ. නූතන යථාර්ථයන් තුළ මෙය ගැටළුවක් යැයි මම නොසිතමි.
- Kubernetes වෙත සංක්රමණය කිරීමේ හැකියාව ලබා දෙයි. පාරිභෝගිකයාගේ සැලසුම් සැලකිල්ලට ගනිමින්, තේරීම පැහැදිලිය.
ELK
මීට පෙර, අපි ලඝු-සටහන් එකතු කිරීම හෝ සැකසීම නොකළෙමු. අඩුපාඩු කාටත් පැහැදිලියි. අපි ELK තෝරා ගත්තේ අපට දැනටමත් මෙම ක්‍රමය පිළිබඳ අත්දැකීම් ඇති බැවිනි. අපි එහි ගබඩා කරන්නේ යෙදුම් ලොග් පමණි. ප්රධාන තේරීම් නිර්ණායක වූයේ සම්පූර්ණ පෙළ සෙවීම සහ එහි වේගයයි.
Clickhouse
මුලදී, තේරීම InfluxDB මත වැටුණි. Nginx ලඝු-සටහන්, pg_stat_statements වෙතින් සංඛ්‍යාලේඛන එකතු කිරීම සහ Prometheus ඓතිහාසික දත්ත ගබඩා කිරීමේ අවශ්‍යතාවය අපි අවබෝධ කර ගත්තෙමු. අපි Influx වලට කැමති වුණේ නැහැ මොකද එය කලින් කලට විශාල මතක ප්රමාණයක් පරිභෝජනය කිරීමට පටන් ගෙන කඩා වැටෙනවා. මීට අමතරව, මට remote_addr මගින් විමසුම් සමූහ කිරීමට අවශ්‍ය විය, නමුත් මෙම DBMS හි කණ්ඩායම් කිරීම ටැග් මගින් පමණි. ටැග් මිල අධිකයි (මතකය), ඔවුන්ගේ අංකය කොන්දේසි සහිතව සීමිතය.
අපි නැවතත් අපේ සෙවීම ආරම්භ කළෙමු. අවශ්‍ය වූයේ අවම සම්පත් පරිභෝජනයක් සහිත විශ්ලේෂණාත්මක දත්ත සමුදායක්, වඩාත් සුදුසු වන්නේ තැටියේ දත්ත සම්පීඩනයයි.
Clickhouse මෙම සියලු නිර්ණායක සපුරාලන අතර, අපගේ තේරීම ගැන අපි කිසිවිටක පසුතැවෙන්නේ නැත. අපි එයට අසාමාන්‍ය දත්ත ප්රමාණයක් ලියන්නේ නැත (ඇතුළත් කිරීම් ගණන විනාඩියකට පන්දහසක් පමණ වේ).
NewRelic
NewRelic ඓතිහාසිකව අප සමඟ සිටියේ එය පාරිභෝගිකයාගේ තේරීම වූ බැවිනි. අපි එය APM එකක් ලෙස භාවිතා කරමු.
සර්බික්ස්
විවිධ API වල Black Box නිරීක්ෂණය කිරීමට අපි Zabbix භාවිතා කරන්නෙමු.
අධීක්ෂණ ප්‍රවේශයක් නිර්වචනය කිරීම
අපට අවශ්‍ය වූයේ කාර්යය දිරාපත් කිරීමට සහ එමඟින් අධීක්ෂණය සඳහා ප්රවේශය ක්‍රමානුකූල කිරීමට ය.
මෙය සිදු කිරීම සඳහා, මම අපගේ පද්ධතිය පහත මට්ටම්වලට බෙදා ඇත:
- දෘඪාංග සහ VMS;
- මෙහෙයුම් පද්ධතිය;
- පද්ධති සේවා, මෘදුකාංග තොගය;
- අයදුම්පත;
- ව්යාපාර තර්කනය.
මෙම ප්රවේශය පහසු වන්නේ ඇයි:
- එක් එක් මට්ටම්වල වැඩ සඳහා වගකිව යුත්තේ කවුරුන්ද යන්න අපි දන්නා අතර, මේ මත පදනම්ව, අපට ඇඟවීම් යැවිය හැකිය;
- ඇඟවීම් යටපත් කිරීමේදී අපට ව්‍යුහය භාවිතා කළ හැකිය - සමස්තයක් ලෙස අථත්‍ය යන්ත්‍රය නොමැති විට දත්ත සමුදාය නොමැතිකම පිළිබඳ ඇඟවීමක් යැවීම අමුතු දෙයක් වනු ඇත.
අපගේ කර්තව්‍යය වන්නේ පද්ධතියේ ක්‍රියාකාරිත්වයේ උල්ලංඝනයන් හඳුනා ගැනීම බැවින්, අනතුරු ඇඟවීමේ නීති ලිවීමේදී අවධානය යොමු කළ යුතු යම් ප්‍රමිතික කට්ටලයක් අපි එක් එක් මට්ටමින් ඉස්මතු කළ යුතුය. ඊළඟට, අපි "VMS", "මෙහෙයුම් පද්ධතිය" සහ "පද්ධති සේවා, මෘදුකාංග තොගය" මට්ටම් හරහා යමු.
අතථ්‍ය යන්ත්‍ර
සත්කාරකත්වය අපට ප්‍රොසෙසරයක්, තැටියක්, මතකයක් සහ ජාලයක් වෙන් කරයි. ඒවගේම අපිට මුල් දෙකේ ප්‍රශ්න තිබුණා. එබැවින්, මිනුම්:
CPU සොරකම් කරන ලද කාලය - ඔබ Amazon (t2.micro, උදාහරණයක් ලෙස) මත අතථ්‍ය යන්ත්‍රයක් මිලට ගන්නා විට, ඔබට සම්පූර්ණ ප්‍රොසෙසර හරයක් වෙන් කර නොමැති නමුත් එහි කාලයෙහි කෝටාවක් පමණක් බව ඔබ තේරුම් ගත යුතුය. ඔබ එය අවසන් වූ විට, ප්‍රොසෙසරය ඔබෙන් ඉවතට ගනු ඇත.
මෙම මෙට්රික් ඔබට එවැනි අවස්ථාවන් නිරීක්ෂණය කිරීමට සහ තීරණ ගැනීමට ඉඩ සලසයි. උදාහරණයක් ලෙස, තරබාරු ගාස්තුවක් ගැනීම හෝ පසුබිම් කාර්යයන් සහ API ඉල්ලීම් සැකසීම විවිධ සේවාදායකයන් වෙත බෙදා හැරීම අවශ්‍යද?
IOPS + CPU iowait කාලය - යම් හේතුවක් නිසා, බොහෝ ක්ලවුඩ් හොස්ටින් ප්‍රමාණවත් IOPS ලබා නොදීමෙන් පව් කරයි. එපමණක් නොව, අඩු IOPS සහිත කාලසටහනක් ඔවුන්ට තර්කයක් නොවේ. එබැවින්, CPU iowait එකතු කිරීම වටී. මෙම ප්‍රස්ථාර යුගලය සමඟ - අඩු IOPS සහ ඉහළ I/O බලා සිටීම - ඔබට දැනටමත් සත්කාරක සමාගම සමඟ කතා කර ගැටලුව විසඳා ගත හැක.
මෙහෙයුම් පද්ධතිය
මෙහෙයුම් පද්ධති ප්‍රමිතික:
- පවතින මතක ප්‍රමාණය% වලින්;
- swap භාවිත ක්‍රියාකාරකම්: vmstat swapin, swapout;
- පවතින ඉනෝඩ ගණන සහ ගොනු පද්ධතියේ නිදහස් ඉඩ %
- සාමාන්ය බර;
- tw රාජ්යයේ සම්බන්ධතා සංඛ්යාව;
- සම්බන්ධක වගුව සම්පූර්ණත්වය;
- ජාලයේ ගුණාත්මකභාවය ss උපයෝගීතාව, iproute2 පැකේජය භාවිතයෙන් නිරීක්ෂණය කළ හැකිය - එහි ප්රතිදානයෙන් RTT සම්බන්ධතා දර්ශකයක් ලබාගෙන එය dest port මගින් කණ්ඩායම් කරන්න.
මෙහෙයුම් පද්ධති මට්ටමේදී අපට ක්‍රියාවලි ලෙස එවැනි ආයතනයක් ඇත. එහි ක්‍රියාකාරිත්වයේ වැදගත් කාර්යභාරයක් ඉටු කරන ක්‍රියාවලි සමූහයක් පද්ධතිය තුළ හඳුනා ගැනීම වැදගත්ය. උදාහරණයක් ලෙස, ඔබට pgpools කිහිපයක් තිබේ නම්, ඔබ ඒ සෑම එකක් සඳහාම තොරතුරු රැස් කළ යුතුය.
ප්‍රමිතික කට්ටලය පහත පරිදි වේ:
- CPUs;
- මතකය මූලික වශයෙන් පදිංචි වේ;
- IO - IOPS හි වඩාත් සුදුසුය;
- FileFd - විවෘත සහ සීමාව;
- සැලකිය යුතු පිටු අසමත්වීම් - මේ ආකාරයෙන් ඔබට හුවමාරු වන ක්‍රියාවලිය තේරුම් ගත හැකිය.
අපි Docker හි සියලු නිරීක්ෂණ යොදවන අතර, අපි ප්‍රමිතික දත්ත රැස් කිරීමට උපදේශක භාවිතා කරමු. වෙනත් යන්ත්‍රවල අපි ක්‍රියාවලි අපනයනකරු භාවිතා කරමු.
පද්ධති සේවා, මෘදුකාංග තොගය
සෑම යෙදුමකටම එයටම ආවේණික වූ විශේෂතා ඇති අතර, නිශ්චිත ප්‍රමිතික කට්ටලයක් හුදකලා කිරීම අපහසුය.
විශ්වීය කට්ටලය වන්නේ:
- ඉල්ලීම් අනුපාතය;
- වැරදි සංඛ්යාව;
- ප්රමාදය;
- සන්තෘප්තිය.
මෙම මට්ටමේ නිරීක්ෂණ සඳහා අපගේ වඩාත්ම කැපී පෙනෙන උදාහරණ වන්නේ Nginx සහ PostgreSQL ය.
අපගේ පද්ධතියේ වැඩිපුරම පටවා ඇති සේවාව දත්ත සමුදායයි. අතීතයේදී, දත්ත සමුදාය කරන්නේ කුමක්දැයි සොයා ගැනීමට අපට බොහෝ විට ගැටළු ඇති විය.
අපි තැටි මත අධික බරක් දුටුවෙමු, නමුත් මන්දගාමී ලඝු-සටහන් ඇත්ත වශයෙන්ම කිසිවක් නොපෙන්වයි. විමසුම් සංඛ්‍යාලේඛන එකතු කරන දසුනක් වන pg_stat_statements භාවිතයෙන් අපි මෙම ගැටලුව විසඳා ගත්තෙමු.
ඇඩ්මින්ලට ඕන එච්චරයි.
අපි කියවීමේ සහ ලිවීමේ ඉල්ලීම්වල ක්‍රියාකාරකම්වල ප්‍රස්ථාර ගොඩනඟමු:
සෑම දෙයක්ම සරල සහ පැහැදිලි ය, සෑම ඉල්ලීමකටම තමන්ගේම වර්ණයක් ඇත.
සමානව කැපී පෙනෙන උදාහරණයක් වන්නේ Nginx ලොග් ය. ස්වල්ප දෙනෙක් ඒවා විග්‍රහ කිරීම හෝ තිබිය යුතු දේ ලැයිස්තුවේ සඳහන් කිරීම පුදුමයක් නොවේ. සම්මත ආකෘතිය ඉතා තොරතුරු නොවන අතර එය පුළුල් කළ යුතුය.
පුද්ගලිකව, මම request_time, upstream_response_time, body_bytes_sent, request_length, request_id එක් කළා. අපි ප්‍රතිචාර දැක්වීමේ වේලාව සහ දෝෂ ගණන සැලසුම් කරමු:
අපි ප්‍රතිචාර දැක්වීමේ කාලය සහ දෝෂ ගණන පිළිබඳ ප්‍රස්ථාර ගොඩනඟමු. මතකද? මම ව්යාපාර කාර්යයන් ගැන කතා කළාද? ඉක්මනින් සහ දෝෂ නොමැතිව? අපි දැනටමත් මෙම ගැටළු ප්‍රස්ථාර දෙකකින් ආවරණය කර ඇත්තෙමු. තවද ඔබට දැනටමත් ඔවුන් භාවිතා කරමින් රාජකාරියේ යෙදී සිටින පරිපාලකයින් ඇමතීමට හැකිය.
නමුත් තවත් එක් ගැටළුවක් ඉතිරිව ඇත - සිදුවීමට හේතු ඉක්මනින් ඉවත් කිරීම සහතික කිරීම.
සිද්ධි නිරාකරණය
ගැටලුවක් හඳුනාගැනීමේ සිට විසඳීම දක්වා සම්පූර්ණ ක්‍රියාවලිය පියවර ගණනාවකට බෙදිය හැකිය:
- ගැටලුව හඳුනා ගැනීම;
- රාජකාරි පරිපාලක වෙත දැනුම් දීම;
- සිද්ධියකට ප්රතිචාරය;
- හේතු ඉවත් කිරීම.
අපි මෙය හැකි ඉක්මනින් කළ යුතු බව වැදගත් ය. ගැටලුවක් හඳුනාගෙන දැනුම්දීමක් යැවීමේ අදියරේදී අපට වැඩි කාලයක් ලබා ගත නොහැකි නම් - ඕනෑම අවස්ථාවක මිනිත්තු දෙකක් ඔවුන් වෙනුවෙන් වැය කරනු ඇත, පසුව ඒවා වැඩිදියුණු කිරීම් සඳහා කෙත් ඉවත් කරනු ලැබේ.
අපි හිතමු රාජකාරි නිලධාරියාගේ දුරකථනය නාද වුණා කියලා. ඔහු කුමක් කරයිද? ප්‍රශ්නවලට පිළිතුරු සොයන්න - කැඩී ගියේ කුමක්ද, එය කැඩී ගියේ කොතැනින්ද, ප්‍රතික්‍රියා කරන්නේ කෙසේද? මෙන්න අපි මෙම ප්‍රශ්නවලට පිළිතුරු සපයන ආකාරය:
අපි මෙම සියලු තොරතුරු දැනුම්දීමේ පෙළට ඇතුළත් කර, මෙම ගැටලුවට ප්‍රතිචාර දක්වන්නේ කෙසේද, එය විසඳන්නේ කෙසේද සහ එය උත්සන්න කරන්නේ කෙසේද යන්න විස්තර කරන විකි පිටුවකට සබැඳියක් ලබා දෙන්න.
මම තවමත් යෙදුම් ස්ථරය සහ ව්‍යාපාරික තර්කනය ගැන කිසිවක් පවසා නැත. අවාසනාවන්ත ලෙස, අපගේ යෙදුම් තවමත් ප්‍රමිතික එකතුව ක්‍රියාත්මක නොකරයි. මෙම මට්ටම් වලින් ඕනෑම තොරතුරක එකම මූලාශ්රය ලඝු-සටහන් වේ.
කරුණු කිහිපයක්.
පළමුව, ව්‍යුහගත ලඝු-සටහන් ලියන්න. පණිවිඩයේ පෙළට සන්දර්භය ඇතුළත් කිරීමට අවශ්‍ය නැත. මේ නිසා ඒවා කණ්ඩායම් කිරීමට සහ විශ්ලේෂණය කිරීමට අපහසු වේ. මේ සියල්ල සාමාන්‍යකරණය කිරීමට Logstash බොහෝ කාලයක් ගතවේ.
දෙවනුව, බරපතල මට්ටම් නිවැරදිව භාවිතා කරන්න. සෑම භාෂාවකටම තමන්ගේම සම්මතයක් ඇත. පුද්ගලිකව, මම මට්ටම් හතරක් වෙන් කරමි:
- දෝෂයක් නැත;
- සේවාදායක පැත්තේ දෝෂය;
- වැරැද්ද අපේ පැත්තේ, අපි මුදල් නැති කර ගන්නේ නැහැ, අපි අවදානම් දරන්නේ නැහැ;
- වැරැද්ද අපේ පැත්තේ, අපිට සල්ලි නැති වෙනවා.
මට සාරාංශ කිරීමට ඉඩ දෙන්න. ඔබ ව්යාපාර තර්කනය මත පදනම්ව නිරීක්ෂණ ගොඩනැගීමට උත්සාහ කළ යුතුය. යෙදුමම නිරීක්ෂණය කිරීමට සහ විකුණුම් ගණන, නව පරිශීලක ලියාපදිංචි කිරීම් ගණන, දැනට ක්‍රියාකාරී පරිශීලකයින් සංඛ්යාව සහ යනාදිය වැනි ප්‍රමිතික සමඟ ක්රියා කිරීමට උත්සාහ කරන්න.
ඔබගේ සම්පූර්ණ ව්‍යාපාරය බ්‍රවුසරයේ එක් බොත්තමක් නම්, එය ක්ලික් කර නිසි ලෙස ක්රියා කරන්නේ දැයි ඔබ නිරීක්ෂණය කළ යුතුය. ඉතිරි සියල්ල කමක් නැත.
ඔබට මෙය නොමැති නම්, අප කළාක් මෙන් ඔබට යෙදුම් ලොග, Nginx ලොග සහ යනාදිය තුළ එය අල්ලා ගැනීමට උත්සාහ කළ හැකිය. ඔබ යෙදුමට හැකි තරම් සමීප විය යුතුය.
මෙහෙයුම් පද්ධති ප්‍රමිතික ඇත්ත වශයෙන්ම වැදගත් වේ, නමුත් ව්‍යාපාරය ඒවා ගැන උනන්දුවක් නොදක්වයි, අපට ඒවා සඳහා ගෙවනු නොලැබේ.
මූලාශ්රය: www.habr.com