پیداوار میں OpenTelemetry: اندھیرے میں ڈیبگ کرنا بند کریں۔

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

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

بات trace نہیں، کہانی ہے۔

A trace span کی ایک ترتیب ہے۔ اس طرح رکھو کہ یہ ٹھنڈا لگتا ہے. عملی طور پر، ہر span کہانی کا ایک ٹکڑا ہے: POST /checkout, SELECT inventory, call payment provider, publish order.created.

قدر تب آتی ہے جب آپ حقیقی سوالات کا جواب دینا شروع کرتے ہیں:

• کون سی بیرونی سروس سست ہو رہی ہے؟
• کیا غلطیاں کسی مخصوص ورژن سے آتی ہیں؟
• کیا مسئلہ سب کو متاثر کرتا ہے یا صرف ایک کرایہ دار؟
• کیا دوبارہ کوشش ٹائم آؤٹ کو چھپا رہی ہے؟
• غیر مطابقت پذیر کام شروع ہوتا ہے لیکن پھر کہیں اور مر جاتا ہے؟

یہ سوالات جلد بازی میں پھینکے جانے والے console.log سے حل نہیں ہو سکتے۔ درحقیقت، اکثر ہنگامی حالت میں شامل کیا گیا لاگ آج آپ کی مدد کرتا ہے اور کل شور بن جاتا ہے۔

میں اسے ایپ میں کیسے رکھوں گا Node.js

صحت مند ترین سیٹ اپ آسان ہے: ایپ ٹیلی میٹری تیار کرتی ہے، Collector فیصلہ کرتی ہے کہ اسے کہاں بھیجنا ہے۔

Node.js app -> OpenTelemetry Collector -> backend di observability

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

Collector تمام صحیح طریقوں سے بورنگ ہے۔ یہ OTLP حاصل کرتا ہے، بیچنگ کرتا ہے، فلٹر کرسکتا ہے، نمونے لے سکتا ہے، عام صفات کو شامل کرسکتا ہے اور متعدد سسٹمز میں ایکسپورٹ کرسکتا ہے۔

خود سازی: اچھا، لیکن کافی نہیں۔

Node.js میں میں آٹو انسٹرومینٹیشن کے ساتھ شروع کروں گا۔ یہ آپ کو HTTP، معاون فریم ورک، ڈیٹا بیس اور عام لائبریریوں میں فوری مرئیت فراہم کرتا ہے۔

npm install @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http

پھر آپ باقی ایپ سے پہلے SDK شروع کریں:

import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

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

const span = tracer.startSpan('checkout.create_order');

try {
  span.setAttribute('cart.items_count', input.items.length);
  const order = await createOrder(input);
  span.setAttribute('order.id', order.id);
  return order;
} catch (error) {
  span.recordException(error as Error);
  throw error;
} finally {
  span.end();
}

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

تین اصول جو بہت زیادہ انتشار سے بچتے ہیں۔

پہلا اصول: ہر سروس میں service.name، ماحول اور ورژن ہونا چاہیے۔ یہ معمولی معلوم ہوتا ہے، لیکن ان صفات کے بغیر trace بہت کم مفید ہے۔ جب کوئی تعیناتی کچھ توڑ دیتی ہے، تو آپ دو سیکنڈ میں ورژن کے لحاظ سے فلٹر کرنا چاہتے ہیں۔

دوسرا اصول: صفات میں حساس ڈیٹا نہ ڈالیں۔ ای میلز، ٹوکنز، انٹیجر پے لوڈز، اور پتے حادثاتی طور پر مشاہداتی پس منظر میں ختم نہیں ہونے چاہئیں۔ اگر آپ کو کسی صارف کی شناخت کرنے کی ضرورت ہے تو اندرونی IDs، ہیشنگ یا کم حساس فیلڈز پر غور کریں۔

تیسرا قاعدہ: قلبی شخصیت پر توجہ دیں۔ user.id trace کے وصف کے طور پر معنی رکھتا ہے۔ میٹرک لیبل کے طور پر یہ آپ کے اخراجات اور کارکردگی کو تباہ کر سکتا ہے۔

میٹرکس: چند، لیکن اچھے

میں بہت عملی میٹرکس کے ساتھ شروع کروں گا:

• شرحیں، غلطیاں اور درخواستوں کی مدت؛
• بیرونی انحصار کی تاخیر؛
• ٹائم آؤٹ اور دوبارہ کوششوں کی تعداد؛
• دم کی گہرائی؛
• کام کی مدت؛
• فی ورژن غلطیوں کا فیصد۔

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

لاگز: پھر بھی مفید، لیکن منسلک

لاگز غائب نہیں ہوتے ہیں۔ جب وہ trace_id اور span_id لے جاتے ہیں تو وہ زیادہ مفید ہو جاتے ہیں۔ اس لیے آپ ایک ایرر لاگ سے شروع کر سکتے ہیں اور trace کھول سکتے ہیں، یا آہستہ trace سے شروع کر سکتے ہیں اور صرف اس راستے میں بنائے گئے لاگز کو پڑھ سکتے ہیں۔

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

وہ چیک لسٹ جو میں "ہم کور کر رہے ہیں" کہنے سے پہلے استعمال کروں گا

• trace دراصل متعدد خدمات کو عبور کرتا ہے۔
• لاگز میں trace_id اور span_id شامل ہیں۔
• Collector کو بیچنگ اور میموری کی حدود کے ساتھ ترتیب دیا گیا ہے۔
• غلطیاں span میں ریکارڈ کی گئی ہیں۔
• نمونے لینے کی پالیسی ہے۔
• میٹرکس نے کارڈنلٹی کو کنٹرول کیا ہے۔
• حساس ڈیٹا کو فلٹر کیا جاتا ہے۔
• الرٹس صارف کی علامات سے شروع ہوتے ہیں، بے ترتیب گراف سے نہیں۔

نتیجہ

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

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

ذرائع

• OpenTelemetry: Overview
• OpenTelemetry Collector: Configuration
• OpenTelemetry JavaScript: Node.js getting started
• OpenTelemetry Semantic Conventions