1~
2پہلی بار جب آپ کو واقعی مشاہدے کی ضرورت ہوتی ہے تو وہ نہیں ہے جب آپ سکون سے ڈیش بورڈ کو دیکھ رہے ہوں۔ یہ تب ہوتا ہے جب صارف "چیک آؤٹ سست ہے" لکھتا ہے، غلطی کا گراف نارمل نظر آتا ہے اور لاگز میں آپ کو صرف منقطع پیغامات کی ایک قطار نظر آتی ہے۔
3~
4OpenTelemetry اس لمحے سے بچنے کے لیے بنایا گیا تھا: زیادہ گرافکس رکھنے کے لیے نہیں، بلکہ ٹکڑوں کو جوڑنے کے لیے۔ ایک درخواست API میں داخل ہوتی ہے، ڈیٹا بیس کو کال کرتی ہے، ایک بیرونی فراہم کنندہ سے گزرتی ہے، قطار میں لگی نوکری پوسٹ کرتی ہے، اور شاید بعد میں تین خدمات ناکام ہوجاتی ہیں۔ تقسیم شدہ ٹریسنگ کے بغیر، آپ اس کہانی کو ہاتھ سے دوبارہ تشکیل دیتے ہیں۔ OpenTelemetry کے ساتھ کم از کم آپ کے پاس نقشہ ہے۔
5~
6## بات trace نہیں، کہانی ہے۔
7~
8A trace span کی ایک ترتیب ہے۔ اس طرح رکھو کہ یہ ٹھنڈا لگتا ہے. عملی طور پر، ہر span کہانی کا ایک ٹکڑا ہے: `POST /checkout`, `SELECT inventory`, `call payment provider`, `publish order.created`.
9~
10قدر تب آتی ہے جب آپ حقیقی سوالات کا جواب دینا شروع کرتے ہیں:
11~
12- کون سی بیرونی سروس سست ہو رہی ہے؟
13- کیا غلطیاں کسی مخصوص ورژن سے آتی ہیں؟
14- کیا مسئلہ سب کو متاثر کرتا ہے یا صرف ایک کرایہ دار؟
15- کیا دوبارہ کوشش ٹائم آؤٹ کو چھپا رہی ہے؟
16- غیر مطابقت پذیر کام شروع ہوتا ہے لیکن پھر کہیں اور مر جاتا ہے؟
17~
18یہ سوالات جلد بازی میں پھینکے جانے والے `console.log` سے حل نہیں ہو سکتے۔ درحقیقت، اکثر ہنگامی حالت میں شامل کیا گیا لاگ آج آپ کی مدد کرتا ہے اور کل شور بن جاتا ہے۔
19~
20## میں اسے ایپ میں کیسے رکھوں گا Node.js
21~
22صحت مند ترین سیٹ اپ آسان ہے: ایپ ٹیلی میٹری تیار کرتی ہے، Collector فیصلہ کرتی ہے کہ اسے کہاں بھیجنا ہے۔
23~
24```text
25Node.js app -> OpenTelemetry Collector -> backend di observability
26```
27~
28براہ راست وینڈر کو برآمد کیوں نہیں کرتے؟ کیونکہ پہلے تو یہ تیز لگتا ہے، پھر آپ کو احساس ہوگا کہ ہر سروس کی مختلف کنفیگریشنز، مختلف دوبارہ کوششیں، مختلف فلٹرز ہیں اور حساس ڈیٹا کو ہٹانے یا منزل کو تبدیل کرنے کے لیے کوئی مرکزی نقطہ نہیں ہے۔
29~
30Collector تمام صحیح طریقوں سے بورنگ ہے۔ یہ OTLP حاصل کرتا ہے، بیچنگ کرتا ہے، فلٹر کرسکتا ہے، نمونے لے سکتا ہے، عام صفات کو شامل کرسکتا ہے اور متعدد سسٹمز میں ایکسپورٹ کرسکتا ہے۔
31~
32## خود سازی: اچھا، لیکن کافی نہیں۔
33~
34Node.js میں میں آٹو انسٹرومینٹیشن کے ساتھ شروع کروں گا۔ یہ آپ کو HTTP، معاون فریم ورک، ڈیٹا بیس اور عام لائبریریوں میں فوری مرئیت فراہم کرتا ہے۔
35~
36```bash
37npm install @opentelemetry/sdk-node \
38  @opentelemetry/auto-instrumentations-node \
39  @opentelemetry/exporter-trace-otlp-http
40```
41~
42پھر آپ باقی ایپ سے پہلے SDK شروع کریں:
43~
44```typescript
45import { NodeSDK } from '@opentelemetry/sdk-node';
46import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
47import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
48~
49const sdk = new NodeSDK({
50  traceExporter: new OTLPTraceExporter({
51    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
52  }),
53  instrumentations: [getNodeAutoInstrumentations()],
54});
55~
56sdk.start();
57```
58~
59تاہم، یہ فریم ورک دیکھتا ہے، آپ کی مصنوعات کو نہیں۔ یہ جانتا ہے کہ آپ نے استفسار کیا ہے، لیکن یہ نہیں جانتا کہ استفسار "تخلیق آرڈر" یا "سبسکرپشن کی تجدید" میں تھا۔ اس کے لیے آپ کو ان پوائنٹس پر span مینوئلز کی ضرورت ہے جہاں غلبہ شمار ہوتا ہے۔
60~
61```typescript
62const span = tracer.startSpan('checkout.create_order');
63~
64try {
65  span.setAttribute('cart.items_count', input.items.length);
66  const order = await createOrder(input);
67  span.setAttribute('order.id', order.id);
68  return order;
69} catch (error) {
70  span.recordException(error as Error);
71  throw error;
72} finally {
73  span.end();
74}
75```
76~
77میں کہیں بھی span مینوئلز نہیں ڈالوں گا۔ میں انہیں وہاں رکھوں گا، صبح تین بجے، میں یہ سمجھنا چاہوں گا کہ آدھے کوڈ بیس کو پڑھے بغیر کیا ہوا ہے۔
78~
79## تین اصول جو بہت زیادہ انتشار سے بچتے ہیں۔
80~
81پہلا اصول: ہر سروس میں `service.name`، ماحول اور ورژن ہونا چاہیے۔ یہ معمولی معلوم ہوتا ہے، لیکن ان صفات کے بغیر trace بہت کم مفید ہے۔ جب کوئی تعیناتی کچھ توڑ دیتی ہے، تو آپ دو سیکنڈ میں ورژن کے لحاظ سے فلٹر کرنا چاہتے ہیں۔
82~
83دوسرا اصول: صفات میں حساس ڈیٹا نہ ڈالیں۔ ای میلز، ٹوکنز، انٹیجر پے لوڈز، اور پتے حادثاتی طور پر مشاہداتی پس منظر میں ختم نہیں ہونے چاہئیں۔ اگر آپ کو کسی صارف کی شناخت کرنے کی ضرورت ہے تو اندرونی IDs، ہیشنگ یا کم حساس فیلڈز پر غور کریں۔
84~
85تیسرا قاعدہ: قلبی شخصیت پر توجہ دیں۔ `user.id` trace کے وصف کے طور پر معنی رکھتا ہے۔ میٹرک لیبل کے طور پر یہ آپ کے اخراجات اور کارکردگی کو تباہ کر سکتا ہے۔
86~
87## میٹرکس: چند، لیکن اچھے
88~
89میں بہت عملی میٹرکس کے ساتھ شروع کروں گا:
90~
91- شرحیں، غلطیاں اور درخواستوں کی مدت؛
92- بیرونی انحصار کی تاخیر؛
93- ٹائم آؤٹ اور دوبارہ کوششوں کی تعداد؛
94- دم کی گہرائی؛
95- کام کی مدت؛
96- فی ورژن غلطیوں کا فیصد۔
97~
98بقیہ ضرورت پڑنے پر شامل کیا جاتا ہے۔ گرافوں سے بھرے ڈیش بورڈز جن پر کوئی نہیں دیکھتا وہ فرنیچر ہیں، مشاہدہ کرنے کے قابل نہیں۔
99~
100## لاگز: پھر بھی مفید، لیکن منسلک
101~
102لاگز غائب نہیں ہوتے ہیں۔ جب وہ `trace_id` اور `span_id` لے جاتے ہیں تو وہ زیادہ مفید ہو جاتے ہیں۔ اس لیے آپ ایک ایرر لاگ سے شروع کر سکتے ہیں اور trace کھول سکتے ہیں، یا آہستہ trace سے شروع کر سکتے ہیں اور صرف اس راستے میں بنائے گئے لاگز کو پڑھ سکتے ہیں۔
103~
104باہمی تعلق کے بغیر، آپ سوئیاں تلاش کر رہے ہیں. ارتباط کے ساتھ، کم از کم آپ جانتے ہیں کہ کس دراز میں دیکھنا ہے۔
105~
106## وہ چیک لسٹ جو میں "ہم کور کر رہے ہیں" کہنے سے پہلے استعمال کروں گا
107~
108- trace دراصل متعدد خدمات کو عبور کرتا ہے۔
109- لاگز میں `trace_id` اور `span_id` شامل ہیں۔
110- Collector کو بیچنگ اور میموری کی حدود کے ساتھ ترتیب دیا گیا ہے۔
111- غلطیاں span میں ریکارڈ کی گئی ہیں۔
112- نمونے لینے کی پالیسی ہے۔
113- میٹرکس نے کارڈنلٹی کو کنٹرول کیا ہے۔
114- حساس ڈیٹا کو فلٹر کیا جاتا ہے۔
115- الرٹس صارف کی علامات سے شروع ہوتے ہیں، بے ترتیب گراف سے نہیں۔
116~
117## نتیجہ
118~
119OpenTelemetry پیداواری مسائل خود حل نہیں کرتا۔ لیکن ان کے ساتھ نمٹنے کا طریقہ بدل جاتا ہے۔ آنکھیں بند کرکے لاگز شامل کرنے کے بجائے، آپ درخواست کے اصل راستے پر چلنا شروع کر دیتے ہیں۔
120~
121میرے لیے یہ نشانی آسان ہے کہ یہ کام کر رہا ہے: جب کچھ ہوتا ہے، ٹیم یہ پوچھنا بند کر دیتی ہے کہ "ہم کہاں دیکھ رہے ہیں؟" اور پوچھنا شروع کر دیتا ہے "وہ ٹکڑا سست کیوں ہے؟"۔ یہی وہ جگہ ہے جہاں مشاہدہ ایک ٹول بن جاتا ہے، ڈیش بورڈز کا مجموعہ نہیں۔
122~
123## ذرائع
124~
125- [OpenTelemetry: Overview](https://opentelemetry.io/docs/specs/otel/overview/)
126- [OpenTelemetry Collector: Configuration](https://opentelemetry.io/docs/collector/configuration/)
127- [OpenTelemetry JavaScript: Node.js getting started](https://opentelemetry.io/docs/languages/js/getting-started/nodejs/)
128- [OpenTelemetry Semantic Conventions](https://opentelemetry.io/docs/concepts/semantic-conventions/)
129~