گرافانا پلگ ان تیار کرنا: غلطیوں کی تاریخ

ہیلو سب! کچھ مہینے پہلے، ہم نے اپنا نیا اوپن سورس پروجیکٹ، Kubernetes مانیٹرنگ کے لیے ایک Grafana پلگ ان کو پروڈکشن میں شروع کیا۔ DevOpsProdigy KubeGrafپلگ ان سورس کوڈ دستیاب ہے۔ GitHub پر عوامی ذخیرہاس آرٹیکل میں، ہم آپ کے ساتھ اس کہانی کا اشتراک کرنا چاہیں گے کہ ہم نے پلگ ان کیسے بنایا، جو ٹولز ہم نے استعمال کیے، اور ترقی کے دوران ہمیں جو نقصانات کا سامنا کرنا پڑا۔ آئیے شروع کریں!

حصہ 0 - تعارف: ہم یہاں کیسے پہنچے؟

گرافانا کے لیے اپنا پلگ ان لکھنے کا خیال ہمیں اتفاق سے آیا۔ ہماری کمپنی 10 سالوں سے مختلف پیچیدگیوں کے ویب پروجیکٹس کی نگرانی کر رہی ہے۔ اس وقت کے دوران، ہم نے مختلف مانیٹرنگ سسٹمز کا استعمال کرتے ہوئے مہارت، دلچسپ کیس اسٹڈیز، اور تجربہ جمع کیا ہے۔ کسی وقت، ہم نے سوچا: "کیا کبرنیٹس کی نگرانی کے لیے کوئی جادوئی ٹول ہے جو آپ کر سکتے ہیں، جیسا کہ وہ کہتے ہیں، 'اسے سیٹ کریں اور بھول جائیں،'"؟ قدرتی طور پر، Prometheus + Grafana کومبو طویل عرصے سے K8S مانیٹرنگ کے لیے انڈسٹری کا معیار رہا ہے۔ اس اسٹیک کے لیے تیار شدہ ٹولز کی ایک وسیع رینج موجود ہے، بشمول prometheus-operator، kubernetes-mixin ڈیش بورڈ سویٹ، اور grafana-kubernetes-app۔

grafana-kubernetes-app پلگ ان ہمارے لیے سب سے دلچسپ آپشن لگتا تھا، لیکن اسے ایک سال سے زیادہ عرصے سے سپورٹ نہیں کیا گیا ہے اور مزید یہ کہ نوڈ-ایکسپورٹر اور kube-state-metrics کے نئے ورژن کے ساتھ کام نہیں کرتا ہے۔ کسی وقت، ہم نے فیصلہ کیا، "کیوں نہ اپنا حل خود بنائیں؟"

ہم نے اپنے پلگ ان میں کن خیالات کو نافذ کرنے کا فیصلہ کیا؟

• ایپلیکیشن میپ ویژولائزیشن: ایک کلسٹر میں ایپلی کیشنز کی ایک آسان نمائندگی، نام کی جگہوں، تعیناتیوں، وغیرہ کے لحاظ سے گروپ کردہ؛
• "تعیناتی - سروس (+ پورٹس)" قسم کے کنکشن کا تصور۔
• کلسٹر نوڈس میں کلسٹر ایپلی کیشنز کی تقسیم کا تصور۔
• متعدد ذرائع سے میٹرکس اور معلومات جمع کرنا: Prometheus اور k8s api سرور۔
• دونوں بنیادی ڈھانچے کی نگرانی (سی پی یو ٹائم، میموری، ڈسک سب سسٹم، نیٹ ورک کا استعمال) اور ایپلیکیشن لاجک - پوڈز کی صحت کی حیثیت، دستیاب نقلوں کی تعداد، اور جاندار/تیاری ٹیسٹ کی پیشرفت کے بارے میں معلومات۔

حصہ 1: گرافانا پلگ ان کیا ہے؟

تکنیکی نقطہ نظر سے، گرافانا کے لیے ایک پلگ ان ایک کونیی کنٹرولر ہے جو گرافانا کی ڈیٹا ڈائرکٹری میں محفوظ ہوتا ہے (/var/grafana/plugins/ /dist/module.js) اور سسٹم جے ایس ماڈیول کے طور پر لوڈ کیا جا سکتا ہے۔ اس ڈائرکٹری میں ایک plugin.json فائل بھی ہونی چاہیے، جس میں آپ کے پلگ ان کے بارے میں تمام میٹا ڈیٹا شامل ہیں: نام، ورژن، پلگ ان کی قسم، ریپوزٹری/ویب سائٹ/لائسنس لنکس، انحصار، وغیرہ۔

module.ts

plugin.json

جیسا کہ آپ اسکرین شاٹ میں دیکھ سکتے ہیں، ہم نے plugin.type = app کی وضاحت کی ہے۔ اس کی وجہ یہ ہے کہ گرافانا کے لیے تین قسم کے پلگ ان ہیں:

پینل: پلگ ان کی سب سے عام قسم - یہ مخصوص میٹرکس کو دیکھنے کے لیے ایک پینل ہے اور مختلف ڈیش بورڈ بنانے کے لیے استعمال ہوتا ہے۔
ڈیٹا کا ذریعہ: کسی بھی ڈیٹا سورس سے ایک پلگ ان کنیکٹر (مثال کے طور پر، Prometheus-datasource، ClickHouse-datasource، ElasticSearch-datasource)۔
اپلی کیشن: ایک پلگ ان جو آپ کو گرافانا کے اندر اپنی فرنٹ اینڈ ایپلیکیشن بنانے، اپنے HTML صفحات بنانے، اور مختلف ڈیٹا کو دیکھنے کے لیے دستی طور پر ڈیٹا سورس تک رسائی کی اجازت دیتا ہے۔ دیگر پلگ ان اقسام (ڈیٹا سورس، پینل) اور مختلف ڈیش بورڈز کو بھی انحصار کے طور پر استعمال کیا جا سکتا ہے۔

قسم = ایپ کے ساتھ پلگ ان انحصار کی مثال.

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

حصہ 2: مقامی ماحول کی تیاری

پلگ ان پر کام کرنے کے لیے، ہمیں قدرتی طور پر ایک Kubernetes کلسٹر کی ضرورت ہوگی جس میں پہلے سے نصب تمام ٹولز ہوں گے: prometheus، node-exporter، kube-state-metrics، اور grafana۔ ماحول کو ترتیب دینے کے لیے تیز، آسان، اور پریشانی سے پاک ہونا چاہیے، اور گرم ری لوڈنگ کو یقینی بنانے کے لیے، گرافانا ڈیٹا ڈائرکٹری کو ڈیولپر کی مشین سے براہ راست نصب کیا جانا چاہیے۔

ہماری رائے میں، Kubernetes کے ساتھ مقامی طور پر کام کرنے کا سب سے آسان طریقہ ہے۔ منی کیوباگلا مرحلہ prometheus-operator کا استعمال کرتے ہوئے Prometheus + Grafana بنڈل کو انسٹال کرنا ہے۔ اس مضمون minikube پر prometheus-operator کی تنصیب کا عمل تفصیل سے بیان کیا گیا ہے۔ استقامت کو فعال کرنے کے لیے، آپ کو پیرامیٹر سیٹ کرنے کی ضرورت ہے۔ persistence : سچا ۔ charts/grafana/values.yaml فائل میں، اپنا PV اور PVC شامل کریں اور persistence.existingClaim پیرامیٹر میں ان کی وضاحت کریں۔

ہماری آخری منی کیوب لانچ اسکرپٹ اس طرح دکھتی ہے:

minikube start --kubernetes-version=v1.13.4 --memory=4096 --bootstrapper=kubeadm --extra-config=scheduler.address=0.0.0.0 --extra-config=controller-manager.address=0.0.0.0
minikube mount 
/home/sergeisporyshev/Projects/Grafana:/var/grafana --gid=472 --uid=472 --9p-version=9p2000.L

حصہ 3: براہ راست ترقی

آبجیکٹ ماڈل

پلگ ان کے نفاذ کی تیاری میں، ہم نے ان تمام بنیادی Kubernetes اداروں کی وضاحت کرنے کا فیصلہ کیا ہے جن کے ساتھ ہم TypeScript کلاسز کے طور پر کام کریں گے: پوڈ، تعیناتی، ڈیمون سیٹ، اسٹیٹ فل سیٹ، جاب، کرون جاب، سروس، نوڈ، اور نام کی جگہ۔ ان کلاسوں میں سے ہر ایک عام بیس ماڈل کلاس سے وراثت میں ملتی ہے، جو کنسٹرکٹر، ڈسٹرکٹر، اور مرئیت کو اپ ڈیٹ کرنے اور ٹوگل کرنے کے طریقوں کی وضاحت کرتی ہے۔ ہر کلاس دیگر اداروں کے ساتھ نیسٹڈ تعلقات کی بھی وضاحت کرتی ہے، جیسے کہ تعیناتی ہستی کے لیے پوڈز کی فہرست۔

import {Pod} from "./pod";
import {Service} from "./service";
import {BaseModel} from './traits/baseModel';

export class Deployment extends BaseModel{
   pods: Array<Pod>;
   services: Array<Service>;

   constructor(data: any){
       super(data);
       this.pods = [];
       this.services = [];
   }
}

گیٹرز اور سیٹرز کا استعمال کرتے ہوئے، ہم ایک آسان اور پڑھنے کے قابل فارمیٹ میں مطلوبہ ہستی میٹرکس ڈسپلے یا سیٹ کر سکتے ہیں۔ مثال کے طور پر، مختص CPU نوڈس کی فارمیٹ شدہ آؤٹ پٹ:

get cpuAllocatableFormatted(){
   let cpu = this.data.status.allocatable.cpu;
   if(cpu.indexOf('m') > -1){
       cpu = parseInt(cpu)/1000;
   }
   return cpu;
}

صفحات

ہمارے پلگ ان کے تمام صفحات کی فہرست ابتدائی طور پر انحصار والے حصے میں ہمارے pluing.json میں بیان کی گئی ہے۔

ہر صفحے کے بلاک میں، ہمیں صفحہ کا نام بتانا ضروری ہے (اس کے بعد یہ ایک سلگ میں تبدیل ہو جائے گا جس کے ذریعے یہ صفحہ قابل رسائی ہو گا)؛ اس صفحہ کے کام کے لیے ذمہ دار اجزاء کا نام (اجزاء کی فہرست module.ts پر برآمد کی جاتی ہے)؛ صارف کے کردار کا اشارہ جس کے لیے اس صفحہ کے ساتھ کام دستیاب ہے اور سائڈبار کے لیے نیویگیشن کی ترتیبات۔

صفحہ کے آپریشن کے ذمہ دار جزو میں، ہمیں ٹیمپلیٹ یو آر ایل کو سیٹ کرنا ہوگا، اسے مارک اپ پر مشتمل ایچ ٹی ایم ایل فائل کا راستہ دینا ہوگا۔ کنٹرولر کے اندر، انحصار انجکشن کے ذریعے، ہم دو اہم کونیی خدمات تک رسائی حاصل کر سکتے ہیں:

• backendSrv ایک سروس ہے جو Grafana API سرور کے ساتھ تعامل فراہم کرتی ہے۔
• datasourceSrv ایک ایسی خدمت ہے جو آپ کے Grafana میں نصب تمام ڈیٹا سورسز کے ساتھ مقامی تعامل فراہم کرتی ہے (مثال کے طور پر، .getAll() طریقہ تمام انسٹال کردہ ڈیٹا سورسز کی فہرست لوٹاتا ہے؛ .get( ) — کسی مخصوص ڈیٹا سورس کی مثال آبجیکٹ واپس کرتا ہے۔

حصہ 4: ڈیٹا سورس

گرافانا کے نقطہ نظر سے، ڈیٹا سورس کسی دوسرے کی طرح ایک پلگ ان ہے: اس کا اپنا انٹری پوائنٹ، module.js، اور میٹا ڈیٹا کے ساتھ ایک plugin.json فائل ہے۔ ٹائپ = ایپ کے ساتھ پلگ ان تیار کرتے وقت، ہم موجودہ ڈیٹا سورسز (مثال کے طور پر، prometheus-datasource) یا اپنے اپنے کے ساتھ تعامل کرسکتے ہیں، جسے ہم براہ راست پلگ ان ڈائرکٹری (dist/datasource/*) میں اسٹور کرسکتے ہیں یا انحصار کے طور پر انسٹال کرسکتے ہیں۔ ہمارے معاملے میں، ڈیٹا سورس پلگ ان کوڈ کے ساتھ بنڈل ہے۔ ایک config.html ٹیمپلیٹ اور ایک ConfigCtrl کنٹرولر بھی درکار ہے، جو ڈیٹا سورس مثال کے کنفیگریشن پیج اور ڈیٹا سورس کنٹرولر کے لیے استعمال کیا جائے گا، جو آپ کے ڈیٹا سورس کے لیے منطق کو لاگو کرتا ہے۔

KubeGraf پلگ ان میں، صارف کے انٹرفیس کے نقطہ نظر سے، ڈیٹا سورس ایک Kubernetes کلسٹر کی ایک مثال ہے جو درج ذیل صلاحیتوں کو نافذ کرتا ہے (ماخذ کوڈ دستیاب ہے ссылке по):

• k8s api سرور سے ڈیٹا حاصل کرنا (نام کی جگہوں، تعیناتیوں وغیرہ کی فہرست حاصل کرنا)
• prometheus-datasource (جو ہر مخصوص کلسٹر کے لیے پلگ ان کی ترتیبات میں منتخب کیا جاتا ہے) سے درخواستوں کو پراکسی کرنا اور جامد صفحات اور ڈیش بورڈز دونوں میں ڈیٹا استعمال کرنے کے لیے جوابات کو فارمیٹنگ کرنا۔
• پلگ ان کے جامد صفحات پر ڈیٹا کو اپ ڈیٹ کرنا (ایک سیٹ ریفریش ریٹ کے ساتھ)۔
• گرافانا ڈیش بورڈز میں ٹیمپلیٹ شیٹ بنانے کے لیے سوالات پر کارروائی کرنا (طریقہ .metriFindQuery())

• حتمی k8s کلسٹر کے ساتھ کنکشن ٹیسٹ۔

testDatasource(){
   let url = '/api/v1/namespaces';
   let _url = this.url;
   if(this.accessViaToken)
       _url += '/__proxy';
   _url += url;
   return this.backendSrv.datasourceRequest({
       url: _url,
       method: "GET",
       headers: {"Content-Type": 'application/json'}
   })
       .then(response => {
           if (response.status === 200) {
               return {status: "success", message: "Data source is OK", title: "Success"};
           }else{
               return {status: "error", message: "Data source is not OK", title: "Error"};
           }
       }, error => {
           return {status: "error", message: "Data source is not OK", title: "Error"};
       })
}

ایک خاص طور پر دلچسپ پہلو، ہماری رائے میں، ڈیٹا سورس کے لیے تصدیق اور اجازت کے طریقہ کار کا نفاذ ہے۔ عام طور پر، آؤٹ آف دی باکس، ہم آخری ڈیٹا سورس تک رسائی کو کنفیگر کرنے کے لیے گرافانا کے بلٹ ان ڈیٹا سورسHttpSettings کو استعمال کر سکتے ہیں۔ اس جزو کے ساتھ، ہم URL اور بنیادی تصدیق/تصدیق کی ترتیبات: لاگ ان/پاس ورڈ، یا کلائنٹ-سرٹ/کلائنٹ-کی کی وضاحت کرکے HTTP ڈیٹا سورس تک رسائی کو ترتیب دے سکتے ہیں۔ بیئرر ٹوکن (k8s کے لیے ڈی فیکٹو اسٹینڈرڈ) کا استعمال کرتے ہوئے رسائی کو ترتیب دینے کی صلاحیت کو نافذ کرنے کے لیے کچھ ٹنکرنگ کی ضرورت ہے۔

اس مسئلے کو حل کرنے کے لیے، آپ گرافانا کا بلٹ ان "پلگ ان روٹس" میکانزم استعمال کر سکتے ہیں (مزید تفصیلات پر سرکاری دستاویزات کا صفحہ)۔ ہماری ڈیٹا سورس کی ترتیبات میں، ہم روٹنگ کے قواعد کے ایک سیٹ کا اعلان کر سکتے ہیں جن پر گرافانا پراکسی سرور کے ذریعے کارروائی کی جائے گی۔ مثال کے طور پر، ہر انفرادی اختتامی نقطہ کے لیے، ٹیمپلیٹ سپورٹ کے ساتھ ہیڈر یا یو آر ایل سیٹ کرنے کا اختیار موجود ہے، جس کے لیے ڈیٹا jsonData اور safeJsonData فیلڈز سے لیا جا سکتا ہے (پاس ورڈز یا ٹوکنز کو خفیہ کردہ شکل میں ذخیرہ کرنے کے لیے)۔ ہماری مثال میں، فارم کی درخواستیں۔ /__proxy/api/v1/namespaces مندرجہ ذیل قسم کے یو آر ایل سے پراکسی کیا جائے گا۔
اجازت کے ساتھ /api/v1/namespaces: بیئرر ہیڈر سیٹ۔

قدرتی طور پر، k8s api سرور کے ساتھ کام کرنے کے لیے، ہمیں صرف پڑھنے کے لیے رسائی کے ساتھ ایک صارف کی ضرورت ہے، جو بنانے کے لیے ظاہر ہے جسے آپ اس میں بھی تلاش کر سکتے ہیں۔ پلگ ان سورس کوڈ.

حصہ 5: رہائی

ایک بار جب آپ اپنا گرافانا پلگ ان لکھ لیتے ہیں، تو آپ قدرتی طور پر اسے اوپن سورس بنانا چاہیں گے۔ گرافانا میں، یہ ایک پلگ ان لائبریری ہے، پر دستیاب ہے۔ grafana.com/grafana/plugins

آپ کا پلگ ان آفیشل اسٹور میں دستیاب ہونے کے لیے، آپ کو PR بنانے کی ضرورت ہے۔ یہ ذخیرہ، repo.json فائل میں اس طرح کا مواد شامل کرنا:

جہاں ورژن آپ کے پلگ ان کا ورژن ہے، یو آر ایل ریپوزٹری کا لنک ہے، اور کمٹ کمٹ کا ہیش ہے جو پلگ ان کا مخصوص ورژن دستیاب کرائے گا۔

اور آؤٹ پٹ پر آپ کو اس طرح کی ایک شاندار تصویر نظر آئے گی:

اس کا ڈیٹا خود بخود آپ کے Readme.md، Changelog.md، اور پلگ ان کی تفصیل کے ساتھ plugin.json فائل سے حاصل کر لیا جائے گا۔

حصہ 6: نتائج کے بجائے

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

ہم امید کرتے ہیں کہ یہ مضمون آپ کو گرافانا جیسے شاندار ٹول کو سمجھنے میں مدد کرے گا اور، شاید، اپنا پلگ ان لکھیں۔

آپ کا شکریہ!)

ماخذ: www.habr.com