Zabbix යනු අධීක්ෂණ පද්ධතියකි. වෙනත් ඕනෑම පද්ධතියක් මෙන්, එය සියලුම අධීක්ෂණ පද්ධතිවල ප්රධාන ගැටළු තුනකට මුහුණ දෙයි: දත්ත එකතු කිරීම සහ සැකසීම, ඉතිහාසය ගබඩා කිරීම සහ එය පිරිසිදු කිරීම.
දත්ත ලබා ගැනීම, සැකසීම සහ පටිගත කිරීමේ අදියර සඳහා කාලය ගතවේ. බොහෝ නොවේ, නමුත් විශාල පද්ධතියක් සඳහා මෙය විශාල ප්රමාදයන් ඇති විය හැක. ගබඩා ගැටලුව දත්ත ප්‍රවේශ ගැටලුවකි. ඒවා වාර්තා, චෙක්පත් සහ ප්‍රේරක සඳහා භාවිතා වේ. දත්ත ප්‍රවේශයේ ප්රමාදයන් ද කාර්ය සාධනයට බලපායි. දත්ත සමුදායන් වර්ධනය වන විට, අදාළ නොවන දත්ත මකා දැමිය යුතුය. ඉවත් කිරීම දුෂ්කර මෙහෙයුමක් වන අතර එය සමහර සම්පත් ද අනුභව කරයි.
Zabbix හි එකතු කිරීම සහ ගබඩා කිරීමේදී ප්‍රමාද වීමේ ගැටළු හැඹිලිගත කිරීම මගින් විසඳනු ලැබේ: හැඹිලි වර්ග කිහිපයක්, දත්ත ගබඩාවේ හැඹිලිගත කිරීම. තෙවන ගැටළුව විසඳීම සඳහා, හැඹිලි කිරීම සුදුසු නොවේ, එබැවින් Zabbix TimescaleDB භාවිතා කළේය. ඔහු ඒ ගැන ඔබට කියයි Andrey Gushchin - තාක්ෂණික සහාය ඉංජිනේරු . Andrey වසර 6 කට වැඩි කාලයක් Zabbix හට සහාය දක්වන අතර කාර්ය සාධනය පිළිබඳ සෘජු අත්දැකීම් ඇත.
TimescaleDB ක්රියා කරන්නේ කෙසේද, සාමාන්‍ය PostgreSQL හා සසඳන විට එය ලබා දිය හැකි කාර්ය සාධනය කුමක්ද? TimescaleDB දත්ත ගබඩාව සඳහා Zabbix ඉටු කරන කාර්යභාරය කුමක්ද? මුල සිට ආරම්භ කරන්නේ කෙසේද සහ PostgreSQL වෙතින් සංක්‍රමණය වන්නේ කෙසේද සහ වඩා හොඳ කාර්ය සාධනයක් ඇත්තේ කුමන වින්‍යාසයද? කප්පාදුව යටතේ මේ සියල්ල ගැන.
ඵලදායිතා අභියෝග
සෑම අධීක්ෂණ පද්ධතියක්ම නිශ්චිත කාර්ය සාධන අභියෝගවලට මුහුණ දෙයි. මම ඒවායින් තුනක් ගැන කතා කරමි: දත්ත එකතු කිරීම සහ සැකසීම, ගබඩා කිරීම සහ ඉතිහාසය ඉවත් කිරීම.
වේගවත් දත්ත එකතු කිරීම සහ සැකසීම. හොඳ අධීක්ෂණ පද්ධතියක් ඉක්මනින් සියලු දත්ත ලබා ගත යුතු අතර ප්‍රේරක ප්‍රකාශන අනුව - එහි නිර්ණායක අනුව එය සැකසිය යුතුය. සැකසීමෙන් පසු, පද්ධතිය ඉක්මනින් මෙම දත්ත පසුකාලීන භාවිතය සඳහා දත්ත ගබඩාවේ සුරැකිය යුතුය.
ඉතිහාස ගබඩාව. හොඳ නිරීක්ෂණ පද්ධතියක් දත්ත ගබඩාවක ඉතිහාසය ගබඩා කළ යුතු අතර ප්‍රමිතික සඳහා පහසු ප්‍රවේශයක් සැපයිය යුතුය. වාර්තා, ප්රස්ථාර, ප්‍රේරක, එළිපත්ත සහ ගණනය කළ අනතුරු ඇඟවීමේ දත්ත අයිතමවල ඉතිහාසය භාවිත කිරීමට අවශ්ය වේ.
ඉතිහාසය හිස් කිරීම. සමහර වෙලාවට මෙට්‍රික් ගබඩා කරන්න අවශ්ය නැති දවසක් එනවා. ඔබට වසර 5 කට පෙර, මාසයක් හෝ දෙකකට පෙර එකතු කරන ලද දත්ත ඔබට අවශ්ය වන්නේ ඇයි: සමහර නෝඩ් මකා ඇත, සමහර ධාරක හෝ ප්‍රමිතික ඒවා යල් පැන ගිය සහ තවදුරටත් එකතු නොකරන නිසා තවදුරටත් අවශ්ය නොවේ. හොඳ නිරීක්ෂණ පද්ධතියක් ඓතිහාසික දත්ත ගබඩා කළ යුතු අතර දත්ත සමුදාය වර්ධනය නොවන පරිදි වරින් වර මකා දැමිය යුතුය.
පරණ දත්ත පිරිසිදු කිරීම දත්ත සමුදායේ ක්‍රියාකාරිත්වයට බෙහෙවින් බලපාන තීරණාත්මක ගැටළුවකි.
Zabbix හි හැඹිලිගත කිරීම
Zabbix හි, පළමු සහ දෙවන ඇමතුම් හැඹිලිය භාවිතයෙන් විසඳනු ලැබේ. දත්ත රැස් කිරීමට සහ සැකසීමට RAM භාවිතා කරයි. ගබඩා කිරීම සඳහා - ප්‍රේරක, ප්රස්ථාර සහ ගණනය කළ දත්ත මූලද්‍රව්‍යවල ඉතිහාසය. දත්ත සමුදාය පැත්තේ මූලික තේරීම් සඳහා යම් හැඹිලි ඇත, උදාහරණයක් ලෙස, ප්රස්තාර.
Zabbix සේවාදායකයේ පැත්තේ හැඹිලිගත කිරීම යනු:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
අපි ඒවා වඩාත් විස්තරාත්මකව සලකා බලමු.
ConfigurationCache
අපි ප්‍රමිතික, ධාරක, දත්ත අයිතම, ප්‍රේරක - පෙර සැකසුම් සඳහා සහ දත්ත රැස් කිරීම සඳහා අපට අවශ්ය සියල්ල ගබඩා කරන ප්රධාන හැඹිලිය මෙයයි.
දත්ත ගබඩාවේ අනවශ්‍ය විමසුම් ඇති නොවන පරිදි මේ සියල්ල ConfigurationCache හි ගබඩා කර ඇත. සේවාදායකය ආරම්භ වූ පසු, අපි මෙම හැඹිලිය යාවත්කාලීන කරන්නෙමු, වින්‍යාසයන් සාදන්න සහ වරින් වර යාවත්කාලීන කරන්නෙමු.
දත්ත එකතුව
රූප සටහන තරමක් විශාලයි, නමුත් එහි ඇති ප්රධානතම දේ අහුලන්නන්. මේවා විවිධ “ඡන්ද පොළවල්” - එකලස් කිරීමේ ක්රියාවලි. ඔවුන් විවිධ ආකාරයේ එකලස් කිරීම් සඳහා වගකිව යුතුය: ඔවුන් SNMP, IPMI හරහා දත්ත රැස් කර, පෙර සැකසුම් වෙත මාරු කරයි.
එකතුකරන්නන් තැඹිලි පාටින් දක්වා ඇත.
Zabbix විසින් චෙක්පත් එකතු කිරීමට අවශ්ය එකතු කිරීමේ අයිතම ගණනය කර ඇත. අප සතුව ඒවා තිබේ නම්, අපි ඒවා සඳහා දත්ත කෙලින්ම ValueCache වෙතින් ලබා ගනිමු.
පූර්ව සැකසුම් ඉතිහාස හැඹිලිය
සියලුම එකතුකරන්නන් රැකියා ලබා ගැනීමට ConfigurationCache භාවිතා කරයි. ඉන්පසු ඒවා පෙර සැකසුම් වෙත මාරු කරයි.
PreProcessing PreProcessing පියවර ලබා ගැනීම සඳහා ConfigurationCache භාවිතා කරයි. එය මෙම දත්ත විවිධ ආකාරවලින් සකසයි.
PreProcessing භාවිතයෙන් දත්ත සැකසීමෙන් පසු, අපි එය සැකසීම සඳහා HistoryCache හි සුරකිමු. මෙය දත්ත එකතු කිරීම අවසන් කරන අතර අපි Zabbix හි ප්රධාන ක්‍රියාවලිය වෙත යන්නෙමු - ඉතිහාස සමමුහුර්තකය, එය මොනොලිතික් ගෘහ නිර්මාණ ශිල්පයක් බැවින්.
සටහන: පෙර සැකසුම් කිරීම තරමක් අපහසු මෙහෙයුමකි. v 4.2 සමඟ එය ප්‍රොක්සි වෙත ගෙන ගොස් ඇත. ඔබට දත්ත මූලද්රව්ය විශාල සංඛ්‍යාවක් සහ එකතු කිරීමේ සංඛ්‍යාතයක් සහිත ඉතා විශාල Zabbix තිබේ නම්, මෙය කාර්යය වඩාත් පහසු කරයි.
ValueCache, ඉතිහාසය සහ ප්රවණතා හැඹිලිය
ඉතිහාස සමමුහුර්තකරණය යනු එක් එක් දත්ත මූලද්රව්ය, එනම් එක් එක් අගය පරමාණුකව සකසන ප්රධාන ක්‍රියාවලියයි.
ඉතිහාස සමමුහුර්තකය HistoryCache වෙතින් අගයන් ලබා ගන්නා අතර ගණනය කිරීම් සඳහා ප්‍රේරක තිබේද යන්න වින්යාසය පරීක්ෂා කරයි. ඒවා තිබේ නම්, එය ගණනය කරයි.
ඉතිහාස සමමුහුර්තකරණය සිදුවීමක් නිර්මාණය කරයි, වින්යාසය මගින් අවශ්ය නම් ඇඟවීම් සෑදීමට උත්සන්න කිරීම සහ වාර්තා කරයි. පසුකාලීන සැකසුම් සඳහා ප්‍රේරක තිබේ නම්, එය ඉතිහාස වගුවට ප්‍රවේශ නොවන පරිදි ValueCache හි මෙම අගය ගබඩා කරයි. ප්‍රේරක සහ ගණනය කරන ලද මූලද්රව්ය ගණනය කිරීමට අවශ්ය දත්ත වලින් ValueCache පුරවන්නේ මේ ආකාරයටයි.
ඉතිහාස සමමුහුර්ත කරන්නා සියලුම දත්ත දත්ත සමුදායට ලියන අතර එය තැටියට ලියයි. සැකසුම් ක්‍රියාවලිය මෙතැනින් අවසන් වේ.
දත්ත සමුදාය තුළ හැඹිලිගත කිරීම
දත්ත සමුදාය පැත්තේ ඔබට සිදුවීම් පිළිබඳ ප්රස්ථාර හෝ වාර්තා බැලීමට අවශ්ය විට විවිධ හැඹිලි ඇත:
Innodb_buffer_poolMySQL පැත්තේ;shared_buffersPostgreSQL පැත්තේ;effective_cache_sizeඔරකල් පැත්තේ;shared_poolDB2 පැත්තේ.
තවත් බොහෝ හැඹිලි ඇත, නමුත් මේවා සියලු දත්ත සමුදායන් සඳහා ප්රධාන ඒවා වේ. විමසුම් සඳහා බොහෝ විට අවශ්ය දත්ත RAM හි ගබඩා කිරීමට ඒවා ඔබට ඉඩ සලසයි. මේ සඳහා ඔවුන්ට ඔවුන්ගේම තාක්ෂණයන් ඇත.
දත්ත සමුදායේ කාර්ය සාධනය ඉතා වැදගත් වේ
Zabbix සේවාදායකය නිරන්තරයෙන් දත්ත එකතු කර එය ලියයි. නැවත ආරම්භ කරන විට, එය ValueCache පිරවීම සඳහා ඉතිහාසයෙන් ද කියවයි. ස්ක්‍රිප්ට් සහ වාර්තා භාවිතා කරයි Zabbix API, එය වෙබ් අතුරු මුහුණතක් මත ගොඩනගා ඇත. Zabbix API දත්ත සමුදායට ප්‍රවේශ වන අතර ප්රස්ථාර, වාර්තා, සිදුවීම් ලැයිස්තු සහ නවතම ගැටළු සඳහා අවශ්ය දත්ත ලබා ගනී.
දෘශ්‍යකරණය සඳහා - ග්‍රැෆනා. මෙය අපගේ පරිශීලකයින් අතර ජනප්‍රිය විසඳුමකි. එය සෘජුවම Zabbix API හරහා සහ දත්ත සමුදාය වෙත ඉල්ලීම් යැවිය හැකි අතර දත්ත ලබාගැනීම සඳහා යම් තරඟයක් නිර්මාණය කරයි. එබැවින්, ප්‍රතිඵල සහ පරීක්‍ෂණ වේගවත් බෙදා හැරීමට ගැළපීමට දත්ත සමුදායේ සියුම් හා වඩා හොඳ සුසර කිරීම අවශ්ය වේ.
ගෘහ පාලිකාව
Zabbix හි තුන්වන කාර්ය සාධන අභියෝගය වන්නේ හවුස් කීපර් භාවිතයෙන් ඉතිහාසය ඉවත් කිරීමයි. එය සියලු සැකසුම් අනුගමනය කරයි - දත්ත මූලද්රව්ය මඟින් දින තුළ වෙනස්කම් (ප්රවණතා) ගතිකත්වය කොපමණ කාලයක් ගබඩා කළ යුතුද යන්න දක්වයි.
අපි පියාසර කරන විට TrendsCache ගණනය කරමු. දත්ත පැමිණි විට, අපි එය එක් පැයක් සඳහා එකතු කර ප්රවණතා වෙනස්වීම් වල ගතිකත්වය සඳහා වගු වල සටහන් කරමු.
ගෘහ සේවිකාව සුපුරුදු "තෝරාගැනීම්" භාවිතයෙන් දත්ත සමුදායෙන් තොරතුරු ආරම්භ කර මකා දමයි. අභ්යන්තර ක්රියාවලීන්ගේ කාර්ය සාධන ප්රස්ථාර වලින් දැකිය හැකි පරිදි මෙය සැමවිටම ඵලදායී නොවේ.
රතු ප්‍රස්ථාරයෙන් පෙන්නුම් කරන්නේ ඉතිහාස සමමුහුර්තකය නිරන්තරයෙන් කාර්යබහුල බවයි. ඉහළින් ඇති තැඹිලි ප්‍රස්ථාරය ගෘහ පාලකයා වන අතර එය නිරන්තරයෙන් ක්‍රියාත්මක වේ. ඔහු සඳහන් කළ සියලුම පේළි මකා දැමීමට දත්ත සමුදාය බලා සිටියි.
ඔබ ගෘහ පාලකයා අක්රිය කළ යුත්තේ කවදාද? උදාහරණයක් ලෙස, "අයිතම හැඳුනුම්පතක්" ඇති අතර ඔබට නිශ්චිත කාලයක් තුළ අවසාන පේළි 5 දහසක් මකා දැමිය යුතුය. ඇත්ත වශයෙන්ම, මෙය සිදුවන්නේ දර්ශකය අනුව ය. නමුත් සාමාන්යයෙන් දත්ත කට්ටලය ඉතා විශාල වන අතර දත්ත සමුදාය තවමත් තැටියෙන් කියවා එය හැඹිලියට තබයි. මෙය සැමවිටම දත්ත සමුදාය සඳහා ඉතා මිල අධික මෙහෙයුමක් වන අතර, දත්ත සමුදායේ විශාලත්වය අනුව, කාර්ය සාධන ගැටළු ඇති විය හැක.
ගෘහ සේවිකාව අක්රිය කිරීමට පහසුය. වෙබ් අතුරු මුහුණතේ ගෘහ පාලකයා සඳහා "පරිපාලන පොදු" හි සැකසුමක් ඇත. අපි අභ්යන්තර ප්රවණතා ඉතිහාසය සඳහා අභ්යන්තර ගෘහ පාලනය අක්රිය කරන අතර එය තවදුරටත් එය කළමනාකරණය නොකරයි.
ගෘහ සේවිකාව ක්රියා විරහිත කර, ප්රස්ථාර සමතලා කර ඇත - මෙම නඩුවේ තිබිය හැකි ගැටළු සහ තෙවන කාර්ය සාධන අභියෝගය විසඳීමට උපකාර කළ හැක්කේ කුමක්ද?
කොටස් කිරීම - කොටස් කිරීම හෝ කොටස් කිරීම
සාමාන්යයෙන්, මා ලැයිස්තුගත කර ඇති එක් එක් සම්බන්ධතා දත්ත සමුදාය මත කොටස් කිරීම වෙනස් ආකාරයකින් වින්යාස කර ඇත. සෑම කෙනෙකුටම තමන්ගේම තාක්ෂණයක් ඇත, නමුත් ඒවා සාමාන්යයෙන් සමාන වේ. නව කොටසක් සෑදීම බොහෝ විට යම් යම් ගැටළු වලට මග පාදයි.
සාමාන්යයෙන්, කොටස් වින්යාස කර ඇත්තේ “සැකසුම” මත පදනම්ව - එක් දිනක් තුළ සාදන ලද දත්ත ප්‍රමාණය. රීතියක් ලෙස, කොටස් කිරීම එක් දිනකින් නිකුත් කරනු ලැබේ, මෙය අවම වේ. නව කණ්ඩායමක ප්රවණතා සඳහා - මාස 1 යි.
"සැකසුම" ඉතා විශාල නම් අගයන් වෙනස් විය හැක. කුඩා “සැකසීමක්” 5 nvps (තත්පරයට නව අගයන්) දක්වා නම්, මධ්යම එකක් 000 සිට 5 දක්වා වේ, එවිට විශාල එකක් 000 nvps ට වැඩි වේ. මේවා විශාල සහ ඉතා විශාල ස්ථාපනයන් වන අතර ඒවා දත්ත සමුදායේ ප්රවේශමෙන් වින්යාස කිරීම අවශ්ය වේ.
ඉතා විශාල ස්ථාපනයන්හිදී, එක් දිනක කාලසීමාව ප්රශස්ත නොවේ. මම දිනකට 40 GB හෝ ඊට වැඩි MySQL කොටස් දැක ඇත. මෙය ගැටළු ඇති කළ හැකි සහ අඩු කළ යුතු ඉතා විශාල දත්ත ප්‍රමාණයකි.
කොටස් කිරීම ලබා දෙන්නේ කුමක්ද?
කොටස් කිරීමේ වගු. බොහෝ විට මේවා තැටියේ වෙනම ගොනු වේ. විමසුම් සැලැස්ම එක් කොටසක් වඩාත් ප්රශස්ත ලෙස තෝරා ගනී. සාමාන්යයෙන් කොටස් කිරීම පරාසය අනුව භාවිතා වේ - මෙය Zabbix සඳහාද සත්‍ය වේ. අපි එහි “වේලා මුද්‍රාව” භාවිතා කරමු - යුගයේ ආරම්භයේ සිට කාලය. මේවා අපට සාමාන්‍ය අංක. ඔබ දවසේ ආරම්භය සහ අවසානය සකසා ඇත - මෙය කොටසකි.
ඉක්මන් ඉවත් කිරීම - DELETE. මකාදැමීම සඳහා පේළි තෝරා ගැනීමකට වඩා එක් ගොනුවක්/උප වගුවක් තෝරා ඇත.
දත්ත ලබා ගැනීම සැලකිය යුතු ලෙස වේගවත් කරයි SELECT - සම්පූර්ණ වගුවට වඩා කොටස් එකක් හෝ කිහිපයක් භාවිතා කරයි. ඔබ දින දෙකක් පැරණි දත්ත වෙත ප්‍රවේශ වන්නේ නම්, එය දත්ත සමුදායෙන් වේගයෙන් ලබා ගනී, මන්ද ඔබට අවශ්ය වන්නේ එක් ගොනුවක් හැඹිලියට පටවා එය ආපසු ලබා දීම මිස විශාල වගුවක් නොවේ.
බොහෝ විට බොහෝ දත්ත සමුදායන් ද වේගවත් වේ INSERT - ළමා මේසයට ඇතුළත් කිරීම්.
කාල සටහන ඩී.බී
v 4.2 සඳහා, අපි අපගේ අවධානය TimescaleDB වෙත යොමු කළෙමු. මෙය ස්වදේශීය අතුරු මුහුණතක් සහිත PostgreSQL සඳහා දිගුවකි. දිගුව කාල ශ්‍රේණි දත්ත සමඟ ඵලදායී ලෙස ක්රියා කරයි, සම්බන්ධතා දත්ත සමුදායේ ප්‍රතිලාභ අහිමි නොවී. TimescaleDB ද ස්වයංක්‍රීයව කොටස් කරයි.
TimescaleDB හි සංකල්පයක් ඇත අධි වගු (හයිපර්ටබල්) ඔබ නිර්මාණය කරන. එහි අඩංගු වේ කුට්ටි - කොටස්. කුට්ටි ස්වයංක්‍රීයව කළමනාකරණය කළ හැකි අධි මේස කොටස් වන අතර එය අනෙකුත් කොටස්වලට බලපාන්නේ නැත. සෑම කොටසකටම තමන්ගේම කාල පරාසයක් ඇත.
TimescaleDB එදිරිව PostgreSQL
TimescaleDB ඇත්තෙන්ම කාර්යක්ෂමව ක්රියා කරයි. දිගු නිෂ්පාදකයින් කියා සිටින්නේ ඔවුන් වඩාත් නිවැරදි ඉල්ලීම් සැකසුම් ඇල්ගොරිතමයක් භාවිතා කරන බවයි, විශේෂයෙන්, ඇතුළු කිරීම්. දත්ත කට්ටල ඇතුළු කිරීමේ ප්‍රමාණය වර්ධනය වන විට, ඇල්ගොරිතම නිරන්තර ක්‍රියාකාරිත්වය පවත්වා ගනී.
පේළි මිලියන 200 කට පසු, PostgreSQL සාමාන්යයෙන් සැලකිය යුතු ලෙස පහත වැටීමට පටන් ගන්නා අතර කාර්ය සාධනය 0 දක්වා අඩු කරයි. TimescaleDB ඔබට ඕනෑම දත්ත ප්‍රමාණයක් සඳහා කාර්යක්ෂමව “ඇතුළු කිරීම්” ඇතුළත් කිරීමට ඉඩ සලසයි.
ස්ථාපනය
TimescaleDB ස්ථාපනය කිරීම ඕනෑම පැකේජයක් සඳහා තරමක් පහසු වේ. තුල සෑම දෙයක්ම විස්තරාත්මකව විස්තර කර ඇත - එය නිල PostgreSQL පැකේජ මත රඳා පවතී. TimescaleDB අතින් ගොඩනගා සම්පාදනය කළ හැක.
Zabbix දත්ත සමුදාය සඳහා අපි සරලව දිගුව සක්රිය කරමු:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
ඔබ සක්රිය කරන්න extension සහ Zabbix දත්ත සමුදාය සඳහා එය සාදන්න. අවසාන පියවර වන්නේ අධි වගුවක් නිර්මාණය කිරීමයි.
TimescaleDB වෙත ඉතිහාස වගු සංක්‍රමණය කිරීම
මේ සඳහා විශේෂ කාර්යයක් ඇත create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
ශ්‍රිතයට පරාමිති තුනක් ඇත. පලමු - දත්ත ගබඩාවේ වගුව, ඒ සඳහා ඔබ අධි වගුවක් සෑදිය යුතුය. දෙවැනි - ක්ෂේත්‍රය, ඔබ නිර්මාණය කිරීමට අවශ්ය අනුව chunk_time_interval - භාවිතා කළ යුතු කොටස් කැබලි වල පරතරය. මගේ නඩුවේ, පරතරය එක් දිනක් - 86.
තුන්වන පරාමිතිය - migrate_data. සෙට් උනොත් true, එවිට සියලුම වත්මන් දත්ත පෙර-සාදන ලද කුට්ටි වෙත මාරු කරනු ලැබේ. මම එය මා විසින්ම භාවිතා කළෙමි migrate_data. මට පැයකට වැඩි කාලයක් ගත වූ 1 TB පමණ විය. සමහර අවස්ථාවලදී පවා, පරීක්ෂා කිරීමේදී, ඒවා මාරු නොකිරීමට, ගබඩා කිරීම සඳහා අවශ්ය නොවන අක්ෂර වර්ගවල ඓතිහාසික දත්ත මම මකා දැමුවා.
අවසාන පියවර - UPDATE: හිදී db_extension දැම්මා timescaledbඑවිට මෙම දිගුව පවතින බව දත්ත සමුදාය තේරුම් ගනී. Zabbix එය සක්රිය කර දත්ත සමුදායට වාක්‍ය ඛණ්ඩය සහ විමසුම් නිවැරදිව භාවිතා කරයි - TimescaleDB සඳහා අවශ්ය එම විශේෂාංග.
දෘඪාංග වින්යාසය
මම සර්වර් දෙකක් පාවිච්චි කළා. පලමු - VMware යන්ත්‍රය. එය තරමක් කුඩා ය: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz ප්‍රොසෙසර, 16 GB RAM සහ 200 GB SSD.
මම Debian 10.8-10.8.pgdg1+90 OS සහ xfs ගොනු පද්ධතිය සමඟ PostgreSQL 1 ස්ථාපනය කළෙමි. මෙම විශේෂිත දත්ත සමුදාය භාවිතා කිරීමට මම සෑම දෙයක්ම අවම වශයෙන් වින්යාස කළෙමි, Zabbix විසින්ම භාවිතා කරන දේ අඩු කළෙමි.
එම යන්ත්‍රයේම Zabbix සේවාදායකයක්, PostgreSQL සහ පැටවුම් නියෝජිතයන්. මා සතුව ක්‍රියාකාරී නියෝජිතයන් 50ක් භාවිතා කරන ලදී LoadableModuleඉතා ඉක්මනින් විවිධ ප්‍රතිඵල උත්පාදනය කිරීමට: අංක, තන්තු. මම database එක ගොඩක් data වලින් පිරෙව්වා.
මුලදී වින්යාසය අඩංගු විය මූලද්රව්ය 5 ක් එක් සත්කාරක දත්ත. සෑම මූලද්‍රව්‍යයක්ම පාහේ සැබෑ ස්ථාපනයන්ට සමාන කිරීමට ප්‍රේරකයක් අඩංගු විය. සමහර අවස්ථා වල ප්‍රේරක එකකට වඩා තිබුනා. එක් ජාල නෝඩයක් සඳහා විය 3-000 ප්‍රේරක.
දත්ත අයිතම යාවත්කාලීන පරතරය - තත්පර 4-7. මම නියෝජිතයන් 50 ක් පමණක් නොව තවත් එකතු කිරීමෙන් බර නියාමනය කළෙමි. එසේම, දත්ත මූලද්රව්ය භාවිතා කරමින්, මම බර පැටවීම ගතිකව සකස් කර යාවත්කාලීන කාල පරතරය තත්පර 4 දක්වා අඩු කළෙමි.
PostgreSQL. 35 nvps
මෙම දෘඪාංගයේ මගේ පළමු ධාවනය වූයේ පිරිසිදු PostgreSQL - තත්පරයට 35 අගයන්. ඔබට පෙනෙන පරිදි, දත්ත ඇතුළත් කිරීම තත්පරයක කොටස් ගනී - සියල්ල හොඳ සහ වේගවත්. එකම දේ තමයි 200 GB SSD තැටියක් ඉක්මනින් පිරෙන එක.
මෙය සම්මත Zabbix සේවාදායක කාර්ය සාධන උපකරණ පුවරුවකි.
පළමු නිල් ප්‍රස්ථාරය යනු තත්පරයකට ඇති අගයන් ගණනයි. දකුණු පස ඇති දෙවන ප්‍රස්ථාරය වන්නේ ගොඩනැගීමේ ක්රියාවලි පැටවීමයි. තෙවැන්න අභ්යන්තර ගොඩනැගීමේ ක්‍රියාවලීන් පූරණය කරයි: ඉතිහාස සමමුහුර්ත කරන්නන් සහ ගෘහ පාලක, එය සෑහෙන කාලයක් මෙහි ක්‍රියාත්මක වේ.
සිව්වන ප්‍රස්ථාරයෙන් HistoryCache භාවිතය පෙන්වයි. මෙය දත්ත සමුදායට ඇතුල් කිරීමට පෙර බෆරයක් වර්ගයකි. හරිත පස්වන ප්‍රස්ථාරය ValueCache භාවිතය පෙන්වයි, එනම්, ප්‍රේරක සඳහා ValueCache පහර කීයක් - මෙය තත්පරයකට අගයන් දහස් ගණනකි.
PostgreSQL. 50 nvps
ඉන්පසු මම එම දෘඩාංගයේ බර තත්පරයට අගයන් 50 දක්වා වැඩි කළෙමි.
ගෘහ සේවිකාවගෙන් පැටවීමේදී, අගයන් 10 ක් ඇතුළු කිරීමට තත්පර 2-3 ක් ගත විය.
ගෘහ සේවිකාව දැනටමත් වැඩවලට මැදිහත් වීමට පටන් ගෙන ඇත.
තෙවන ප්‍රස්ථාරයෙන් පෙන්නුම් කරන්නේ, සාමාන්යයෙන්, උගුල් කරන්නන් සහ ඉතිහාස සමමුහුර්ත කරන්නන් මත පැටවීම තවමත් 60% මට්ටමේ පවතින බවයි. සිව්වන ප්‍රස්ථාරයේ, Housekeeper මෙහෙයුමේදී HistoryCache දැනටමත් ඉතා ක්‍රියාකාරීව පිරවීමට පටන් ගෙන ඇත. එය 20% පිරී ඇත, එනම් 0,5 GB පමණ වේ.
PostgreSQL. 80 nvps
ඉන්පසු මම බර තත්පරයට අගයන් 80 දක්වා වැඩි කළෙමි. මෙය ආසන්න වශයෙන් දත්ත මූලද්රව්ය 400 ක් සහ ප්‍රේරක 280 ක් පමණ වේ.
ඉතිහාස සමමුහුර්ත කිරීම් තිහක පැටවීමේ පිරිවැය දැනටමත් තරමක් ඉහළ ය.
මම විවිධ පරාමිතීන් ද වැඩි කළෙමි: ඉතිහාස සමමුහුර්ත කිරීම්, හැඹිලි.
මගේ දෘඪාංග මත, ඉතිහාස සමමුහුර්තක පැටවීම උපරිම ලෙස වැඩි විය. HistoryCache ඉක්මනින් දත්ත වලින් පුරවා ඇත - සැකසුම් සඳහා දත්ත බෆරය තුළ රැස් කර ඇත.
මේ කාලය පුරාම මම ප්‍රොසෙසරය, RAM සහ අනෙකුත් පද්ධති පරාමිති භාවිතා කරන ආකාරය නිරීක්ෂණය කළ අතර තැටි භාවිතය උපරිම වන බව සොයා ගත්තා.
මම භාවිතය සාක්ෂාත් කර ගෙන ඇත උපරිම තැටි හැකියාවන් මෙම දෘඩාංග මත සහ මෙම අථත්‍ය යන්ත්‍රය මත. එවැනි තීව්‍රතාවයකින්, PostgreSQL තරමක් ක්‍රියාකාරීව දත්ත ෆ්ලෂ් කිරීමට පටන් ගත් අතර තැටියට ලිවීමට සහ කියවීමට තව දුරටත් කාලය නොතිබුණි.
දෙවන සේවාදායකය
මම වෙනත් සේවාදායකයක් ගත්තා, එහි දැනටමත් ප්‍රොසෙසර 48 ක් සහ 128 GB RAM තිබුණි. මම එය සුසර කළා - එය 60 ඉතිහාස සමමුහුර්තකරණයට සකසා, පිළිගත හැකි කාර්ය සාධනයක් ලබා ගත්තා.
ඇත්ත වශයෙන්ම, මෙය දැනටමත් යමක් කළ යුතු ඵලදායිතාවයේ සීමාවයි.
කාල පරාසයDB. 80 nvps
මගේ ප්රධාන කාර්යය වන්නේ Zabbix භාරයට එරෙහිව TimescaleDB හි හැකියාවන් පරීක්ෂා කිරීමයි. තත්පරයකට අගයන් 80 ක් යනු බොහෝය, ප්‍රමිතික එකතු කිරීමේ වාර ගණන (Yandex හැර, ඇත්ත වශයෙන්ම) සහ තරමක් විශාල “සැකසුම”.
සෑම ප්‍රස්ථාරයකම අඩුවීමක් ඇත - මෙය හරියටම දත්ත සංක්‍රමණය වේ. Zabbix සේවාදායකයේ අසාර්ථක වීමෙන් පසුව, ඉතිහාස සමමුහුර්තකරණයේ පැටවීමේ පැතිකඩ බොහෝ වෙනස් විය - එය තුන් වතාවක් පහත වැටුණි.
TimescaleDB මඟින් ඔබට 3 ගුණයක වේගයෙන් දත්ත ඇතුළත් කිරීමට සහ අඩු HistoryCache භාවිතා කිරීමට ඉඩ සලසයි.
ඒ අනුව, ඔබට නියමිත වේලාවට දත්ත ලැබෙනු ඇත.
කාල පරාසයDB. 120 nvps
එවිට මම දත්ත මූලද්රව්ය ගණන 500 දක්වා වැඩි කළෙමි. ප්රධාන කාර්යය වූයේ TimescaleDB හි හැකියාවන් පරීක්ෂා කිරීමයි - මට තත්පරයකට අගයන් 125 දහසක් ගණනය කළ අගයක් ලැබුණි.
මෙය දිගු කාලයක් වැඩ කළ හැකි වැඩ කරන "සැකසුම" වේ. නමුත් මගේ තැටිය TB 1,5 ක් පමණක් වූ නිසා මම එය දින දෙකකින් පිරෙව්වා.
වැදගත්ම දෙය නම් ඒ සමඟම නව TimescaleDB කොටස් නිර්මාණය වීමයි.
කාර්ය සාධනය සඳහා මෙය සම්පූර්ණයෙන්ම නොපෙනේ. MySQL හි කොටස් සාදන විට, උදාහරණයක් ලෙස, සියල්ල වෙනස් වේ. මෙය සාමාන්යයෙන් රාත්‍රියේදී සිදු වන්නේ එය සාමාන්‍ය ඇතුළත් කිරීම් අවහිර කිරීම, වගු සමඟ වැඩ කිරීම සහ සේවා පිරිහීමක් ඇති කළ හැකි බැවිනි. TimescaleDB හි මෙය එසේ නොවේ.
උදාහරණයක් ලෙස, මම සමාජයේ බොහෝ දෙනෙකුගෙන් එක් ප්‍රස්ථාරයක් පෙන්වන්නම්. පින්තූරයේ, TimescaleDB සක්‍රීය කර ඇති අතර, ප්‍රොසෙසරයේ io.weight භාවිතා කිරීමේ බර පහත වැටී ඇත. අභ්යන්තර ක්රියාවලි මූලද්රව්ය භාවිතය ද අඩු විය. එපමණක් නොව, මෙය සාමාන්‍ය පෑන්කේක් තැටිවල සාමාන්‍ය අථත්‍ය යන්ත්‍රයක් මිස SSD එකක් නොවේ.
සොයා ගැනීම්
TimescaleDB යනු කුඩා "සැකසුම" සඳහා හොඳ විසඳුමකි, තැටියේ ක්‍රියාකාරිත්වයට බලපාන. දත්ත සමුදාය හැකි ඉක්මනින් දෘඪාංග වෙත සංක්‍රමණය වන තෙක් හොඳින් වැඩ කිරීමට එය ඔබට ඉඩ සලසයි.
TimescaleDB වින්යාස කිරීම පහසුය, කාර්ය සාධන වාසි ලබා දෙයි, Zabbix සමඟ හොඳින් ක්රියා කරයි සහ PostgreSQL වලට වඩා වාසි ඇත.
ඔබ PostgreSQL භාවිතා කරන්නේ නම් සහ එය වෙනස් කිරීමට අදහස් නොකරන්නේ නම්, මම නිර්දේශ කරමි Zabbix සමඟින් TimescaleDB දිගුව සමඟ PostgreSQL භාවිතා කරන්න. මෙම විසඳුම මධ්යම "සැකසුම" දක්වා ඵලදායී ලෙස ක්රියා කරයි.
අපි "ඉහළ කාර්ය සාධනය" කියන විට අපි අදහස් කරමු . මිලියන සංඛ්‍යාත පරිශීලකයින්ට සේවා සැපයීමට සේවා සබල කරන තාක්ෂණයන් සහ භාවිතයන් ගැන දැන ගැනීමට ඔබට වැඩි වේලාවක් බලා සිටීමට සිදු නොවනු ඇත. ලැයිස්තුව නොවැම්බර් 7 සහ 8 සඳහා අපි දැනටමත් සම්පාදනය කර ඇත, නමුත් මෙහි තවත් යෝජනා කළ හැක.
අපගේ Subscribe කරන්න и , අපි ඉදිරියේදී පැවැත්වෙන සම්මන්ත්‍රණයේ විශේෂාංග හෙළි කරන අතර එයින් උපරිම ප්‍රයෝජන ගන්නේ කෙසේදැයි සොයා බලමු.
මූලාශ්රය: www.habr.com