🥇څنګه په کبرنیټس کې د پوډ لومړیتوبونه په ګرافانا لابراتوار کې د ځنډ لامل شو

نوټ. ژباړه: موږ ستاسو پام ته د ګرافانا د جوړونکو لخوا ساتل شوي د کلاوډ خدمت کې د وروستي ځنډ د لاملونو په اړه تخنیکي توضیحات وړاندې کوو. دا یو کلاسیک مثال دی چې څنګه د زیربنا کیفیت ښه کولو لپاره ډیزاین شوی یو نوی او ښکاري خورا ګټور خصوصیت کولی شي زیان ورسوي که تاسو د تولید په واقعیتونو کې د دې غوښتنلیک ډیری باریکیو ته چمتو نه کړئ. دا خورا ښه دی کله چې د دې په څیر توکي څرګند شي چې تاسو ته اجازه درکوي نه یوازې له خپلو غلطیو څخه زده کړئ. توضیحات د ګرافانا لابراتوار څخه د محصول د مرستیال څخه د دې متن په ژباړه کې دي.

د جمعې په ورځ ، د جولای په 19 ، په ګرافانا کلاوډ کې کوربه شوي پرومیټیوس خدمت د نږدې 30 دقیقو لپاره فعالیت ودراوه. زه د ټولو پیرودونکو څخه بخښنه غواړم چې د بندیدو له امله اغیزمن شوي. زموږ دنده دا ده چې د څارنې وسیلې چمتو کړئ چې تاسو ورته اړتیا لرئ، او موږ پوهیږو چې د دوی شتون نه درلودل ستاسو ژوند ډیر ستونزمن کوي. موږ دا پیښه ډیره جدي نیسو. دا یادښت تشریح کوي چې څه پیښ شوي، موږ څنګه ځواب ورکړ، او موږ څه کوو ترڅو ډاډ ترلاسه کړو چې دا بیا نه پیښیږي.

له تاریخ څخه دمخه

Grafana Cloud Hosted Prometheus خدمت پر بنسټ والړ دی کورټیک - د CNCF پروژه چې په افقی ډول د توزیع وړ ، خورا شتون لري ، څو کرایه کونکي پرومیټیوس خدمت رامینځته کړي. د کورټیکس جوړښت د انفرادي مایکرو خدماتو سیټ څخه جوړ دی، چې هر یو یې خپل فعالیت ترسره کوي: نقل کول، ذخیره کول، پوښتنې، او نور. Cortex د فعال پرمختګ لاندې دی او په دوامداره توګه نوي ځانګړتیاوې اضافه کوي او فعالیت ښه کوي. موږ په منظم ډول کلسترونو ته د کورټیکس نوي ریلیزونه ځای په ځای کوو ترڅو پیرودونکي وکولی شي د دې ځانګړتیاو څخه ګټه پورته کړي - خوشبختانه ، کورټیکس پرته له ځنډ څخه تازه کیدی شي.

د بې ساري تازه معلوماتو لپاره ، د Ingester Cortex خدمت د تازه پروسې په جریان کې اضافي Ingester نقل ته اړتیا لري. (نوټ. ژباړه: Ingester - د کورټیکس اساسي برخه. د دې دنده دا ده چې د نمونو دوامداره جریان راټول کړئ ، د پرومیټیوس ټوټو کې یې ګروپ کړئ او په ډیټابیس کې یې ذخیره کړئ لکه DynamoDB ، BigTable یا Cassandra.) دا زاړه انجسټرانو ته اجازه ورکوي چې اوسني ډیټا نوي انجسټرانو ته ولیږدوي. دا د یادولو وړ ده چې انجیسټر د سرچینو غوښتنه کوي. د دوی د کار کولو لپاره ، تاسو اړتیا لرئ په هر پوډ کې 4 کورونه او 15 جی بی حافظه ولرئ ، د بیلګې په توګه. زموږ د Kubernetes کلسترونو په قضیه کې د بیس ماشین د پروسس ځواک او حافظې 25٪. په عموم کې، موږ معمولا په کلستر کې د 4 کورونو او 15 GB حافظې په پرتله خورا ډیر غیر کارول شوي سرچینې لرو، نو موږ کولی شو په اسانۍ سره د نوي کولو په جریان کې دا اضافي انګسټرونه سپن کړو.

په هرصورت، دا ډیری وختونه پیښیږي چې د نورمال عملیاتو په جریان کې هیڅ ماشین د دې 25٪ غیر کارول شوي سرچینې نلري. هو، موږ حتی هڅه نه کوو: CPU او حافظه به تل د نورو پروسو لپاره ګټور وي. د دې ستونزې د حل لپاره، موږ د کارولو پریکړه وکړه Kubernetes Pod لومړیتوبونه. نظر دا دی چې انجسټرانو ته د نورو (بې ریاسته) مایکرو خدماتو په پرتله لوړ لومړیتوب ورکړي. کله چې موږ اضافي (N+1) انجیسټر چلولو ته اړتیا لرو، موږ په لنډمهاله توګه نور کوچني پوډونه بې ځایه کوو. دا پوډونه په نورو ماشینونو کې وړیا سرچینو ته لیږدول کیږي، د اضافي انګسټر چلولو لپاره کافي لوی "سوري" پریږدي.

د پنجشنبې په ورځ، د جولای په 18، موږ خپلو کلسترونو ته د لومړیتوب څلور نوي درجې وړاندې کړې: جدي, высокий, اوسط и ټيټه. دوی په داخلي کلستر کې ازمول شوي چې د شاوخوا یوې اونۍ لپاره د پیرودونکي ترافیک نلري. د ډیفالټ په واسطه، پوډونه پرته له کوم مشخص لومړیتوب ترلاسه شوي اوسط لومړیتوب، ټولګی د انجسټرانو لپاره ټاکل شوی و لوړ لومړیتوب. انتقادي د څارنې لپاره ځانګړې شوې وه (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etc.). زموږ ترتیب خلاص دی، او تاسو کولی شئ PR وګورئ دلته.

حادثه

د جمعې په ورځ، د جولای په 19، یو انجینر د لوی پیرودونکي لپاره یو نوی وقف شوی کورټیکس کلستر پیل کړ. د دې کلستر لپاره په ترتیب کې د نوي پوډ لومړیتوبونه شامل نه وو، نو ټول نوي پوډونه د ډیفالټ لومړیتوب ټاکل شوي - اوسط.

د Kubernetes کلستر د نوي کورټیکس کلستر لپاره کافي سرچینې نه درلودې، او موجوده تولید Cortex کلستر تازه نه و (Ingesters پرته پریښودل شوي لوړ لومړیتوب). له هغه وخته چې د نوي کلستر انجسټرانو په ډیفالټ ډول درلود اوسط لومړیتوب، او په تولید کې موجود پوډونه پرته له لومړیتوب څخه کار کوي، د نوي کلستر انګسټرانو د موجوده کورټیکس تولید کلستر څخه انګیسټرونه ځای په ځای کړل.

د تولید کلستر کې د ویستل شوي انجیسټر لپاره ریپلیکا سیټ ویستل شوی پوډ کشف کړ او د کاپي ټاکل شوي شمیر ساتلو لپاره یې نوی رامینځته کړ. نوی پوډ د ډیفالټ لخوا ټاکل شوی و اوسط لومړیتوب، او په تولید کې بل "زاړه" انګسټر خپلې سرچینې له لاسه ورکړې. پایله دا وه د واورې تودوخې پروسه، کوم چې د کورټیکس تولید کلسترونو لپاره د انګیسټر څخه د ټولو پوډونو بې ځایه کیدو لامل شو.

Ingesters ریاستي دي او د تیرو 12 ساعتونو لپاره ډاټا ذخیره کوي. دا موږ ته اجازه راکوي چې د اوږدې مودې ذخیره کولو ته د لیکلو دمخه دوی په ډیر اغیزمن ډول فشار کړو. د دې لاسته راوړلو لپاره، کورټیکس د ویشل شوي هش میز (DHT) په کارولو سره د لړۍ په اوږدو کې ډیټا شارډ کوي او هره لړۍ د ډینامو سټایل کورم تسلسل په کارولو سره په دریو انجسټرونو کې تکراروي. Cortex Ingesters ته معلومات نه لیکي چې معیوب شوي دي. په دې توګه، کله چې لوی شمیر انجینټرونه DHT پریږدي، Cortex نشي کولی د ننوتلو کافي نقل چمتو کړي، او دوی خرابیږي.

کشف او درملنه

د "غلطي بودیجې" پراساس د پرومیټیوس نوي خبرتیاوې (تېروتنه - د بودیجې پر بنسټ - توضیحات به په راتلونکي مقاله کې څرګند شي) د بند له پیل څخه 4 دقیقې وروسته د الارم غږول پیل کړل. په راتلونکو پنځو دقیقو یا څو دقیقو کې، موږ ځینې تشخیصونه پرمخ یوړل او د کوبرنیټس اصلي کلستر یې اندازه کړ ترڅو دواړه نوي او موجوده تولید کلسترونه کوربه کړي.

د نورو پنځو دقیقو وروسته، زاړه انګسټرانو په بریالیتوب سره خپل معلومات لیکلي، نوي یې پیل کړي، او د کورټیکس کلسترونه بیا شتون لري.

نورې 10 دقیقې د کورټیکس مخې ته موقعیت لرونکي د تصدیق ریورس پراکسي څخه د حافظې څخه بهر (OOM) غلطیو تشخیص او سمولو کې مصرف شوې. د OOM تېروتنې په QPS کې د لس چنده زیاتوالي له امله رامینځته شوي (موږ باور لرو د پیرودونکي پرومیټیوس سرورونو څخه د ډیر تیریدونکي غوښتنو له امله).

پایلې

د ټول ځنډ وخت 26 دقیقې و. هیڅ معلومات له لاسه نه دي ورکړل شوي. Ingesters په بریالیتوب سره په حافظه کې ټول معلومات د اوږدې مودې ذخیره کې بار کړي. د بندیدو پرمهال ، د پیرودونکي پرومیټیوس سرورونه بفر شوي حذف شوي (لیرې) د کارولو ریکارډونه نوی API remote_write د WAL پر بنسټ (لیکوال کالم سټان د ګرافانا لابراتوار څخه) او د حادثې وروسته ناکامې لیکنې تکرار کړې.

د تولید کلستر لیکلو عملیات

موندنو

دا مهمه ده چې د دې پیښې څخه زده کړه وکړو او د هغې د تکرار مخنیوي لپاره اړین ګامونه پورته کړو.

په ښکاره ډول، موږ باید ډیفالټ نه وای ټاکلی اوسط لومړیتوب تر هغه چې په تولید کې ټول مصرف کونکي ترلاسه کړي высокий یو لومړیتوب. برسېره پردې، دا اړینه وه چې مخکې له مخکې دوی ته پاملرنه وشي لوړ لومړیتوب. هر څه اوس سم شوي دي. موږ هیله لرو چې زموږ تجربه به د نورو سازمانونو سره مرسته وکړي چې په Kubernetes کې د پوډ لومړیتوبونو کارولو په اړه فکر کوي.

موږ به د هر هغه اضافي شیانو په ګمارلو کې د کنټرول اضافي کچې اضافه کړو چې تشکیلات یې په کلستر کې نړیوال دي. له اوس څخه، دا ډول بدلونونه به ارزول کیږي بоزيات خلک. سربیره پردې، هغه تعدیل چې د حادثې لامل شوی د جلا پروژې سند لپاره خورا کوچنی وګڼل شو - دا یوازې د GitHub مسله کې بحث شوی. له اوس څخه، په تشکیلاتو کې دا ډول ټول بدلونونه به د مناسبې پروژې اسنادو سره وي.

په نهایت کې ، موږ به د اوورلوډ OOM مخنیوي لپاره د تصدیق ریورس پراکسي له سره تنظیم کول اتومات کړو چې موږ یې شاهدان یو ، او په راتلونکي کې د ورته مسلو مخنیوي لپاره به د فال بیک او سکیلینګ پورې اړوند د پرومیټیوس ډیفالټ ترتیبات بیاکتنه وکړو.

ناکامۍ ځینې مثبتې پایلې هم درلودې: د اړینو سرچینو په ترلاسه کولو سره، Cortex په اتوماتيک ډول پرته له اضافي مداخلې روغ شو. موږ د کار کولو ارزښتناکه تجربه هم ترلاسه کړه Grafana Loki - زموږ د ننوتو راټولولو نوی سیسټم - کوم چې د دې ډاډ ترلاسه کولو کې مرسته وکړه چې د ناکامۍ په جریان کې او وروسته ټول انجیسټرانو سم چلند وکړ.

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

سرچینه: www.habr.com

څنګه په کوبرنیټس کې د پوډ لومړیتوبونه د ګرافانا لابراتوارونو کې د ځنډ لامل شوي