اوپن ٹیلی میٹری کیسے کام کرتی ہے: ایک مکمل گائیڈ

اگر آپ سافٹ ویئر ڈویلپر یا DevOps انجینئر ہیں، تو آپ شاید OpenTelemetry میں آئے ہوں گے۔ یہ خاص طور پر اس وقت بہت زیادہ سامنے آتا ہے جب مشاہدے، نگرانی، یا تقسیم شدہ نظاموں کو ڈیبگ کرنے کے بارے میں بات کی جاتی ہے۔

آپ کو بنیادی تعریف معلوم ہو سکتی ہے، لیکن یہ جاننا کہ OpenTelemetry کیا ہے اور یہ جاننا کہ یہ اصل میں کیسے کام کرتی ہے دو مختلف چیزیں ہیں۔

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

اگر آپ OpenTelemetry میں بالکل نئے ہیں، تو پریشان نہ ہوں۔ اس سے پہلے کہ ہم مزید آگے بڑھیں، آئیے اگلے حصے میں ان پر ایک سرسری نظر ڈالتے ہیں۔

انڈیکس

OpenTelemetry کیا ہے؟

OpenTelemetry ایک وینڈر غیر جانبدار، اوپن سورس مشاہداتی فریم ورک ہے۔ یہ آپ کی ایپلیکیشن کے لیے ایک معیاری طریقہ فراہم کرتا ہے، ٹیلی میٹری ڈیٹا تیار کرتا ہے، اور اس ڈیٹا کو آپ کے منتخب کردہ مشاہداتی پس منظر میں برآمد کرتا ہے۔

OpenTelemetry سے پہلے، ہر مانیٹرنگ ٹول کا اپنا ڈیٹا اکٹھا کرنے کا طریقہ تھا۔ اگر آپ Datadog استعمال کرتے ہیں، تو آپ کو اپنی ایپ کو Datadog کے طریقے سے آلہ بنانے کی ضرورت ہے۔ اگر آپ Jaeger پر سوئچ کرتے ہیں تو آپ کو دوبارہ شروع کرنے کی ضرورت ہوگی۔ OpenTelemetry آپ کی ایپلی کیشنز کو انسٹرومنٹ کرنے کا ایک معیاری طریقہ فراہم کرکے اس کو تبدیل کرتا ہے، قطع نظر اس کے کہ آپ بیک اینڈ استعمال کرتے ہیں۔

[!NOTE] OpenTelemetry کوئی مانیٹرنگ پلیٹ فارم، ڈیش بورڈ، یا ڈیٹا اسٹور نہیں ہے۔ یہ ٹیلی میٹری کو ایک مشاہداتی پس منظر میں جمع کرنے اور برآمد کرنے کے لیے ٹولز اور معیارات فراہم کرتا ہے جہاں ایپلیکیشنز ڈیٹا کو ذخیرہ، استفسار اور تجزیہ کر سکتی ہیں۔

اوپن ٹیلی میٹری جو ڈیٹا اکٹھا کرتی ہے اسے ٹیلی میٹری کہتے ہیں۔ یہ وہ معلومات ہے جو ایپلیکیشن اپنے آپ کو تیار کرتی ہے جب یہ چلتی ہے، اور تین شکلوں میں آتی ہے:

• ثبوت یہ آپ کو بتاتا ہے کہ درخواست سسٹم کے ذریعے کیسے منتقل ہوئی۔

• میٹرکس یہ نمبر فراہم کرتا ہے جیسے کہ ایپ فی سیکنڈ کتنی درخواستوں پر کارروائی کر رہی ہے یا کتنی میموری استعمال کر رہی ہے۔

• لاگ کسی ایپلیکیشن کے اندر پیش آنے والے مخصوص ایونٹ کا ٹائم اسٹیمپڈ ریکارڈ۔

اوپن ٹیلی میٹری کیسے کام کرتی ہے۔

جب کوئی درخواست آپ کی درخواست تک پہنچتی ہے، تو پردے کے پیچھے بہت کچھ ہوتا ہے۔ OpenTelemetry کا مشن تمام سرگرمی (ٹریس، میٹرکس، اور لاگز) کو پکڑنا اور اسے صحیح جگہ پر بھیجنا ہے۔

یہ اس کی طرح دکھتا ہے:

ہر قدم کے مخصوص کام ہوتے ہیں۔ آئیے ایک ایک کرکے ان کو دیکھتے ہیں۔

مرحلہ 1: اپنی درخواست کو تیار کریں۔

کسی بھی چیز کو حاصل کرنے کے لیے OpenTelemetry کے لیے، آپ کو پہلے اپنی درخواست کا آلہ بنانا چاہیے۔ انسٹرومینٹیشن صرف کوڈ شامل کرنے کا عمل ہے جو OpenTelemetry کو بتاتا ہے کہ کیا دیکھنا ہے اور کیا لاگ کرنا ہے۔

آپ کی درخواست کو تیار کرنے کے دو طریقے ہیں: خودکار طور پر یا دستی طور پر۔

1. خودکار پیمائش

یہ شروع کرنے کے لیے سب سے آسان ہے۔ اپنے موجودہ کوڈ کو تبدیل کیے بغیر اپنے پروجیکٹ میں لائبریری شامل کرنے سے آپ کی ایپلیکیشن مکمل ہوجاتی ہے۔

مثال کے طور پر، اگر آپ Node.js ایکسپریس ایپ چلا رہے ہیں، تو OpenTelemetry آٹو انسٹرومینٹیشن پیکج شامل کریں اور یہ خود بخود آنے والی HTTP درخواستوں، آؤٹ گوئنگ کالز، ڈیٹا بیس کے سوالات اور مزید کیپچر کرنا شروع کر دے گا۔

متعلقہ ترتیبات مندرجہ ذیل ہیں:

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');

const sdk = new NodeSDK({
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

اگر یہ ایپ شروع ہونے سے پہلے چلائی جاتی ہے، تو OpenTelemetry خود بخود ٹیلی میٹری کیپچر کرنا شروع کر دے گی۔ مکمل سیٹ اپ گائیڈ کے لیے، Node.js میں OpenTelemetry کے ساتھ شروعات کرنا دیکھیں۔

2. دستی پیمائش

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

یہاں ایک سادہ سی مثال ہے: ہم کہتے ہیں کہ ہمارے پاس ایک فنکشن ہے جو آرڈر پر کارروائی کرتا ہے۔

function processOrder(orderId) {
  // processing logic
}

دستی آلات کے ساتھ، ہم اسے اس طرح لپیٹتے ہیں:

const { trace } = require('@opentelemetry/api');

const tracer = trace.getTracer('order-service');

function processOrder(orderId) {
  return tracer.startActiveSpan('processOrder', (span) => {
    // processing logic

    span.end();
  });
}

اگر کچھ ہوتا ہے تو، آپ نے ایک دائرہ کار بنایا ہے۔ دائرہ کار اب درج ذیل معاملات کو ریکارڈ کرتا ہے: processOrder آپ آغاز، اختتامی وقت، دورانیہ وغیرہ کو چیک کر سکتے ہیں۔ مرحلہ 3 میں دائرہ کار کے بارے میں مزید جانیں۔

مکمل دستی آلات کے حوالے کے لیے، OpenTelemetry JavaScript Instrumentation دیکھیں۔

مرحلہ 2: OpenTelemetry ایک ٹیلی میٹری سگنل تیار کرتا ہے۔

ایک بار جب آپ کی ایپلیکیشن تیار ہو جاتی ہے، تو OpenTelemetry ٹیلی میٹری ڈیٹا بنانا شروع کر دیتا ہے کہ آپ کی ایپلی کیشن کیا کر رہی ہے۔ یہ ڈیٹا تین شکلوں میں آتا ہے، جسے سگنل کہتے ہیں۔ اس کے لیے نشانات، میٹرکس اور نوشتہ جات ہیں، جن کا میں پہلے ہی خاکہ دے چکا ہوں۔ ہر سگنل مختلف قسم کے مشاہداتی سوال کا جواب دیتا ہے۔

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

یہاں ایک فوری موازنہ ہے:

سگنل	میں آپ کو کیا دکھاؤں؟	ہاں	آپ کے سوالات کے جوابات
ٹریک	سسٹم کے ذریعے درخواست کا سفر	ادائیگی کی درخواستیں APIs، آرڈرنگ سروسز اور ڈیٹا بیس سے گزر رہی ہیں۔	یہ درخواست سست کیوں ہے؟ آپ کہاں ناکام ہوئے؟
میٹرک نظام	وقت کے ساتھ پیمائش	200 درخواستیں فی سیکنڈ، اوسط جوابی وقت 95ms	کیا میری درخواست اب ٹھیک ہے؟
لاگ	مخصوص واقعات کا ریکارڈ	ERROR: payment failed for order #1234	اس مقام پر بالکل کیا ہوا؟

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

مرحلہ 3: اپنی درخواست کے ذریعے ٹریکنگ کی درخواست کریں۔

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

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

ہر ٹریس کی ایک منفرد ٹریس ID ہوتی ہے اور ہر اسکوپ کی اپنی اسکوپ ID ہوتی ہے۔ ٹریکنگ ID وہ ہے جو تمام دائروں کو آپس میں جوڑتی ہے۔ اس بات سے کوئی فرق نہیں پڑتا ہے کہ درخواست کتنی ہی سروسز سے گزرتی ہے، وہ سب ایک ہی ٹریکنگ ID کا اشتراک کرتے ہیں، جس سے مشاہدے کے پس منظر کو شروع سے آخر تک درخواست کی پیروی کرنے کی اجازت ملتی ہے۔

یہاں ایک سادہ مثال ہے: جب کوئی صارف آرڈر دیتا ہے، تو درخواست چار سروسز سے گزرتی ہے:

ہر رینج کا آغاز اور اختتامی وقت ہوتا ہے، لہذا آپ دیکھ سکتے ہیں کہ ہر کام میں کتنا وقت لگتا ہے۔ اگر کوئی چیز سست ہو جاتی ہے یا ناکام ہو جاتی ہے، تو آپ صرف دائرہ کار کو دیکھ کر اس بات کی نشاندہی کر سکتے ہیں کہ یہ کہاں ہوا ہے۔

مرحلہ 4: سیاق و سباق کی تشہیر کے ذریعے تمام خدمات کو جوڑیں۔

مرحلہ 3 میں، ہم نے دیکھا کہ کس طرح ایک ہی ٹریس متعدد خدمات کو پھیلا سکتا ہے۔ لیکن ایک سوال ہے جو پوچھنا ضروری ہے۔ OpenTelemetry کو کیسے معلوم ہوگا کہ آیا ادائیگی کی خدمت کا دائرہ کار آرڈرنگ سروس کے دائرہ کار کی طرح ہی ٹریکنگ کے تحت آتا ہے؟

اگر کچھ نہیں جوڑتا ہے تو، ہر سروس اپنے دائرہ کار کو آزادانہ طور پر ریکارڈ کرتی ہے۔ API گیٹ وے ایک کارروائی دیکھے گا، آرڈرنگ سروس کو دوسری کارروائی نظر آئے گی، اور ادائیگی کی خدمت کو تیسری کارروائی نظر آئے گی۔ خدمات کے درمیان ڈیبگ کرنا تقریباً ناممکن ہے کیونکہ وہ مکمل طور پر الگ الگ درخواستیں دکھائی دیتی ہیں جن کا ایک دوسرے سے کوئی تعلق نہیں ہے۔

یہیں سے سیاق و سباق کی تبلیغ شروع ہوتی ہے۔ جب کوئی درخواست ایک سروس سے دوسری سروس میں منتقل ہوتی ہے، تو OpenTelemetry اس سروس سے ایک ٹریکنگ سیاق و سباق (عام طور پر ایک HTTP ہیڈر) منسلک کرتا ہے۔ اس سیاق و سباق میں ٹریس ID اور پیرنٹ اسکوپ ID ہوتا ہے لہذا درخواست کو سنبھالنے والی کوئی بھی سروس جانتی ہے کہ اس ٹریس کا تعلق کس ٹریس سے ہے اور یہ کہاں کا ہے۔

حقیقت میں یہ ہے:

تینوں سروسز ایک ہی ٹریکنگ آئی ڈی کا اشتراک کرتی ہیں۔ یہ وہی ہے جو مشاہداتی پس منظر کو متعدد اسکوپس کو ایک مکمل ٹریس میں جوڑنے کی اجازت دیتا ہے۔

OpenTelemetry اس کے لیے اپنے اصول نہیں بناتی ہے۔ یہ W3C ٹریس سیاق و سباق کے معیار کی پیروی کرتا ہے، ایک وسیع پیمانے پر اپنایا گیا تصریح جو اس بات کی وضاحت کرتی ہے کہ ٹریس سیاق و سباق کو کس طرح فارمیٹ کیا جاتا ہے اور سروسز کے درمیان منتقل کیا جاتا ہے، اس لیے وہ مختلف زبانوں، فریم ورکس، اور وینڈرز میں مستقل طور پر کام کرتے ہیں۔

اچھی خبر یہ ہے کہ اگر آپ خودکار آلات استعمال کرتے ہیں تو سیاق و سباق کی تبلیغ خود بخود ہو جاتی ہے۔ OpenTelemetry ہیڈرز کو خود بخود ہینڈل کرتا ہے، لہذا آپ کو ان کے بارے میں سوچنے کی ضرورت نہیں ہے جب تک کہ آپ اپنی مرضی کے مطابق ٹرانسپورٹ یا غیر معیاری سیٹ اپ کے ساتھ کام نہیں کر رہے ہیں۔

مرحلہ 5: OpenTelemetry SDK ٹیلی میٹری کو ہینڈل کرتا ہے۔

اس مقام پر، OpenTelemetry ٹیلی میٹری کو پکڑتا ہے اور پوری سروس میں منسلک ٹریکنگ کو برقرار رکھتا ہے۔ تاہم، اسکوپ کے بننے اور ایپلیکیشن چھوڑنے کے لمحے کے درمیان کسی چیز کو اسے سنبھالنے کی ضرورت ہے۔ یہ وہی ہے جو SDK کرتا ہے۔

جب انسٹرومینٹڈ کوڈ اسکوپس بناتا ہے، تو یہ OpenTelemetry API کے ذریعے ایسا کرتا ہے۔ APIs وہ ہیں جن کے ساتھ آپ بطور ڈویلپر تعامل کرتے ہیں۔ trace.getTracer() اور tracer.startActiveSpan(). لیکن اکیلے API کسی بھی چیز پر کارروائی نہیں کرتا یا بھیجتا ہے۔ اصل میں کچھ کرنے کے لیے آپ کو اس کے پیچھے SDK کی ضرورت ہوگی۔

جب SDK ٹیلی میٹری وصول کرتا ہے، تو یہ اسے پروسیسر کے ذریعے چلاتا ہے۔ پروسیسر باہر بھیجنے سے پہلے اسپین کو ایک ساتھ بیچنے، اضافی خصوصیات شامل کرنے، غیر ضروری ڈیٹا کو فلٹر کرنے وغیرہ کے لیے ذمہ دار ہے۔ BatchSpanProcessorایک وقت میں ایک کے بجائے بیچوں میں گروپ بندی اور برآمد کرکے پیداواری کارکردگی میں اضافہ کریں۔

پروسیسر کے چلنے سے پہلے SDK نمونے لینے کو بھی سنبھالتا ہے۔ نمونے لینے سے آپ یہ کنٹرول کر سکتے ہیں کہ آپ واقعی کتنی ٹیلی میٹری جمع کرتے ہیں۔ ہائی ٹریفک ایپلیکیشن میں ہر ایک رینج کو ریکارڈ کرنے سے ڈیٹا کی ایک بڑی مقدار پیدا ہوتی ہے۔ سیمپلنگ آپ کو SDK کو ٹریس کے صرف ایک حصے پر قبضہ کرنے کی ہدایت کرنے کی اجازت دیتا ہے، جس سے آپ مرئیت کو کھوئے بغیر لاگت اور ڈیٹا والیوم کا نظم کر سکتے ہیں۔

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

مرحلہ 6: برآمد کنندہ ٹیلی میٹری ڈیٹا بھیجتا ہے۔

برآمد کرنا آسان ہے۔ SDK کے ذریعے تیار کردہ ٹیلی میٹری لیتا ہے اور اسے آپ کی ترتیب کردہ منزل پر بھیجتا ہے۔

OpenTelemetry OTLP، OpenTelemetry پروٹوکول کا استعمال کرتے ہوئے ٹیلی میٹری ڈیٹا منتقل کرتا ہے۔ یہ ایک معیاری وائرڈ پروٹوکول ہے جو خاص طور پر ٹریس، میٹرکس، اور لاگز کی منتقلی کے لیے ڈیزائن کیا گیا ہے اور HTTP یا gRPC پر چلتا ہے۔

[!NOTE] OTLP اور OpenTelemetry ایک ہی چیز نہیں ہیں۔ OpenTelemetry ایک مکمل فریم ورک ہے جس میں آلات سازی، SDK، جمع کرنے والے، اور بہت کچھ شامل ہے۔ OTLP صرف ایک پروٹوکول ہے جو ڈیٹا منتقل کرنے کے لیے استعمال ہوتا ہے۔

OTLP پہلے سے طے شدہ ہے، لیکن تمام برآمد کنندگان اسے استعمال نہیں کرتے ہیں۔ کچھ برآمد کنندگان اپنے فارمیٹ میں براہ راست ایک مخصوص بیک اینڈ پر ڈیٹا بھیجتے ہیں، جیسے جیگر یا پرومیتھیس۔ لہذا، آپ کے سیٹ اپ پر منحصر ہے، آپ کلکٹر یا بیک اینڈ کو ڈیٹا بھیجنے کے لیے OTLP ایکسپورٹ کا استعمال کر سکتے ہیں، یا آپ اسے براہ راست بھیجنے کے لیے وینڈر کے لیے مخصوص ایکسپورٹ کا استعمال کر سکتے ہیں۔”

مرحلہ 7: OpenTelemetry کلکٹر ڈیٹا وصول کرتا ہے اور اس پر کارروائی کرتا ہے۔

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

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

کلکٹر کے تین مراحل ہوتے ہیں:

• وصول کرنے والا سیٹ ایپلی کیشنز سے آنے والی ٹیلی میٹری کی اجازت دیتا ہے، عام طور پر OTLP کے ذریعے۔

• پروسیسر جمع کرنے والے کی سطح پر ڈیٹا کو تبدیل کریں، بشمول بیچنگ رینج، فلٹرنگ شور، اور فارورڈ کرنے سے پہلے پراپرٹیز شامل کرنا۔

• برآمد کنندہ پروسیس شدہ ڈیٹا کو بیک اینڈ پر بھیجیں، یا اگر ضروری ہو تو متعدد بیک اینڈز کو بھیجیں۔

کلیکٹر کی کم از کم ترتیب یہ ہے:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:

exporters:
  otlphttp:
    endpoint: https://your-backend.com

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]

یہ کنفیگریشن gRPC کے ذریعے نشانات کو قبول کرتی ہے، انہیں کارکردگی کے لیے بیچ دیتی ہے، اور HTTP کے ذریعے مشاہدے کے پس منظر پر بھیجتی ہے۔

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

مکمل کنفیگریشن کے لیے، OpenTelemetry کلکٹر کنفیگریشن دستاویز دیکھیں۔

مرحلہ 8: آبزرویبلٹی بیک اینڈ ٹیلی میٹری کو اسٹور اور تجزیہ کرتا ہے۔

یہیں سے OpenTelemetry کا کام ختم ہوتا ہے۔ ایک بار جب ٹیلی میٹری کلکٹر سے نکل جاتی ہے، تو یہ آبزرویبلٹی بیک اینڈ پر پہنچ جاتی ہے۔

بیک اینڈ ڈیٹا کو اسٹور کرتا ہے، آپ کو اس سے استفسار کرنے کی اجازت دیتا ہے، اور ڈیش بورڈز اور انتباہات فراہم کرتا ہے جن کے ساتھ آپ روزانہ کی بنیاد پر بات چیت کرتے ہیں۔ OpenTelemetry اس میں سے کوئی پیش نہیں کرتا ہے۔ آپ کو وہاں سے ڈیٹا ملتا ہے اور بیک اینڈ باقی کام کرتا ہے۔

کچھ مشہور بیک اینڈ جو مقامی طور پر OpenTelemetry کی حمایت کرتے ہیں:

• اوپن سورس: جیگر، پرومیتھیس، گرافانا ٹیمپو

• اشتہار: Datadog، New Relic، Honeycomb، Dynatrace، Elastic، Lightstep، Grafana Cloud، Middleware۔

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

اوپن ٹیلی میٹری فلو انضمام

فرض کریں کہ ایک صارف اپنے موبائل بینکنگ ایپ سے بینک ٹرانسفر شروع کرتا ہے۔ اب جب کہ درخواست API گیٹ وے تک پہنچ گئی ہے اور ایپلیکیشن کو آلہ بنایا گیا ہے، OpenTelemetry فوری طور پر جو کچھ ہو رہا ہے اسے پکڑنا شروع کر دیتا ہے۔ آنے والی درخواستوں کے لیے گنجائش پیدا کرتا ہے اور ایک ٹریکنگ ID تفویض کرتا ہے۔

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

دریں اثنا، SDK پس منظر میں ٹیلی میٹری پر کارروائی کرتا ہے اور برآمد کنندہ کو منتقل کرنے سے پہلے اس کو بیچ پروسیسر کے ذریعے چلاتا ہے۔ برآمد ہر چیز کو OTLP میں پیک کرتی ہے اور اسے کلکٹر کو بھیج دیتی ہے۔ کلکٹر پروسیسنگ کے قوانین کا اطلاق کرتا ہے اور انہیں مشاہداتی پس منظر میں منتقل کرتا ہے۔

ذیل میں اس بہاؤ میں شامل تمام اجزاء کا خلاصہ ہے۔

عنصر	کردار
طریقہ	آپ کی درخواست کے اندر کیا ہو رہا ہے اسے پکڑیں۔
API	ان طریقوں کو بے نقاب کریں جنہیں آپ کا کوڈ اسکوپس، میٹرکس اور لاگز بنانے کے لیے کال کرتا ہے۔
SDK	برآمد کے لیے ٹیلی میٹری پر کارروائی اور تیار کرتا ہے۔
برآمد کنندہ	OTLP کے ذریعے ٹیلی میٹری پیک کریں اور بھیجیں۔
جمع کرنے والا	ٹیلی میٹری کو وصول کریں، اس پر کارروائی کریں اور اپنے بیک اینڈ پر روٹ کریں۔
مشاہداتی پسدید	ٹیلی میٹری کو اسٹور، استفسار اور تصور کریں۔

ایک واحد منتقلی کی درخواست اب پسدید کو مکمل سراغ لگانے کی اجازت دیتی ہے۔ جب آپ ڈیش بورڈ کھولتے ہیں اور ٹریکنگ آئی ڈی بازیافت کرتے ہیں تو اس ٹرانزیکشن کے لیے تمام سروسز، اسکوپس اور ملی سیکنڈز آپ کی آنکھوں کے سامنے ظاہر ہوتے ہیں۔

کیا تمام OpenTelemetry اجزاء کی ضرورت ہے؟

سچ پوچھیں تو، آپ کو OpenTelemetry کے ساتھ شروع کرنے کے لیے تمام اجزاء کی ضرورت نہیں ہے۔ اس مضمون میں نظر آنے والی پائپ لائن مجموعی سیٹ اپ ہے، لیکن تمام ٹیمیں اسے مکمل طور پر استعمال نہیں کریں گی۔

1. جمع کرنے والوں کو چھوڑ کر: ایکسپورٹ ٹول ٹیلی میٹری کو براہ راست آپ کے بیک اینڈ پر بغیر کسی چیز کے بھیجتا ہے۔ چھوٹے منصوبوں کے لیے بہترین ہے یا اگر آپ ابھی شروع کر رہے ہیں۔

2. جمع کرنے والوں کے لیے: یہ زیادہ عام پروڈکشن سیٹ اپ ہے۔ ٹیمیں جمع کرنے والوں کو شامل کرتی ہیں جب انہیں زیادہ کنٹرول کی ضرورت ہوتی ہے، جیسے ٹیلی میٹری کو ایک سے زیادہ بیک اینڈ پر روٹ کرنا، حساس ڈیٹا کو فلٹر کرنا، یا درجنوں سروسز سے ایک ہی جگہ پر ٹیلی میٹری کا انتظام کرنا۔

کلکٹر طاقتور ہے، لیکن ضروری نہیں ہے۔ اگر آپ کا سیٹ اپ آسان ہے تو بغیر شروع کریں اور جب آپ کو واقعی ضرورت ہو تو مزید شامل کریں۔

اوپن ٹیلی میٹری کیوں استعمال کریں؟

اب آپ دیکھتے ہیں کہ OpenTelemetry کے تمام حصے ایک ساتھ کیسے فٹ ہوتے ہیں۔ یہاں یہ ہے کہ یہ کیوں استعمال کرنے کے قابل ہے:

• وینڈر غیر جانبدار آلہ: OpenTelemetry سے پہلے، مشاہداتی ٹولز کو سوئچ کرنے کے لیے شروع سے پوری ایپلیکیشن کو دوبارہ انسٹرومینٹ کرنے کی ضرورت ہوتی ہے۔ OpenTelemetry آپ کو ایک بار آلہ بنانے اور بیک اینڈ کو آزادانہ طور پر سوئچ کرنے کی اجازت دیتا ہے۔

• خدمات اور زبانوں میں مسلسل ٹیلی میٹری: بیک اینڈ گو میں ہو سکتا ہے، مائیکرو سروسز ازگر میں ہو سکتی ہے، اور ڈیٹا پائپ لائن جاوا میں ہو سکتی ہے۔ OpenTelemetry میں ان سب کے لیے SDKs ہیں، اور وہ سب ایک ہی فارمیٹ میں ٹیلی میٹری تیار کرتے ہیں، اس لیے پورا اسٹیک ایک ہی زبان بولتا ہے۔

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

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

نتیجہ

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

اگر آپ کو اس مضمون سے کچھ اور یاد نہیں ہے، تو یاد رکھیں کہ ہم ایپلیکیشن کو انسٹرومنٹ کرتے ہیں، ٹیلی میٹری تیار کرتے ہیں، اس پر کارروائی کرتے ہیں، اسے برآمد کرتے ہیں اور اس کا تجزیہ کرتے ہیں۔ ہر قدم کے پیچھے اجزاء ہوتے ہیں اور اب آپ جانتے ہیں کہ ہر قدم کیا کرتا ہے۔

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

اگر آپ کو یہ معلومات کارآمد لگی تو میں رابطہ کرنا چاہوں گا۔ آپ مجھے LinkedIn پر تلاش کر سکتے ہیں یا اگر آپ کے کوئی سوالات ہیں یا مشاہداتی اور ڈویلپر ٹولز کے بارے میں بات کرنا چاہتے ہیں، تو براہ کرم بلا جھجھک مجھ سے رابطہ کریں۔