ট্রেসিং: এটি কী, নীতি এবং ডেটা সংগ্রহ

মনিটরিংয়ে ট্রেসিং কী

ট্রেসিং হল ডিস্ট্রিবিউটেড পর্যবেক্ষণের একটি পদ্ধতি যেখানে প্রতিটি আগত অনুরোধ সিস্টেমের সব সার্ভিস এবং উপাদানের মাধ্যমে ট্র্যাক করা হয়। মেট্রিক্সের বিপরীতে, যা সমষ্টিগত মান দেখায় (গড় প্রতিক্রিয়া সময়, ত্রুটির সংখ্যা), ট্রেসিং একটি নির্দিষ্ট অনুরোধের সম্পূর্ণ প্রসঙ্গ সংরক্ষণ করে।

প্রক্রিয়াকরণের প্রতিটি ধাপ — ডেটাবেস কল, অন্য মাইক্রোসার্ভিসে HTTP অনুরোধ, ব্যাকগ্রাউন্ড টাস্ক নির্বাহ — একটি টাইমস্ট্যাম্প, অবস্থা এবং বৈশিষ্ট্যসহ একটি পৃথক ইউনিট হিসেবে রেকর্ড করা হয়। Google Dapper (২০১০-এর মূল প্রকাশনা) অনুসারে, ট্রেসিং ডিস্ট্রিবিউটেড সিস্টেমে একটি মাত্র কলের নির্ভুলতায় বিলম্ব সনাক্ত করতে দেয়।

ট্রেসিং বিশেষ করে মোবাইল অ্যাপ্লিকেশনের জন্য গুরুত্বপূর্ণ যেখানে ব্যাকএন্ড ডজন ডজন মাইক্রোসার্ভিস নিয়ে গঠিত। একটি ব্যবহারকারীর ক্রিয়া — যেমন অ্যাকাউন্টে লগইন — API Gateway, প্রমাণীকরণ সার্ভিস, ডেটাবেস এবং Push সার্ভিসের মধ্য দিয়ে যেতে পারে। ট্রেসিং ছাড়া, কোন উপাদান প্রতিক্রিয়া ধীর করছে তা নির্ধারণ করা প্রায় অসম্ভব।

Spans এবং traces: মৌলিক ডেটা কাঠামো

ট্রেসিংয়ের মৌলিক একক হল span। প্রতিটি span একটি লজিক্যাল অপারেশন উপস্থাপন করে: একটি HTTP অনুরোধ, SQL কোয়েরি, gRPC কল, JSON সিরিয়ালাইজেশন। একটি span-এ একটি অনন্য আইডেন্টিফায়ার, প্যারেন্ট আইডেন্টিফায়ার, অপারেশনের নাম, শুরু সময়, সময়কাল, অবস্থা এবং বৈশিষ্ট্যের একটি সেট থাকে।

একটি trace-এ spans-এর শ্রেণীবিন্যাস

একই মূল অনুরোধের সাথে সম্পর্কিত সব spans একটি trace-এ গোষ্ঠীবদ্ধ হয়। মূল span এন্ট্রি পয়েন্ট উপস্থাপন করে — মোবাইল ক্লায়েন্ট থেকে API-তে একটি HTTP অনুরোধ। চাইল্ড spans একটি গাছ গঠন করে, যেখানে প্রতিটি span parent_span_id ফিল্ডের মাধ্যমে তার প্যারেন্টকে রেফারেন্স করে।

একটি trace-এর সময়কাল সব spans-এর অনন্য সময় বিভাগের সময়কালের যোগফলের সমান। যদি দুটি চাইল্ড span সমান্তরালে নির্বাহিত হয়, তাদের সময় যোগ করা হয় না — সমান্তরাল মাইক্রোসার্ভিস কলের কারণে সৃষ্ট বিলম্ব সঠিকভাবে বিশ্লেষণের জন্য এটি গুরুত্বপূর্ণ।

Span বৈশিষ্ট্য এবং ইভেন্ট

প্রতিটি span-এ বৈশিষ্ট্য থাকতে পারে — মেটা-তথ্যসহ কী-ভ্যালু জোড়া: অনুরোধ URL, ব্যবহারকারী ID, API সংস্করণ, হোস্ট নাম। বৈশিষ্ট্যগুলি ট্রেস ফিল্টার এবং গোষ্ঠীবদ্ধ করতে ব্যবহৃত হয়। বৈশিষ্ট্যের পাশাপাশি, spans ইভেন্ট সমর্থন করে — টেক্সট বর্ণনাসহ টাইমস্ট্যাম্প, যেমন "ক্যাশ মিস" বা "সংযোগ পুনরায় চেষ্টা"।

ডিস্ট্রিবিউটেড ট্রেসিং কীভাবে কাজ করে

ডিস্ট্রিবিউটেড ট্রেসিং বিভিন্ন প্রক্রিয়া এবং বিভিন্ন মেশিনে তৈরি spans সংযুক্ত করার সমস্যা সমাধান করে। প্রক্রিয়াটি কনটেক্সট প্রপাগেশনের উপর ভিত্তি করে: যখন সার্ভিস A সার্ভিস B-কে কল করে, তখন বাহিরগামী অনুরোধে বর্তমান trace ID এবং প্যারেন্ট span ID সহ একটি হেডার যোগ করা হয়।

মানক কনটেক্সট প্রপাগেশন প্রোটোকল হল W3C Trace Context (traceparent এবং tracestate হেডার) এবং Zipkin B3 (X-B3-TraceId, X-B3-SpanId হেডার)। W3C Trace Context ২০২১ সালে W3C কনসোর্টিয়াম দ্বারা একটি মান হিসেবে গৃহীত হয়েছিল এবং এটি সব প্রধান টেলিমেট্রি প্রদানকারী দ্বারা সমর্থিত।

অনুরোধ পাওয়ার পর, সার্ভিস B হেডার থেকে trace_id বের করে এবং সেই trace_id দিয়ে একটি চাইল্ড span তৈরি করে। এইভাবে, অনুরোধ সম্পূর্ণ হওয়ার পর, বিভিন্ন সার্ভিসের সব spans কালেক্টরের পাশে একটি single trace-এ একত্রিত হয়। এর জন্য প্রতিটি সার্ভিসকে একই ট্রেসিং লাইব্রেরি দিয়ে ইন্সট্রুমেন্টেড হতে হবে।

মাইক্রোসার্ভিসে কনটেক্সট প্রপাগেশন

মোবাইল ডেভেলপমেন্টে, কনটেক্সট প্রপাগেশন শুধু ব্যাকএন্ডই নয়, ক্লায়েন্ট-সার্ভার ইন্টারঅ্যাকশনকেও কভার করে। একটি মোবাইল অ্যাপ্লিকেশন প্রতিটি API অনুরোধের হেডারে trace_id পাঠাতে পারে, যা ক্লায়েন্ট ক্রিয়াকে সার্ভার-সাইড প্রসেসিংয়ের সাথে সংযুক্ত করতে দেয়। iOS এবং Android-এর জন্য OpenTelemetry SDK HTTP ক্লায়েন্টের মাধ্যমে স্বয়ংক্রিয় ট্রেস কনটেক্সট তৈরি এবং প্রপাগেশন সমর্থন করে।

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

উপস্থাপিত Kotlin ইন্টারসেপ্টর সার্ভারে প্রতিটি HTTP অনুরোধের জন্য একটি span তৈরি করে। প্যারেন্ট কনটেক্সট Context.current()-এর মাধ্যমে কলিং কোড থেকে প্রপাগেট হয়, যা ক্লায়েন্ট-সাইড ট্রেসিংকে সার্ভার-সাইড ট্রেসিংয়ের সাথে সংযুক্ত করতে দেয়।

OpenTelemetry এর মাধ্যমে ট্রেসিং বাস্তবায়ন

OpenTelemetry ট্রেস ডেটা সংগ্রহের জন্য ডি ফ্যাক্টো মান। এটি spans তৈরি করার জন্য একটি ইউনিফাইড API, জনপ্রিয় লাইব্রেরির স্বয়ংক্রিয় ইন্সট্রুমেন্টেশন এবং বিভিন্ন ব্যাকএন্ডে ডেটা এক্সপোর্ট করার জন্য একটি নমনীয় প্রক্রিয়া প্রদান করে: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic।

স্বয়ংক্রিয় ইন্সট্রুমেন্টেশন

OpenTelemetry জনপ্রিয় ফ্রেমওয়ার্কের জন্য স্বয়ংক্রিয় span তৈরি সমর্থন করে: Spring Boot, Ktor, Flask, Express, gRPC। ডেভেলপারকে শুধু প্রকল্পে একটি নির্ভরতা যোগ করতে হয়, এবং লাইব্রেরি স্বয়ংক্রিয়ভাবে আগত এবং বহির্গামী অনুরোধ আটকায়। Java-র জন্য অটো-ইন্সট্রুমেন্টেশন একটি javaagent ব্যবহার করে যা সোর্স কোড পরিবর্তন না করেই ফ্লাইতে বাইটকোড সংশোধন করে।

মোবাইল প্ল্যাটফর্মের জন্য, OpenTelemetry Swift SDK এবং Kotlin SDK প্রদান করে। তারা নেটওয়ার্ক অনুরোধ (URLSession, OkHttp), ডেটাবেস অপারেশন (CoreData, Room) এবং ব্যাকগ্রাউন্ড টাস্কের জন্য স্বয়ংক্রিয়ভাবে spans তৈরি করে। ডেভেলপার বিজনেস লজিকের জন্য কাস্টম spans যোগ করতে পারে।

ডেটা এক্সপোর্ট

সংগৃহীত spans OTLP (OpenTelemetry Protocol) এর মাধ্যমে কালেক্টরে পাঠানো হয়। কালেক্টর ডেটা বাফার, ফিল্টার এবং এক বা একাধিক স্টোরেজ সিস্টেমে ফরওয়ার্ড করতে পারে। OpenTelemetry ডকুমেন্টেশন অনুসারে, gRPC এক্সপোর্ট ব্যবহার করার সময় span তৈরি থেকে ড্যাশবোর্ডে প্রদর্শন পর্যন্ত সাধারণ বিলম্ব ২–৫ সেকেন্ড।

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

Swift কোড নেটওয়ার্কিং লেয়ারের স্বয়ংক্রিয় ইন্সট্রুমেন্টেশন সক্রিয় করে এবং ব্যবহারকারী প্রোফাইল পুনরুদ্ধার অপারেশনের জন্য একটি কাস্টম span তৈরি করে। user.id বৈশিষ্ট্য পরবর্তীতে নির্দিষ্ট ব্যবহারকারী দ্বারা ট্রেস ফিল্টার করতে দেয়।

ট্রেস স্যাম্পলিং কৌশল

উচ্চ-লোড সিস্টেমে, প্রতিটি অনুরোধ ট্রেস করা অসম্ভব — এটি স্টোরেজ এবং নেটওয়ার্কে অগ্রহণযোগ্য চাপ সৃষ্টি করে। স্যাম্পলিং শুধু ট্রেসের একটি অংশ সংরক্ষণ করে এই সমস্যার সমাধান করে। কৌশলের পছন্দ সরাসরি ডেটা সম্পূর্ণতা এবং পরিকাঠামো খরচকে প্রভাবিত করে।

হেড-বেসড স্যাম্পলিং

ট্রেস সংরক্ষণের সিদ্ধান্ত তার তৈরির সময় — মূল span-এ নেওয়া হয়। সবচেয়ে সহজ এবং সাধারণ পদ্ধতি: অনুরোধের একটি নির্দিষ্ট শতাংশ (যেমন, ৫%) সংরক্ষিত হয়, বাকি বাতিল করা হয়। অসুবিধা — বিরল ত্রুটিগুলি ধরা হবে বলে নিশ্চিত করা যায় না। OpenTelemetry-তে Probability sampler ০.০ থেকে ১.০ পর্যন্ত সম্ভাব্যতা সেটিং সমর্থন করে।

টেল-বেসড স্যাম্পলিং

সিদ্ধান্ত ট্রেসের সব span সম্পূর্ণ না হওয়া পর্যন্ত স্থগিত করা হয়। একটি বিশ্লেষক মূল্যায়ন করে যে ট্রেসটিতে ত্রুটি, সময়সীমা অতিক্রম বা আকর্ষণীয় বৈশিষ্ট্য আছে কিনা, এবং তবেই তা সংরক্ষণ করে। এই পদ্ধতির জন্য কালেক্টরে সব span বাফার করা প্রয়োজন, যা মেমরি খরচ বাড়ায়। Grafana Labs অনুসারে, বিরল কিন্তু গুরুত্বপূর্ণ ত্রুটিযুক্ত সিস্টেমে "প্রতি উপযোগী ডেটা খরচ" এর ক্ষেত্রে টেল-বেসড স্যাম্পলিং ৪০–৬০% বেশি কার্যকর।

ট্রেসিং এবং লগিংয়ের পার্থক্য

লগিং গুরুত্ব স্তর (info, warn, error) সহ পৃথক ইভেন্ট রেকর্ড করে কিন্তু একটি অনুরোধের প্রসঙ্গে তাদের সংযুক্ত করে না। ট্রেসিং, বিপরীতে, একটি এন্ড-টু-এন্ড অনুরোধের অন্তর্গত অপারেশনের একটি কাঠামোবদ্ধ গাছ তৈরি করে। বাস্তবে, এই দুটি পদ্ধতি পরস্পরবিরোধী নয় বরং একে অপরের পরিপূরক।

লগ একটি নির্দিষ্ট ত্রুটির বিস্তারিত বিশ্লেষণের জন্য কার্যকর: ডেভেলপার সঠিক বার্তা, স্ট্যাক ট্রেস এবং ভেরিয়েবলের মান দেখে। ট্রেসিং প্রশ্নের উত্তর দেয় "অনুরোধটি ৫ সেকেন্ড কেন নিচ্ছে" — এটি দেখায় কোন মাইক্রোসার্ভিস বা কল সবচেয়ে বেশি সময় নিয়েছে। Honeycomb (2024) অনুসারে, লগিংয়ের সাথে ট্রেসিং ব্যবহারকারী দলগুলি ঘটনার মূল কারণ ২.৩ গুণ দ্রুত খুঁজে পায়।

আধুনিক পদ্ধতি — অবজার্ভেবিলিটি — ট্রেসিং, মেট্রিক্স এবং লগকে একটি একক সিস্টেমে একত্রিত করে। OpenTelemetry এই তিনটি সংকেতের মধ্যে সম্পর্ক সমর্থন করে: প্রতিটি span সম্পর্কিত লগের লিংক ধারণ করতে পারে, এবং মেট্রিক্স নির্দিষ্ট ট্রেসে ড্রিল ডাউন করার জন্য trace_id দিয়ে ট্যাগ করা যেতে পারে।