বিতরণ করা ট্রেসিং: অতীত, বর্তমান এবং ভবিষ্যত

ডিস্ট্রিবিউটেড ট্রেসিং একটি বিভক্ত বিষয়। একবার প্রতিটি KubeCon এর doyen , প্রযুক্তিটি পর্যবেক্ষণযোগ্যতার বিপ্লব ঘটাবে বলে আশা করা হয়েছিল।

ফাস্ট ফরোয়ার্ড 5 বছর, হাইপ কিছুটা কমে গেছে, ব্যথা সম্পর্কে আরও অনেক কথা আছে, এবং গ্রহণ মধ্যম। ইতিমধ্যে, প্রযুক্তি সম্প্রসারণ এবং মানককরণের বিষয়ে অবিচলিত কার্যকলাপ অব্যাহত রয়েছে - ওপেন টেলিমেট্রি (ওপেনট্রেসিং-এর উপর ভিত্তি করে) কুবারনেটসের পরে দ্বিতীয় বৃহত্তম সিএনসিএফ প্রকল্প । তাহলে ডিস্ট্রিবিউটেড ট্রেসিং এর সাথে চুক্তি কি? এক অবিলম্বে এটি বাস্তবায়ন বা অপেক্ষা করুন এবং দেখুন উচিত?

এই নিবন্ধে, আসুন ডিস্ট্রিবিউটেড ট্রেসিংকে গভীরভাবে অন্বেষণ করি

1. ডিস্ট্রিবিউটেড ট্রেসিং সম্পর্কে বিশেষ কী এবং কেন আমাদের এটি দরকার?
2. আজ ডিস্ট্রিবিউটেড ট্রেসিং এর সমস্যা কি কি?
3. আসন্ন উন্নয়ন কি এবং তারা বিদ্যমান চ্যালেঞ্জ মোকাবেলা কিভাবে?

ভূমিকা - কীভাবে বিতরণ করা ট্রেসিং কাজ করে

অপ্রচলিতদের জন্য, ডিস্ট্রিবিউটেড ট্রেসিং হল এমন একটি প্রযুক্তি যা আমাদেরকে একটি একক অনুরোধ ট্র্যাক করতে দেয় কারণ এটি একটি বিতরণ করা পরিবেশের বিভিন্ন উপাদান/মাইক্রোসার্ভিস অতিক্রম করে। অনুরোধের পথে করা প্রতিটি নেটওয়ার্ক কল ক্যাপচার করা হয় এবং একটি স্প্যান হিসাবে উপস্থাপন করা হয়।

এটি সক্ষম করার জন্য, বিতরণ করা ট্রেসিং সরঞ্জামগুলি প্রতিটি অনুরোধের শিরোনামে একটি অনন্য ট্রেস প্রসঙ্গ (ট্রেস আইডি) সন্নিবেশ করায় এবং অনুরোধের পথ জুড়ে ট্রেস প্রসঙ্গটি প্রচারিত হয়েছে তা নিশ্চিত করার জন্য প্রক্রিয়াগুলি প্রয়োগ করে৷

কিভাবে একটি বিতরণ ট্রেস একটি অনুরোধ পাথ প্রতিনিধিত্ব করে

কেন আমাদের প্রথমে ডিস্ট্রিবিউটেড ট্রেসিং দরকার

বিতরণ করা ট্রেসিং অনন্য কারণ এটি পর্যবেক্ষণের জন্য একক হিসাবে একটি অনুরোধের উপর ফোকাস করে। একটি পর্যবেক্ষণ/মেট্রিক্স প্ল্যাটফর্মে, একটি উপাদান (যেমন, একটি পরিষেবা, হোস্ট) হল মৌলিক একক যা পর্যবেক্ষণ করা হচ্ছে। সময়ের সাথে সাথে এই ইউনিটের আচরণ সম্পর্কে কেউ এই প্ল্যাটফর্মগুলিকে প্রশ্ন করতে পারে। উদাহরণস্বরূপ, একটি নির্দিষ্ট সময়সীমার মধ্যে এই পরিষেবাটির স্বাস্থ্য/থ্রুপুট/ত্রুটির হার কত?

লগের সাহায্যে, যে মৌলিক এককটি পরিলক্ষিত হচ্ছে সেটি হল একটি ইভেন্ট - যেমন, কোড এক্সিকিউশনের সময় যখনই কোনো ঘটনা ঘটে, কিছু তথ্য প্রিন্ট করুন। কোড লেখার সময় এই "ইভেন্টগুলি" বিকাশকারীদের দ্বারা বিষয়গতভাবে সংজ্ঞায়িত করা হয়। লগের সাথে চ্যালেঞ্জ হল যে তারা সকলেই বিচ্ছিন্ন, প্রতিটি উপাদান বিচ্ছিন্নভাবে লগ বার্তাগুলির নিজস্ব ফর্ম মুদ্রণ করে, বোঝার জন্য তাদের একসাথে সংযুক্ত করার কোনও সহজ উপায় নেই।

বিপরীতে, বিতরণকৃত ট্রেসিংয়ের সাথে যা পর্যবেক্ষণ করা হচ্ছে তা একটি একক অনুরোধ কারণ এটি বিভিন্ন উপাদান অতিক্রম করে। এটি আমাদেরকে সামগ্রিকভাবে বিতরণ করা সিস্টেম সম্পর্কে প্রশ্ন জিজ্ঞাসা করতে এবং একটি জটিল, আন্তঃসংযুক্ত সিস্টেমে কোথায় ঘটেছে তা বোঝার অনুমতি দেয়।

ডিস্ট্রিবিউটেড ট্রেসিং-এর মূল কেসটি এই যুক্তিতে নিহিত যে অনুরোধের চারপাশে এই অভিযোজন শেষ ব্যবহারকারীর অভিজ্ঞতার সবচেয়ে কাছাকাছি । এবং ফলস্বরূপ, আমরা কীভাবে বিতরণ করা আর্কিটেকচারগুলি পরীক্ষা এবং সমস্যা সমাধান করতে চাই তার জন্য এটি সবচেয়ে স্বজ্ঞাত।

ডিস্ট্রিবিউটেড ট্রেসিংয়ের বিবর্তন

বিগত দশকে বিতরণকৃত সফ্টওয়্যার আর্কিটেকচারের ব্যাপকভাবে গ্রহণের কারণে ডিস্ট্রিবিউটেড ট্রেসিংয়ের গুরুত্ব বেড়েছে।

আধুনিক মাইক্রোসার্ভিসেস-ভিত্তিক আর্কিটেকচার হল 90 এর দশকের শেষের ইন্টারনেট বৃদ্ধির গল্প থেকে একটি বিবর্তন, যখন এটি অনুরোধ-প্রতিক্রিয়া সিস্টেমগুলি ব্যবহার করা সাধারণ হয়ে ওঠে।

"90 এর দশকের শেষের দিকে এবং ইন্টারনেটের বিস্ফোরক বৃদ্ধির সাথে, একটি ওয়েব সার্ভার ফ্রন্টএন্ড এবং একটি ডাটাবেস ব্যাকএন্ড সহ অনুরোধ-প্রতিক্রিয়া সিস্টেমের বিশাল প্রসার ঘটেছে, যেমন দ্বি-স্তরের ওয়েবসাইটগুলি... অনুরোধগুলি সিস্টেম সম্পর্কে যুক্তির জন্য একটি নতুন মাত্রা ছিল , সমষ্টিগতভাবে যে কোনো একটি মেশিন বা প্রক্রিয়ার অর্থোগোনাল।"

- অনুশীলনে বিতরণ করা ট্রেসিং, ও'রিলি মিডিয়া

এই মাইক্রোসার্ভিসেস আর্কিটেকচারে, প্রতিটি একক অনুরোধ অনেকগুলিকে আঘাত করে (10s বা এমনকি 100s মাইক্রোসার্ভিসেস), এর মধ্যে বেশ কয়েকটি নেটওয়ার্ক কল করে। Uber-এর মাইক্রোসার্ভিসেস আর্কিটেকচারের জন্য নীচে পড়ুন, যেখানে 3000+ পরিষেবা রয়েছে।

2018 থেকে উবারের মাইক্রোসার্ভিসেস আর্কিটেকচার। উৎস: https://www.uber.com/en-IN/blog/microservice-architecture/

এই ধরনের জটিল সিস্টেমে, ডিস্ট্রিবিউটেড ট্রেসিং যেকোনো ধরনের সমস্যা সমাধানের জন্য গুরুত্বপূর্ণ হয়ে ওঠে। ফলস্বরূপ, ডিস্ট্রিবিউটেড ট্রেসিং বৃহৎ কোম্পানীগুলির দ্বারা অগ্রণী ছিল যেগুলি বড়, জটিল, বিতরণ করা পরিবেশ ব্যবহার করে প্রাথমিকভাবে গ্রহণকারী ছিল।

• 2010 সালে প্রকাশিত Google এর ড্যাপার পেপারটি বিতরণ ট্রেসিংয়ের সূচনা ছিল

  
  

• পরের কয়েক বছরে, আরও দুটি কোম্পানি তাদের নিজস্ব বিতরণ করা ট্রেসিং সিস্টেমকে ওপেন-সোর্স করেছে (2012 সালে টুইটার ওপেন-সোর্সড জিপকিন এবং 2017 সালে উবার ওপেন-সোর্সড জাইগার)। Zipkin এবং Jaeger আজও সবচেয়ে জনপ্রিয় বিতরণ করা ট্রেসিং সরঞ্জামগুলির মধ্যে রয়েছে

  
  

• 2016 সাল থেকে, ওপেনট্রেসিং প্রকল্পের মাধ্যমে সমস্ত উপাদান জুড়ে বিতরণ ট্রেসিংকে মানক করার জন্য একটি উল্লেখযোগ্য প্রচেষ্টা করা হয়েছে। OpenTracing অবশেষে 2019 সালে OpenTelemetry হয়ে ওঠে। OpenTelemetry ব্যাপকভাবে জনপ্রিয় এবং বিশ্বব্যাপী এর হাজার হাজার অবদানকারী রয়েছে

  
  

• এখন ডিস্ট্রিবিউটেড ট্রেসিং ব্যাপকভাবে মেট্রিক্স এবং লগের পাশাপাশি পর্যবেক্ষণের তৃতীয় "স্তম্ভ" হিসাবে বিবেচিত হয়। বেশিরভাগ প্রধান পর্যবেক্ষণ এবং পর্যবেক্ষণযোগ্যতা খেলোয়াড় তাদের পণ্যের অংশ হিসাবে বিতরণ করা ট্রেসিং সরঞ্জাম সরবরাহ করে।

ডিস্ট্রিবিউটেড ট্রেসিংয়ের অবস্থা: তত্ত্ব বনাম বাস্তবতা

যাইহোক, প্রতিশ্রুতি, উত্তেজনা এবং সম্প্রদায়ের প্রচেষ্টা সত্ত্বেও, আজ বিতরণকৃত ট্রেসিং গ্রহণ প্রায় ~25%। মাইক্রোসার্ভিসেস আর্কিটেকচারে কোম্পানিগুলি খুঁজে পাওয়া অস্বাভাবিক নয় যারা লগ এবং মেট্রিক্সের সাথে কাজ করছে, যদিও তাদের স্পষ্টভাবে বিতরণ ট্রেসিং প্রয়োজন।

একই সময়ে, আজ বিশ্বে গড়-সময়-টু-সমাধান উত্পাদন ত্রুটিগুলি বেড়ে চলেছে। 73% কোম্পানি রিপোর্ট করে যে আজ উৎপাদন সমস্যা সমাধান করতে এক ঘন্টার বেশি সময় লাগে ।

যেকোনো বিকাশকারীকে জিজ্ঞাসা করুন তাদের জীবনের সবচেয়ে বেদনাদায়ক মুহূর্তগুলি কী এবং তারা উৎপাদনে একটি Sev-1 ত্রুটি ডিবাগ করার সময় কাটানো সময় সম্পর্কে কথা বলবে যা দেখে মনে হচ্ছে কয়েকশ লোক তাদের ঘাড় নিঃশ্বাস নিচ্ছে।

তখন মনে হয়, যে কোনো কোম্পানি যে তার MTTR (যা প্রায় প্রতিটি কোম্পানি) সম্পর্কে যত্নশীল তাদের ডিস্ট্রিবিউটেড ট্রেসিং ব্যবহার করা উচিত এবং এই পরিবেশে গ্রহণ করা উচিত ছিল আকাশচুম্বী। কিন্তু প্রকৃত সংখ্যা যে সমর্থন করে না - তাই কি দেয়?

আজ ডিস্ট্রিবিউটেড ট্রেসিং এর সাথে চ্যালেঞ্জ

ডিস্ট্রিবিউটেড ট্রেসিং নিয়ে আজ বেশ কিছু সমস্যা রয়েছে যা কোম্পানিগুলিকে মান পেতে হলে কাটিয়ে উঠতে হবে - যার সবগুলোই মূলধারার বর্ণনায় ব্যাপকভাবে আলোচিত হয় না।

1. বাস্তবায়ন কঠিন!

আজ একটি পরিষেবাতে বিতরণ করা ট্রেসিং বাস্তবায়ন করতে, আমাদের একটি কোড পরিবর্তন এবং একটি প্রকাশ করতে হবে। যদিও কোড পরিবর্তন করা একটি সাধারণ-পর্যাপ্ত পর্যবেক্ষনের জন্য চাওয়া, বিশেষত বিতরণ করা ট্রেসিংয়ের সাথে চ্যালেঞ্জটি হল এই - e একটি বিতরণ করা ট্রেস পেতে বা ট্রেস ব্রেক করার জন্য খুব পরিষেবা বা উপাদানের সাহায্য করা দরকার।

কেউ শুধুমাত্র একটি একক পরিষেবা দিয়ে শুরু করতে পারে না - যেমন কেউ পর্যবেক্ষণ বা লগিং করে - এবং মূল্য উপলব্ধি করতে পারে। ডিস্ট্রিবিউটেড ট্রেসিংয়ের জন্য ব্যবহারযোগ্য ট্রেস তৈরি করতে পরিষেবাগুলির একটি সম্মিলিত সেট জুড়ে উপকরণের প্রয়োজন।

এটি তাদের পরিষেবাগুলিতে পরিবর্তন করার জন্য বেশ কয়েকটি দল এবং পরিষেবা মালিকদের মধ্যে সমন্বয় প্রয়োজন৷ সুতরাং এটি একটি সাংগঠনিক সমস্যা হয়ে দাঁড়ায়- আপনি মূল্য উপলব্ধি করতে পারার আগে কয়েক মাস ধরে 100 টি দলকে তাদের পরিষেবার উপকরণ দেওয়ার জন্য কল্পনা করুন।

এটি আজ বিতরণ করা ট্রেসিংয়ের সাথে সবচেয়ে বড় চ্যালেঞ্জ।

2. জটিল নমুনা সিদ্ধান্তের জন্য প্রয়োজন

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

লগিংও একই কাজ করে (এবং প্রতি অনুরোধে আরও ডেটা নির্গত করে, যা পরে বিশাল লগ অ্যাগ্রিগেশন টুলস দ্বারা পরিচালিত হয়), পার্থক্য হল যে বেশিরভাগ কোম্পানির ইতিমধ্যেই লগিং আছে । আরও একটি ডেটা টাইপ প্রবর্তন করা যা প্রায় লগিংয়ের মতোই বিশাল হতে চলেছে এবং এটি সম্ভবত ব্যয় দ্বিগুণ করবে।

খরচের এই সমস্যাটি পরিচালনা করার জন্য, সমস্ত বিতরণ করা ট্রেসিং সিস্টেম আজ নমুনা ব্যবহার করে এবং শুধুমাত্র ট্রেসের একটি উপসেট রেকর্ড করে। সাধারণ স্যাম্পলিং রেট বর্তমানে 0.1% থেকে 2% এর মধ্যে। যুক্তি হল যে এমনকি 1% নমুনাও পারফরম্যান্সের প্রতিবন্ধকতাগুলির একটি শালীন সামগ্রিক চিত্র দেওয়ার জন্য যথেষ্ট।

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

3. কিন্তু নমুনা অর্থপূর্ণভাবে মান হ্রাস করে

ধরা যাক একটি কোম্পানী প্রতিটি পরিষেবা/কম্পোনেন্টকে ইনস্ট্রুমেন্ট করার প্রচেষ্টার মধ্য দিয়ে যায় এবং তারপরে তারা ব্যাঙ্ক ভাঙতে না পারে তা নিশ্চিত করার জন্য নমুনা নেওয়ার কৌশল নির্ধারণ করে।

এখন কী - আমাদের কি MTTR নাটকীয়ভাবে কমে যাওয়ার আশা করা উচিত? না, কারণ স্যাম্পলিংয়ের কারণে ডেভেলপাররা আসলে সমস্যা সমাধানের জন্য ডিস্ট্রিবিউটেড ট্রেসিং ব্যবহার করতে পারে না।

একজন বিকাশকারীর অভিজ্ঞতা কল্পনা করুন - "আমি যে সমস্যাটি জানি তা খুঁজে পাচ্ছি না। আমি ত্রুটি তৈরি করেছি, কিন্তু আমি সংশ্লিষ্ট ট্রেস খুঁজে পাচ্ছি না"।

তাহলে কি হয়? বিকাশকারীরা বিতরণ করা ট্রেসিং ডেটার গুণমানকে বিশ্বাস করা বন্ধ করে এবং ডিবাগিং/ সমস্যা সমাধানের জন্য তাদের নিয়মিত পদ্ধতিতে ফিরে যায় (যেমন, লগ ব্যবহার করে)

4. বিকাশকারীর ব্যবহার কম ফ্রিকোয়েন্সি

এই সীমাবদ্ধতার প্রেক্ষিতে, আজ ডিস্ট্রিবিউটেড ট্রেসিং প্রাথমিকভাবে কর্মক্ষমতা সমস্যা সমাধানের উপায় হিসেবে বিক্রি করা হয়।

মনে রাখবেন যে একটি মৌলিক বিতরণ করা ট্রেস আসলেই আমাদের বলে যে কে কে কল করেছে এবং প্রতিটি স্প্যান কত সময় নিয়েছে। বিতরণ করা ট্রেস আমাদের বলে না যে পরিষেবার মধ্যে কী ঘটেছে যা ত্রুটি/উচ্চ বিলম্বের কারণ। এর জন্য, বিকাশকারীদের এখনও লগ বার্তাটি দেখতে হবে এবং/অথবা ডিবাগ করার জন্য স্থানীয়ভাবে সমস্যাটি পুনরুত্পাদন করতে হবে।

একটি সাধারণ কোম্পানিতে, কর্মক্ষমতা সংক্রান্ত সমস্যাগুলি সম্ভবত মোটের 10% কম। তাই বাস্তবে, ডিস্ট্রিবিউটেড ট্রেসিং শুধুমাত্র সমস্যার এই ছোট অংশের জন্যই উপযোগী।

গড় ডেভেলপার যিনি একটি পরিষেবা পাঠান এবং মালিক হন তারা বছরে 2-3 বার একটি বিতরণ করা ট্রেসিং টুল ব্যবহার করছেন।

এই সমস্ত চ্যালেঞ্জের প্রভাব

সংক্ষেপে:

1. বিতরণ করা ট্রেসিং বাস্তবায়ন করা কঠিন
2. ডিস্ট্রিবিউটেড ট্রেসিংয়ের খরচ নিয়ন্ত্রণের জন্য ব্যাপক নমুনা প্রয়োজন
3. কিন্তু স্যাম্পলিং মান যথেষ্ট কমিয়ে দেয়
4. ফলস্বরূপ, বিকাশকারীরা শুধুমাত্র অদ্ভুত এক-অফ পারফরম্যান্স ব্যবহারের ক্ষেত্রে ট্রেসিং ব্যবহার করে

এই সমস্ত বিতরণ ট্রেসিংয়ের জন্য RoI কেসটিকে বেশ অস্পষ্ট করে তোলে।

একটি সাধারণ হাইপ চক্রে, আমরা যা বলতে পারি তা হ'ল আমরা এখন স্ফীত প্রত্যাশার পর্যায় অতিক্রম করেছি এবং মোহভঙ্গ স্থির হতে শুরু করেছে।

আমরা যদি শেষ-রাজ্যের পরিপ্রেক্ষিতে চিন্তা করি, যদিও কম্পিউটিং সিস্টেমের ভবিষ্যত বিতরণ করা হয়, তবে বিতরণ করা ট্রেসিং স্বাভাবিকভাবেই পর্যবেক্ষণযোগ্যতার জন্য সবচেয়ে মৌলিক ভেক্টর। সেই বিশ্বে, বিতরণকৃত আর্কিটেকচার সহ যেকোন কোম্পানি উৎপাদনে ঘটতে থাকা যেকোনো সমস্যা সমাধানের প্রাথমিক প্রক্রিয়া হিসাবে ট্রেসিং ব্যবহার করে - সত্যিকারের "পর্যবেক্ষণযোগ্যতা" - বনাম আমাদের আজকের সিস্টেমগুলির নিষ্ক্রিয় পর্যবেক্ষণ।

যদিও আমরা সেই শেষ-অবস্থায় পৌঁছানোর আগে, আমাদের স্থিতাবস্থার উপর বেশ কিছু উন্নতির প্রয়োজন হবে। ভাল খবর হল যে এর অনেকটাই ইতিমধ্যে চলছে। আসুন তাদের প্রতিটি তাকান. তাই আমরা ভবিষ্যতে কি দেখতে আশা করতে পারেন?

বিতরণ ট্রেসিং এর ভবিষ্যত

কোন কোড পরিবর্তন ছাড়াই তাত্ক্ষণিক যন্ত্র

একটি এজেন্টকে ড্রপ করার কল্পনা করুন এবং কোড পরিবর্তন ছাড়াই একবারে একটি সম্পূর্ণ বিতরণ করা সিস্টেম (সমস্ত পরিষেবা, উপাদান) কভার করতে সক্ষম হচ্ছেন।

এটি আগামী 2-3 বছরে বাস্তবসম্মতভাবে সম্ভব বলে মনে হচ্ছে।

OpenTelemetry-এর অটো-ইনস্ট্রুমেন্টেশন লাইব্রেরিগুলি ইতিমধ্যেই কিছু প্রোগ্রামিং ভাষার জন্য এটি সক্ষম করে (তবে Go এর মতো সংকলিত ভাষাগুলিতে কম পড়ে)। সমান্তরালভাবে, eBPF-এর মতো প্রযুক্তিগুলি কোনও কোড পরিবর্তন ছাড়াই সিস্টেম-ওয়াইড ইন্সট্রুমেন্টেশন সক্ষম করতে বিকশিত হচ্ছে৷ উভয়ের মধ্যে, আমরা নিরাপদে আশা করতে পারি যে কয়েক বছরের মধ্যে ইন্সট্রুমেন্টেশন সমস্যাটি সমাধান করা হবে।

স্যাম্পলিং এআই-ভিত্তিক আগ্রহের অনুরোধের নির্বাচনের পথ দেয়

একটি এলএলএম বিশ্বে, এলোমেলো নমুনা অন্ধকার যুগ থেকে একটি ধ্বংসাবশেষের মতো দেখতে শুরু করে। আদর্শভাবে, আমাদের 100% ট্রেস দেখতে, অস্বাভাবিক দেখায় এমন কিছু সনাক্ত করতে এবং ভবিষ্যতে পরীক্ষার জন্য সংরক্ষণ করতে সক্ষম হওয়া উচিত। আর র্যান্ডম স্যাম্পলিং নেই।

যদি আমরা এটি সম্পর্কে চিন্তা করি, আমরা সত্যিই ~95% "সুখী অনুরোধ" সম্পর্কে চিন্তা করি না। আমরা শুধুমাত্র ~5% অস্বাভাবিক ট্রেস - ত্রুটি, ব্যতিক্রম, উচ্চ বিলম্ব, বা কিছু ধরণের নরম ত্রুটির বিষয়ে যত্নশীল। তাই আমাদের 100% দেখার এবং আকর্ষণীয় 5% বাছাই করার একটি উপায় দরকার।

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

টেইল-ভিত্তিক স্যাম্পলিংয়ের প্রধান চ্যালেঞ্জ হল যে পুরো অনুরোধটি সম্পূর্ণ না হওয়া পর্যন্ত আপনাকে একটি ট্রেসের সমস্ত স্প্যান সংরক্ষণ করতে হবে এবং তারপরে ট্রেসটি রাখা/বাতিল করার সিদ্ধান্ত নিতে হবে। এর অর্থ হল আমরা একটি নির্দিষ্ট সময়ের জন্য (অনুরোধ সম্পূর্ণ না হওয়া পর্যন্ত) প্রতিটি একক অনুরোধ, সমস্ত স্প্যান সহ সঞ্চয় করি - এর জন্য লোড-ব্যালেন্সিং, স্টোরেজ এবং প্রক্রিয়াকরণের জন্য উপাদান সহ একটি পৃথক ডেটা আর্কিটেকচার প্রয়োজন যা অত্যন্ত জটিল এবং ব্যয়বহুল।

OpenTelemetry-এর একটি টেইল-ভিত্তিক স্যাম্পলিং সংগ্রাহক রয়েছে, তবে, এটি এখনও পরিপক্ক নয় এবং এর বেশ কয়েকটি স্কেলেবিলিটি চ্যালেঞ্জ রয়েছে (উপরে উল্লিখিত সমস্যার কারণে)। ইতিমধ্যে, ZeroK.ai সহ বেশ কয়েকটি কোম্পানি অসঙ্গতি সনাক্তকরণকে দক্ষ এবং মাপযোগ্য করতে AI ব্যবহার করার জন্য কাজ করছে।

এই স্থানের উন্নয়নের দ্রুত গতির সাথে, আমরা যুক্তিসঙ্গতভাবে আশা করতে পারি যে আগামী 3-5 বছরের মধ্যে এই সমস্যাটিও সমাধান হবে।

"সমৃদ্ধ" বিতরণ করা ট্রেসের উত্থান যা সমস্ত ডিবাগিং সক্ষম করে

ট্রেসিং এর পরবর্তী প্রজন্মের মধ্যে একটি সত্যিকারের লাফ হবে যখন ট্রেসিং "শুধুমাত্র কর্মক্ষমতা সমস্যা" থেকে "সমস্ত সমস্যা" তে বিবর্তিত হবে। তখনই বিতরণ করা ট্রেসিংয়ের প্রকৃত শক্তি প্রকাশ পায়।

এটি সম্ভব হওয়ার জন্য, প্রতিটি ট্রেসের সমৃদ্ধ প্রসঙ্গ থাকতে হবে।

একটি দৃশ্যকল্প কল্পনা করুন যেখানে প্রতিটি ট্রেসের প্রতিটি স্প্যান রয়েছে:

• অনুরোধ এবং প্রতিক্রিয়া পেলোড (PII মাস্কিং সহ)

• যেকোনো ব্যতিক্রমের জন্য ট্রেস স্ট্যাক করুন

• লগ

• কুবারনেটস ইভেন্ট

• পড রাষ্ট্র

• এবং যে স্প্যান বরাবর ঘটেছে যে অন্য কিছু

  
  

সব এক সমন্বিত, নির্বিঘ্ন প্রবাহ.

এবং কল্পনা করুন যে একজন যে ট্রেসটি খুঁজছেন তা খুঁজে পাওয়া খুব সহজ - সেখানে কোনও নমুনা-সম্পর্কিত ডেটা ফাঁক নেই, সমস্যাগুলি অনুমান করা এবং গোষ্ঠীবদ্ধ করা হয়েছে এবং বিভিন্ন মাত্রা জুড়ে ফিল্টার করা যেতে পারে৷

তারপরে, বিকাশকারীকে যেকোন সফ্টওয়্যার সমস্যা ডিবাগ করতে হবে। এবং সম্ভাব্যভাবে, সমস্ত AI মডেলের নির্ণয় করতে হবে এবং একজন বিকাশকারীকে কী ভুল হচ্ছে তা নির্দেশ করতে হবে।

এই পৃথিবীতে, ট্রেসটি পর্যবেক্ষণের জন্য প্রাথমিক অক্ষ হয়ে ওঠে, লগিং প্রতিস্থাপন করে । ডিস্ট্রিবিউটেড ট্রেসিং-এর শেষ-স্টেট দেখতে কেমন হতে পারে - যদিও এটি এখনও এখানে নেই, আমরা আজ যেখানে আছি সেখান থেকে এটি দৃশ্যমান।

এটি সম্ভব করার প্রধান বাধা হল ডেটা ভলিউমের বিস্ফোরণ যা এই সমস্ত প্রসঙ্গ ডেটা সংরক্ষণের কারণ হবে। এটি সম্ভব করার জন্য আমাদের ডেটা প্রসেসিং এবং স্টোরেজ আর্কিটেকচারে গভীর উদ্ভাবনের প্রয়োজন হবে। এটি এখনও প্রাথমিক দিন এবং আমাদের অপেক্ষা করতে হবে এবং এখানে কী ঘটে তা দেখতে হবে।

সারসংক্ষেপ

সংক্ষেপে, ডিস্ট্রিবিউটেড ট্রেসিং একটি প্রয়োজনীয় এবং স্বজ্ঞাত দৃষ্টিভঙ্গি যা উত্পাদনে বিতরণকৃত অ্যাপ্লিকেশন আর্কিটেকচারগুলি পর্যবেক্ষণ করতে সক্ষম হওয়ার জন্য প্রয়োজনীয়।

প্রথম প্রজন্মের বিতরণ করা ট্রেসিং, প্রতিশ্রুতিবদ্ধ থাকাকালীন, বেশ কয়েকটি চ্যালেঞ্জ দ্বারা বেষ্টিত হয়েছে যা কোম্পানিগুলির জন্য ট্রেসিং থেকে মূল্য পাওয়া কঠিন করে তুলেছে, যা গ্রহণকে কিছুটা বাধাগ্রস্ত করেছে।

যাইহোক, মহাকাশে বেশ কিছু উত্তেজনাপূর্ণ উন্নয়ন ঘটছে যা ট্রেসিংকে আমাদের আজকের তুলনায় সহজ, সরল এবং আরও শক্তিশালী করে তুলবে বলে আশা করা হচ্ছে, ভবিষ্যতে পর্যবেক্ষণযোগ্যতাকে আরও নিরবচ্ছিন্ন করে তুলবে।