Package google.rpc

সূচক

খারাপ অনুরোধ

ক্লায়েন্টের অনুরোধে লঙ্ঘনের বর্ণনা দেয়। এই ত্রুটির ধরণটি অনুরোধের সিনট্যাকটিক দিকগুলিতে ফোকাস করে।

ক্ষেত্র
field_violations[]

FieldViolation

ক্লায়েন্টের অনুরোধে সমস্ত লঙ্ঘনের বর্ণনা দেয়।

ক্ষেত্র লঙ্ঘন

একটি খারাপ অনুরোধ ক্ষেত্র বর্ণনা করতে ব্যবহৃত একটি বার্তার ধরণ।

ক্ষেত্র
field

string

একটি পথ যা অনুরোধের মূল অংশের একটি ক্ষেত্রের দিকে নিয়ে যায়। মানটি হবে ডট-বিচ্ছিন্ন শনাক্তকারীদের একটি ক্রম যা একটি প্রোটোকল বাফার ক্ষেত্র সনাক্ত করে।

নিম্নলিখিত বিষয়গুলি বিবেচনা করুন:

message CreateContactRequest {
  message EmailAddress {
    enum Type {
      TYPE_UNSPECIFIED = 0;
      HOME = 1;
      WORK = 2;
    }

    optional string email = 1;
    repeated EmailType type = 2;
  }

  string full_name = 1;
  repeated EmailAddress email_addresses = 2;
}

এই উদাহরণে, প্রোটো field নিম্নলিখিত মানগুলির মধ্যে একটি নিতে পারে:

  • full_name মানের লঙ্ঘনের জন্য full_name
  • প্রথম email_addresses বার্তার email ক্ষেত্রে লঙ্ঘনের জন্য email_addresses[1].email
  • তৃতীয় email_addresses বার্তায় দ্বিতীয় type মানের লঙ্ঘনের জন্য email_addresses[3].type[2] ।

JSON-এ, একই মানগুলি নিম্নরূপে উপস্থাপিত হয়:

  • fullName মানের লঙ্ঘনের জন্য fullName
  • প্রথম emailAddresses বার্তার email ক্ষেত্রে লঙ্ঘনের জন্য emailAddresses[1].email
  • তৃতীয় emailAddresses বার্তায় দ্বিতীয় type মানের লঙ্ঘনের জন্য emailAddresses[3].type[2] ।
description

string

অনুরোধের উপাদানটি কেন খারাপ তার একটি বর্ণনা।

reason

string

ফিল্ড-লেভেল ত্রুটির কারণ। এটি একটি ধ্রুবক মান যা ফিল্ড-লেভেল ত্রুটির নিকটতম কারণ চিহ্নিত করে। এটি google.rpc.ErrorInfo.domain এর সুযোগের মধ্যে FieldViolation এর ধরণটি অনন্যভাবে সনাক্ত করবে। এটি সর্বাধিক 63 টি অক্ষরের হওয়া উচিত এবং [AZ][A-Z0-9_]+[A-Z0-9] এর একটি নিয়মিত অভিব্যক্তির সাথে মেলে, যা UPPER_SNAKE_CASE কে প্রতিনিধিত্ব করে।

localized_message

LocalizedMessage

ফিল্ড-লেভেল ত্রুটির জন্য একটি স্থানীয় ত্রুটি বার্তা প্রদান করে যা API গ্রাহকের কাছে ফেরত পাঠানো নিরাপদ।

কোড

gRPC API-এর জন্য ক্যানোনিকাল ত্রুটি কোড।

কখনও কখনও একাধিক ত্রুটি কোড প্রযোজ্য হতে পারে। পরিষেবাগুলি প্রযোজ্য সবচেয়ে নির্দিষ্ট ত্রুটি কোডটি ফেরত দেবে। উদাহরণস্বরূপ, যদি উভয় কোড প্রযোজ্য হয় তবে FAILED_PRECONDITION এর চেয়ে OUT_OF_RANGE পছন্দ করুন। একইভাবে FAILED_PRECONDITION এর চেয়ে NOT_FOUND বা ALREADY_EXISTS পছন্দ করুন।

এনামস
OK

কোনও ভুল নয়; সাফল্যের সাথে ফিরে এসেছি।

HTTP ম্যাপিং: ২০০ ঠিক আছে

CANCELLED

অপারেশনটি বাতিল করা হয়েছিল, সাধারণত কলকারীর দ্বারা।

HTTP ম্যাপিং: 499 ক্লায়েন্ট ক্লোজড রিকোয়েস্ট

UNKNOWN

অজানা ত্রুটি। উদাহরণস্বরূপ, এই ত্রুটিটি তখনই ফিরে আসতে পারে যখন অন্য ঠিকানা স্থান থেকে প্রাপ্ত একটি Status মান এমন একটি ত্রুটি স্থানের অন্তর্গত যা এই ঠিকানা স্থানের অজানা। এছাড়াও, API দ্বারা উত্থাপিত ত্রুটিগুলি যা পর্যাপ্ত ত্রুটি তথ্য প্রদান করে না সেগুলি এই ত্রুটিতে রূপান্তরিত হতে পারে।

HTTP ম্যাপিং: ৫০০ অভ্যন্তরীণ সার্ভার ত্রুটি

INVALID_ARGUMENT

ক্লায়েন্ট একটি অবৈধ আর্গুমেন্ট নির্দিষ্ট করেছে। মনে রাখবেন এটি FAILED_PRECONDITION থেকে আলাদা। INVALID_ARGUMENT এমন আর্গুমেন্ট নির্দেশ করে যা সিস্টেমের অবস্থা নির্বিশেষে সমস্যাযুক্ত (যেমন, একটি ত্রুটিপূর্ণ ফাইলের নাম)।

HTTP ম্যাপিং: 400 খারাপ অনুরোধ

DEADLINE_EXCEEDED

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

HTTP ম্যাপিং: ৫০৪ গেটওয়ে টাইমআউট

NOT_FOUND

কিছু অনুরোধকৃত সত্তা (যেমন, ফাইল বা ডিরেক্টরি) পাওয়া যায়নি।

সার্ভার ডেভেলপারদের জন্য নোট: যদি ব্যবহারকারীদের একটি সম্পূর্ণ শ্রেণীর জন্য কোনও অনুরোধ প্রত্যাখ্যান করা হয়, যেমন ধীরে ধীরে বৈশিষ্ট্য রোলআউট বা নথিভুক্ত নয় এমন অ্যালোলিস্ট, তাহলে NOT_FOUND ব্যবহার করা যেতে পারে। যদি ব্যবহারকারীদের একটি শ্রেণীর মধ্যে কিছু ব্যবহারকারীর জন্য কোনও অনুরোধ প্রত্যাখ্যান করা হয়, যেমন ব্যবহারকারী-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ, তাহলে PERMISSION_DENIED ব্যবহার করতে হবে।

HTTP ম্যাপিং: 404 পাওয়া যায়নি

ALREADY_EXISTS

ক্লায়েন্ট যে সত্তাটি তৈরি করার চেষ্টা করেছিল (যেমন, ফাইল বা ডিরেক্টরি) তা ইতিমধ্যেই বিদ্যমান।

HTTP ম্যাপিং: 409 দ্বন্দ্ব

PERMISSION_DENIED

কলকারীর নির্দিষ্ট ক্রিয়াকলাপটি সম্পাদন করার অনুমতি নেই। কিছু রিসোর্স ক্লান্ত করার কারণে প্রত্যাখ্যানের ক্ষেত্রে PERMISSION_DENIED ব্যবহার করা উচিত নয় (এই ত্রুটিগুলির জন্য RESOURCE_EXHAUSTED ব্যবহার করুন)। যদি কলকারীকে সনাক্ত করা না যায় তবে PERMISSION_DENIED ব্যবহার করা উচিত নয় (এই ত্রুটিগুলির জন্য UNAUTHENTICATED ব্যবহার করুন)। এই ত্রুটি কোডটি বোঝায় না যে অনুরোধটি বৈধ বা অনুরোধকৃত সত্তা বিদ্যমান বা অন্যান্য পূর্ব-শর্ত পূরণ করে।

HTTP ম্যাপিং: 403 নিষিদ্ধ

UNAUTHENTICATED

অনুরোধটিতে ক্রিয়াকলাপের জন্য বৈধ প্রমাণীকরণ শংসাপত্র নেই।

HTTP ম্যাপিং: 401 অননুমোদিত

RESOURCE_EXHAUSTED

কিছু রিসোর্স শেষ হয়ে গেছে, সম্ভবত প্রতি ব্যবহারকারীর কোটা, অথবা সম্ভবত পুরো ফাইল সিস্টেমে জায়গা নেই।

HTTP ম্যাপিং: ৪২৯টি অনেক বেশি অনুরোধ

FAILED_PRECONDITION

অপারেশনটি বাতিল করা হয়েছে কারণ সিস্টেমটি অপারেশনটি সম্পাদনের জন্য প্রয়োজনীয় অবস্থায় নেই। উদাহরণস্বরূপ, যে ডিরেক্টরিটি মুছে ফেলা হবে তা খালি নয়, একটি rmdir অপারেশন একটি নন-ডিরেক্টরিতে প্রয়োগ করা হয়েছে, ইত্যাদি।

পরিষেবা বাস্তবায়নকারীরা নিম্নলিখিত নির্দেশিকাগুলি ব্যবহার করে FAILED_PRECONDITION , ABORTED এবং UNAVAILABLE এর মধ্যে সিদ্ধান্ত নিতে পারেন: (a) যদি ক্লায়েন্ট কেবল ব্যর্থ কলটি পুনরায় চেষ্টা করতে পারে তবে UNAVAILABLE ব্যবহার করুন। (b) যদি ক্লায়েন্ট উচ্চতর স্তরে পুনরায় চেষ্টা করতে চায় তবে ABORTED ব্যবহার করুন। উদাহরণস্বরূপ, যখন একটি ক্লায়েন্ট-নির্দিষ্ট পরীক্ষা-এবং-সেট ব্যর্থ হয়, ক্লায়েন্টকে একটি পঠন-পরিবর্তন-লেখার ক্রম পুনরায় চালু করতে হবে তা নির্দেশ করে। (c) যদি সিস্টেমের অবস্থা স্পষ্টভাবে ঠিক না করা পর্যন্ত ক্লায়েন্ট পুনরায় চেষ্টা না করে তবে FAILED_PRECONDITION ব্যবহার করুন। উদাহরণস্বরূপ, যদি একটি "rmdir" ব্যর্থ হয় কারণ ডিরেক্টরিটি খালি নেই, তাহলে FAILED_PRECONDITION ফেরত দেওয়া উচিত কারণ ডিরেক্টরি থেকে ফাইলগুলি মুছে ফেলা না হলে ক্লায়েন্ট পুনরায় চেষ্টা করা উচিত নয়।

HTTP ম্যাপিং: 400 খারাপ অনুরোধ

ABORTED

অপারেশনটি বাতিল করা হয়েছিল, সাধারণত সিকোয়েন্সার চেক ব্যর্থতা বা লেনদেন বাতিলের মতো একটি কনকারেন্সি সমস্যার কারণে।

FAILED_PRECONDITION , ABORTED এবং UNAVAILABLE এর মধ্যে সিদ্ধান্ত নেওয়ার জন্য উপরের নির্দেশিকাগুলি দেখুন।

HTTP ম্যাপিং: 409 দ্বন্দ্ব

OUT_OF_RANGE

বৈধ পরিসর অতিক্রম করে অপারেশনটি করার চেষ্টা করা হয়েছিল। যেমন, ফাইলের শেষের দিকে খোঁজা বা পড়া।

INVALID_ARGUMENT বিপরীতে, এই ত্রুটিটি এমন একটি সমস্যা নির্দেশ করে যা সিস্টেমের অবস্থা পরিবর্তন হলে ঠিক করা যেতে পারে। উদাহরণস্বরূপ, একটি 32-বিট ফাইল সিস্টেম INVALID_ARGUMENT তৈরি করবে যদি [0,2^32-1] রেঞ্জের মধ্যে না থাকা অফসেটে পড়তে বলা হয়, তবে এটি বর্তমান ফাইলের আকারের বাইরের অফসেট থেকে পড়তে বলা হলে OUT_OF_RANGE তৈরি করবে।

FAILED_PRECONDITION এবং OUT_OF_RANGE মধ্যে বেশ কিছুটা ওভারল্যাপ রয়েছে। আমরা OUT_OF_RANGE (আরও নির্দিষ্ট ত্রুটি) ব্যবহার করার পরামর্শ দিচ্ছি যাতে কোনও স্পেসের মধ্য দিয়ে পুনরাবৃত্তি করা কলাররা সহজেই OUT_OF_RANGE ত্রুটিটি খুঁজে বের করতে পারে এবং কখন এটি সম্পন্ন হয়েছে তা সনাক্ত করতে পারে।

HTTP ম্যাপিং: 400 খারাপ অনুরোধ

UNIMPLEMENTED

এই পরিষেবাটিতে অপারেশনটি বাস্তবায়িত হয়নি অথবা সমর্থিত/সক্রিয় নয়।

HTTP ম্যাপিং: 501 বাস্তবায়িত হয়নি

INTERNAL

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

HTTP ম্যাপিং: ৫০০ অভ্যন্তরীণ সার্ভার ত্রুটি

UNAVAILABLE

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

FAILED_PRECONDITION , ABORTED এবং UNAVAILABLE এর মধ্যে সিদ্ধান্ত নেওয়ার জন্য উপরের নির্দেশিকাগুলি দেখুন।

HTTP ম্যাপিং: 503 পরিষেবা অনুপলব্ধ

DATA_LOSS

অপ্রত্যাশিত তথ্য ক্ষতি বা দুর্নীতি।

HTTP ম্যাপিং: ৫০০ অভ্যন্তরীণ সার্ভার ত্রুটি

ত্রুটি তথ্য

কাঠামোগত বিবরণ সহ ত্রুটির কারণ বর্ণনা করে।

"pubsub.googleapis.com" API সক্রিয় না থাকাকালীন যোগাযোগ করার সময় একটি ত্রুটির উদাহরণ:

{ "reason": "API_DISABLED"
  "domain": "googleapis.com"
  "metadata": {
    "resource": "projects/123",
    "service": "pubsub.googleapis.com"
  }
}

এই উত্তরটি ইঙ্গিত করে যে pubsub.googleapis.com API সক্রিয় নেই।

স্টক শেষ হয়ে যাওয়া কোনও অঞ্চলে স্প্যানার ইনস্ট্যান্স তৈরি করার চেষ্টা করার সময় যে ত্রুটি দেখা দেয় তার উদাহরণ:

{ "reason": "STOCKOUT"
  "domain": "spanner.googleapis.com",
  "metadata": {
    "availableRegions": "us-central1,us-east2"
  }
}
ক্ষেত্র
reason

string

ত্রুটির কারণ। এটি একটি ধ্রুবক মান যা ত্রুটির নিকটতম কারণ চিহ্নিত করে। ত্রুটির কারণগুলি ত্রুটির একটি নির্দিষ্ট ডোমেনের মধ্যে অনন্য। এটি সর্বাধিক 63 অক্ষরের হওয়া উচিত এবং [AZ][A-Z0-9_]+[A-Z0-9] এর একটি নিয়মিত অভিব্যক্তির সাথে মেলে, যা UPPER_SNAKE_CASE প্রতিনিধিত্ব করে।

domain

string

"কারণ" যে লজিক্যাল গ্রুপিংয়ের সাথে সম্পর্কিত। ত্রুটি ডোমেনটি সাধারণত সেই টুল বা পণ্যের নিবন্ধিত পরিষেবার নাম যা ত্রুটি তৈরি করে। উদাহরণ: "pubsub.googleapis.com"। যদি ত্রুটিটি কিছু সাধারণ অবকাঠামো দ্বারা তৈরি হয়, তাহলে ত্রুটি ডোমেনটি অবশ্যই একটি বিশ্বব্যাপী অনন্য মান হতে হবে যা পরিকাঠামো সনাক্ত করে। Google API অবকাঠামোর জন্য, ত্রুটি ডোমেনটি হল "googleapis.com"।

metadata

map<string, string>

এই ত্রুটি সম্পর্কে অতিরিক্ত কাঠামোগত বিবরণ।

কীগুলি অবশ্যই [az][a-zA-Z0-9-_]+ এর একটি নিয়মিত এক্সপ্রেশনের সাথে মিলবে তবে আদর্শভাবে lowerCamelCase হওয়া উচিত। এছাড়াও, তাদের দৈর্ঘ্য 64 অক্ষরের মধ্যে সীমাবদ্ধ থাকতে হবে। অতিক্রম করা সীমার বর্তমান মান সনাক্ত করার সময়, ইউনিটগুলি কীতে থাকা উচিত, মান নয়। উদাহরণস্বরূপ, {"instanceLimit": "100/request"} এর পরিবর্তে, {"instanceLimitPerRequest": "100"} হিসাবে ফেরত পাঠানো উচিত, যদি ক্লায়েন্ট একটি একক (ব্যাচ) অনুরোধে তৈরি করা যেতে পারে এমন উদাহরণের সংখ্যা অতিক্রম করে।

সাহায্য

ডকুমেন্টেশনের লিঙ্ক অথবা ব্যান্ডের বাইরের কোনও অ্যাকশন সম্পাদনের জন্য লিঙ্ক প্রদান করে।

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

ক্ষেত্র

স্থানীয় বার্তা

একটি স্থানীয় ত্রুটি বার্তা প্রদান করে যা ব্যবহারকারীর কাছে ফেরত পাঠানো নিরাপদ যা একটি RPC ত্রুটির সাথে সংযুক্ত করা যেতে পারে।

ক্ষেত্র
locale

string

https://www.rfc-editor.org/rfc/bcp/bcp47.txt এ সংজ্ঞায়িত স্পেসিফিকেশন অনুসরণ করে ব্যবহৃত লোকেল। উদাহরণ হল: "en-US", "fr-CH", "es-MX"

message

string

উপরের লোকেলে স্থানীয়কৃত ত্রুটি বার্তা।

পূর্বশর্ত ব্যর্থতা

কোন পূর্বশর্তগুলি ব্যর্থ হয়েছে তা বর্ণনা করে।

উদাহরণস্বরূপ, যদি কোনও RPC ব্যর্থ হয় কারণ এটির জন্য পরিষেবার শর্তাবলী স্বীকার করার প্রয়োজন ছিল, তাহলে এটি PreconditionFailure বার্তায় পরিষেবার শর্তাবলী লঙ্ঘনের তালিকাভুক্ত করতে পারে।

ক্ষেত্র
violations[]

Violation

সমস্ত পূর্বশর্ত লঙ্ঘনের বর্ণনা দেয়।

লঙ্ঘন

একটি বার্তার ধরণ যা একটি একক পূর্বশর্ত ব্যর্থতা বর্ণনা করতে ব্যবহৃত হয়।

ক্ষেত্র
type

string

PreconditionFailure এর ধরণ। সমর্থিত Precondition লঙ্ঘনের বিষয়গুলি সংজ্ঞায়িত করার জন্য আমরা একটি পরিষেবা-নির্দিষ্ট enum প্রকার ব্যবহার করার পরামর্শ দিই। উদাহরণস্বরূপ, "পরিষেবার শর্তাবলী লঙ্ঘনের" জন্য "TOS"।

subject

string

প্রকারের সাথে সম্পর্কিত বিষয়টি ব্যর্থ হয়েছে। উদাহরণস্বরূপ, "TOS" প্রকারের সাথে সম্পর্কিত "google.com/cloud" নির্দেশ করবে যে কোন পরিষেবার শর্তাবলী উল্লেখ করা হচ্ছে।

description

string

পূর্বশর্তটি কীভাবে ব্যর্থ হয়েছে তার একটি বর্ণনা। বিকাশকারীরা ব্যর্থতাটি কীভাবে ঠিক করবেন তা বুঝতে এই বিবরণটি ব্যবহার করতে পারেন।

উদাহরণস্বরূপ: "পরিষেবার শর্তাবলী গৃহীত হয়নি"।

কোটা ব্যর্থতা

কোটা চেক কীভাবে ব্যর্থ হয়েছে তা বর্ণনা করে।

উদাহরণস্বরূপ, যদি কলিং প্রজেক্টের জন্য একটি দৈনিক সীমা অতিক্রম করা হয়, তাহলে একটি পরিষেবা প্রকল্প আইডি এবং অতিক্রম করা কোটা সীমার বিবরণ সম্বলিত একটি QuotaFailure বিশদ সহ প্রতিক্রিয়া জানাতে পারে। যদি কলিং প্রজেক্টটি ডেভেলপার কনসোলে পরিষেবাটি সক্ষম না করে থাকে, তাহলে একটি পরিষেবা প্রকল্প আইডি দিয়ে প্রতিক্রিয়া জানাতে পারে এবং service_disabled সত্যে সেট করতে পারে।

কোটা ব্যর্থতা পরিচালনা করার বিষয়ে অন্যান্য বিশদের জন্য RetryInfo এবং সহায়তা প্রকারগুলিও দেখুন।

ক্ষেত্র
violations[]

Violation

সকল কোটা লঙ্ঘনের বর্ণনা দেয়।

লঙ্ঘন

একটি একক কোটা লঙ্ঘন বর্ণনা করতে ব্যবহৃত একটি বার্তার ধরণ। উদাহরণস্বরূপ, একটি দৈনিক কোটা বা একটি কাস্টম কোটা যা অতিক্রম করেছে।

ক্ষেত্র
subject

string

যে বিষয়ে কোটা পরীক্ষা করা হয়নি। উদাহরণস্বরূপ, "clientip: " অথবা "প্রকল্প: "।

description

string

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

উদাহরণস্বরূপ: "পরিষেবা নিষ্ক্রিয়" অথবা "পঠন ক্রিয়াকলাপের দৈনিক সীমা অতিক্রম করেছে"।

api_service

string

যে API পরিষেবা থেকে QuotaFailure.Violation উৎপন্ন হয়। কিছু ক্ষেত্রে, কোটা সমস্যাগুলি কল করা API পরিষেবার পরিবর্তে অন্য কোনও API পরিষেবা থেকে উদ্ভূত হয়। অন্য কথায়, API পরিষেবার উপর নির্ভরতা QuotaFailure এর কারণ হতে পারে এবং এই ক্ষেত্রে নির্ভরতা API পরিষেবার নাম থাকবে।

উদাহরণস্বরূপ, যদি API নামকটি Kubernetes Engine API (container.googleapis.com) হয়, এবং Kubernetes Engine API-তে কোটা লঙ্ঘন ঘটে, তাহলে এই ক্ষেত্রটি "container.googleapis.com" হবে। অন্যদিকে, যদি Kubernetes Engine API Compute Engine API (compute.googleapis.com) তে VM তৈরি করার সময় কোটা লঙ্ঘন ঘটে, তাহলে এই ক্ষেত্রটি "compute.googleapis.com" হবে।

quota_metric

string

লঙ্ঘিত কোটার মেট্রিক। কোটা মেট্রিক হল API অনুরোধ বা CPU-এর মতো ব্যবহার পরিমাপ করার জন্য একটি নামযুক্ত কাউন্টার। যখন কোনও পরিষেবাতে কোনও কার্যকলাপ ঘটে, যেমন ভার্চুয়াল মেশিন বরাদ্দ, তখন এক বা একাধিক কোটা মেট্রিক প্রভাবিত হতে পারে।

উদাহরণস্বরূপ, "compute.googleapis.com/cpus_per_vm_family", "storage.googleapis.com/internet_egress_bandwidth"।

quota_id

string

লঙ্ঘিত কোটার আইডি। "সীমার নাম" নামেও পরিচিত, এটি একটি API পরিষেবার প্রেক্ষাপটে একটি কোটার অনন্য শনাক্তকারী।

উদাহরণস্বরূপ, "CPUS-PER-VM-FAMILY-per-project-region"।

quota_dimensions

map<string, string>

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

উদাহরণস্বরূপ, "প্রতি অঞ্চল প্রতি VM পরিবারের CPU" কোটা "compute.googleapis.com/cpus_per_vm_family" মেট্রিকের "region" এবং "vm_family" মাত্রার উপর একটি সীমা প্রয়োগ করে। এবং যদি লঙ্ঘনটি "us-central1" অঞ্চলে এবং VM পরিবারের "n1" ক্ষেত্রে ঘটে থাকে, তাহলে quota_dimensions হবে,

{ "অঞ্চল": "us-central1", "vm_family": "n1", }

যখন বিশ্বব্যাপী একটি কোটা প্রয়োগ করা হয়, তখন quota_dimensions সর্বদা খালি থাকবে।

quota_value

int64

QuotaFailure সময় প্রয়োগকৃত কোটার মান।

উদাহরণস্বরূপ, যদি CPU-এর সংখ্যার উপর QuotaFailure এর সময় প্রয়োগকৃত কোটার মান "10" হয়, তাহলে এই ক্ষেত্রের মান এই পরিমাণকে প্রতিফলিত করবে।

future_quota_value

int64

লঙ্ঘনের সময় নতুন কোটা মান চালু করা হচ্ছে। রোলআউট সম্পন্ন হওয়ার পরে, এই মানটি quota_value এর পরিবর্তে প্রয়োগ করা হবে। লঙ্ঘনের সময় যদি কোনও রোলআউট প্রক্রিয়াধীন না থাকে, তাহলে এই ক্ষেত্রটি সেট করা নেই।

উদাহরণস্বরূপ, যদি লঙ্ঘনের সময় CPU কোটার সংখ্যা 10 থেকে 20 এ পরিবর্তন করে একটি রোলআউট প্রক্রিয়াধীন থাকে, তাহলে এই ক্ষেত্রের মান 20 হবে।

তথ্য অনুরোধ করুন

বাগ ফাইল করার সময় বা অন্যান্য ধরণের প্রতিক্রিয়া প্রদানের সময় ক্লায়েন্টরা যে অনুরোধটি সংযুক্ত করতে পারে তার মেটাডেটা রয়েছে।

ক্ষেত্র
request_id

string

একটি অস্বচ্ছ স্ট্রিং যা কেবলমাত্র পরিষেবাটি তৈরি করে তার দ্বারা ব্যাখ্যা করা উচিত। উদাহরণস্বরূপ, এটি পরিষেবার লগে অনুরোধগুলি সনাক্ত করতে ব্যবহার করা যেতে পারে।

serving_data

string

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

রিসোর্সইনফো

যে রিসোর্সটি অ্যাক্সেস করা হচ্ছে তা বর্ণনা করে।

ক্ষেত্র
resource_type

string

যে ধরণের রিসোর্স অ্যাক্সেস করা হচ্ছে তার নাম, যেমন "sql table", "cloud storage bucket", "file", "Google calendar"; অথবা রিসোর্সের URL টাইপ: যেমন "type.googleapis.com/google.pubsub.v1.Topic"।

resource_name

string

যে রিসোর্সটি অ্যাক্সেস করা হচ্ছে তার নাম। উদাহরণস্বরূপ, একটি শেয়ার করা ক্যালেন্ডারের নাম: "example.com _4fghdhgsrgh@group.calendar.google.com" , যদি বর্তমান ত্রুটিটি google.rpc.Code.PERMISSION_DENIED হয়।

owner

string

রিসোর্সের মালিক (ঐচ্ছিক)। উদাহরণস্বরূপ, "ব্যবহারকারী: " অথবা "প্রকল্প: "।

description

string

এই রিসোর্সটি অ্যাক্সেস করার সময় কী কী ত্রুটির সম্মুখীন হতে হয় তা বর্ণনা করে। উদাহরণস্বরূপ, একটি ক্লাউড প্রকল্প আপডেট করার জন্য ডেভেলপার কনসোল প্রকল্পে writer অনুমতির প্রয়োজন হতে পারে।

পুনঃপ্রয়োগ তথ্য

ক্লায়েন্টরা কখন একটি ব্যর্থ অনুরোধ পুনরায় চেষ্টা করতে পারে তা বর্ণনা করে। ক্লায়েন্টরা এখানে সুপারিশ উপেক্ষা করতে পারে অথবা ত্রুটির প্রতিক্রিয়া থেকে এই তথ্য অনুপস্থিত থাকলে পুনরায় চেষ্টা করতে পারে।

পুনরায় চেষ্টা করার সময় ক্লায়েন্টদের সর্বদা এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করার পরামর্শ দেওয়া হয়।

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

ক্ষেত্র
retry_delay

Duration

একই অনুরোধ পুনরায় চেষ্টা করার মধ্যে ক্লায়েন্টদের কমপক্ষে এতক্ষণ অপেক্ষা করা উচিত।

অবস্থা

Status টাইপ একটি লজিক্যাল এরর মডেলকে সংজ্ঞায়িত করে যা REST API এবং RPC API সহ বিভিন্ন প্রোগ্রামিং পরিবেশের জন্য উপযুক্ত। এটি gRPC দ্বারা ব্যবহৃত হয়। প্রতিটি Status বার্তায় তিনটি ডেটা থাকে: ত্রুটি কোড, ত্রুটি বার্তা এবং ত্রুটির বিবরণ।

এই ত্রুটি মডেল এবং এটির সাথে কীভাবে কাজ করবেন সে সম্পর্কে আপনি API ডিজাইন গাইডে আরও জানতে পারবেন।

ক্ষেত্র
code

int32

স্ট্যাটাস কোড, যা google.rpc.Code এর একটি enum মান হওয়া উচিত।

message

string

ডেভেলপার-মুখোমুখি ত্রুটির বার্তা, যা ইংরেজিতে হওয়া উচিত। ব্যবহারকারী-মুখোমুখি যেকোনো ত্রুটির বার্তা স্থানীয়করণ করে google.rpc.Status.details ক্ষেত্রে পাঠানো উচিত, অথবা ক্লায়েন্ট দ্বারা স্থানীয়করণ করা উচিত।

details[]

Any

ত্রুটির বিবরণ বহনকারী বার্তাগুলির একটি তালিকা। API গুলির ব্যবহারের জন্য বার্তার ধরণের একটি সাধারণ সেট রয়েছে।