لاگز، میٹرکس اور ٹریسز کے لیے بڑے پیمانے پر مشاہدہ پذیری کی حکمت عملی کیا ہے؟

Question

Accepted Answer

مشاہدہ پذیری **تین ستونوں** پر منحصر ہے — **لاگز**، **میٹرکس**، اور **ٹریسز** — اور مقصد ایک ایسے سسٹم کے لیے "کیا غلط ہے اور کیوں" کا جواب دینا ہے جو ہاتھ سے معائنہ کرنے کے لیے بہت بڑا ہے۔ بڑے پیمانے پر، حکمت عملی ارتباط، نمونہ گیری، اور لاگت کے بارے میں ہے۔

## تینوں ستون

| ستون | جوابات | آلات |
|---|---|---|
| میٹرکس | کیا کوئی مسئلہ ہے؟ (شرح، تاخیر) | Prometheus, Grafana |
| ٹریسز | بہاؤ میں کہاں؟ | OpenTelemetry, Jaeger |
| لاگز | بالکل کیا ہوا؟ | ELK, Loki |

```text
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
   (broad)              (path)                          (detail)
```

## انہیں منسلک کریں

ٹریس/ارتباطی ID کو میٹرکس لیبلز، لاگ لائنوں، اور spans کے ذریعے چلنا چاہیے، تاکہ آپ ان کے درمیان تبدیل ہو سکیں۔

```text
log line:  level=error trace_id=abc123 service=payments msg="gateway timeout"
                       ^^^^^^^^^^^^^^^ same id appears in the trace + metrics
```

## بڑے پیمانے کی فکریں

```text
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
```

## خرابی

100% میں سب کچھ لاگ کرنا سزا ور انجام تک نہیں پہنچایا جا سکتا اور سگنل کو ڈوب دیتا ہے۔ اس کی بجائے، نمونہ گیری، ڈھانچہ، اور SLOs پر انتباہات دیں۔

## یہ کیوں اہم ہے

سیکڑوں خدمات کے ساتھ، آپ SSH میں نہیں جا سکتے اور دیکھ سکتے — مشاہدہ پذیری پروڈکشن کے رویے کو سمجھنے کا واحد طریقہ ہے۔

جیتنے والی حکمت عملی منسلک، نمونہ شدہ، اور SLO سے چلنے والی ہے: یہ حقیقی مسائل کو تیز رفتاری سے سامنے لاتی ہے بغیر آپ کو ٹیلیمیٹری سٹوریج پر دیوالیہ کیے یا آن کال کو شور میں دفن کیے۔

میٹرکس	کیا کوئی مسئلہ ہے؟ (شرح، تاخیر)	Prometheus, Grafana
ٹریسز	بہاؤ میں کہاں؟	OpenTelemetry, Jaeger
لاگز	بالکل کیا ہوا؟	ELK, Loki