VictoriaMetrics යනු කාල ශ්‍රේණියක ස්වරූපයෙන් දත්ත ගබඩා කිරීම සහ සැකසීම සඳහා වේගවත් හා පරිමාණය කළ හැකි DBMS වේ (වාර්තාවක් යනු මෙම කාලයට අනුරූප වන කාලය සහ අගයන් සමූහයකින් සමන්විත වේ, නිදසුනක් ලෙස, සංවේදකවල තත්ත්වය පිළිබඳ වරින් වර ඡන්ද විමසීමෙන් ලබාගත් හෝ මිනුම් එකතුව).
මගේ නම Kolobaev Pavel. DevOps, SRE, LeroyMerlin, හැම දෙයක්ම කේතය වගේ - ඒ සියල්ල අපි ගැන: මා ගැන සහ අනෙකුත් LeroyMerlin සේවකයින් ගැන.
OpenStack මත පදනම් වූ වලාකුළක් ඇත. තාක්ෂණික රේඩාර් වෙත කුඩා සබැඳියක් ඇත.
එය ගොඩනගා ඇත්තේ Kubernetes දෘඩාංග මත මෙන්ම OpenStack සහ logging සඳහා අදාළ සියලුම සේවාවන් මත ය.
මේක තමයි අපි සංවර්ධනයේදී තිබුණු යෝජනා ක්‍රමය. අපි මේ සියල්ල සංවර්ධනය කරන විට, අපට K8s පොකුර තුළම දත්ත ගබඩා කරන Prometheus ක්‍රියාකරුවෙකු සිටියේය. ස්ක්‍රබ් කළ යුතු දේ ඔහු ඉබේම සොයා ගෙන එය ඔහුගේ පාද යට තබයි, දළ වශයෙන්.
අපට සියලු දත්ත Kubernetes පොකුරෙන් පිටතට ගෙන යාමට අවශ්ය වනු ඇත, මන්ද යමක් සිදුවුවහොත්, කුමක්ද සහ කොතැනද යන්න අප තේරුම් ගත යුතුය.
පළමු විසඳුම නම්, අපි ෆෙඩරේෂන් යාන්ත්‍රණය හරහා කුබර්නෙටස් පොකුරට යන විට, අපට තෙවන පාර්ශවීය ප්‍රොමිතියස් සිටින විට අපි ෆෙඩරේෂන් භාවිතා කිරීමයි.
නමුත් මෙහි කුඩා ගැටළු කිහිපයක් තිබේ. අපගේ නඩුවේදී, අපට මෙට්රික් 250 ක් ඇති විට ගැටළු ආරම්භ වූ අතර, මෙට්රික් 000 ක් ඇති විට, අපට එසේ වැඩ කළ නොහැකි බව අපට වැටහුණි. අපි scrape_timeout තත්පර 400 දක්වා වැඩි කළෙමු.
අපට මෙය කිරීමට සිදු වූයේ ඇයි? Prometheus වැටේ ආරම්භයේ සිට කාල සීමාව ගණනය කිරීමට පටන් ගනී. දත්ත තවමත් ගලා යන බව කමක් නැත. මෙම නිශ්චිත කාල සීමාව තුළ දත්ත ඒකාබද්ධ කර නොමැති නම් සහ http හරහා සැසිය වසා නොගන්නේ නම්, සැසිය අසාර්ථක වූ බව සලකනු ලබන අතර දත්ත ප්‍රොමිතියස් තුළට නොපැමිණේ.
සමහර දත්ත අතුරුදහන් වූ විට අපට ලැබෙන ප්‍රස්ථාර සෑම කෙනෙකුටම හුරුපුරුදුය. කාලසටහන් ඉරා දමා ඇති අතර අපි මේ ගැන සතුටු නොවෙමු.
මීළඟ විකල්පය වන්නේ එකම ෆෙඩරේෂන් යාන්ත්‍රණය හරහා විවිධ ප්‍රොමිතියස් දෙකක් මත පදනම්ව බෙදා හැරීමයි.
උදාහරණයක් ලෙස, ඒවා ගෙන ඒවා නමින් කොටස් කරන්න. මෙයද භාවිතා කළ හැකිය, නමුත් අපි ඉදිරියට යාමට තීරණය කළෙමු.
අපට දැන් මෙම කැබලි කෙසේ හෝ සැකසීමට සිදුවනු ඇත. ඔබට ප්‍රොම්ක්සි ගත හැකිය, එය ෂාර්ඩ් ප්‍රදේශයට ගොස් දත්ත ගුණ කරයි. එය තනි පිවිසුම් ලක්ෂ්‍යයක් ලෙස කැබලි දෙකක් සමඟ ක්‍රියා කරයි. මෙය promxy හරහා ක්‍රියාත්මක කළ හැකි නමුත් එය තවමත් ඉතා අපහසුය.
පළමු විකල්පය නම් ෆෙඩරේෂන් යාන්ත්‍රණය ඉතා මන්දගාමී බැවින් එය අත්හැරීමට අපට අවශ්‍යයි.
Prometheus සංවර්ධකයින් පැහැදිලිවම පවසන්නේ, "යාලුවනේ, අපි ප්රමිතික දිගුකාලීන ගබඩා කිරීමට සහය නොදක්වන නිසා වෙනත් TimescaleDB එකක් භාවිතා කරන්න." මෙය ඔවුන්ගේ කාර්යයක් නොවේ.
සෑම දෙයක්ම එක තැනක ගබඩා නොකිරීමට අපි තවමත් පිටත බෑමට අවශ්ය කඩදාසි කැබැල්ලක ලියා තබමු.
දෙවන අවාසිය නම් මතක පරිභෝජනයයි. ඔව්, 2020 දී ගිගාබයිට් කිහිපයක් මතකයේ සතයක් වැය වන බව බොහෝ දෙනෙක් කියනු ඇති බව මට වැටහේ, නමුත් තවමත්.
දැන් අපට dev සහ prod පරිසරයක් ඇත. dev හි එය මෙට්රික් 9 සඳහා ගිගාබයිට් 350ක් පමණ වේ. නිෂ්පාදනයේදී එය ගිගාබයිට් 000ක් සහ මෙට්රික් 14කට වඩා ටිකක් වැඩියි. ඒ අතරම, අපගේ රඳවා තබා ගැනීමේ කාලය විනාඩි 780 ක් පමණි. මේක නරකයි. දැන් මම පැහැදිලි කරන්නම් ඇයි කියලා.
අපි ගණනය කිරීමක් කරන්නෙමු, එනම් මෙට්රික් මිලියන එකහමාරක් සමඟ, අපි දැනටමත් ඒවාට සමීපව සිටිමු, සැලසුම් අවධියේදී අපට ගිගාබයිට් 35-37 මතකයක් ලැබේ. නමුත් දැනටමත් මෙට්රික් මිලියන 4කට ගිගාබයිට් 90ක පමණ මතකයක් අවශ්ය වේ. එනම්, එය Prometheus සංවර්ධකයින් විසින් සපයන ලද සූත්රය භාවිතයෙන් ගණනය කරන ලදී. අපි සහසම්බන්ධය දෙස බැලූ අතර නිරීක්ෂණය සඳහා පමණක් සේවාදායකයක් සඳහා මිලියන කිහිපයක් ගෙවීමට අපට අවශ්ය නැති බව අවබෝධ විය.
අපි යන්ත්‍ර සංඛ්‍යාව වැඩි කරනවා පමණක් නොව, අපි අථත්‍ය යන්ත්‍ර ද නිරීක්ෂණය කරමු. එබැවින්, අථත්‍ය යන්ත්‍ර වැඩි වන තරමට, විවිධ වර්ගවල ප්රමිතික වැඩි වන විට, ප්රමිතික අනුව අපගේ පොකුරේ විශේෂ වර්ධනයක් අපට ලැබෙනු ඇත.
තැටි අවකාශය සමඟ, මෙහි සෑම දෙයක්ම එතරම් නරක නැත, නමුත් මම එය වැඩිදියුණු කිරීමට කැමතියි. අපට දින 15ක් තුළ මුළු ගිගාබයිට් 120ක් ලැබුණි, එයින් 100ක් සම්පීඩිත දත්ත, 20ක් සම්පීඩිත දත්ත, නමුත් අපට අවශ්ය වන්නේ අඩුවෙන්.
ඒ අනුව, අපි තවත් එක් කරුණක් ලියන්නෙමු - මෙය අපට තවමත් ඉතිරි කිරීමට අවශ්ය විශාල සම්පත් පරිභෝජනයකි, මන්ද අපගේ අධීක්ෂණ පොකුර OpenStack කළමනාකරණය කරන අපගේ පොකුරට වඩා වැඩි සම්පත් පරිභෝජනය කිරීමට අපට අවශ්ය නැති බැවිනි.
ප්‍රොමිතියස්ගේ තවත් එක් අඩුපාඩුවක් තිබේ, එය අප විසින්ම හඳුනාගෙන ඇත, මෙය අවම වශයෙන් යම් ආකාරයක මතක සීමාවකි. ප්‍රොමිතියස් සමඟ, මෙහි සෑම දෙයක්ම වඩා නරක ය, මන්ද එයට එවැනි හැරීම් කිසිසේත් නොමැති බැවිනි. ඩොකර් හි සීමාවක් භාවිතා කිරීම ද විකල්පයක් නොවේ. හදිසියේම ඔබේ RAF වැටී 20-30 ගිගාබයිට් තිබේ නම්, එය ඉහළ යාමට ඉතා දිගු කාලයක් ගතවනු ඇත.
Prometheus අපට නොගැලපෙන තවත් හේතුවක් මෙයයි, එනම් මතක පරිභෝජනය සීමා කළ නොහැක.
එවැනි යෝජනා ක්රමයක් ඉදිරිපත් කිරීමට හැකි වනු ඇත. HA පොකුරක් සංවිධානය කිරීම සඳහා අපට මෙම යෝජනා ක්‍රමය අවශ්ය වේ. මෙම ප්රමිතික ගබඩා කරන සේවාදායකය බිඳ වැටුණද, අපගේ ප්රමිතික සැම විටම සහ සෑම තැනකම තිබීමට අපට අවශ්යය. එබැවින් අපට එවැනි යෝජනා ක්රමයක් ගොඩ නැගීමට සිදුවනු ඇත.
මෙම යෝජනා ක්‍රමය පවසන්නේ අපට කැබලිවල අනුපිටපත් ඇති බවත්, ඒ අනුව, පරිභෝජනය කරන සම්පත්වල පිරිවැය අනුපිටපත් කරන බවත්ය. එය පාහේ තිරස් අතට පරිමාණය කළ හැකි නමුත් කෙසේ වෙතත් සම්පත් පරිභෝජනය අපායක් වනු ඇත.
අවාසි අප විසින්ම ලියා ඇති ආකාරයෙන් අනුපිළිවෙලින්:
- බාහිරව ප්රමිතික උඩුගත කිරීම අවශ්ය වේ.
- ඉහළ සම්පත් පරිභෝජනය.
- මතක පරිභෝජනය සීමා කිරීමට ක්රමයක් නොමැත.
- HA හි සංකීර්ණ සහ සම්පත්-දැඩි ක්‍රියාත්මක කිරීම.
අප වෙනුවෙන්ම, අපි ගබඩා පහසුකමක් ලෙස Prometheus වෙතින් ඉවත්ව යන බව අපි තීරණය කළෙමු.
අපට අවශ්ය අමතර අවශ්‍යතා අප විසින් හඳුනාගෙන ඇත. මෙය:
- මෙය promql සහාය වේ, මන්ද දැනටමත් Prometheus සඳහා බොහෝ දේ ලියා ඇත: විමසුම්, ඇඟවීම්.
- ඉන්පසුව අපට ග්‍රැෆානා ඇත, එය දැනටමත් ප්‍රොමිතියස් සඳහා පසුබිමක් ලෙස හරියටම ලියා ඇත. මට උපකරණ පුවරු නැවත ලිවීමට අවශ්ය නැත.
- අපට සාමාන්‍ය HA ගෘහ නිර්මාණ ශිල්පයක් ගොඩනැගීමට අවශ්‍යයි.
- ඕනෑම සම්පත් පරිභෝජනය අඩු කිරීමට අපට අවශ්යය.
- තවත් කුඩා සූක්ෂ්මතාවයක් තිබේ. අපට විවිධ වර්ගයේ ක්ලවුඩ් මෙට්රික් එකතු කිරීමේ පද්ධති භාවිතා කළ නොහැක. අපි තවම මෙම මිතික වලට වැටෙන්නේ කුමක්දැයි නොදනිමු. ඕනෑම දෙයක් එහි පියාසර කළ හැකි බැවින්, අපි දේශීය ස්ථානගත කිරීම්වලට සීමා විය යුතුය.
පොඩි තේරීමක් තිබුණා. අපි අත්දැකීම් ඇති හැම දෙයක්ම එකතු කළා. අපි ඒකාබද්ධ කිරීමේ කොටසේ Prometheus පිටුව දෙස බලා, ලිපි පොකුරක් කියවා, එහි ඇති දේ දුටුවෙමු. අපි වෙනුවෙන්ම, අපි ප්‍රොමිතියස් වෙනුවට ආදේශකයක් ලෙස වික්ටෝරියා මෙට්‍රික්ස් තෝරා ගත්තෙමු.
ඇයි? නිසා:
- promql දන්නවා.
- මොඩියුලර් ගෘහ නිර්මාණ ශිල්පයක් ඇත.
- Grafana වෙත වෙනස්කම් අවශ්ය නොවේ.
- වැදගත්ම දෙය නම්, අපි බොහෝ විට අපගේ සමාගම තුළ ප්රමිතික ගබඩාව සේවාවක් ලෙස සපයනු ඇත, එබැවින් අපි විවිධ ආකාරයේ සීමා කිරීම් සඳහා කල්තියාම බලා සිටිමු, එවිට පරිශීලකයින්ට පොකුරේ ඇති සියලුම සම්පත් සීමිත ආකාරයකින් භාවිතා කළ හැකිය, මන්ද එය බහුකාර්ය වනු ඇත.
අපි පළමු සංසන්දනය කරමු. අපි එකම Prometheus පොකුර ඇතුලට ගන්නවා, බාහිර Prometheus ඒකට යනවා. remoteWrite VictoriaMetrics හරහා එකතු කරන්න.
VictoriaMetrics වෙතින් CPU පරිභෝජනයෙහි සුළු වැඩිවීමක් මෙහිදී අප විසින් අල්ලා ගන්නා ලද බව මම වහාම වෙන්කරවා ගනිමි. VictoriaMetrics wiki ඔබට හොඳම පරාමිති මොනවාදැයි කියයි. අපි ඒවා පරීක්ෂා කළා. ඔවුන් CPU පරිභෝජනය ඉතා හොඳින් අඩු කර ඇත.
අපගේ නඩුවේදී, Kubernetes පොකුරේ පිහිටා ඇති Prometheus හි මතක පරිභෝජනය සැලකිය යුතු ලෙස වැඩි නොවීය.
අපි එකම දත්තවල දත්ත මූලාශ්‍ර දෙකක් සංසන්දනය කරමු. Prometheus හි අපට පෙනෙන්නේ එකම නැතිවූ දත්ත ය. VictoriaMetrics හි සියල්ල හොඳයි.
තැටි අවකාශය පරීක්ෂණ ප්රතිඵල. Prometheus හි අපට ගිගාබයිට් 120 ක් ලැබුණි. VictoriaMetrics හි අපට දැනටමත් දිනකට ගිගාබයිට් 4 ක් ලැබේ. අපි Prometheus හි දැකීමට පුරුදු වී සිටින දේට වඩා තරමක් වෙනස් යාන්ත්‍රණයක් තිබේ. එනම්, දත්ත දැනටමත් දිනකට, පැය භාගයකින් හොඳින් සම්පීඩිත වේ. පසුව දත්ත තවමත් නැති වී යන බව නොතකා, ඒවා දැනටමත් දිනකට, පැය භාගයකින් හොඳින් නෙළා ඇත. ප්රතිඵලයක් වශයෙන්, අපි තැටි ඉඩ ඉතිරි කර ඇත.
අපි මතක සම්පත් පරිභෝජනය ද ඉතිරි කරමු. පරීක්ෂා කරන අවස්ථාවේදී, අපි ප්‍රොමිතියස් අථත්‍ය යන්ත්‍රයක යොදවා තිබුණි - කෝර් 8, ගිගාබයිට් 24. Prometheus සෑම දෙයක්ම පාහේ අනුභව කරයි. ඔහු OOM Killer මත වැටුණි. ඒ අතරම, එයට සක්‍රීය මෙට්රික් 900 ක් පමණක් වත් කරන ලදී. මෙය තත්පරයට මෙට්රික් 000-25 පමණ වේ.
අපි VictoriaMetrics ධාවනය කළේ ගිගාබයිට් 8ක RAM එකක් සහිත dual-core අතථ්‍ය යන්ත්‍රයක් මතයි. 8GB යන්ත්‍රයක දේවල් කිහිපයක් සමඟින් එහා මෙහා යාමෙන් VictoriaMetrics හොඳින් ක්‍රියා කිරීමට අපි සමත් විය. අවසානයේදී, අපි එය ගිගාබයිට් 7 දක්වා තබා ගත්තෙමු. ඒ අතරම, අන්තර්ගතය බෙදා හැරීමේ වේගය, එනම් මිතික, Prometheus ට වඩා වැඩි විය.
Prometheus හා සසඳන විට CPU වඩා හොඳ වී ඇත. මෙහිදී Prometheus විසින් cores 2,5ක් පරිභෝජනය කරන අතර VictoriaMetrics විසින් cores 0,25ක් පමණක් පරිභෝජනය කරයි. ආරම්භයේදී - 0,5 cores. එය ඒකාබද්ධ වන විට, එය එක් හරයකට ළඟා වේ, නමුත් මෙය අතිශයින්, අතිශයින් දුර්ලභ ය.
අපගේ නඩුවේදී, පැහැදිලි හේතු නිසා තේරීම VictoriaMetrics මත වැටුණි; අපට මුදල් ඉතිරි කිරීමට අවශ්ය වූ අතර අපි එය කළෙමු.
අපි වහාම කරුණු දෙකක් හරස් කරමු - ප්රමිතික උඩුගත කිරීම සහ සම්පත්වල ඉහළ පරිභෝජනය. ඒ වගේම අපිට තවම අපිට ඉතිරි වෙලා තියෙන කරුණු දෙකක් තීරණය කරන්න විතරයි තියෙන්නේ.
මෙන්න මම වහාම වෙන් කිරීමක් කරන්නම්, අපි VictoriaMetrics ප්රමිතික ගබඩාවක් ලෙස සලකමු. නමුත් අපි බොහෝ විට සියලුම Leroy සඳහා ගබඩාව ලෙස VictoriaMetrics ලබා දෙන බැවින්, මෙම පොකුර අපට ලබා නොදෙන ලෙස භාවිතා කරන අය සීමා කළ යුතුය.
කාලය, දත්ත පරිමාව සහ ක්‍රියාත්මක කිරීමේ කාලය අනුව සීමා කිරීමට ඔබට ඉඩ සලසන අපූරු පරාමිතියක් තිබේ.
මතක පරිභෝජනය සීමා කිරීමට අපට ඉඩ සලසන විශිෂ්ට විකල්පයක් ද ඇත, එමඟින් අපට සාමාන්‍ය මෙහෙයුම් වේගය සහ ප්‍රමාණවත් සම්පත් පරිභෝජනය ලබා ගැනීමට ඉඩ සලසන ශේෂය සොයාගත හැකිය.
තවත් එක් කරුණක් අඩු කරන්න, එනම් ලක්ෂ්‍යය ඉක්මවා යන්න - ඔබට මතක පරිභෝජනය සීමා කළ නොහැක.
පළමු පුනරාවර්තන වලදී, අපි VictoriaMetrics Single Node පරීක්ෂා කළෙමු. ඊළඟට අපි VictoriaMetrics Cluster Version වෙත යන්නෙමු.
VictoriaMetrics හි විවිධ සේවාවන් ඔවුන් ක්‍රියාත්මක කරන්නේ කුමක් මතද සහ ඔවුන් පරිභෝජනය කරන්නේ කුමන සම්පත් මතද යන්න මත මෙහි අපට නිදහස් හස්තයක් ඇත. මෙය ඉතා නම්‍යශීලී සහ පහසු විසඳුමකි. අපි මෙය අපටම භාවිතා කළෙමු.
VictoriaMetrics Cluster අනුවාදයේ ප්‍රධාන සංරචක වන්නේ vmstsorage වේ. ඒවායින් N අංකයක් තිබිය හැක. අපගේ නඩුවේ දැනට ඒවායින් 2 ක් ඇත.
ඒ වගේම vminsert තියෙනවා. මෙය අපට ඉඩ දෙන ප්‍රොක්සි සේවාදායකයකි: අප එයට පැවසූ සියලුම ගබඩා අතර බෙදා හැරීම සැකසීමට සහ එය අනුරුවකට ද ඉඩ දෙයි, එනම් ඔබට ෂර්ඩින් සහ අනුරුවක් යන දෙකම ඇත.
Vminsert Prometheus වෙතින් OpenTSDB, Graphite, InfluxDB සහ remoteWrite ප්‍රොටෝකෝල සඳහා සහය දක්වයි.
vmselect එකත් තියෙනවා. එහි ප්‍රධාන කාර්යය වන්නේ vmstorage වෙත ගොස් ඔවුන්ගෙන් දත්ත ලබාගෙන මෙම දත්ත ඩුප්ලිකේට් කර සේවාදායකයාට ලබා දීමයි.
vmagent කියලා අපූරු දෙයක් තියෙනවා. අපි ඇත්තටම ඇයට කැමතියි. එය ඔබට Prometheus මෙන් හරියටම වින්‍යාස කිරීමට සහ තවමත් Prometheus මෙන් සෑම දෙයක්ම කිරීමට ඉඩ සලසයි. එනම්, එය විවිධ ආයතන සහ සේවාවන්ගෙන් මිතික එකතු කර ඒවා vminsert වෙත යවයි. එවිට සෑම දෙයක්ම ඔබ මත රඳා පවතී.
තවත් විශිෂ්ට සේවාවක් වන්නේ vmalert වන අතර එමඟින් ඔබට VictoriaMetrics පසුබිමක් ලෙස භාවිතා කිරීමට, vminsert වෙතින් සැකසූ දත්ත ලබා ගැනීමට සහ එය vmselect වෙත යැවීමට ඉඩ සලසයි. එය අනතුරු ඇඟවීම් මෙන්ම නීති ද සකස් කරයි. ඇඟවීම් වලදී, අපි ඇලර්ට් කළමනාකරු හරහා ඇඟවීම් ලබා ගනිමු.
wmauth සංරචකයක් ඇත. අපි එය පොකුරු බහුකාර්ය අනුවාදය සඳහා අවසර පද්ධතියක් ලෙස භාවිතා කළ හැකිය (මෙය තවමත් තීරණය කර නැත) භාවිතා කළ හැකිය. එය Prometheus සඳහා remoteWrite සඳහා සහය දක්වන අතර ඔබට ලිවිය හැකි හෝ කළ නොහැකි url හෝ එහි දෙවන කොටස මත පදනම්ව අවසර දිය හැක.
vmbackup, vmrestore ද ඇත. මෙය සාරාංශයක් ලෙස, සියලු දත්තවල ප්රතිෂ්ඨාපනය සහ උපස්ථය වේ. S3, GCS, file කරන්න පුළුවන්.
අපගේ පොකුරේ පළමු පුනරාවර්තනය නිරෝධායනය අතරතුර සිදු කරන ලදී. ඒ වන විට අනුරුවක් නොතිබූ අතර, අපගේ පුනරාවර්තනය එකිනෙකට වෙනස් සහ ස්වාධීන පොකුරු දෙකකින් සමන්විත වූ අතර එමඟින් අපට දුරස්ථ ලිවීම හරහා දත්ත ලැබුණි.
අපි VictoriaMetrics Single Node සිට VictoriaMetrics Cluster Version වෙත මාරු වූ විට, අපි තවමත් පරිභෝජනය කරන ලද සම්පත් සමඟම සිටිමු, එනම් ප්‍රධාන එක මතකය බව මෙහිදී මම වෙන්කරවා ගනිමි. මෙය ආසන්න වශයෙන් අපගේ දත්ත, එනම් සම්පත් පරිභෝජනය, බෙදා හරින ලද ආකාරයයි.
මෙහි අනුරුවක් දැනටමත් එකතු කර ඇත. අපි මේ සියල්ල සාපේක්ෂ විශාල පොකුරකට ඒකාබද්ධ කළෙමු. අපගේ සියලුම දත්ත කොටස් කර ඇති අතර අනුකරණය කර ඇත.
සම්පූර්ණ පොකුරට N ඇතුල්වීමේ ස්ථාන ඇත, එනම් Prometheus හට HAPROXY හරහා දත්ත එක් කළ හැක. මෙන්න අපට මෙම පිවිසුම් ස්ථානය ඇත. තවද මෙම පිවිසුම් ස්ථානය හරහා ඔබට Grafana වෙතින් ලොග් විය හැකිය.
අපගේ නඩුවේදී, HAPROXY යනු මෙම පොකුර තුළ ප්‍රොක්සි විසින් තෝරන, ඇතුළු කරන සහ වෙනත් සේවාවන් කරන එකම තොටයි. අපගේ නඩුවේදී, එක් ලිපිනයක් සෑදීමට නොහැකි විය; අපට ඇතුල් වීමේ ස්ථාන කිහිපයක් කිරීමට සිදු විය, මන්ද VictoriaMetrics පොකුරු ධාවනය වන අතථ්‍ය යන්ත්‍ර එකම වලාකුළු සැපයුම්කරුගේ විවිධ කලාපවල පිහිටා ඇත, එනම් අපගේ වලාකුළ තුළ නොව පිටත ය. .
අපට අනතුරු ඇඟවීමක් තිබේ. අපි එය භාවිතා කරමු. අපි Prometheus වෙතින් අනතුරු ඇඟවීමේ කළමනාකරු භාවිතා කරමු. අපි Opsgenie සහ Telegram අනතුරු ඇඟවීමේ බෙදාහැරීමේ නාලිකාවක් ලෙස භාවිතා කරමු. ටෙලිග්‍රාම් හි ඔවුන් dev වෙතින් වත් කරනු ලැබේ, සමහර විට prod වෙතින් යමක්, නමුත් බොහෝ විට ඉංජිනේරුවන්ට අවශ්ය සංඛ්‍යානමය දෙයක්. සහ Opsgenie විවේචනාත්මක ය. මේවා ඇමතුම්, සිදුවීම් කළමනාකරණය.
සදාකාලික ප්රශ්නය: "අධීක්ෂණය අධීක්ෂණය කරන්නේ කවුද?" අපගේ නඩුවේදී, අධීක්ෂණ මොනිටර එයම අධීක්ෂණය කරයි, මන්ද අපි එක් එක් නෝඩය මත vmagent භාවිතා කරන බැවිනි. අපගේ නෝඩ් එකම සැපයුම්කරුගේ විවිධ දත්ත මධ්‍යස්ථාන හරහා බෙදා හරින බැවින්, සෑම දත්ත මධ්‍යස්ථානයකටම තමන්ගේම නාලිකාවක් ඇත, ඒවා ස්වාධීන වන අතර බෙදුණු මොළයක් පැමිණියද, අපට තවමත් ඇඟවීම් ලැබෙනු ඇත. ඔව්, ඒවායින් වැඩි ගණනක් පවතිනු ඇත, නමුත් කිසිවකට වඩා වැඩි ඇඟවීම් ලබා ගැනීම වඩා හොඳය.
අපි HA ක්‍රියාත්මක කිරීමකින් අපගේ ලැයිස්තුව අවසන් කරමු.
තවද මම වික්ටෝරියා මෙට්‍රික්ස් ප්‍රජාව සමඟ සන්නිවේදනය කිරීමේ අත්දැකීම සටහන් කිරීමට කැමැත්තෙමි. එය ඉතා ධනාත්මක විය. කොල්ලෝ ප්‍රතිචාර දක්වනවා. ඔවුන් ඉදිරිපත් කරන සෑම නඩුවක්ම සොයා බැලීමට උත්සාහ කරති.
මම GitHub හි ගැටළු ආරම්භ කළෙමි. ඒවා ඉතා ඉක්මනින් විසඳා ඇත. සම්පුර්ණයෙන්ම වසා නොමැති තවත් ගැටළු කිහිපයක් ඇත, නමුත් මෙම දිශාවට ක්‍රියාත්මක වන කේතයෙන් මට දැනටමත් පෙනේ.
පුනරාවර්තන අතරතුර මට ඇති වූ ප්‍රධාන වේදනාව වූයේ මම නෝඩයක් වසා දැමුවහොත්, පළමු තත්පර 30 සඳහා vminsert හට පසුබිමක් නොමැති බව තේරුම් ගත නොහැකි වීමයි. මෙය දැන් තීරණය කර ඇත. තත්පරයකින් හෝ දෙකකින්, ඉතිරි සියලුම නෝඩ් වලින් දත්ත ලබා ගන්නා අතර, එම නැතිවූ නෝඩය එනතෙක් ඉල්ලීම නතර වේ.
යම් අවස්ථාවක දී අපට අවශ්ය වූයේ VictoriaMetrics VictoriaMetrics ක්‍රියාකරුවෙකු වීමටය. අපි ඔහු එනතුරු බලා සිටියෙමු. අපි දැන් VictoriaMetrics ක්‍රියාකරුට ප්‍රොමිතියස් ප්‍රොමිතියස් වැනි සියලුම පූර්ව ගණනය කිරීමේ නීති ලබා ගැනීම සඳහා රාමුවක් සක්‍රියව ගොඩනඟමින් සිටිමු, මන්ද අපි Prometheus ක්‍රියාකරු සමඟ එන නීති තරමක් ක්‍රියාකාරීව භාවිතා කරන බැවිනි.
පොකුරු ක්‍රියාත්මක කිරීම වැඩිදියුණු කිරීමට යෝජනා තිබේ. මම ඒවා ඉහත දක්වා ඇත.
ඒ වගේම මට ඇත්තටම අඩු සාම්පලයක් අවශ්‍යයි. අපගේ නඩුවේදී, ප්රවණතා බැලීම සඳහා පමණක් පහත හෙලීම අවශ්ය වේ. දළ වශයෙන් කිවහොත්, දිවා කාලයේදී මට මෙට්රික් එකක් ප්‍රමාණවත් වේ. මෙම ප්රවණතා වසරක්, තුනක්, පහක්, අවුරුදු දහයක් සඳහා අවශ්ය වේ. තවද එක් මෙට්රික් අගයක් ප්රමාණවත්ය.
- Prometheus භාවිතා කරන විට අපගේ සමහර සගයන් මෙන් අපි වේදනාව දැන සිටිමු.
- අපි අපි වෙනුවෙන් වික්ටෝරියා මෙට්‍රික්ස් තෝරා ගත්තෙමු.
- එය සිරස් අතට සහ තිරස් අතට හොඳින් පරිමාණය කරයි.
- අපට විවිධ සංරචක පොකුරේ විවිධ නෝඩ් ගණනට බෙදා හැරීම, මතකයෙන් සීමා කිරීම, මතකය එකතු කිරීම යනාදිය කළ හැකිය.
අපි ඇත්තටම එයට කැමති නිසා අපි නිවසේදී VictoriaMetrics භාවිතා කරන්නෙමු. මේක තමයි තිබ්බ සහ වෙලා තියෙන දේ.
VictoriaMetrics චැට්, මගේ සම්බන්ධතා, LeroyMerlin තාක්ෂණික රේඩාර් සඳහා QR කේත කිහිපයක්.
මූලාශ්රය: www.habr.com