গুরুত্বপূর্ণ লিংক
সার্ভিস হেলথ ড্যাশবোর্ড (বর্তমানে শুধু Enterprise API গ্রাহকদের জন্য উপলভ্য)
সঠিক ডিফল্ট দিয়ে শুরু করুন
Service Health ড্যাশবোর্ড খুললে, এটি ডিফল্টভাবে দেখায়:
সব প্রকল্প
গত ৩০ দিন
ঘণ্টাভিত্তিক রেজোলিউশন
এই ভিউ শুধু প্রাথমিক ধারণার জন্য উপযোগী. অর্থবহ সমস্যা সমাধানের জন্য সবসময় ফিল্টারিং প্রয়োজন.
তদন্তের আগে ফিল্টার করুন
সঠিক ফিল্টারিং সবচেয়ে গুরুত্বপূর্ণ ধাপ. বেশিরভাগ ভুল ব্যাখ্যা মডেল, টিয়ার বা প্রকল্প মিশিয়ে ফেলার কারণে হয়.
মডেল অনুযায়ী ফিল্টার করুন (একবারে একটি)
সবসময় একটি মাত্র মডেলে ফিল্টার করুন.
কারণ:
কম-ট্রাফিক মডেলের সমস্যা বেশি-ভলিউম ট্রাফিকের আড়ালে থাকতে পারে
উচ্চ-ভলিউম মডেল স্থানীয় সমস্যাকে বৈশ্বিক মনে করাতে পারে
ভিন্ন মডেলের পারফরম্যান্স লক্ষ্য ভিন্ন
দ্রষ্টব্য: একাধিক মডেল নির্বাচন করলে সেগুলো একত্রিত হয়—এগুলোর মধ্যে সুইচ হয় না.
সার্ভিস টিয়ার অনুযায়ী ফিল্টার করুন
আপনি যদি একাধিক টিয়ার ব্যবহার করেন (স্ট্যান্ডার্ড, দ্রুত মোড (আগে অগ্রাধিকার প্রক্রিয়াকরণ নামে পরিচিত), স্কেল টিয়ার), তাহলে আপনি যে টিয়ারটি তদন্ত করছেন সেটিতেই সবসময় ফিল্টার করুন.
কেন:
টিয়ারগুলোর পারফরম্যান্স বৈশিষ্ট্য আলাদা
দ্রুত মোড ও স্কেল টিয়ারের নির্ধারিত SLA আছে
টিয়ার মিশে গেলে পেইড-টিয়ারের পারফরম্যান্স অস্পষ্ট হয়
লেটেন্সি বিশ্লেষণের জন্য এটি বিশেষভাবে গুরুত্বপূর্ণ.
বিদ্যমান মডেলগুলোর ক্ষেত্রে, ব্যবহার ড্যাশবোর্ডে দ্রুত মোডের ট্র্যাফিক এখনও priority হিসেবে দেখা যায়.
প্রকল্প অনুযায়ী ফিল্টার করুন
ডিফল্টভাবে, Service Health সব প্রকল্প দেখায়.
সমস্যা সমাধানের জন্য, যে প্রকল্প(গুলো)তে সমস্যা দেখা গেছে সেগুলোতে ফিল্টার করুন.
কারণ:
একটি উচ্চ-ভলিউম প্রকল্প মেট্রিকগুলোকে প্রভাবিত করে আধিপত্য করতে পারে.
ছোট প্রভাবিত প্রকল্পগুলো সম্পর্কহীন ট্রাফিকের আড়ালে পড়তে পারে.
শুধু তখনই “সব প্রকল্প” নির্বাচিত রাখুন, যদি মনে করেন সমস্যাটি সত্যিই পুরো প্রতিষ্ঠানে ঘটছে.
ত্রুটি সমস্যা সমাধান
HTTP অনুরোধ ভিউ ব্যবহার করুন
ত্রুটি তদন্ত করতে:
মডেল ও সার্ভিস টিয়ার অনুযায়ী ফিল্টার করুন.
Uptime ট্যাবের বদলে HTTP Requests ট্যাব খুলুন.
এই ভিউ HTTP স্ট্যাটাস কোড অনুযায়ী মোট অনুরোধ ও ত্রুটির সংখ্যা দেখায়. সূক্ষ্ম স্পাইক বা পরিবর্তন শনাক্ত করতে মিনিট-স্তরের রেজোলিউশনে জুম করুন.
সংখ্যা নয়, ত্রুটির হার ব্যাখ্যা করুন
যেকোনো প্রোডাকশন সিস্টেমে কিছু ত্রুটি প্রত্যাশিত. কাঁচা মোট সংখ্যার বদলে ত্রুটির শতাংশে মনোযোগ দিন.
আপনার মোট ভলিউম যত বেশি, ত্রুটির হার অত্যন্ত কম হলেও সম্ভাব্য ত্রুটির সংখ্যা তত বেশি হতে পারে.
Service Health-এ ত্রুটি দেখা না গেলে
আপনি যদি ক্লায়েন্ট-সাইড ত্রুটি দেখেন কিন্তু Service Health-এ সংশ্লিষ্ট ডাটা না থাকে:
অনুরোধগুলো সম্ভবত OpenAI-তে পৌঁছায়নি.
সমস্যাটি সাধারণত আপস্ট্রিমে থাকে (টাইমআউট, প্রক্সি, নেটওয়ার্কিং).
আগ্রাসী ক্লায়েন্ট-সাইড টাইমআউটে এটি সাধারণ.
লেটেন্সি সমস্যা সমাধান
লেটেন্সি বিশ্লেষণ সবচেয়ে অর্থবহ হয় দ্রুত মোড এবং স্কেল টিয়ার টিয়ারে, কারণ এগুলোর নির্ধারিত SLA আছে. স্ট্যান্ডার্ড টিয়ারে লেটেন্সির ভিন্নতা বেশি দেখা যেতে পারে এবং সেখানে নিশ্চিত লেটেন্সি নেই.
মূল মেট্রিক
প্রতিটি মেট্রিক দেখতে, সংশ্লিষ্ট ট্যাবে ক্লিক করুন:
টোকেন ভেলোসিটি: প্রতি সেকেন্ডে তৈরি হওয়া টোকেন; প্রম্পটের আকারের ওপর নির্ভর করে না.
অনুরোধের সময়: মোট অনুরোধের সময়কাল; আউটপুটের আকার ও রিজনিং দ্বারা প্রবলভাবে প্রভাবিত.
প্রথম টোকেন পর্যন্ত সময় (TTFT): প্রথম টোকেন তৈরি হওয়া পর্যন্ত সময়; আনক্যাশড ইনপুট প্রম্পটের আকার ও রিজনিং দ্বারা প্রবলভাবে প্রভাবিত.
সবসময় P50 / P75 / P95 পারসেন্টাইল পর্যালোচনা করুন. গড় মান বাস্তব ব্যবহারকারীর প্রভাব আড়াল করতে পারে.
৬. ল্যাটেন্সির সঙ্গে টোকেন ব্যবহারের সম্পর্ক নির্ণয়
Service Health দেখায় আচরণ কখন বদলেছে. ব্যবহারের ডাটা কেন তা ব্যাখ্যা করতে সাহায্য করে.
Usage ড্যাশবোর্ডে, Service Health Dashboard-এ আপনার ভিউয়ের সঙ্গে প্রাসঙ্গিক ডাটা দেখছেন তা নিশ্চিত করতে নিচের কাজগুলো করুন:
একই প্রকল্প ও মডেলে ফিল্টার করুন.
প্রযোজ্য হলে, সার্ভিস টিয়ার অনুযায়ী গ্রুপ করুন.
আউটপুট টোকেনে মনোযোগ দিন, যা ল্যাটেন্সিকে সবচেয়ে বেশি প্রভাবিত করে.
আরও গভীর বিশ্লেষণের জন্য, Activity Data এক্সপোর্ট করুন এবং সময়ের সাথে প্রতি অনুরোধে টোকেন পরীক্ষা করুন.
7. সহায়তা দলকে কী জানাবেন (প্রয়োজনে)
সহায়তা দলের সঙ্গে যোগাযোগ করলে, অন্তর্ভুক্ত করুন:
প্রভাবিত Org IDগুলি (গুরুত্বপূর্ণ)
প্রভাবিত এন্ডপয়েন্ট, যেমন Chat Completions বা Responses (গুরুত্বপূর্ণ)
প্রভাবিত মডেলগুলো (গুরুত্বপূর্ণ)
সমস্যাটি দ্রুত মোড না স্কেল টিয়ারে হচ্ছে কি না (গুরুত্বপূর্ণ)
লেটেন্সি বা ত্রুটির জন্য টাইমজোনসহ সময়সীমা (গুরুত্বপূর্ণ)
প্রাসঙ্গিক x-request-id বা X-Client-Request-Id, যদি থাকে
আপনি যে রিকোয়েস্টগুলো দেবেন, সেগুলোর টাইমজোনসহ টাইমস্ট্যাম্প, বা অন্তত তারিখ
থাকলে, আরও অন্তর্ভুক্ত করুন:
রিকোয়েস্টগুলোর সঙ্গে সংশ্লিষ্ট Project ID
ডাটা রেসিডেন্সি রিকোয়েস্টগুলো প্রভাবিত হয়েছে কি না, এবং কোনগুলো
আপনি যে প্রবণতাগুলো দেখছেন, সেগুলোর বিবরণ
সমস্যার ধরন অনুযায়ী অন্তর্ভুক্ত করুন:
ত্রুটি: ব্যর্থ হওয়া বা ত্রুটি হওয়া রিকোয়েস্টের আনুমানিক শতাংশ, রেসপন্স কোড, ত্রুটি বার্তা, এবং ত্রুটির রেসপন্স পেতে কত সময় লেগেছে.
লেটেন্সি: কোন পারসেন্টাইলগুলো প্রভাবিত (P50 / P90 / P95 / P99), সেগুলো গ্রাহকের বেসলাইনের তুলনায় কত বেশি, এবং পাঠানোর ও পাওয়ার টাইমস্ট্যাম্পসহ ধীর রিকোয়েস্টের উদাহরণ.
উভয় ক্ষেত্র: ত্রুটি বা লেটেন্সি ডাটার স্ক্রিনশট বা টেবিল, এবং ত্রুটির হার বা লেটেন্সি প্রত্যাশার চেয়ে বেশি ছিল তা কীভাবে নির্ধারণ করেছেন.
সাধারণ সমস্যা সমাধানের পরিস্থিতি
টাইমআউট হচ্ছে কিন্তু Service Health স্বাভাবিক দেখাচ্ছে
সম্ভাব্য কারণ: অনুরোধগুলো OpenAI-তে পৌঁছানোর আগেই টাইমআউট হচ্ছে.
যাচাই করুন:
ক্লায়েন্ট বা প্রক্সির টাইমআউট সেটিংস
লোকাল নেটওয়ার্ক বা লোড ব্যালান্সারের পরিবর্তন
Service Health ড্যাশবোর্ডে 499 ত্রুটির উপস্থিতি (এগুলো আপনার নিজস্ব সিস্টেমে 5xx ত্রুটি হিসেবে দেখা যেতে পারে).
ডিপ্লয়মেন্ট ছাড়াই ল্যাটেন্সি বেড়েছে
সম্ভাব্য কারণ: আউটপুট টোকেনের আকার বা রিজনিং ব্যবহার বেড়েছে এবং/অথবা ট্রাফিক সার্ভিস টিয়ারগুলোর মধ্যে সরে গেছে.
যাচাই করুন:
Usage ড্যাশবোর্ডে প্রতি অনুরোধে গড় আউটপুট টোকেন (ডাটা ডাউনলোড করে আউটপুট টোকেনকে মোট অনুরোধ দিয়ে ভাগ করতে হবে).
Service Health ড্যাশবোর্ডে Request Time এবং TTFT পারসেন্টাইল.
দ্রুত মোড বা স্কেল টিয়ার ধীর মনে হচ্ছে
সম্ভাব্য কারণ: মেট্রিকগুলো টিয়ারজুড়ে মিশে গেছে, অর্থাৎ স্ট্যান্ডার্ড-টিয়ারের ট্র্যাফিক পেইড-টিয়ারের পারফরম্যান্স আড়াল করছে.
যা পরীক্ষা করবেন:
ফিল্টারগুলো একটি মাত্র টিয়ার ও মডেলে সীমাবদ্ধ আছে.
টিয়ারগুলোর মধ্যে টোকেন গতির তুলনা.
5XX ত্রুটির হঠাৎ বৃদ্ধি
সম্ভাব্য কারণ: অল্প শতাংশ ট্রাফিককে প্রভাবিত করা সাময়িক ব্যর্থতা.
যাচাই করুন:
ত্রুটির হারের শতাংশ
একই সময়ে ট্রাফিকের পরিমাণ বদলেছে কি না
সমস্যা শুধু একটি প্রকল্পকে প্রভাবিত করছে
সম্ভাব্য কারণ: প্রকল্প-নির্দিষ্ট কনফিগারেশন বা ব্যবহারের প্যাটার্ন.
যাচাই করুন:
প্রকল্প-স্তরের ফিল্টারিং
অপ্রভাবিত প্রকল্পগুলোর সঙ্গে তুলনা
চূড়ান্ত সারাংশ
মেট্রিক ব্যাখ্যা করার আগে প্রাসঙ্গিক হলে মডেল, টিয়ার ও প্রকল্প অনুযায়ী ফিল্টার করুন.
ল্যাটেন্সি বিশ্লেষণে গড় নয়, পারসেন্টাইল ব্যবহার করুন.
ছোট ত্রুটির হার প্রত্যাশিত.
ডাটা না থাকা সাধারণত আপস্ট্রিম সমস্যার ইঙ্গিত দেয়.
ব্যবহারের ডাটা ল্যাটেন্সি কেন বদলেছে তা ব্যাখ্যা করতে সাহায্য করে; Service Health দেখায় আচরণ কখন বদলেছে.