VictoriaMetrics د وخت لړۍ په بڼه د معلوماتو ذخیره کولو او پروسس کولو لپاره یو ګړندی او د توزیع وړ DBMS دی (ریکارډ د وخت او د دې وخت سره مطابقت لرونکي ارزښتونو سیټ لري ، د مثال په توګه ، د سینسرونو حالت د دورې رایې ورکولو له لارې ترلاسه کیږي یا د میټریک راټولول).
زما نوم کولوبایف پاول دی. DevOps، SRE، LeroyMerlin، هرڅه د کوډ په څیر دي - دا ټول زموږ په اړه دي: زما په اړه او د LeroyMerlin نورو کارمندانو په اړه.
د OpenStack پر بنسټ یو بادل شتون لري. د تخنیکي رادار لپاره یو کوچنی اړیکه شتون لري.
دا د Kubernetes هارډویر، او همدارنګه د OpenStack او logging لپاره په ټولو اړونده خدماتو کې جوړ شوی.
دا هغه سکیم دی چې موږ یې په پراختیا کې درلود. کله چې موږ دا ټول رامینځته کول ، موږ د پرومیټیوس آپریټر درلود چې پخپله د K8s کلستر کې ډاټا ذخیره کوي. هغه په اوتومات ډول هغه څه ومومي چې پاکولو ته اړتیا لري او د خپلو پښو لاندې یې اچوي، په نږدې ډول خبرې کوي.
موږ به اړتیا ولرو چې ټول معلومات د Kubernetes کلستر څخه بهر وباسو، ځکه چې که یو څه پیښ شي، موږ باید پوه شو چې څه او چیرته.
لومړی حل دا دی چې موږ فدراسیون وکاروو کله چې موږ د دریمې ډلې پرومیتیوس لرو، کله چې موږ د فدراسیون میکانیزم له لارې د کوبرنیټس کلستر ته ځو.
مګر دلته ځینې کوچنۍ ستونزې شتون لري. زموږ په قضیه کې، ستونزې هغه وخت پیل شوې کله چې موږ 250 میټریکونه درلودل، او کله چې 000 میټریکونه وو، موږ پوهیږو چې موږ نشو کولی داسې کار وکړو. موږ د scrape_timeout 400 ثانیو ته لوړ کړ.
ولې موږ باید دا کار وکړو؟ Prometheus د کټ له پیل څخه د وخت پای شمیرل پیلوي. دا مهمه نده چې معلومات لاهم جریان لري. که چیرې د دې ټاکلې مودې په جریان کې ډاټا یوځای نشي او سیشن د HTTP له لارې نه وي تړل شوی، نو بیا ناسته ناکامه ګڼل کیږي او ډاټا پخپله پرومیتیوس ته نه رسیږي.
هرڅوک د هغه ګرافونو سره اشنا دي چې موږ یې ترلاسه کوو کله چې ځینې معلومات ورک وي. مهال ویش مات شوی او موږ له دې څخه خوښ نه یو.
بل انتخاب د ورته فدراسیون میکانیزم له لارې د دوه مختلف پرومیتیوس پراساس شارډینګ دی.
د مثال په توګه، یوازې دوی واخلئ او د نوم په واسطه یې وخورئ. دا هم کارول کیدی شي، مګر موږ پریکړه وکړه چې حرکت وکړو.
موږ به اوس دا شارډونه په یو ډول پروسس کړو. تاسو کولی شئ پرامکسی واخلئ، کوم چې د شارډ ساحې ته ځي او ډاټا ضربوي. دا د دوه شارډونو سره د یو واحد ننوتلو نقطې په توګه کار کوي. دا د promxy له لارې پلي کیدی شي، مګر دا لاهم خورا ستونزمن دی.
لومړی اختیار دا دی چې موږ غواړو د فدراسیون میکانیزم پریږدو ځکه چې دا خورا ورو دی.
د پرومیټیوس پراختیا کونکي په روښانه ډول وايي ، "هلکانو ، یو مختلف TimescaleDB وکاروئ ځکه چې موږ به د میټریکونو اوږدې مودې ذخیره کولو ملاتړ ونه کړو." دا د دوی دنده نه ده.
موږ د کاغذ په یوه ټوټه کې لیکو چې موږ لاهم اړتیا لرو چې بهر پورته کړو، نو دا چې هرڅه په یو ځای کې ذخیره نه کړو.
دوهم نیمګړتیا د حافظې مصرف دی. هو ، زه پوهیږم چې ډیری به ووایی چې په 2020 کې د څو ګیګابایټ حافظې یوه پیسي لګښت لري ، مګر لاهم.
اوس موږ یو dev او prod چاپیریال لرو. په dev کې دا د 9 میټریکونو لپاره شاوخوا 350 ګیګابایټ دی. په تولید کې دا 000 ګیګابایټ او لږ څه 14 میټریک دی. په ورته وخت کې، زموږ د ساتلو وخت یوازې 780 دقیقې دی. دا بد دی. او اوس زه به تشریح کړم چې ولې.
موږ محاسبه کوو ، دا د یو نیم ملیون میټریکونو سره ، او موږ دمخه دوی ته نږدې یو ، د ډیزاین مرحله کې موږ 35-37 ګیګابایټ حافظه ترلاسه کوو. مګر دمخه 4 ملیون میټریکونه شاوخوا 90 ګیګابایټ حافظې ته اړتیا لري. دا دی، دا د پرومیټیوس پراختیا کونکو لخوا چمتو شوي فارمول په کارولو سره محاسبه شوې. موږ اړیکې ته وکتل او پوه شو چې موږ نه غواړو یوازې د څارنې لپاره د سرور لپاره څو ملیونه تادیه کړو.
موږ به نه یوازې د ماشینونو شمیر زیات کړو، موږ پخپله د مجازی ماشینونو څارنه هم کوو. له همدې امله، څومره چې مجازی ماشینونه، د مختلفو ډولونو ډیر میټریکونه، او نور. موږ به د میټریکونو له مخې زموږ د کلستر ځانګړې وده ولرو.
د ډیسک ځای سره ، دلته هرڅه دومره خراب ندي ، مګر زه غواړم دا ښه کړم. موږ په 15 ورځو کې ټول 120 ګیګابایټ ترلاسه کړل، چې 100 یې کمپریس شوي ډیټا دي، 20 غیر کمپریس شوي ډیټا دي، مګر موږ تل لږ غواړو.
په دې اساس، موږ یو بل ټکی لیکو - دا د سرچینو لوی مصرف دی، کوم چې موږ لاهم غواړو خوندي کړو، ځکه چې موږ نه غواړو زموږ د څارنې کلستر زموږ د کلستر په پرتله ډیرې سرچینې مصرف کړي، کوم چې د OpenStack اداره کوي.
د Prometheus یو بل نیمګړتیا شتون لري، کوم چې موږ د ځان لپاره پیژندلي، دا لږترلږه د حافظې یو ډول محدودیت دی. د پرومیتیوس سره، دلته هرڅه خورا خراب دي، ځکه چې دا هیڅ ډول مرحلې نلري. په ډاکر کې د حد کارول هم یو اختیار ندی. که ناڅاپه ستاسو RAF راټیټ شي او 20-30 ګیګابایټ شتون ولري، نو دا به ډیر وخت ونیسي.
دا یو بل دلیل دی چې ولې پرومیتیوس زموږ لپاره مناسب نه دی، د بیلګې په توګه موږ نشو کولی د حافظې مصرف محدود کړو.
دا به ممکنه وي چې د داسې یو سکیم سره راشي. موږ دې سکیم ته اړتیا لرو ترڅو د HA کلستر تنظیم کړو. موږ غواړو چې زموږ میټریکونه تل او هرچیرې شتون ولري، حتی که هغه سرور چې دا میټریکونه ذخیره کوي خراب شي. او په دې توګه موږ باید دا ډول سکیم جوړ کړو.
دا سکیم وايي چې موږ به د شارډونو نقل ولرو، او په وینا یې، د مصرف شویو سرچینو لګښتونو نقل. دا تقریبا په افقی ډول اندازه کیدی شي، مګر بیا هم د سرچینو مصرف به دوزخي وي.
نیمګړتیاوې په ترتیب کې چې موږ یې د ځان لپاره لیکلي:
- په بهر کې د میټریک اپلوډ کولو ته اړتیا لري.
- د سرچینو لوړ مصرف.
- د حافظې مصرف محدودولو لپاره هیڅ لاره نشته.
- د HA پیچلي او د سرچینو ژور تطبیق.
د ځان لپاره، موږ پریکړه وکړه چې موږ د پرومیټیوس څخه د ذخیره کولو اسانتیا په توګه لیرې یو.
موږ د ځان لپاره اضافي اړتیاوې په ګوته کړي چې موږ ورته اړتیا لرو. دا:
- دا د promql ملاتړ دی، ځکه چې د پرومیټیوس لپاره لا دمخه ډیری شیان لیکل شوي دي: پوښتنې، خبرتیاوې.
- او بیا موږ ګرافانا لرو ، کوم چې دمخه د پرومیتیس لپاره د شالید په توګه په ورته ډول لیکل شوی. زه نه غواړم ډشبورډونه بیا ولیکم.
- موږ غواړو یو عادي HA جوړښت جوړ کړو.
- موږ غواړو د هر ډول سرچینو مصرف کم کړو.
- یو بل کوچنی اړخ شتون لري. موږ نشو کولی د بادل میټریک راټولولو سیسټمونو مختلف ډولونه وکاروو. موږ نه پوهیږو چې پدې میټریکونو کې به څه راشي. او له هغه ځایه چې هر څه کولی شي هلته الوتنه وکړي ، موږ باید خپل ځان ځایی ځای پرځای کولو پورې محدود کړو.
لږ انتخاب وو. موږ ټول هغه څه راټول کړل چې موږ ورسره تجربه درلوده. موږ د ادغام برخه کې د پرومیټیوس پا pageې ته وکتل ، د مقالو یوه ډله ولوستله ، او ولیدل چې هلته څه وو. او د ځان لپاره ، موږ د پرومیټیوس د بدیل په توګه ویکتوریا میټریک غوره کړ.
ولې؟ ځکه:
- promql پیژني.
- یو ماډلر جوړښت شتون لري.
- په ګرافانا کې بدلونونو ته اړتیا نلري.
- او تر ټولو مهم، موږ به شاید زموږ په شرکت کې د خدمت په توګه د میټریک ذخیره چمتو کړو، نو موږ د مختلفو ډولونو محدودیتونو په لټه کې یو ترڅو کاروونکي کولی شي د کلستر ټولې سرچینې په یو څه محدود ډول وکاروي، ځکه چې فرصت شتون لري. چې دا به څو اړخیزه وي.
راځئ چې لومړی پرتله وکړو. موږ ورته پرومیتیوس د کلستر دننه اخلو، بهرنی پرومیتیوس دې ته ځي. د RemoteWrite VictoriaMetrics له لارې اضافه کړئ.
زه به سمدلاسه ریزرویشن وکړم چې دلته موږ د ویکتوریا میټریکس څخه د CPU مصرف کې یو څه زیاتوالی موندلی. د VictoriaMetrics ویکي تاسو ته وایي چې کوم پیرامیټونه غوره دي. موږ دوی چک کړل. دوی د CPU مصرف خورا ښه کم کړی.
زموږ په قضیه کې ، د پرومیټیوس حافظې مصرف ، کوم چې د کوبرنیټس کلستر کې موقعیت لري ، د پام وړ وده نه ده کړې.
موږ د ورته معلوماتو دوه سرچینې پرتله کوو. په Prometheus کې موږ ورته ورک شوي ډاټا ګورو. په ویکتوریا میټریکس کې هرڅه سم دي.
د ډیسک ځای ازموینې پایلې. موږ په پرومیټیوس کې په ټولیز ډول 120 ګیګابایټ ترلاسه کړل. په ویکتوریا میټریکس کې موږ دمخه هره ورځ 4 ګیګابایټ ترلاسه کوو. د هغه څه په پرتله یو څه مختلف میکانیزم شتون لري چې موږ یې په پرومیتیس کې لیدلو عادت شوي یو. دا دی، ډاټا لا دمخه په یوه ورځ کې، په نیم ساعت کې خورا ښه فشار شوي. دوی لا دمخه په یوه ورځ کې په نیم ساعت کې ښه حاصل شوي، سره له دې چې ډاټا به بیا هم وروسته له لاسه ورکړي. د پایلې په توګه، موږ د ډیسک ځای خوندي کړ.
موږ د حافظې سرچینې مصرف هم خوندي کوو. د ازموینې په وخت کې ، موږ پرومیټیوس په مجازی ماشین کې ځای په ځای کړی و - 8 کور ، 24 ګیګابایټ. Prometheus نږدې هرڅه خوري. هغه د OOM قاتل باندې راوتلی. په ورته وخت کې، یوازې 900 فعال میټریکونه په دې کې اچول شوي. دا په هره ثانیه کې شاوخوا 000-25 میټریک دی.
موږ VictoriaMetrics د 8 ګیګابایټ RAM سره په دوه ګونی کور مجازی ماشین کې چلولی. موږ وکولی شو چې ویکتوریا میټریک ترلاسه کړو ترڅو په 8GB ماشین کې د یو څو شیانو سره شاوخوا ګړندي کولو سره ښه کار وکړي. په پای کې، موږ دا 7 ګیګابایټ ته وسپاره. په ورته وخت کې، د منځپانګې د وړاندې کولو سرعت، د بیلګې په توګه، د پرومیتیوس په پرتله حتی لوړ و.
CPU د Prometheus په پرتله خورا ښه شوی. دلته Prometheus 2,5 cores مصرفوي، او VictoriaMetrics یوازې 0,25 کورونه مصرفوي. په پیل کې - 0,5 کورونه. لکه څنګه چې دا یوځای کیږي، دا یو کور ته رسیږي، مګر دا خورا خورا نادر دی.
زموږ په قضیه کې، انتخاب د واضح دلیلونو لپاره په ویکتوریا میټریک باندې راوتلی؛ موږ غوښتل پیسې خوندي کړو او موږ یې وکړل.
راځئ چې سمدلاسه دوه ټکي تیر کړو - د میټریک اپلوډ کول او د سرچینو لوړه مصرف. او موږ باید یوازې دوه ټکي پریکړه وکړو چې موږ لاهم د ځان لپاره پاتې یو.
دلته زه به سمدلاسه ریزرویشن وکړم ، موږ ویکتوریا میټریک د میټریک ذخیره په توګه ګورو. مګر له هغه ځایه چې موږ به ډیری احتمال د ټولو لیروی لپاره د ذخیره کولو په توګه ویکتوریا میټریک چمتو کړو، موږ اړتیا لرو هغه کسان محدود کړو چې دا کلستر کاروي ترڅو دوی موږ ته نه راکوي.
یو په زړه پوری پیرامیټر شتون لري چې تاسو ته اجازه درکوي د وخت ، د معلوماتو حجم او د اجرا کولو وخت لخوا محدود کړئ.
دلته یو غوره اختیار هم شتون لري چې موږ ته اجازه راکوي د حافظې مصرف محدود کړو ، پدې توګه موږ کولی شو خورا توازن ومومئ چې موږ ته اجازه راکوي د عادي عملیاتي سرعت او کافي سرچینو مصرف ترلاسه کړو.
یو بل ټکی منفي کړئ، د بیلګې په توګه د نقطې څخه تیر کړئ - تاسو نشئ کولی د حافظې مصرف محدود کړئ.
په لومړیو تکرارونو کې، موږ د ویکتوریا میټریکس واحد نوډ ازموینه وکړه. بیا موږ د ویکتوریا میټریک کلستر نسخه ته ځو.
دلته موږ په ویکتوریا میټریک کې د مختلف خدماتو جلا کولو لپاره وړیا لاس لرو پدې پورې اړه لري چې دوی به څه پرمخ وړي او کومې سرچینې به یې مصرف کړي. دا یو ډیر انعطاف منونکی او مناسب حل دی. موږ دا په خپل ځان وکارول.
د VictoriaMetrics کلستر نسخه اصلي برخې vmstsorage دي. کیدای شي د دوی شمیر N وي. زموږ په قضیه کې تر دې دمه 2 یې شتون لري.
او vminsert شتون لري. دا یو پراکسي سرور دی چې موږ ته اجازه راکوي: د ټولو ذخیرو تر مینځ شارډینګ تنظیم کړئ چې موږ ورته ویلي وو، او دا د نقل اجازه هم ورکوي، د بیلګې په توګه تاسو به دواړه شارډینګ او یو نقل ولرئ.
Vminsert د Prometheus څخه OpenTSDB، Graphite، InfluxDB او remoteWrite پروتوکولونو ملاتړ کوي.
vmselect هم شته. د دې اصلي دنده دا ده چې vmstorage ته لاړ شئ، له دوی څخه ډاټا ترلاسه کړئ، دا ډاټا نقل کړئ او پیرودونکي ته یې ورکړئ.
د vmagent په نوم یو عجيب شی شتون لري. موږ واقعیا هغه خوښوو. دا تاسو ته اجازه درکوي دقیقا د پرومیتیوس په څیر تنظیم کړئ او لاهم هرڅه د پرومیتیوس په څیر ترسره کړئ. دا دی، دا د مختلفو ادارو او خدماتو څخه میټریکونه راټولوي او vminsert ته یې لیږي. بیا هرڅه په تاسو پورې اړه لري.
بل لوی خدمت vmalert دی، کوم چې تاسو ته اجازه درکوي VictoriaMetrics د بیک انډ په توګه وکاروئ، د vminsert څخه پروسس شوي ډاټا ترلاسه کړئ او vmselect ته یې واستوئ. دا پخپله خبرتیاوې پروسس کوي، او همدارنګه مقررات. د خبرتیاو په حالت کې، موږ د خبرتیا مدیر له لارې خبرتیا ترلاسه کوو.
د wmauth برخه ده. موږ ممکن یا ونه کړو (موږ تراوسه پدې اړه پریکړه نه ده کړې) دا د کلسترونو څو اړخیز نسخې لپاره د واک ورکولو سیسټم په توګه وکاروو. دا د پرومیټیوس لپاره د ریموټ رایټ ملاتړ کوي او کولی شي د یو آر ایل پراساس اجازه ورکړي ، یا د هغې دویمه برخه ، چیرې چې تاسو لیکلی شئ یا نشئ کولی.
دلته vmbackup، vmrestore هم شتون لري. دا په اصل کې د ټولو معلوماتو بیا رغونه او بیک اپ دی. S3، GCS، فایل کولی شي.
زموږ د کلستر لومړی تکرار د قرنطین پرمهال رامینځته شوی. په هغه وخت کې، هیڅ نقل شتون نه درلود، نو زموږ تکرار دوه مختلف او خپلواک کلسترونه لري چې موږ یې د ریموټ رائټ له لارې ډاټا ترلاسه کړې.
دلته زه به یو ریزرویشن وکړم کله چې موږ د ویکتوریا میټریکس واحد نوډ څخه د ویکتوریا میټریکس کلستر نسخه ته واړوو ، موږ لاهم د ورته مصرف شوي سرچینو سره پاتې یو ، د بیلګې په توګه اصلي حافظه ده. دا تقریبا څنګه زموږ ډاټا، د بیلګې په توګه د سرچینو مصرف، ویشل شوي.
یو نقل لا دمخه دلته اضافه شوی. موږ دا ټول په یوه نسبتا لوی کلستر کې یوځای کړل. زموږ ټول معلومات دواړه ټوټې شوي او نقل شوي دي.
ټول کلستر د N ننوتلو نقطې لري، پدې معنی چې پرومیتیس کولی شي د HAPROXY له لارې ډاټا اضافه کړي. دلته موږ دا د ننوتلو نقطه لرو. او د دې ننوتلو نقطې له لارې تاسو کولی شئ له ګرافانا څخه ننوځئ.
زموږ په قضیه کې، HAPROXY یوازینی بندر دی چې پراکسي په دې کلستر کې دننه انتخاب، داخل او نور خدمتونه کوي. زموږ په قضیه کې ، دا ناممکن وه چې یو پته جوړه کړو؛ موږ باید د ننوتلو څو نقطې رامینځته کړو ، ځکه چې پخپله مجازی ماشینونه چې د ویکتوریا میټریک کلسټر چلوي د ورته کلاوډ چمتو کونکي مختلف زونونو کې موقعیت لري ، د بیلګې په توګه زموږ د بادل دننه نه ، بلکه بهر. .
موږ خبرداری لرو. موږ یې کاروو. موږ د پرومیتیس څخه د خبرتیا مدیر کاروو. موږ Opsgenie او Telegram د خبرتیا رسولو چینل په توګه کاروو. په ټیلیګرام کې دوی د dev څخه راوباسي، شاید د تولید څخه یو څه، مګر ډیری یې احصایوي، د انجنیرانو لخوا اړین دي. او Opsgenie مهم دی. دا زنګونه دي، د پیښې مدیریت.
ابدي پوښتنه: "څوک د څارنې څارنه کوي؟" زموږ په قضیه کې، د څارنې څارنه پخپله څارنه کوي، ځکه چې موږ په هر نوډ کې vmagent کاروو. او له هغه ځایه چې زموږ نوډونه د ورته چمتو کونکي مختلف ډیټا مرکزونو کې توزیع شوي ، د هر ډیټا مرکز خپل چینل لري ، دوی خپلواک دي ، او حتی که چیرې دماغ تقسیم شي ، موږ به بیا هم خبرتیاوې ترلاسه کړو. هو، دلته به ډیر څه وي، مګر دا غوره ده چې د هیڅ څخه ډیر خبرتیا ترلاسه کړئ.
موږ خپل لیست د HA پلي کولو سره پای ته ورسوو.
او نور زه غواړم د ویکتوریا میټریکس ټولنې سره د خبرو اترو تجربه یاد کړم. دا خورا مثبت وګرځید. هلکان ځواب ویونکي دي. دوی هڅه کوي هر هغه قضیه وڅیړي چې وړاندیز کیږي.
ما په GitHub کې مسلې پیل کړې. دوی ډیر ژر حل شول. دلته یو څو نورې مسلې شتون لري چې په بشپړ ډول نه دي تړل شوي، مګر زه دمخه د کوډ څخه لیدلی شم چې پدې لوري کار روان دی.
د تکرار په جریان کې زما لپاره اصلي درد دا و چې که زه یو نوډ بند کړم ، نو د لومړیو 30 ثانیو لپاره vminsert نشي پوهیدلی چې هیڅ بیکینډ شتون نلري. دا اوس پریکړه شوې ده. او په حقیقت کې په یوه یا دوه ثانیو کې، ډاټا د ټولو پاتې نوډونو څخه اخیستل کیږي، او غوښتنه د دې ورک شوي نوډ په انتظار کې پاتې کیږي.
په یو وخت کې موږ غوښتل VictoriaMetrics د VictoriaMetrics آپریټر وي. موږ ورته انتظار کاوه. موږ اوس په فعاله توګه د ویکتوریا میټریک آپریټر لپاره یو چوکاټ رامینځته کوو ترڅو ټول د محاسبې دمخه مقررات او نور په غاړه واخلو.
د کلستر پلي کولو ښه کولو لپاره وړاندیزونه شتون لري. ما دوی پورته بیان کړل.
او زه واقعیا غواړم نمونه ښکته کړم. زموږ په قضیه کې، د نمونې ښکته کولو ته په ځانګړې توګه د رجحاناتو لیدلو لپاره اړتیا ده. په لنډه توګه، د ورځې په جریان کې زما لپاره یو میټریک کافی دی. دا تمایلات یو کال، درې، پنځه، لس کاله ته اړتیا لري. او یو میټریک ارزښت خورا کافی دی.
- موږ درد پیژنو، لکه څنګه چې زموږ ځینې همکاران لري، کله چې پرومیتیس کاروي.
- موږ د ځان لپاره ویکتوریا میټریک غوره کړ.
- دا په عمودی او افقی ډول خورا ښه اندازه کوي.
- موږ کولی شو مختلف اجزا په کلستر کې د نوډونو مختلف شمیرو ته وویشو، دوی د حافظې لخوا محدود کړو، حافظه اضافه کړو، او نور.
موږ به په کور کې VictoriaMetrics وکاروو ځکه چې موږ واقعیا خوښ یو. دا هغه څه دي چې وو او څه شوي دي.
د ویکتوریا میټریک چیٹ لپاره یو څو QR کوډونه ، زما اړیکې ، لیرویمیرلین تخنیکي رادار.
سرچینه: www.habr.com