کبرنیٹس کلسٹر کی نگرانی: ایک جائزہ اور پرومیتھیس کا تعارف

Kubernetes کی نگرانی کے تصور پر غور کریں، Prometheus ٹول سے واقف ہوں، اور الرٹنگ کے بارے میں بات کریں۔

نگرانی کا موضوع بہت بڑا ہے، اسے ایک مضمون میں الگ نہیں کیا جا سکتا۔ اس متن کا مقصد ٹولز، تصورات اور نقطہ نظر کا ایک جائزہ فراہم کرنا ہے۔

مضمون کا مواد ایک نچوڑ ہے۔ سکول کا کھلا لیکچر "سلرم". اگر آپ مکمل کورس کرنا چاہتے ہیں تو - کورس کے لیے سائن اپ کریں۔ Kubernetes میں انفراسٹرکچر کی نگرانی اور لاگنگ.

کبرنیٹس کلسٹر میں کیا مانیٹر کیا جاتا ہے۔

جسمانی سرورز اگر Kubernetes کلسٹر اس کے سرورز پر تعینات ہے، تو آپ کو ان کی صحت کی نگرانی کرنے کی ضرورت ہے۔ Zabbix اس کام کو سنبھالتا ہے؛ اگر آپ اس کے ساتھ کام کرتے ہیں، تو آپ کو انکار کرنے کی ضرورت نہیں ہے، کوئی تنازعہ نہیں ہوگا۔ یہ Zabbix ہے جو ہمارے سرورز کی حالت پر نظر رکھتا ہے۔

آئیے کلسٹر کی سطح پر نگرانی کی طرف بڑھتے ہیں۔

کنٹرول طیارے کے اجزاء: API، شیڈیولر اور دیگر۔ کم از کم، آپ کو یہ یقینی بنانا ہوگا کہ سرورز یا etcd کا API 0 سے زیادہ ہے۔ Etcd بہت سارے میٹرکس واپس کر سکتا ہے: ان ڈسکوں کے ذریعے جن پر یہ گھوم رہا ہے، اس کے etcd کلسٹر کی صحت کے لحاظ سے، اور دیگر۔

میں Docker ایک طویل عرصہ پہلے شائع ہوا اور ہر کوئی اس کے مسائل سے بخوبی واقف ہے: بہت سارے کنٹینرز منجمد اور دیگر مسائل کو جنم دیتے ہیں۔ لہذا، خود ڈوکر کو، ایک نظام کے طور پر، کم از کم دستیابی کے لیے بھی کنٹرول کیا جانا چاہیے۔

ڈی این ایس۔ اگر ڈی این ایس کلسٹر میں گر جاتا ہے، تو اس کے بعد پوری ڈسکوری سروس بند ہو جائے گی، پوڈ سے پوڈ تک کالیں کام کرنا بند کر دیں گی۔ میری مشق میں، ایسی کوئی پریشانی نہیں تھی، لیکن اس کا مطلب یہ نہیں ہے کہ DNS کی حالت پر نظر رکھنے کی ضرورت نہیں ہے۔ درخواست میں تاخیر اور کچھ دیگر میٹرکس کو CoreDNS پر ٹریک کیا جا سکتا ہے۔

داخل ہونا۔ پراجیکٹ کے اندراج پوائنٹس کے طور پر داخلے (بشمول انگریس کنٹرولر) کی دستیابی کو کنٹرول کرنا ضروری ہے۔

کلسٹر کے اہم اجزاء کو ختم کر دیا گیا ہے - اب آئیے تجرید کی سطح پر جائیں۔

ایسا لگتا ہے کہ ایپلی کیشنز پوڈ میں چلتی ہیں، جس کا مطلب ہے کہ انہیں کنٹرول کرنے کی ضرورت ہے، لیکن حقیقت میں ایسا نہیں ہے۔ پھلیاں عارضی ہیں: آج وہ ایک سرور پر چلتی ہیں، کل دوسرے پر۔ آج ان میں سے 10 ہیں، کل 2۔ لہذا، کوئی بھی پھلیوں کی نگرانی نہیں کرتا ہے۔ مائیکرو سرویس فن تعمیر کے اندر، مجموعی طور پر ایپلیکیشن کی دستیابی کو کنٹرول کرنا زیادہ اہم ہے۔ خاص طور پر، سروس اینڈ پوائنٹس کی دستیابی کو چیک کریں: کیا کچھ کام کرتا ہے؟ اگر درخواست دستیاب ہے، تو اس کے پیچھے کیا ہوتا ہے، اب کتنی نقلیں ہیں؟ یہ دوسرے آرڈر کے سوالات ہیں۔ انفرادی واقعات کی نگرانی کرنے کی ضرورت نہیں ہے۔

آخری سطح پر، آپ کو ایپلی کیشن کے آپریشن کو خود کنٹرول کرنے، کاروباری میٹرکس لینے کی ضرورت ہے: آرڈرز کی تعداد، صارف کا رویہ، وغیرہ۔

Prometheus

کلسٹر کی نگرانی کا بہترین نظام ہے۔ Prometheus. میں کسی ایسے آلے کے بارے میں نہیں جانتا جو معیار اور استعمال میں آسانی کے لحاظ سے پرومیتھیس سے مماثل ہو۔ یہ لچکدار انفراسٹرکچر کے لیے بہت اچھا ہے، اس لیے جب وہ کہتے ہیں "Kubernetes مانیٹرنگ"، تو ان کا مطلب عام طور پر Prometheus ہوتا ہے۔

Prometheus کے ساتھ شروع کرنے کے لیے کچھ اختیارات ہیں: Helm کا استعمال کرتے ہوئے، آپ باقاعدہ Prometheus یا Prometheus آپریٹر انسٹال کر سکتے ہیں۔

1. باقاعدہ پرومیتھیس۔ اس کے ساتھ سب کچھ ٹھیک ہے، لیکن آپ کو ConfigMap کو کنفیگر کرنے کی ضرورت ہے - درحقیقت، ٹیکسٹ بیسڈ کنفیگریشن فائلیں لکھیں، جیسا کہ ہم نے مائیکرو سروس آرکیٹیکچر سے پہلے کیا تھا۔
2. Prometheus Operator تھوڑا زیادہ پھیلا ہوا ہے، اندرونی منطق کے لحاظ سے تھوڑا زیادہ پیچیدہ ہے، لیکن اس کے ساتھ کام کرنا آسان ہے: یہاں الگ الگ اشیاء ہیں، تجریدات کلسٹر میں شامل کیے گئے ہیں، اس لیے وہ کنٹرول اور ترتیب دینے میں بہت زیادہ آسان ہیں۔

پروڈکٹ کو سمجھنے کے لیے، میں تجویز کرتا ہوں کہ پہلے باقاعدہ Prometheus انسٹال کریں۔ آپ کو کنفگریشن کے ذریعے ہر چیز کو ترتیب دینا پڑے گا، لیکن یہ فائدہ مند ہوگا: آپ کو پتہ چل جائے گا کہ کس چیز سے تعلق رکھتا ہے اور اسے کیسے ترتیب دیا گیا ہے۔ Prometheus آپریٹر میں، آپ فوری طور پر ایک تجرید کی بلندی پر پہنچ جاتے ہیں، حالانکہ اگر آپ چاہیں تو گہرائی میں بھی جا سکتے ہیں۔

Prometheus Kubernetes کے ساتھ اچھی طرح سے مربوط ہے: یہ API سرور تک رسائی اور تعامل کرسکتا ہے۔

Prometheus مقبول ہے، یہی وجہ ہے کہ ایپلی کیشنز اور پروگرامنگ زبانوں کی ایک بڑی تعداد اس کی حمایت کرتی ہے۔ سپورٹ کی ضرورت ہے، چونکہ Prometheus کا اپنا میٹرکس فارمیٹ ہے، اور اسے منتقل کرنے کے لیے، آپ کو ایپلی کیشن کے اندر لائبریری یا ریڈی میڈ ایکسپورٹر کی ضرورت ہے۔ اور ایسے برآمد کنندگان کی تعداد بہت کم ہے۔ مثال کے طور پر، PostgreSQL ایکسپورٹر ہے: یہ PostgreSQL سے ڈیٹا لیتا ہے اور اسے Prometheus فارمیٹ میں تبدیل کرتا ہے تاکہ Prometheus اس کے ساتھ کام کر سکے۔

پرومیتھیس فن تعمیر

پرومیتھیس سرور پچھلا سرا ہے، پرومیتھیس کا دماغ۔ میٹرکس کو یہاں ذخیرہ اور پروسیس کیا جاتا ہے۔

میٹرکس کو ٹائم سیریز ڈیٹا بیس (TSDB) میں محفوظ کیا جاتا ہے۔ TSDB کوئی الگ ڈیٹا بیس نہیں ہے، بلکہ گو زبان میں ایک پیکیج ہے جو Prometheus میں سرایت کرتا ہے۔ موٹے طور پر، سب کچھ ایک بائنری میں ہے.

TSDB میں ڈیٹا کو زیادہ دیر تک ذخیرہ نہ کریں۔

پرومیتھیس کا بنیادی ڈھانچہ میٹرکس کے طویل مدتی ذخیرہ کرنے کے لیے موزوں نہیں ہے۔ پہلے سے طے شدہ برقرار رکھنے کی مدت 15 دن ہے۔ آپ اس حد سے تجاوز کر سکتے ہیں، لیکن ذہن میں رکھیں: آپ TSDB میں جتنا زیادہ ڈیٹا اسٹور کریں گے اور جتنا زیادہ وقت آپ اسے کریں گے، اتنے ہی زیادہ وسائل استعمال ہوں گے۔ Prometheus میں تاریخی ڈیٹا کو ذخیرہ کرنا برا عمل سمجھا جاتا ہے۔

اگر آپ کے پاس بہت زیادہ ٹریفک ہے، میٹرکس کی تعداد سینکڑوں ہزار فی سیکنڈ ہے، تو بہتر ہے کہ ان کی اسٹوریج کو ڈسک کی جگہ یا مدت کے لحاظ سے محدود کیا جائے۔ عام طور پر، "ہاٹ ڈیٹا" کو صرف چند گھنٹوں میں TSDB، میٹرکس میں محفوظ کیا جاتا ہے۔ لمبے سٹوریج کے لیے، ان ڈیٹا بیسز میں ایکسٹرنل سٹوریج کا استعمال کیا جاتا ہے جو واقعی اس کے لیے موزوں ہیں، مثال کے طور پر، InfluxDB، ClickHouse وغیرہ۔ میں نے ClickHouse کے بارے میں مزید اچھے جائزے دیکھے۔

پرومیتھیس سرور ماڈل پر کام کرتا ہے۔ ھیںچو: وہ میٹرکس کے لیے ان اختتامی پوائنٹس پر جاتا ہے جو ہم نے اسے دیے تھے۔ انہوں نے کہا: "API سرور پر جائیں"، اور وہ ہر سیکنڈ میں وہاں جاتا ہے اور میٹرکس لیتا ہے۔

مختصر زندگی (نوکری یا کرون جاب) والی اشیاء کے لیے جو سکریپنگ ادوار کے درمیان ظاہر ہو سکتی ہیں، ایک پش گیٹ وے جزو ہے۔ قلیل مدتی اشیاء کے میٹرکس کو اس میں دھکیل دیا گیا ہے: کام بڑھ گیا ہے، ایک کارروائی کی گئی ہے، میٹرکس کو پش گیٹ وے پر بھیج دیا گیا ہے اور مکمل ہو گیا ہے۔ تھوڑی دیر بعد، Prometheus اپنی رفتار سے نیچے آئے گا اور Pushgateway سے یہ میٹرکس اٹھا لے گا۔

Prometheus میں اطلاعات کو ترتیب دینے کے لیے ایک الگ جزو ہے - الرٹ مینیجر. اور انتباہ کے قواعد۔ مثال کے طور پر، اگر سرور API 0 ہے تو آپ کو ایک الرٹ بنانے کی ضرورت ہے۔ ایونٹ کے فائر ہونے پر، الرٹ مزید ڈسپیچ کے لیے الرٹ مینیجر کو بھیج دیا جاتا ہے۔ الرٹ مینیجر کے پاس کافی لچکدار روٹنگ سیٹنگز ہیں: انتباہات کا ایک گروپ ایڈمنز کی ٹیلیگرام چیٹ، دوسرا ڈویلپرز کی چیٹ، اور تیسرا انفراسٹرکچر ورکرز کی چیٹ پر بھیجا جا سکتا ہے۔ اطلاعات سلیک، ٹیلی گرام، ای میل اور دیگر چینلز پر بھیجی جا سکتی ہیں۔

اور آخر میں، میں آپ کو Prometheus قاتل فیچر کے بارے میں بتاؤں گا - دریافت. Prometheus کے ساتھ کام کرتے وقت، آپ کو نگرانی کے لیے اشیاء کے مخصوص پتے بتانے کی ضرورت نہیں ہے، یہ ان کی قسم کا تعین کرنے کے لیے کافی ہے۔ یعنی، آپ کو "یہاں آئی پی ایڈریس ہے، یہاں پورٹ ہے - مانیٹر" لکھنے کی ضرورت نہیں ہے، اس کے بجائے، آپ کو یہ تعین کرنے کی ضرورت ہے کہ ان اشیاء کو تلاش کرنے کے لیے کن اصولوں کے مطابق (اہداف - مقاصد)۔ Prometheus خود، اس بات پر منحصر ہے کہ کون سی اشیاء فی الحال فعال ہیں، ضروری چیزوں کو کھینچتا ہے اور انہیں نگرانی میں شامل کرتا ہے۔

یہ نقطہ نظر کوبرنیٹس کے ڈھانچے کے ساتھ اچھی طرح فٹ بیٹھتا ہے، جہاں ہر چیز بھی تیرتی ہے: آج 10 سرورز ہیں، کل 3۔ ہر بار سرور کے IP ایڈریس کی وضاحت نہ کرنے کے لیے، انہوں نے ایک بار لکھا کہ اسے کیسے تلاش کیا جائے - اور Discovering یہ کرے گا۔ .

پرومیتھیس زبان کہلاتی ہے۔ پروم کیو ایل. اس زبان کا استعمال کرتے ہوئے، آپ مخصوص میٹرکس کی قدریں حاصل کر سکتے ہیں اور پھر انہیں تبدیل کر سکتے ہیں، ان کی بنیاد پر تجزیاتی حسابات تیار کر سکتے ہیں۔

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

Prometheus ویب انٹرفیس

Prometheus کا اپنا، کافی حد تک کم سے کم ویب انٹرفیس ہے۔ صرف ڈیبگ یا مظاہرے کے لیے موزوں ہے۔

ایکسپریشن لائن میں، آپ PromQL زبان میں ایک سوال لکھ سکتے ہیں۔

انتباہات کے ٹیب میں الرٹ کرنے کے اصول ہوتے ہیں، اور ان کی تین حیثیتیں ہیں:

1. غیر فعال - اگر الرٹ اس وقت فعال نہیں ہے، یعنی، اس کے ساتھ سب کچھ ٹھیک ہے، اور اس نے کام نہیں کیا؛
2. زیر التواء - یہ ہے اگر الرٹ کام کرتا ہے، لیکن بھیجنا ابھی تک نہیں گزرا ہے۔ تاخیر نیٹ ورک کے پلک جھپکنے کی تلافی کے لیے مقرر کی گئی ہے: اگر مخصوص سروس ایک منٹ کے اندر بڑھ گئی ہے، تو الارم ابھی نہیں بجانا چاہیے۔
3. فائرنگ تیسری حیثیت ہے جب الرٹ روشن ہوتا ہے اور پیغامات بھیجتا ہے۔

اسٹیٹس مینو میں آپ کو اس بارے میں معلومات تک رسائی ملے گی کہ Prometheus کیا ہے۔ اہداف (اہداف) کی منتقلی بھی ہے، جس کے بارے میں ہم نے اوپر بات کی ہے۔

Prometheus انٹرفیس کے مزید تفصیلی جائزہ کے لیے، دیکھیں کبرنیٹس کلسٹر کی نگرانی پر سلرم کے لیکچر میں.

گرافانا کے ساتھ انضمام

Prometheus ویب انٹرفیس میں، آپ کو خوبصورت اور قابل فہم گراف نہیں ملیں گے جن سے آپ کلسٹر کی حالت کے بارے میں کوئی نتیجہ اخذ کر سکیں۔ ان کی تعمیر کے لیے، Prometheus Grafana کے ساتھ مربوط ہے۔ ہمیں ایسے ڈیش بورڈ ملتے ہیں۔

Prometheus اور Grafana کے انضمام کو ترتیب دینا بالکل بھی مشکل نہیں ہے، آپ دستاویزات میں ہدایات تلاش کر سکتے ہیں: پرومیتھیئس کے لیے گرافانا کی حمایتٹھیک ہے، میں اس کے ساتھ ختم کروں گا.

مندرجہ ذیل مضامین میں، ہم نگرانی کے موضوع کو جاری رکھیں گے: ہم گرافانا لوکی اور متبادل ٹولز کا استعمال کرتے ہوئے نوشتہ جات کو جمع کرنے اور ان کا تجزیہ کرنے کے بارے میں بات کریں گے۔

مصنف: Marcel Ibraev، تصدیق شدہ Kubernetes ایڈمنسٹریٹر، کمپنی میں پریکٹس انجینئر ساؤتھ برج، اسپیکر اور کورس ڈویلپر سلرم۔

ماخذ: www.habr.com