Prometheus 2 හි කාල ශ්‍රේණි දත්ත සමුදාය (TSDB) යනු දත්ත සමුච්චය කිරීමේ වේගය, විමසුම් ක්‍රියාත්මක කිරීම සහ සම්පත් කාර්යක්ෂමතාව අනුව Prometheus 2 හි v1 ගබඩාවට වඩා විශාල දියුණුවක් ලබා දෙන ඉංජිනේරු විසඳුමක විශිෂ්ට උදාහරණයකි. අපි Percona Monitoring and Management (PMM) හි Prometheus 2 ක්‍රියාත්මක කරමින් සිටි අතර Prometheus 2 TSDB හි ක්‍රියාකාරිත්වය අවබෝධ කර ගැනීමට මට අවස්ථාව ලැබුණි. මෙම ලිපියෙන් මම මෙම නිරීක්ෂණවල ප්රතිඵල ගැන කතා කරමි.
සාමාන්‍ය Prometheus වැඩ බර
සාමාන්‍ය කාර්ය දත්ත සමුදායන් සමඟ කටයුතු කිරීමට පුරුදු වී සිටින අයට, සාමාන්‍ය Prometheus කාර්ය භාරය තරමක් සිත්ගන්නා සුළුය. දත්ත සමුච්චය වීමේ වේගය ස්ථායී වේ: සාමාන්‍යයෙන් ඔබ නිරීක්ෂණය කරන සේවාවන් ආසන්න වශයෙන් සමාන ප්‍රමිතික සංඛ්‍යාවක් යවන අතර යටිතල පහසුකම් සාපේක්ෂව සෙමින් වෙනස් වේ.
තොරතුරු සඳහා ඉල්ලීම් විවිධ මූලාශ්රවලින් පැමිණිය හැකිය. ඒවායින් සමහරක්, ඇඟවීම් වැනි, ස්ථාවර සහ පුරෝකථනය කළ හැකි අගයක් සඳහා ද උත්සාහ කරයි. බොහෝ වැඩ බර සඳහා මෙය නොවුනත්, පරිශීලක ඉල්ලීම් වැනි අනෙකුත්, පිපිරීම් ඇති විය හැක.
පැටවීමේ පරීක්ෂණය
පරීක්ෂණය අතරතුර, මම දත්ත රැස් කිරීමේ හැකියාව කෙරෙහි අවධානය යොමු කළෙමි. මම Go 2.3.2 සමඟින් සම්පාදනය කරන ලද Prometheus 1.10.1 (PMM 1.14 හි කොටසක් ලෙස) මෙම ස්ක්‍රිප්ට් භාවිතයෙන් Linode සේවාවෙහි යෙදෙව්වෙමි: . වඩාත්ම යථාර්ථවාදී බර උත්පාදනය සඳහා, මෙය භාවිතා කිරීම මම සැබෑ බරක් සහිත MySQL නෝඩ් කිහිපයක් දියත් කළෙමි (Sysbench TPC-C ටෙස්ට්), ඒ සෑම එකක්ම Linux/MySQL නෝඩ් 10 ක් අනුකරණය කරන ලදී.
MySQL අවස්ථා දෙසීයක් නිරීක්ෂණය කරමින් load simulation 32ක් ක්‍රියාත්මක කරමින් අතථ්‍ය හර අටක් සහ 20 GB මතකයක් සහිත Linode සේවාදායකයක් මත පහත පරීක්ෂණ සියල්ල සිදු කරන ලදී. නැතහොත්, Prometheus අනුව, ඉලක්ක 800 ක්, තත්පරයකට සීරීම් 440 ක්, තත්පරයට වාර්තා 380 දහසක් සහ සක්‍රීය කාල ශ්‍රේණි මිලියන 1,7 ක්.
නිර්මාණ
Prometheus 1.x විසින් භාවිතා කරන ලද සම්ප්‍රදායික දත්ත සමුදායේ සාමාන්‍ය ප්‍රවේශය වේ . බර පැටවීමට එය ප්‍රමාණවත් නොවේ නම්, ඔබට ඉහළ ප්‍රමාදයන් අත්විඳිය හැකි අතර සමහර ඉල්ලීම් අසාර්ථක වනු ඇත. Prometheus 2 හි මතක භාවිතය යතුර හරහා වින්‍යාසගත කළ හැක storage.tsdb.min-block-duration, තැටියට ෆ්ලෂ් කිරීමට පෙර පටිගත කිරීම් කොපමණ කාලයක් මතකයේ තබා ගත යුතුද යන්න තීරණය කරයි (පෙරනිමිය පැය 2). අවශ්‍ය මතක ප්‍රමාණය ශුද්ධ එන ප්‍රවාහයට එකතු කරන කාල ශ්‍රේණි, ලේබල් සහ සීරීම් ගණන මත රඳා පවතී. තැටි ඉඩ ප්‍රමාණය අනුව, ප්‍රොමිතියස් එක් වාර්තාවකට බයිට් 3ක් (නියැදිය) භාවිතා කිරීමට අපේක්ෂා කරයි. අනෙක් අතට, මතක අවශ්‍යතා බෙහෙවින් වැඩි ය.
බ්ලොක් ප්‍රමාණය වින්‍යාස කිරීමට හැකි වුවද, එය අතින් වින්‍යාස කිරීම නිර්දේශ නොකරයි, එබැවින් ප්‍රොමිතියස් හට ඔබගේ කාර්ය භාරයට අවශ්‍ය තරම් මතකයක් ලබා දීමට ඔබට බල කෙරෙයි.
එන මෙට්‍රික් ප්‍රවාහයට සහය වීමට ප්‍රමාණවත් මතකයක් නොමැති නම්, ප්‍රොමිතියස් මතකයෙන් ඉවතට ඇද වැටෙනු ඇත, නැතහොත් OOM ඝාතකයා එයට පැමිණේ.
Prometheus මතකය අවසන් වූ විට බිඳවැටීම ප්‍රමාද කිරීමට swap එකතු කිරීම ඇත්ත වශයෙන්ම උපකාරී නොවේ, මන්ද මෙම කාර්යය භාවිතා කිරීම පුපුරන සුලු මතක පරිභෝජනයට හේතු වේ. මම හිතන්නේ එය Go, එහි කුණු එකතු කරන්නා සහ එය swap සමඟ ගනුදෙනු කරන ආකාරය සමඟ සම්බන්ධ දෙයක්.
තවත් රසවත් ප්‍රවේශයක් නම්, ක්රියාවලියේ ආරම්භයේ සිට එය ගණන් කිරීම වෙනුවට, නිශ්චිත වේලාවක තැටියට ෆ්ලෂ් කිරීමට හිස් බ්ලොක් වින්‍යාස කිරීමයි.
ප්‍රස්ථාරයෙන් ඔබට පෙනෙන පරිදි, සෑම පැය දෙකකට වරක් තැටියට ෆ්ලෂ් සිදුවේ. ඔබ min-block-duration පරාමිතිය පැයකට වෙනස් කළහොත්, මෙම යළි පිහිටුවීම් පැය භාගයකට පසුව ආරම්භ වන සෑම පැයකටම සිදුවනු ඇත.
ඔබගේ Prometheus ස්ථාපනයේදී ඔබට මෙය සහ අනෙකුත් ප්‍රස්තාර භාවිතා කිරීමට අවශ්‍ය නම්, ඔබට මෙය භාවිතා කළ හැක . එය PMM සඳහා නිර්මාණය කර ඇති නමුත්, සුළු වෙනස් කිරීම් සහිතව, ඕනෑම Prometheus ස්ථාපනයකට ගැලපේ.
අපට මතකයේ ගබඩා කර ඇති හෙඩ් බ්ලොක් නම් ක්‍රියාකාරී බ්ලොක් එකක් ඇත; පැරණි දත්ත සහිත බ්ලොක් හරහා ලබා ගත හැක mmap(). මෙමගින් හැඹිලිය වෙන වෙනම වින්‍යාස කිරීමේ අවශ්‍යතාවය ඉවත් කරයි, නමුත් හෙඩ් බ්ලොක් එකට නවාතැන් ගත හැකි ප්‍රමාණයට වඩා පැරණි දත්ත විමසීමට ඔබට අවශ්‍ය නම් මෙහෙයුම් පද්ධති හැඹිලිය සඳහා ප්‍රමාණවත් ඉඩක් ඉතිරි කිරීමට අවශ්‍ය බව ද අදහස් වේ.
මෙයින් අදහස් කරන්නේ Prometheus අතථ්‍ය මතක පරිභෝජනය තරමක් ඉහළ පෙනුමක් ඇති බවයි, එය කරදර විය යුතු දෙයක් නොවේ.
තවත් සිත්ගන්නාසුලු නිර්මාණ ලක්ෂ්‍යයක් වන්නේ WAL භාවිතයයි (ඉදිරියට ලියන්න). ගබඩා ලියකියවිලි වලින් ඔබට පෙනෙන පරිදි, Prometheus බිඳවැටීම් වළක්වා ගැනීමට WAL භාවිතා කරයි. දත්ත පැවැත්ම සහතික කිරීම සඳහා නිශ්චිත යාන්ත්‍රණ, අවාසනාවකට මෙන්, හොඳින් ලේඛනගත කර නොමැත. Prometheus අනුවාදය 2.3.2 සෑම තත්පර 10 කට වරක් WAL තැටියට ෆ්ලෂ් කරන අතර මෙම විකල්පය පරිශීලකයාට වින්‍යාස කළ නොහැක.
සංයුක්ත කිරීම්
Prometheus TSDB නිර්මාණය කර ඇත්තේ LSM (Log Structured Merge) ගබඩාවක් ලෙසිනි: හෙඩ් බ්ලොක් එක වරින් වර තැටියට ෆ්ලෂ් කරනු ලබන අතර, විමසුම් අතරතුර බොහෝ වාරණ ස්කෑන් කිරීම වැළැක්වීම සඳහා සංයුක්ත යාන්ත්‍රණයක් බ්ලොක් කිහිපයක් එකට ඒකාබද්ධ කරයි. දිනකට පැටවීමෙන් පසු පරීක්ෂණ පද්ධතියේ මා නිරීක්ෂණය කළ බ්ලොක් ගණන මෙහිදී ඔබට දැක ගත හැකිය.
ඔබට ගබඩාව ගැන වැඩි විස්තර දැන ගැනීමට අවශ්‍ය නම්, ඔබට meta.json ගොනුව පරීක්ෂා කළ හැකිය, එහි ඇති කුට්ටි සහ ඒවා ඇති වූ ආකාරය පිළිබඳ තොරතුරු ඇත.
{
"ulid": "01CPZDPD1D9R019JS87TPV5MPE",
"minTime": 1536472800000,
"maxTime": 1536494400000,
"stats": {
"numSamples": 8292128378,
"numSeries": 1673622,
"numChunks": 69528220
},
"compaction": {
"level": 2,
"sources": [
"01CPYRY9MS465Y5ETM3SXFBV7X",
"01CPYZT0WRJ1JB1P0DP80VY5KJ",
"01CPZ6NR4Q3PDP3E57HEH760XS"
],
"parents": [
{
"ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
"minTime": 1536472800000,
"maxTime": 1536480000000
},
{
"ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
"minTime": 1536480000000,
"maxTime": 1536487200000
},
{
"ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
"minTime": 1536487200000,
"maxTime": 1536494400000
}
]
},
"version": 1
}ප්‍රොමිතියස් හි සංයුක්ත කිරීම් හෙඩ් බ්ලොක් තැටියට ෆ්ලෂ් කරන වේලාවට බැඳී ඇත. මෙම අවස්ථාවේදී, එවැනි මෙහෙයුම් කිහිපයක් සිදු කළ හැකිය.
සංයුක්ත කිරීම් කිසිඳු ආකාරයකින් සීමා නොවන බව පෙනෙන අතර ක්‍රියාත්මක කිරීමේදී විශාල තැටි I/O කරල් ඇති විය හැක.
CPU පැටවුම් කරල්
ඇත්ත වශයෙන්ම, මෙය පද්ධතියේ වේගය කෙරෙහි තරමක් සෘණාත්මක බලපෑමක් ඇති කරයි, සහ LSM ගබඩා කිරීම සඳහා බරපතල අභියෝගයක් ද මතු කරයි: අධික පිරිවැයක් ඇති නොකර ඉහළ ඉල්ලීම් අනුපාතවලට සහාය වීම සඳහා සංයුක්ත කරන්නේ කෙසේද?
සංයුක්ත ක්‍රියාවලියේදී මතකය භාවිතා කිරීම ද ඉතා සිත්ගන්නා සුළුය.
සංයුක්ත කිරීමෙන් පසු, මතකයේ බොහෝමයක් හැඹිලියේ සිට නොමිලේ තත්ත්වයට වෙනස් වන ආකාරය අපට දැක ගත හැකිය: මෙයින් අදහස් කරන්නේ වටිනා තොරතුරු එතැනින් ඉවත් කර ඇති බවයි. එය මෙහි භාවිතා කරන්නේ නම් කුතුහලය fadvice() හෝ වෙනත් අවම කිරීමේ ක්‍රමවේදයක්, එසේත් නැතිනම් හැඹිලිය සංයුක්ත කිරීමේදී විනාශ වූ කුට්ටි වලින් නිදහස් වූ නිසාද?
අසාර්ථක වීමෙන් පසු ප්රකෘතිමත් වීම
අසාර්ථකත්වයන්ගෙන් යථා තත්ත්වයට පත්වීමට කාලය ගත වන අතර හොඳ හේතුවක් ඇත. තත්පරයකට වාර්තා මිලියනයක එන ප්‍රවාහයක් සඳහා, SSD ධාවකය සැලකිල්ලට ගනිමින් ප්‍රතිසාධනය සිදු කරන අතරතුර මට විනාඩි 25 ක් පමණ බලා සිටීමට සිදු විය.
level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."ප්රතිසාධන ක්රියාවලියේ ප්රධාන ගැටළුව වන්නේ අධික මතක පරිභෝජනයයි. සාමාන්‍ය තත්වයකදී සේවාදායකයට එකම මතක ප්‍රමාණයකින් ස්ථායීව ක්‍රියා කළ හැකි වුවද, එය බිඳ වැටුණහොත් එය OOM නිසා එය යථා තත්ත්වයට පත් නොවනු ඇත. මා සොයාගත් එකම විසඳුම වූයේ දත්ත රැස් කිරීම අක්‍රිය කිරීම, සේවාදායකය ඉහළට ගෙන ඒම, එය යථා තත්ත්වයට පත් කිරීමට සහ එකතු කිරීම සක්‍රීය කර නැවත ආරම්භ කිරීමට ඉඩ දීමයි.
උණුසුම් වීම
උණුසුම අතරතුර මතක තබා ගත යුතු තවත් හැසිරීමක් වන්නේ ආරම්භයේ සිටම අඩු කාර්ය සාධනය සහ ඉහළ සම්පත් පරිභෝජනය අතර සම්බන්ධයයි. සමහර විට, නමුත් සියල්ල ආරම්භ නොවන විට, මම CPU සහ මතකය මත බරපතල බරක් නිරීක්ෂණය කළෙමි.
මතක භාවිතයේ ඇති හිඩැස්වලින් පෙන්නුම් කරන්නේ Prometheus හට ආරම්භයේ සිටම සියලුම එකතු කිරීම් වින්‍යාස කිරීමට නොහැකි වන අතර සමහර තොරතුරු නැති වී ඇති බවයි.
ඉහළ CPU සහ මතක බර සඳහා නිශ්චිත හේතු මම සොයාගෙන නොමැත. අධි සංඛ්‍යාතයකින් හෙඩ් බ්ලොක් එකේ නව කාල ශ්‍රේණියක් නිර්මාණය වීම මෙයට හේතුව යැයි මම සැක කරමි.
CPU භාරය ඉහළ යයි
තරමක් ඉහළ I/O භාරයක් නිර්මාණය කරන සංයුක්තවලට අමතරව, සෑම මිනිත්තු දෙකකට වරක්ම CPU පැටවීමෙහි බරපතල කරල් මම දුටුවෙමි. ආදාන ප්‍රවාහය වැඩි වන විට සහ අවම වශයෙන් සමහර මධ්‍යයන් සම්පූර්ණයෙන්ම පටවා ඇති Go's කසළ එකතු කරන්නා විසින් සිදු වූවක් ලෙස පෙනෙන විට පිපිරීම් දිගු වේ.
මේ පැනීම එතරම් සුළුපටු නොවේ. මේවා සිදු වූ විට, ප්‍රොමිතියස්ගේ අභ්‍යන්තර ප්‍රවේශ ලක්ෂ්‍යය සහ ප්‍රමිතික මෙම කාල පරිච්ඡේද තුළම දත්ත හිඩැස් ඇති කිරීමට නොහැකි වන බව පෙනේ.
Prometheus exporter එක තත්පරයකට ක්‍රියා විරහිත වන බව ඔබට දැක ගත හැක.
කසළ එකතු කිරීම (GC) සමඟ සහසම්බන්ධතා අපට දැකිය හැකිය.
නිගමනය
Prometheus 2 හි TSDB වේගවත්, කාල ශ්‍රේණි මිලියන ගණනක් සහ ඒ සමඟම තරමක් සාමාන්‍ය දෘඪාංග භාවිතයෙන් තත්පරයකට වාර්තා දහස් ගණනක් හැසිරවීමේ හැකියාව ඇත. CPU සහ තැටි I/O භාවිතය ද සිත් ඇදගන්නා සුළු ය. මගේ උදාහරණය භාවිතා කරන හරයකට තත්පරයකට මෙට්‍රික් 200 දක්වා පෙන්වයි.
ප්‍රසාරණය සැලසුම් කිරීම සඳහා, ඔබට ප්‍රමාණවත් මතක ප්‍රමාණයක් ගැන මතක තබා ගත යුතු අතර, මෙය සැබෑ මතකය විය යුතුය. මම නිරීක්ෂණය කළ මතක ප්‍රමාණය, එන ප්‍රවාහයේ තත්පරයකට වාර්තා 5 කට 100 GB පමණ වන අතර, මෙහෙයුම් පද්ධති හැඹිලිය සමඟ එක්ව 000 GB පමණ රඳවා ගත් මතකය ලබා දුන්නේය.
ඇත්ත වශයෙන්ම, CPU සහ තැටි I/O කරල් හීලෑ කිරීම සඳහා තවමත් බොහෝ වැඩ කළ යුතු අතර, තරුණ TSDB Prometheus 2 InnoDB, TokuDB, RocksDB, WiredTiger සමඟ සසඳන ආකාරය සලකා බැලීම පුදුමයක් නොවේ, නමුත් ඒවා සියල්ලම සමාන විය. ඔවුන්ගේ ජීවන චක්‍රයේ මුල් අවධියේදී ඇතිවන ගැටළු.
මූලාශ්රය: www.habr.com