বিতরণ করা ট্রেসিং: আমরা এটি সব ভুল করেছি

বিঃদ্রঃ. অনুবাদ: এই উপাদানটির লেখক হলেন সিন্ডি শ্রীধরন, imgix-এর একজন প্রকৌশলী যিনি API ডেভেলপমেন্ট এবং বিশেষ করে মাইক্রোসার্ভিস টেস্টিং-এ বিশেষজ্ঞ। এই উপাদানটিতে, তিনি বিতরণ করা ট্রেসিংয়ের ক্ষেত্রে বর্তমান সমস্যার তার বিশদ দৃষ্টিভঙ্গি শেয়ার করেছেন, যেখানে তার মতে, চাপের সমস্যা সমাধানের জন্য সত্যিকারের কার্যকর সরঞ্জামের অভাব রয়েছে।

[দৃষ্টান্ত থেকে নেওয়া অন্যান্য উপাদান বিতরণ ট্রেসিং সম্পর্কে।]

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

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

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

যেমন একটি ভিন্ন ট্রেস

ডিস্ট্রিবিউটেড ট্রেসিং-এ বেশ কিছু আলাদা উপাদান রয়েছে:

• কন্ট্রোল টুল দিয়ে অ্যাপ্লিকেশন এবং মিডলওয়্যার সজ্জিত করা;
• বিতরণ করা প্রসঙ্গ স্থানান্তর;
• ট্রেস সংগ্রহ;
• ট্রেস স্টোরেজ;
• তাদের নিষ্কাশন এবং দৃশ্যায়ন.

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

বিঃদ্রঃ. অনুবাদ: আরও পাঠ্য বোঝা সহজ করতে, আসুন আমরা দুটি মৌলিক পদের সংজ্ঞা দিই OpenTracing প্রকল্প ডকুমেন্টেশন:

• বিঘত — বিতরণ করা ট্রেসিংয়ের মৌলিক উপাদান। এটি একটি নাম, শুরু এবং শেষের সময়, ট্যাগ, লগ এবং প্রসঙ্গ সহ একটি নির্দিষ্ট ওয়ার্কফ্লো (উদাহরণস্বরূপ, একটি ডাটাবেস কোয়েরি) এর একটি বিবরণ।
• স্প্যানগুলিতে সাধারণত অন্যান্য স্প্যানগুলির লিঙ্ক থাকে, যা একাধিক স্প্যানকে একত্রিত করার অনুমতি দেয় চিহ্ন - একটি অনুরোধের জীবনের ভিজ্যুয়ালাইজেশন যখন এটি একটি বিতরণ সিস্টেমের মাধ্যমে চলে।

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

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

উপরে তালিকাভুক্ত বিকল্পগুলির কোনটিই দৃশ্যকল্পে সম্পূর্ণরূপে প্রযোজ্য নয় ডিবাগ, যার সময় ইঞ্জিনিয়ার ট্রেস দেখে সমস্যা সমাধান করার চেষ্টা করে।

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

আমি এখন পর্যন্ত যে সমস্ত ট্রেসিং সিস্টেম দেখেছি তার সাথে সমস্যাটি হল ফলাফল ভিজ্যুয়ালাইজেশন (ট্রেসভিউ) প্রায় সম্পূর্ণরূপে ট্রেস প্রজন্মের প্রক্রিয়া বৈশিষ্ট্য প্রতিফলিত. এমনকি যখন বিকল্প ভিজ্যুয়ালাইজেশন প্রস্তাব করা হয়: হিটম্যাপ, সার্ভিস টপোলজিস, লেটেন্সি হিস্টোগ্রাম, তারা শেষ পর্যন্ত নিচে নেমে আসে ট্রেসভিউ.

অতীতে আমি অভিযোগ যে বেশিরভাগ UI/UX ট্রেসিং "উদ্ভাবন" সীমাবদ্ধ বলে মনে হচ্ছে চালু হচ্ছে ট্রেস মধ্যে অতিরিক্ত মেটাডেটা, উচ্চ কার্ডিনালিটি সঙ্গে তাদের তথ্য বিনিয়োগ (উচ্চ কার্ডিনালিটি) বা নির্দিষ্ট স্প্যানগুলিতে ড্রিল ডাউন করার ক্ষমতা প্রদান করে বা কোয়েরি চালায় ইন্টার- এবং ইন্ট্রা-ট্রেস... যার মধ্যে ট্রেসভিউ প্রাথমিক ভিজ্যুয়ালাইজেশন টুল থেকে যায়। যতদিন এই অবস্থা চলতে থাকবে, ডিস্ট্রিবিউটেড ট্রেসিং (সর্বোত্তমভাবে) মেট্রিক্স, লগ এবং স্ট্যাক ট্রেসগুলির পরে, ডিবাগিং টুল হিসাবে 4র্থ স্থান নেবে এবং সবচেয়ে খারাপভাবে এটি অর্থ এবং সময়ের অপচয় হিসাবে পরিণত হবে।

ট্রেসভিউ নিয়ে সমস্যা

নিয়তি ট্রেসভিউ — বিতরণ করা সিস্টেমের সমস্ত উপাদান জুড়ে একটি একক অনুরোধের গতিবিধির একটি সম্পূর্ণ চিত্র প্রদান করুন যার সাথে এটি সম্পর্কিত। আরও কিছু উন্নত ট্রেসিং সিস্টেম আপনাকে পৃথক স্প্যানগুলিতে ড্রিল ডাউন করতে এবং সময়ের সাথে সাথে একটি ব্রেকডাউন দেখতে দেয় মধ্যে একটি প্রক্রিয়া (যখন স্প্যানের কার্যকরী সীমানা থাকে)।

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

আপনি যদি সত্যি বিস্ময়করভাবে জটিল বিতরণ ব্যবস্থা, তাহলে একক ব্যক্তি এটিকে তার মাথায় রাখতে সক্ষম নয় সম্পূর্ণ ছবি প্রকৃতপক্ষে, এটি এমনকি সম্ভব এমন অনুমানের উপর ভিত্তি করে একটি সরঞ্জাম তৈরি করা একটি অ্যান্টি-প্যাটার্ন (একটি অকার্যকর এবং অনুৎপাদনশীল পদ্ধতির) কিছু। আদর্শভাবে, ডিবাগিংয়ের জন্য একটি টুল প্রয়োজন যা সাহায্য করে আপনার অনুসন্ধান এলাকা সংকীর্ণ, যাতে প্রকৌশলীরা বিবেচনা করা সমস্যা পরিস্থিতির সাথে প্রাসঙ্গিক মাত্রার একটি উপসেট (পরিষেবা/ব্যবহারকারী/হোস্ট, ইত্যাদি) ফোকাস করতে পারেন। ব্যর্থতার কারণ নির্ণয় করার সময়, প্রকৌশলীদের বোঝার প্রয়োজন হয় না যে সময় কী ঘটেছিল একযোগে সব সেবা, যেহেতু এই ধরনের প্রয়োজনীয়তা মাইক্রোসার্ভিস আর্কিটেকচারের ধারণার বিরোধিতা করবে।

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

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

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

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

স্প্যানগুলি খুবই নিম্ন স্তরের৷

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

তাছাড়া, আমি নিম্নলিখিত দাবি করার স্বাধীনতা নেব: আদর্শভাবে, আমাদের প্রয়োজন নেই সম্পূর্ণ ছবি অনুরোধ জীবনচক্রের সময় ঘটেছে, যা আধুনিক ট্রেসিং সরঞ্জাম দ্বারা প্রতিনিধিত্ব করা হয়। পরিবর্তে, উচ্চ-স্তরের বিমূর্ততার কিছু ফর্ম প্রয়োজন যা কী সম্পর্কে তথ্য ধারণ করে ভুল করছ (ব্যাকট্রেসের অনুরূপ), কিছু প্রসঙ্গ সহ। পুরো ট্রেস দেখার পরিবর্তে, আমি এটি দেখতে পছন্দ করি অংশ, যেখানে আকর্ষণীয় বা অস্বাভাবিক কিছু ঘটে। বর্তমানে, অনুসন্ধানটি ম্যানুয়ালি করা হয়: প্রকৌশলী ট্রেসটি পান এবং আকর্ষণীয় কিছুর সন্ধানে স্বাধীনভাবে স্প্যানগুলি বিশ্লেষণ করেন। সন্দেহজনক কার্যকলাপ শনাক্ত করার আশায় স্প্যানের দিকে তাকিয়ে থাকা লোকেদের দৃষ্টিভঙ্গি মোটেই স্কেল করে না (বিশেষ করে যখন তাদের বিভিন্ন স্প্যানে এনকোড করা সমস্ত মেটাডেটা বোঝাতে হয়, যেমন স্প্যান আইডি, RPC পদ্ধতির নাম, স্প্যানের সময়কাল 'a, লগ, ট্যাগ, ইত্যাদি)।

ট্রেসভিউ বিকল্প

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

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

নির্দিষ্ট পরিষেবাগুলিতে ফোকাস করুন

এমন এক সময়ে যখন শিল্প ধারণাকে ঘিরে একত্রিত হচ্ছে SLO (পরিষেবা স্তরের উদ্দেশ্য) এবং SLI (পরিষেবা স্তর নির্দেশক), এটা যুক্তিসঙ্গত বলে মনে হচ্ছে যে পৃথক দলগুলিকে অগ্রাধিকার দেওয়া উচিত তাদের পরিষেবাগুলি এই লক্ষ্যগুলির সাথে সামঞ্জস্যপূর্ণ। এটা যে অনুসরণ করে সেবা ভিত্তিক ভিজ্যুয়ালাইজেশন এই ধরনের দলের জন্য সবচেয়ে উপযুক্ত।

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

1. শুধুমাত্র উচ্চ বিশিষ্ট অনুরোধের জন্য লেটেন্সি ডিস্ট্রিবিউশন ডায়াগ্রাম (বাহ্যিক অনুরোধ);
2. যখন পরিষেবা SLO লক্ষ্যগুলি অর্জিত হয় না এমন ক্ষেত্রে বিলম্ব বিতরণের চিত্র;
3. প্রশ্নগুলির মধ্যে সবচেয়ে "সাধারণ", "আকর্ষণীয়" এবং "অদ্ভুত" ট্যাগ যা প্রায়শই পুনরাবৃত্তি হয়;
4. ক্ষেত্রে যেখানে লেটেন্সি ব্রেকডাউন তার উপর নির্ভর করে পরিষেবাগুলি তাদের SLO লক্ষ্যগুলি অর্জন করে না;
5. বিভিন্ন ডাউনস্ট্রিম পরিষেবার জন্য লেটেন্সি ব্রেকডাউন।

এর মধ্যে কিছু প্রশ্নের উত্তর বিল্ট-ইন মেট্রিক্স দ্বারা দেওয়া হয় না, যা ব্যবহারকারীদের স্প্যানগুলি যাচাই করতে বাধ্য করে। ফলস্বরূপ, আমাদের একটি অত্যন্ত ব্যবহারকারী-প্রতিকূল প্রক্রিয়া রয়েছে।

এটি প্রশ্ন উত্থাপন করে: বিভিন্ন দল দ্বারা নিয়ন্ত্রিত বিভিন্ন পরিষেবার মধ্যে জটিল মিথস্ক্রিয়া সম্পর্কে কী? তাই না ট্রেসভিউ এই ধরনের পরিস্থিতি হাইলাইট করার জন্য সবচেয়ে উপযুক্ত হাতিয়ার হিসেবে বিবেচনা করা হয় না?

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

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

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

একটি টপোলজি নির্মাণ

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

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

একটা উদাহরণ নেওয়া যাক। একটি অনুমানভিত্তিক সংবাদ সাইট কল্পনা করা যাক। হোম পেজ পরিষেবা (সামনের পৃষ্ঠা) রেডিসের সাথে একটি সুপারিশ পরিষেবা, একটি বিজ্ঞাপন পরিষেবা এবং একটি ভিডিও পরিষেবার সাথে ডেটা বিনিময় করে৷ ভিডিও পরিষেবা S3 থেকে ভিডিও এবং DynamoDB থেকে মেটাডেটা নেয়। সুপারিশ পরিষেবাটি ডায়নামোডিবি থেকে মেটাডেটা গ্রহণ করে, রেডিস এবং মাইএসকিউএল থেকে ডেটা লোড করে এবং কাফকাকে বার্তা লেখে। বিজ্ঞাপন পরিষেবা MySQL থেকে ডেটা গ্রহণ করে এবং কাফকাকে বার্তা লেখে।

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

একটি অনুমানমূলক সংবাদ সাইটের পরিষেবা চিত্র

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

ডায়নামিক টপোলজি শুধুমাত্র "আকর্ষণীয়" পরিষেবাগুলি প্রদর্শন করে

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

তুলনামূলক প্রদর্শন

আরেকটি দরকারী ভিজ্যুয়ালাইজেশন একটি তুলনামূলক প্রদর্শন হবে. বর্তমানে ট্রেসগুলি পাশাপাশি তুলনা করার জন্য খুব উপযুক্ত নয়, তাই তুলনাগুলি সাধারণত স্প্যান. এবং এই নিবন্ধটির মূল ধারণাটি সঠিকভাবে হল যে স্প্যানগুলি ট্রেস ফলাফল থেকে সবচেয়ে মূল্যবান তথ্য বের করার জন্য খুব কম-স্তরের।

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

উপসংহার

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

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

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

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

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

• «Kubernetes পডগুলিতে ডিবাগ করার জন্য kubectl-debug প্লাগইন";
• «মাইক্রোসার্ভিস: আপনার কুবারনেটস থাকলেও আকার গুরুত্বপূর্ণ";
• «মনিটরিং এবং কুবারনেটস (পর্যালোচনা এবং ভিডিও প্রতিবেদন)».

উত্স: www.habr.com