په Prometheus 2 کې د وخت لړۍ ډیټابیس (TSDB) د انجینرۍ حل یوه غوره بیلګه ده چې د ډیټا راټولولو سرعت ، د پوښتنو اجرا کولو ، او سرچینو موثریت له مخې په Prometheus 2 کې د v1 ذخیره کې لوی پرمختګونه وړاندې کوي. موږ د پرکونا څارنې او مدیریت (PMM) کې Prometheus 2 پلي کول او ما فرصت درلود چې د Prometheus 2 TSDB فعالیت پوه شم. په دې مقاله کې به زه د دې کتنو د پایلو په اړه خبرې وکړم.
د پرومیتیوس د کار اوسط
د هغو کسانو لپاره چې د عمومي هدف ډیټابیسونو سره معامله کولو لپاره کارول کیږي ، د پرومیټیوس عادي کاري بار خورا په زړه پوری دی. د معلوماتو د راټولولو کچه ثابته ده: معمولا هغه خدمتونه چې تاسو یې څارنه کوئ نږدې ورته میټریکونه لیږي، او زیربنا نسبتا ورو ورو بدلیږي.
د معلوماتو لپاره غوښتنې کیدای شي د مختلفو سرچینو څخه راشي. ځینې یې، لکه خبرتیاوې، د ثابت او اټکل وړ ارزښت لپاره هم هڅه کوي. نور، لکه د کاروونکي غوښتنې، ممکن د سوځیدو لامل شي، که څه هم دا د ډیری کاري بارونو لپاره قضیه نده.
بار ازموینه
د ازموینې په جریان کې ، ما د معلوماتو راټولولو وړتیا باندې تمرکز وکړ. ما د دې سکریپټ په کارولو سره په لینوډ خدمت کې د Go 2.3.2 (PMM 1.10.1 برخې په توګه) سره ترتیب شوی Prometheus 1.14 ځای په ځای کړ: . د خورا ریښتیني بار تولید لپاره ، دا کارول ما د ریښتیني بار سره ډیری MySQL نوډونه پیل کړل (Sysbench TPC-C ټیسټ) ، چې هر یو یې د 10 لینکس/MySQL نوډونو تقلید کړی.
لاندې ټولې ازموینې په لینوډ سرور کې د اتو مجازی کورونو او 32 GB حافظې سره ترسره شوې ، چې د 20 سوو مای ایس کیو ایل مثالونو نظارت کولو 800 بار سمولونه پرمخ وړي. یا، د Prometheus شرایطو کې، 440 هدفونه، په هره ثانیه کې 380 سکریپونه، په هره ثانیه کې 1,7 زره ریکارډونه، او XNUMX ملیون فعال وخت لړۍ.
ډيزاين
د دودیزو ډیټابیسونو معمول طریقه، په شمول د پرومیتیوس 1.x لخوا کارول کیږي . که دا د بار اداره کولو لپاره کافي نه وي ، نو تاسو به د لوړې ځنډ تجربه وکړئ او ځینې غوښتنې به ناکام شي. په Prometheus 2 کې د حافظې کارول د کیلي له لارې د تنظیم وړ دي storage.tsdb.min-block-duration، کوم چې دا ټاکي چې ډیسک ته د فلش کولو دمخه به څومره وخت ریکارډونه په حافظه کې ساتل کیږي (ډیفالټ 2 ساعته دی). د اړتیا وړ حافظې مقدار به د وخت لړۍ ، لیبلونو او سکریپونو پورې اړه ولري چې خالص راتلونکي جریان کې اضافه شوي. د ډیسک ځای په شرایطو کې، پرومیټیوس موخه لري چې په هر ریکارډ کې 3 بایټس (نمونه) وکاروي. له بلې خوا، د حافظې اړتیاوې خورا لوړې دي.
که څه هم دا ممکنه ده چې د بلاک اندازه تنظیم کړئ، دا سپارښتنه نه کیږي چې دا په لاسي ډول تنظیم کړئ، نو تاسو مجبور یاست چې پرومیتیوس ته څومره حافظه ورکړئ څومره چې دا ستاسو د کاري بار لپاره اړتیا لري.
که چیرې د میټریک راتلونکي جریان ملاتړ کولو لپاره کافي حافظه شتون ونلري ، نو پرومیټیوس به له حافظې څخه راوتلي یا د OOM وژونکي به دې ته ورسیږي.
د حادثې ځنډولو لپاره د سویپ اضافه کول کله چې پرومیټیوس حافظه له لاسه ورکوي واقعیا مرسته نه کوي ، ځکه چې د دې فنکشن کارول د چاودیدونکي حافظې مصرف لامل کیږي. زه فکر کوم چې دا د Go سره څه شی دی ، د دې کثافاتو راټولونکی او هغه لاره چې دا د تبادلې سره معامله کوي.
بله په زړه پورې طریقه دا ده چې د پروسې له پیل څخه د شمیرلو پرځای د سر بلاک په ټاکلي وخت کې ډیسک ته فلش کولو لپاره تنظیم کړئ.
لکه څنګه چې تاسو د ګراف څخه لیدلی شئ، ډیسک ته فلش په هر دوه ساعتونو کې واقع کیږي. که تاسو د min-block-duration پیرامیټر یو ساعت ته بدل کړئ، نو دا بیا تنظیمونه به هر ساعت کې واقع شي، نیم ساعت وروسته پیل کیږي.
که تاسو غواړئ دا او نور ګرافونه په خپل پرومیټیوس نصب کې وکاروئ ، تاسو کولی شئ دا وکاروئ . دا د PMM لپاره ډیزاین شوی و، مګر، د کوچنیو تعدیلاتو سره، د پرومیټیوس نصبولو سره مناسب دی.
موږ یو فعال بلاک لرو چې د سر بلاک په نوم یادیږي چې په حافظه کې ساتل کیږي. د زړو معلوماتو سره بلاکونه له لارې شتون لري mmap(). دا د کیچ په جلا توګه تنظیم کولو اړتیا له مینځه وړي ، مګر دا پدې معنی هم ده چې تاسو اړتیا لرئ د عملیاتي سیسټم کیچ لپاره کافي ځای پریږدئ که تاسو غواړئ د هغه څه څخه زاړه ډیټا پوښتنه وکړئ چې سر بلاک پکې ځای کیدی شي.
دا د دې معنی هم لري چې د پرومیټیوس مجازی حافظې مصرف به خورا لوړ ښکاري ، کوم چې د اندیښنې وړ ندي.
د ډیزاین بل په زړه پورې ټکی د WAL کارول دي (مخکې لاګ ولیکئ). لکه څنګه چې تاسو د ذخیره کولو اسنادو څخه لیدلی شئ، پرومیټیوس د حادثو څخه مخنیوي لپاره 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
}په Prometheus کې مرکبات هغه وخت پورې تړلي دي چې د سر بلاک ډیسک ته فلش کیږي. په دې وخت کې، کیدای شي څو دا ډول عملیات ترسره شي.
داسې ښکاري چې مرکبات په هیڅ ډول محدود ندي او کولی شي د اجرا کولو پرمهال د لوی ډیسک I/O سپکونو لامل شي.
د CPU بار سپکاوی
البته ، دا د سیسټم په سرعت خورا منفي اغیزه لري ، او د LSM ذخیره کولو لپاره جدي ننګونه هم رامینځته کوي: څنګه کولی شو د لوړې غوښتنې نرخونو ملاتړ کولو لپاره کمپیکیشن ترسره کړو پرته لدې چې د ډیر سر لامل شي؟
د ترکیب په پروسه کې د حافظې کارول هم خورا په زړه پوري ښکاري.
موږ کولی شو وګورو چې څنګه د کمپیکیشن وروسته ، ډیری حافظه له کیچ څخه وړیا ته بدلیږي: دا پدې مانا ده چې احتمالي ارزښتناک معلومات له هغه ځایه لرې شوي. حیرانتیا که دا دلته کارول کیږي fadvice() یا د کمولو کوم بل تخنیک، یا دا ځکه چې زیرمه د کمپیکیشن پرمهال له ویجاړ شوي بلاکونو څخه آزاده شوې وه؟
د ناکامۍ وروسته بیا رغونه
د ناکامیو څخه رغونه وخت نیسي، او د ښه دلیل لپاره. په هره ثانیه کې د یو ملیون ریکارډونو راتلونکي جریان لپاره ، زه باید شاوخوا 25 دقیقې انتظار وکړم پداسې حال کې چې رغونه د SSD ډرایو په پام کې نیولو سره ترسره شوې.
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 او حافظه کې جدي بار ولید.
د حافظې په کارولو کې نیمګړتیاوې په ګوته کوي چې پرومیټیوس نشي کولی ټول ټولګه له پیل څخه تنظیم کړي، او ځینې معلومات ورک شوي.
ما د لوړ CPU او حافظې بار لپاره دقیق دلیلونه ندي موندلي. زه شکمن یم چې دا د لوړ فریکونسۍ سره د سر بلاک کې د نوي وخت لړۍ رامینځته کولو له امله دی.
د CPU بار ډیریږي
د ترکیبونو سربیره ، کوم چې په کافي اندازه لوړ I/O بار رامینځته کوي ، ما په هر دوه دقیقو کې د CPU بار کې جدي سپکونه ولیدل. برسټونه اوږده وي کله چې د ننوتلو جریان لوړ وي او داسې ښکاري چې د Go د کثافاتو راټولونکي لخوا رامینځته کیږي، لږترلږه ځینې کورونه په بشپړ ډول بار شوي.
دا کودونه دومره مهم ندي. داسې ښکاري چې کله دا واقع کیږي، د پرومیتیوس داخلي ننوتلو نقطه او میټریکونه شتون نلري، د دې ورته وختونو په اوږدو کې د معلوماتو تشې لامل کیږي.
تاسو دا هم لیدلی شئ چې د پرومیتیس صادرونکی د یوې ثانیې لپاره بندیږي.
موږ کولی شو د کثافاتو راټولولو (GC) سره اړیکې وګورو.
پایلې
په Prometheus 2 کې TSDB ګړندی دی ، د ملیونونو وخت لړۍ اداره کولو وړ دی او په ورته وخت کې په هر ثانیه کې د کافي معمولي هارډویر په کارولو سره زرګونه ریکارډونه. د CPU او ډیسک I/O کارول هم اغیزمن دي. زما مثال په هره ثانیه کې تر 200 میټریک پورې ښودل شوی چې په هر کور کې کارول کیږي.
د پراخولو پلان کولو لپاره، تاسو اړتیا لرئ د کافي حافظې په اړه په یاد ولرئ، او دا باید ریښتینې حافظه وي. د کارول شوي حافظې مقدار چې ما مشاهده کړی شاوخوا 5 GB وه په هر 100 ریکارډونو کې د راتلوونکي جریان په هره ثانیه کې ، کوم چې د عملیاتي سیسټم کیچ سره یوځای شاوخوا 000 GB نیول شوې حافظه ورکوي.
البته، د CPU او ډیسک I/O سپکونو د کنټرول لپاره لاهم ډیر کار کولو ته اړتیا ده، او دا د حیرانتیا خبره نده چې څنګه ځوان TSDB Prometheus 2 د InnoDB، TokuDB، RocksDB، WiredTiger سره پرتله کیږي، مګر دوی ټول ورته ورته وو. د دوی د ژوند دوره کې ستونزې.
سرچینه: www.habr.com