Distributed tracing আর OpenTelemetry — span, context আর sampling

১ · একটি ধীর request: metric আর log কোথায় থেমে যায়

একটি কাল্পনিক অনলাইন বাজার অ্যাপের কথা ভাবুন। ক্রেতা “অর্ডার করুন” চাপলেন। অনুরোধটি গেল shop-api-তে, সেখান থেকে order-svc-এ, তারপর payment-svc-এ, শেষে ব্যাংকের gateway-তে। এটি microservice ধরনের নকশা। একটি ক্লিকের পেছনে চারটি জায়গায় কাজ হচ্ছে।

রাত ৯টায় অভিযোগ এলো, “চেকআউট মাঝে মাঝে ঝুলে থাকে।” আপনি কী কী দেখতে পারেন?

সমস্যাটি সবচেয়ে কঠিন হয় যখন প্রতিটি service-এর নিজের metric স্বাভাবিক দেখায়। order-svc-এর গড় ঠিক আছে, কারণ এক হাজারের মধ্যে অল্প কয়েকটি request ধীর। গড় আর সারাংশ ওই কয়েকটিকে গিলে ফেলে। আবার log-এ হাজার হাজার লাইন, এক সেকেন্ডে অনেক request-এর লাইন মিশে আছে। কোনটি কার, বোঝার উপায় নেই।

Metric, log আর trace মিলে observability-র তিনটি প্রধান সংকেত। তত্ত্বের দিকটি System Design · Observability-তে আছে। এই পর্বে আমরা চালানোর দিকটি দেখব: কীভাবে বসাবেন, পড়বেন, ছাঁটবেন আর খরচ সামলাবেন।

২ · Trace, span আর parent: শব্দগুলো চিনে নিই

একটি request-এর পুরো রেকর্ড হলো trace. তার প্রতিটি কাজের টুকরো হলো span. প্রতিটি span জানে তার trace id, নিজের span id আর তার parent-এর span id. এই তিনটি দিয়েই আলাদা machine-এ তৈরি span পরে একটি গাছ হয়ে যায়। যে span-এর parent নেই, সেটি root span.

Span-গুলো সময়ের দাগে পাশাপাশি আঁকলে যে ছবি হয়, তাকে বলে waterfall. প্রতিটি বারের বাঁ প্রান্ত শুরু, ডান প্রান্ত শেষ, আর নিচের বার ওপরের বারের ভেতরে থাকলে সেটি child. নিচের ছবিটি আমাদের আসল run-এর একটি ধীর request থেকে আঁকা:

৩ · Context propagation: traceparent header পড়া

Span তৈরি হচ্ছে তিনটি আলাদা process-এ। তাহলে payment-svc কীভাবে জানবে সে কোন trace-এর অংশ? উত্তর সহজ: আগের service তাকে বলে দেয়। এই কাজের নাম context propagation. HTTP-তে তথ্যটি যায় একটি header-এ, যার নিয়ম ঠিক করেছে W3C-র Trace Context মান (Recommendation, ২০২০)। Header-টির নাম traceparent. আমাদের run থেকে একটি আসল মান:

traceparent: 00-42a322d43ae0d3f1b5f444ced406e897-0892dd39cd3d82fc-03

03 মানে binary 0000 0011: sampled-এর bit চালু, আর পাশের bit-ও চালু। দ্বিতীয় bit-টি Trace Context Level 2-এর random-trace-id flag, যা বলে trace id-র ডানের অন্তত ৭ byte দৈব। Level 2 লেখার সময়ে W3C-র Candidate Recommendation Draft, চূড়ান্ত মান নয়। আমাদের run-এ SDK নিজে থেকেই এটি বসিয়েছে। বেশিরভাগ ব্যাখ্যায় আপনি -01 দেখবেন। -03 দেখে ঘাবড়াবেন না, প্রথম bit-ই sampling-এর কথা বলে। Head sampling-এর run-এ আমরা বাদ পড়া request-এ -02 পেয়েছি: sampled বন্ধ, random চালু।

পাশে থাকতে পারে tracestate header, যেখানে কোনো vendor নিজের তথ্য রাখে। আর আছে baggage, যা আপনার নিজের key-value পরের সব service-এ নিয়ে যায়। নিচের stepper-এ আমাদের run-এর আসল id দিয়ে দেখুন context কীভাবে তিনটি service পার হলো। খেয়াল করুন, trace-id স্থির, parent-id বদলাচ্ছে:

incoming traceparent : (none)
new trace id         : 42a322d43ae0d3f1b5f444ced406e897
server span          : 80b607806f20610c   parent: none (root)

client span : 0892dd39cd3d82fc   parent: 80b607806f20610c
header      : 00-42a322d43ae0d3f1b5f444ced406e897
              -0892dd39cd3d82fc-03

trace id    : 42a322d43ae0d3f1b5f444ced406e897  (same)
server span : d1e45ffe95da6303
parent      : 0892dd39cd3d82fc  (shop-api's client span)

client span : 5a182c62770cc9d9   parent: d1e45ffe95da6303
header      : 00-42a322d43ae0d3f1b5f444ced406e897
              -5a182c62770cc9d9-03

trace id    : 42a322d43ae0d3f1b5f444ced406e897  (same)
server span : 857c626356151570
parent      : 5a182c62770cc9d9  (order-svc's client span)

fraud.check    : 9abfc62b47d3e471   parent: 857c626356151570
bank.authorize : a04d2e3809e4d14e   parent: 857c626356151570
each process exports its spans to the Collector by OTLP

এবার নিজে পরীক্ষা করুন। নিচের কোড header পড়ে, যাচাই করে, আর পরের hop-এর header বানায়। নতুন id আসে seeded PRNG থেকে, তাই প্রতিবার একই ফল পাবেন। আসল SDK-তে এখানে cryptographically ভালো random উৎস লাগে।

// Parse a W3C traceparent header and build the header for the next hop.
function mulberry32(seed) {
  return function () {
    seed = (seed + 0x6D2B79F5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const rand = mulberry32(65);       // fixed seed: same ids on every run
const hex = n => Array.from({ length: n },
  () => Math.floor(rand() * 16).toString(16)).join('');
function parse(h) {
  const m = /^([0-9a-f]{2})-([0-9a-f]{32})-([0-9a-f]{16})-([0-9a-f]{2})$/.exec(h);
  if (!m) return { ok: false, why: 'wrong shape' };
  const [, version, traceId, parentId, flags] = m;
  if (version === 'ff') return { ok: false, why: 'version ff is forbidden' };
  if (/^0+$/.test(traceId)) return { ok: false, why: 'trace-id is all zero' };
  if (/^0+$/.test(parentId)) return { ok: false, why: 'parent-id is all zero' };
  return { ok: true, traceId, parentId, flags, sampled: (parseInt(flags, 16) & 1) === 1 };
}
const child = c => `00-${c.traceId}-${hex(16)}-${c.flags}`;
const headers = [
  '00-42a322d43ae0d3f1b5f444ced406e897-0892dd39cd3d82fc-03',
  '00-c8351ad671afbc3e94d7ca250e0da4ae-c8b92d09406496cd-02',
  '00-00000000000000000000000000000000-0892dd39cd3d82fc-01',
  '00-42A322D43AE0D3F1B5F444CED406E897-0892dd39cd3d82fc-01',
];
for (const h of headers) {
  const c = parse(h);
  if (!c.ok) { console.log('REJECT ' + c.why + ' -> start a new trace'); continue; }
  console.log(`sampled=${c.sampled} from parent ${c.parentId}`);
  console.log('  next hop: ' + child(c));
}

৪ · আসল run: তিনটি service, Jaeger আর ধীর span

এবার কথা ছেড়ে হাতে দেখি। এই পর্বের সব আউটপুট একটি আসল run থেকে নেওয়া: Docker Engine 29 আর BuildKit, Python 3.12, OpenTelemetry Python SDK 1.45.2, Collector contrib 0.164.0 আর Jaeger 2.22.0. ID, সময় আর সংস্করণ আপনার machine-এ আলাদা হবে। একটি ছোট Flask ফাইল তিনটি container-এ তিনটি service হিসেবে চলছে, আর OpenTelemetry-র Python প্যাকেজগুলো image build-এর সময় pip install দিয়ে বসানো। ধীর হওয়া আর ব্যর্থ হওয়া আমরা ইচ্ছা করে বসিয়েছি, যাতে ফল যাচাই করা যায়।

# payment-svc: the two manual spans. Flask and requests are auto-traced.
with tracer.start_as_current_span("fraud.check"):
    time.sleep(0.008)
with tracer.start_as_current_span("bank.authorize") as s:
    s.set_attribute("peer.service", "bank-gateway")
    if body.get("mode") == "slow":          # planted delay for the demo
        s.add_event("bank retry", {"attempt": 2, "reason": "connect timeout"})
        time.sleep(1.2)
    elif body.get("mode") == "fail":        # planted failure for the demo
        err = RuntimeError("bank refused: gateway 503")
        s.record_exception(err)
        s.set_status(Status(StatusCode.ERROR, "bank refused"))
        return jsonify(error="bank refused"), 502
    else:
        time.sleep(0.03)

এক ক্রেতার request পাঠাই, আর উত্তরে আসা trace id দিয়ে Jaeger-এর HTTP API পড়ি। এই সংস্করণে JSON API আছে /api/v3/-এর নিচে, উত্তরের আকার OTLP-র মতো। পুরোনো /api/services এই run-এ 404 দিয়েছে। Tool-এর পথ সংস্করণভেদে বদলায়, তাই docs দেখে নেবেন।

$ curl -s -X POST -H 'Content-Type: application/json' \
    -d '{"mode":"slow","method":"bkash"}' \
    -w ' [%{http_code} %{time_total}s]\n' http://127.0.0.1:18652/checkout
{"sampled":true,"status":200,"trace_id":"42a322d43ae0d3f1b5f444ced406e897"}
 [200 1.340501s]

$ curl -s http://127.0.0.1:18651/api/v3/services
{"services":["payment-svc","shop-api","order-svc"]}

$ python read_trace.py 42a322d43ae0d3f1b5f444ced406e897
8 spans, 1226.9 ms
    0.0  1226.9  shop-api     POST /checkout
    0.8  1225.9  shop-api     POST
    1.9  1224.2  order-svc    POST /orders
    2.5    12.1  order-svc    db.insert orders
   15.1  1210.6  order-svc    POST
   16.3  1209.0  payment-svc  POST /pay
   16.8     8.0  payment-svc  fraud.check
   24.9  1200.1  payment-svc  bank.authorize
slowest work: payment-svc / bank.authorize = 1200.1 ms

ID না জানলেও চলে। Jaeger-কে সময় ধরে জিজ্ঞেস করা যায়: query.duration_min=500ms দিলে এই run-এ ৪টি request-এর মধ্যে ঠিক একটি trace ফিরেছে, ওই 42a3…e897. এবার ধীর request-টি ধাপে ধাপে পড়ি:

normal request : 0.08 s
this request   : 1.34 s
metric says only: p99 went up

query.service_name=shop-api
query.duration_min=500ms
-> 1 trace: 42a322d43ae0d3f1b5f444ced406e897

1226.9 shop-api  POST /checkout
1225.9 shop-api    POST
1224.2 order-svc     POST /orders
1210.6 order-svc       POST
1209.0 payment-svc       POST /pay
each bar only waits for the bar below it

POST /checkout   1226.9 - 1225.9          =    1.0
POST (client)    1225.9 - 1224.2          =    1.7
POST /orders     1224.2 - 12.1 - 1210.6   =    1.5
POST (client)    1210.6 - 1209.0          =    1.6
POST /pay        1209.0 - 8.0 - 1200.1    =    0.9
db.insert orders                          =   12.1
fraud.check                               =    8.0
bank.authorize                            = 1200.1

1.0 + 1.7 + 1.5 + 1.6 + 0.9 + 12.1 + 8.0 + 1200.1
= 1226.9 ms  (matches the root span)
bank.authorize share = 1200.1 / 1226.9 = 97.8%

bank.authorize
  event: bank retry
    attempt = 2
    reason  = connect timeout
normal request, same span: 30.1 ms

সমান্তরাল কাজে critical path

ওপরের trace ছিল সোজা লাইন। দুটি কাজ একসাথে চললে হিসাব বদলায়। সবচেয়ে লম্বা নির্ভরতার পথকে বলে critical path. এই পথের বাইরের span দ্রুত করলে মোট সময় একটুও কমে না। নিচের কোডে stock.reserve আর payment.pay একসাথে চলে। সংখ্যাগুলো কাল্পনিক, নিজে বদলে দেখুন।

// A waterfall from span data, with the critical path marked. Times in ms.
const spans = [
  { id: 'a', pid: null, name: 'POST /checkout', start: 0, dur: 640 },
  { id: 'b', pid: 'a', name: 'auth.verify', start: 5, dur: 30 },
  { id: 'c', pid: 'a', name: 'stock.reserve', start: 40, dur: 260 },
  { id: 'd', pid: 'a', name: 'payment.pay', start: 40, dur: 590 },
  { id: 'e', pid: 'd', name: 'fraud.check', start: 45, dur: 30 },
  { id: 'f', pid: 'd', name: 'bank.authorize', start: 80, dur: 530 },
];
const end = s => s.start + s.dur;
const kids = s => spans.filter(k => k.pid === s.id);
// Walk backwards: the child that finishes last before the cursor blocks us.
function walk(s, onPath) {
  let cursor = end(s), self = 0;
  for (const k of kids(s).sort((x, y) => end(y) - end(x))) {
    if (end(k) > cursor) continue;              // overlaps a later child
    self += cursor - end(k);
    walk(k, onPath);
    cursor = k.start;
  }
  onPath.set(s.id, self + cursor - s.start);
}
const root = spans.find(s => s.pid === null), onPath = new Map();
walk(root, onPath);
const W = 40, scale = W / root.dur;
for (const s of spans) {
  const a = Math.round(s.start * scale), n = Math.max(1, Math.round(s.dur * scale));
  const bar = ' '.repeat(a) + (onPath.has(s.id) ? '#' : '=').repeat(n);
  console.log(s.name.padEnd(15) + String(s.dur).padStart(4) + ' |' + bar.padEnd(W) + '|');
}
console.log('\ncritical path (self time on the path):');
let sum = 0;
for (const [id, ms] of onPath) { sum += ms; console.log('  ' + spans.find(s => s.id === id).name.padEnd(15) + ms); }
console.log('  total          ' + sum + ' ms');

৫ · Instrumentation, OTLP আর Collector

কোডে telemetry তৈরির ব্যবস্থা বসানোকে বলে instrumentation. আমাদের run-এ দুই রকমই ছিল। আটটি span-এর পাঁচটি এসেছে কোড না ছুঁয়ে, আর তিনটি নিজে লিখেছি।

বাস্তবে নিয়মটি হলো দুটোই। আগে auto দিয়ে পথের কঙ্কাল পান, তারপর গুরুত্বপূর্ণ জায়গায় manual span বসান। Attribute-এর নাম নিজে বানাবেন না, semantic conventions দেখুন। আমাদের run-এ Flask instrumentation দিয়েছে পুরোনো নাম http.status_code, যেখানে নতুন conventions-এ নাম http.response.status_code. সংস্করণ আর সেটিংভেদে নাম বদলায়, তাই dashboard বানানোর আগে নিজের ডেটা দেখে নিন।

OpenTelemetry-র গঠনে API আর SDK আলাদা। Library শুধু API-তে লেখে, যা SDK না থাকলে কিছুই করে না। App-এর মালিক SDK বসিয়ে ঠিক করেন span কোথায় যাবে। Span বের হয় OTLP protocol-এ, সাধারণত gRPC-তে port 4317 বা HTTP-তে 4318. আমাদের service-গুলো সরাসরি Jaeger-এ নয়, পাঠিয়েছে Collector-এ:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 200
  attributes/scrub:
    actions:
      - key: http.request.header.authorization
        action: delete
  batch:
    timeout: 1s

exporters:
  otlp/jaeger:
    endpoint: abcl-tr-jaeger:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, attributes/scrub, batch]
      exporters: [otlp/jaeger]

App শুধু কয়েকটি environment variable জানে, যা পর্ব ৪০-এর Compose ফাইলে বসে:

services:
  payment-svc:
    image: abcl-tr-svc:1
    environment:
      OTEL_SERVICE_NAME: payment-svc
      OTEL_EXPORTER_OTLP_ENDPOINT: http://abcl-tr-collector:4318
      OTEL_EXPORTER_OTLP_PROTOCOL: http/protobuf
      OTEL_TRACES_EXPORTER: otlp
      OTEL_TRACES_SAMPLER: parentbased_always_on

Collector সাধারণত দুই স্তরে চলে। প্রতিটি node বা app-এর পাশে একটি agent (sidecar বা DaemonSet), আর মাঝখানে একটি gateway দল। Agent হালকা কাজ করে, gateway ভারী কাজ যেমন tail sampling করে।

৬ · Sampling: কোন trace রাখবেন

প্রতিটি trace চিরদিন রাখা ব্যয়বহুল। তাই sampling লাগে। প্রশ্ন শুধু কখন সিদ্ধান্ত নেবেন, শুরুতে না শেষে।

হিসাব: rate আর হারানোর সম্ভাবনা

Head sampling-এর rate p হলে, N টি error-এর একটিও না ধরার সম্ভাবনা (1 − p)^N. ঘণ্টায় ১০টি error আর p = ১% হলে এটি 0.99¹⁰ = ০.৯০৪, অর্থাৎ প্রায় ৯০% ঘণ্টায় আপনার হাতে একটিও error trace থাকবে না। p = ১০% হলে 0.9¹⁰ = ০.৩৪৯।

আমরা আসল stack-এ ১০০০টি request পাঠালাম, যার ১০টিতে ইচ্ছাকৃত ব্যর্থতা আর ১০টিতে ইচ্ছাকৃত ১.২ সেকেন্ড দেরি। প্রথমে head sampling: OTEL_TRACES_SAMPLER=parentbased_traceidratio, OTEL_TRACES_SAMPLER_ARG=0.1. তারপর সব trace পাঠিয়ে Collector-এ tail_sampling processor. প্রতিবার Jaeger নতুন করে চালু করা হয়েছে।

# head sampling, ratio 0.1
sent 1000 errors 10 slow 10
traces in Jaeger: 84 | spans: 672 | with error: 1 | over 500 ms: 0

# tail sampling: all errors, all over 500 ms, 5% of the rest
sent 1000 errors 10 slow 10
traces in Jaeger: 64 | spans: 512 | with error: 10 | over 500 ms: 15

Tail কম জমা রেখেও সব সমস্যা ধরেছে। Head-এ ধীর ১০টির একটিও নেই, যা আগের হিসাবের ০.৩৪৯ সম্ভাবনার ঘটনা, অদ্ভুত কিছু নয়।

এবার সিদ্ধান্তটি ভেতর থেকে দেখি। বাঁয়ে আমাদের আসল policy-র সংক্ষিপ্ত রূপ, ডানে তিনটি trace: A স্বাভাবিক (৫৭.৭ ms), B ব্যর্থ, C ধীর।

1tail_sampling:2  decision_wait: 5s3  policies:4    keep-errors: status ERROR5    keep-slow: over 500 ms6    keep-5pct-of-rest: 5%7exporters: [otlp/jaeger]

এবার বড় সংখ্যায় দেখি। নিচের কোড একই ট্রাফিকে দুটি পদ্ধতি চালায়। সংখ্যা বদলে দেখুন, বিশেষ করে P_ERROR আর RATE.

// Head vs tail sampling on the same simulated traffic.
function mulberry32(seed) {
  return function () {
    seed = (seed + 0x6D2B79F5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const N = 100000, SPANS = 8;       // traces, spans per trace
const P_ERROR = 0.001, P_SLOW = 0.004, RATE = 0.01;

function run(seed) {
  const rand = mulberry32(seed);
  const head = { kept: 0, err: 0, slow: 0 }, tail = { kept: 0, err: 0, slow: 0 };
  let errors = 0, slows = 0;
  for (let i = 0; i < N; i++) {
    const x = rand();
    const isErr = x < P_ERROR, isSlow = !isErr && x < P_ERROR + P_SLOW;
    errors += isErr; slows += isSlow;
    // Head: decide at the start, knowing nothing about the outcome.
    if (rand() < RATE) { head.kept++; head.err += isErr; head.slow += isSlow; }
    // Tail: decide at the end, when the outcome is known.
    if (isErr || isSlow || rand() < RATE) {
      tail.kept++; tail.err += isErr; tail.slow += isSlow;
    }
  }
  console.log(`seed ${seed}: ${errors} errors, ${slows} slow in ${N} traces`);
  console.log(`  head 1%: kept ${head.kept}, errors ${head.err}, slow ${head.slow}`);
  console.log(`  tail   : kept ${tail.kept}, errors ${tail.err}, slow ${tail.slow}`);
}
[1, 2, 3].forEach(run);
console.log(`\nno sampling stores ${N * SPANS} spans`);

৭ · Metric, log আর trace জোড়া লাগানো

তিনটি সংকেত আলাদা থাকলে আপনি তিনটি tool-এ হাতড়ে বেড়াবেন। জোড়ার সূত্র হলো একটিই: trace id. কাজের ক্রম সাধারণত এমন: metric-এ alert বাজল, সেখান থেকে একটি উদাহরণ trace, trace থেকে ওই request-এর log.

Metric থেকে trace: exemplar. Histogram-এর একটি bucket-এর সাথে একটি উদাহরণ trace id জুড়ে রাখা যায়। Grafana-র মতো tool-এ p99 গ্রাফের একটি বিন্দু চাপলে সরাসরি ওই trace খোলে। OpenMetrics ফরম্যাটে লাইনটি এমন দেখায় (নমুনা আউটপুট, এই run-এ metric চালানো হয়নি, version-ভেদে আলাদা হতে পারে):

http_server_duration_seconds_bucket{le="2.5"} 1017 # {trace_id="42a322d43ae0d3f1b5f444ced406e897"} 1.2269 1793394784.0

#-এর আগে সাধারণ histogram-এর লাইন, পরে exemplar: কোন trace, তার মান আর সময়। Prometheus-এ exemplar রাখার সুবিধা সংস্করণভেদে আলাদাভাবে চালু করতে হতে পারে। মনে রাখবেন, sampling-এ বাদ পড়া trace id দিলে সেই লিংক কানা হবে। তাই exemplar sampled trace থেকে নেওয়া ভালো।

Log থেকে trace. আমাদের app প্রতিটি structured log লাইনে trace_id লিখেছে। এটি পুরোনো correlation id-এর আধুনিক রূপ। নিচের log আমাদের run থেকে নেওয়া, শুধু লাইন ছোট করতে span_id বাদ। একটি error লাইন থেকে পুরো request খুঁজে আনি:

set -euo pipefail
cat > app.log <<'LOG'
{"svc":"shop-api","msg":"checkout received","trace_id":"42a322d43ae0d3f1b5f444ced406e897"}
{"svc":"order-svc","msg":"order received","trace_id":"42a322d43ae0d3f1b5f444ced406e897"}
{"svc":"shop-api","msg":"checkout received","trace_id":"fc01af965cfa8453d8b537cf6fa9b563"}
{"svc":"order-svc","msg":"order received","trace_id":"fc01af965cfa8453d8b537cf6fa9b563"}
{"svc":"payment-svc","msg":"payment received","trace_id":"42a322d43ae0d3f1b5f444ced406e897"}
{"svc":"payment-svc","msg":"payment received","trace_id":"fc01af965cfa8453d8b537cf6fa9b563"}
{"svc":"payment-svc","msg":"bank refused","trace_id":"fc01af965cfa8453d8b537cf6fa9b563","level":"error"}
LOG
# 1. An alert sends you to the error line. Take its trace id.
id=$(grep '"level":"error"' app.log | sed 's/.*"trace_id":"\([0-9a-f]*\)".*/\1/')
echo "trace id: $id"
# 2. Pull every line of that one request, from every service.
grep "$id" app.log | sed -E 's/.*"svc":"([^"]*)","msg":"([^"]*)".*/\1: \2/'
# 3. How much noise did that remove?
echo "all lines: $(wc -l < app.log), this request: $(grep -c "$id" app.log)"

৮ · Queue, async কাজ আর PII

Queue-র ওপারে trace

HTTP-তে caller অপেক্ষা করে, তাই child span parent-এর ভেতরে থাকে। Message queue-তে তা নয়। Producer বার্তা রেখে চলে যায়, consumer হয়তো ৩ মিনিট পরে ধরে। ধারণাটি একই, শুধু header-এর জায়গায় context যায় বার্তার metadata-য়। Span kind হয় producer আর consumer. Queue-তে বসে থাকার সময় (queue time) waterfall-এ ফাঁক হিসেবে দেখা যায়, যা নিজেই একটি বড় রোগ-নির্ণয়ের তথ্য।

Consumer একসাথে ৫০টি বার্তার batch নিলে সমস্যা হয়: একটি span-এর parent তো ৫০টি হতে পারে না। এখানে কাজে লাগে span link. Consumer নিজের trace শুরু করে, আর ৫০টি উৎসের দিকে link রাখে। কিছু দল এক বার্তার ক্ষেত্রেও parent-এর বদলে link নেয়, কারণ ঘণ্টা পরে চলা কাজ একই trace-এ থাকলে waterfall অর্থহীন লম্বা হয়।

# Sample, not run here. Link back to the producer instead of making it parent.
ctx = extract(message.headers)                  # read traceparent from the message
source = trace.get_current_span(ctx).get_span_context()
with tracer.start_as_current_span("email.send",
                                  kind=SpanKind.CONSUMER,
                                  links=[trace.Link(source)]):
    send_email(message.body)

Queue আর event-এর নকশা বিস্তারে আসবে পর্ব ৭০-এ।

Span-এ কী রাখবেন না

Trace-এ অনেক সময় log-এর চেয়েও বেশি তথ্য থাকে, আর অনেক দল সেটি log-এর মতো পাহারা দেয় না। URL-এর query string, database query, request header, exception-এর message, সবখানে PII ঢুকে যেতে পারে। একটি span-এর attribute-এ ক্রেতার ফোন নম্বর বসলে সেটি Collector, backend আর হয়তো অন্য দেশের vendor পর্যন্ত যায়। দেশভেদে ব্যক্তিগত তথ্যের আইন আলাদা, তাই আপনার ক্ষেত্রে কী প্রযোজ্য, আইনজ্ঞের সাথে যাচাই করুন।

• না: password, token, Authorization header, card নম্বর, OTP, NID.
• সতর্ক: ফোন, email, নাম, ঠিকানা, পূর্ণ URL, SQL-এর মান।
• ঠিক আছে: route (/orders/{id}), status code, পেমেন্টের ধরন, সংস্করণ, region.

দুই স্তরে পাহারা দিন। কোডে শুরুতেই না লেখা হলো সবচেয়ে ভালো। আর শেষ জালের মতো Collector-এ attributes/scrub processor, যেমন আমাদের config-এ ছিল। Baggage আরও ঝুঁকির, কারণ এটি header হয়ে বাইরের service-এও চলে যেতে পারে। Trace দেখার অনুমতিও least privilege মেনে দিন, আর retention ছোট রাখুন।

৯ · খরচ আর cloud-এর সেবা

পরীক্ষায় আসার মতো একটি হিসাব করি। ধরে নিই একটি API-তে সেকেন্ডে ২০০ request, প্রতি request-এ ৮টি span, প্রতি span গড়ে ১ KB, আর backend-এ ingest-এর দাম GB-প্রতি $০.৩০. এই দাম শুধু হিসাবের জন্য ধরা। আসল দাম provider-এর pricing page থেকে দেখবেন। আমরা ৩০ দিনের মাস ধরি, আর 1 GB = 10⁹ B.

Tail-এ বাড়তি লাগে Collector-এর memory: decision_wait ১০ সেকেন্ড হলে 1,600 × 10 × 1 KB = ১৬ MB শুধু কাঁচা span-এর জন্য। আসল memory এর কয়েক গুণ হয়, আর ভিড়ের সময়ের জন্য হিসাব করতে হয়। খরচ বাড়ায় বেশি attribute আর exception-এর লম্বা stack trace, এমনকি একটি লুপের ভেতরের span-ও। হাজার বার চলা লুপে span নয়, একটি event বা attribute ভালো।

Cloud provider-এর tracing সেবা

ধারণা একই, নাম আলাদা। Vendor-নিরপেক্ষ পথ হলো কোড OpenTelemetry-তে রাখা, আর Collector থেকে যেখানে দরকার পাঠানো। লেখার সময়ে সবগুলোই কোনো না কোনোভাবে OpenTelemetry-র ডেটা নিতে পারে, তবে পথ ও সীমা সেবা ও সময়ভেদে আলাদা।

হাতে-কলমে করতে চাইলে নিজের machine-এ Jaeger আর Collector container-ই যথেষ্ট, cloud account লাগে না। Cloud-এর সেবায় পরীক্ষা করলে টাকা কাটতে পারে, তাই budget alert রাখুন আর শেষে resource মুছুন। আমাদের run শেষে containers, network আর image নাম ধরে মুছে ফেলা হয়েছে।

১০ · AI-এর যুগে tracing

AI খুব দ্রুত OpenTelemetry-র config লিখে দেয়। কিন্তু এই জগৎ দ্রুত বদলায়, আর পুরোনো উদাহরণ ইন্টারনেটে ভরা। নিচের ভুলগুলো প্রায়ই দেখা যায়:

AI-এর দেওয়া tracing সেটআপের চেকলিস্ট

• Image আর library-র version নির্দিষ্ট, latest নয়
• Collector-এর config আগে throwaway পরিবেশে চালিয়ে warning পড়েছি
• একটি trace খুলে দেখেছি: সব service একই trace id-তে, কোনো ভাঙা নেই
• Span-এর attribute পড়ে দেখেছি: token, PII বা SQL-এর মান নেই
• Sampling-এর rate থেকে মাসিক span আর খরচের হিসাব করেছি, budget alert আছে
• Port সবার জন্য খোলা নয়, TLS আর অনুমতি ঠিক আছে
• মোছার বা বদলানোর কমান্ড বুঝে চালিয়েছি, প্রম্পটে কোনো secret দিইনি