১১ এপ্রি, ২০২৫·8 মিনিট পড়তে

CRUD ব্যাকএন্ড ও API-র জন্য ন্যূনতম অবজার্ভেবিলিটি সেটআপ

Q: When should I bother adding observability to a CRUD-heavy app?

প্রোডাকশনে সমস্যা ব্যাখ্যা করতে যেখানে সময় লাগে তার চেয়ে সমস্যাটি ঠিক করতে সময় কম লাগে—এসবক্ষেত্রে observability যোগ করা শুরু করুন। যদি আপনি “র্যান্ডম 500s,” ধীর লিস্ট পেজ, বা রিক্রিয়েট করতে না পারা টাইমআউট দেখেন, একটি ছোট সেট কনসিস্টেন্ট লগ, মেট্রিক্স, এবং এলার্টস ঘণ্টার উপর ঘণ্টা ভাঙচুর করা সময় বাঁচাবে।

Q: What’s the difference between monitoring and observability in practice?

মনিটরিং আপনাকে বলে দেয় *কি* ভুল হয়েছে; অবজার্ভেবিলিটি আপনাকে বোঝায় *কেন* সেটা হলো — প্রাসঙ্গিক কনটেক্সট-সমৃদ্ধ সিগন্যাল ব্যবহার করে যেগুলো আপনি সম্পর্কিত করতে পারবেন। CRUD API-গুলির বাস্তব লক্ষ্য হল দ্রুত ডায়াগনোসিস: কোন এন্ডপয়েন্ট, কোন ব্যবহারকারী/টেন্যান্ট, এবং সময়টা অ্যাপে না ডাটাবেসে কেটে গেছে কিনা।

Q: What’s the smallest observability setup that actually works?

সিউক্তি করে বললে: স্ট্রাকচারড রিকোয়েস্ট লগ, কয়েকটি কোর মেট্রিক্স, এবং কিছু ইউজার-ইমপ্যাক্ট এলার্ট দিয়ে শুরু করুন। ট্রেসিং অনেক CRUD অ্যাপের জন্য অপেক্ষা করতে পারে যদি আপনার কাছে ইতিমধ্যে `duration_ms`, `db_time_ms` (বা সমতুল্য) এবং খুঁজে পাওয়া যায় এমন একটি স্থিতিশীল `request_id` থাকে।

Q: How do I set up correlation IDs so logs are useful during incidents?

একটি একক কোরিলেশন ফিল্ড যেমন `request_id` ব্যবহার করুন এবং তা প্রতিটি রিকোয়েস্ট লগ লাইনে এবং প্রতিটি ব্যাকগ্রাউন্ড জব রান-এ অন্তর্ভুক্ত করুন। এটিকে edge-এ জেনারেট করুন, অভ্যন্তরীণ কলগুলোর মাধ্যমে পাঠান, এবং নিশ্চিত করুন ওই ID দিয়েই লগ সার্চ করে একটি ব্যর্থ বা ধীর রিকোয়েস্ট দ্রুত পুনর্গঠন করা যায়।

Q: What should I include in structured logs for a CRUD API?

স্ট্রাকচারড লগে অন্তর্ভুক্ত করুন: `timestamp`, `level`, `service`, `env`, `route`, `method`, `status`, `duration_ms`, এবং নিরাপদ শনাক্তকারী যেমন `tenant_id` বা `account_id`। ডিফল্টভাবে ব্যক্তিগত ডেটা, টোকেন এবং পুরো রিকোয়েস্ট বডি লগ করা থেকে বিরত থাকুন; যদি গভীরে যেতে হয়, তা শুধু নির্দিষ্ট ত্রুটির জন্য রিড্যাকশন দিয়ে করুন।

Q: Which metrics matter most for CRUD backends and API services?

রিকোয়েস্ট রেট, 5xx রেট, ল্যাটেন্সি পার্সেন্টাইল (কমপক্ষে p50 এবং p95), এবং বেসিক স্যাচুরেশন (CPU/memory এবং কোনো ওয়ার্কার বা কিউ প্রেসার)। ডাটাবেস সময় এবং কানেকশন পুল ইউসেজ শুধু শুরুতেই যোগ করুন, কারণ অনেক CRUD আউটেজ আসলে ডাটাবেস কনটেনশন বা পুল এক্সহস্টশনের কারণে হয়।

Q: Why do you emphasize p95/p99 latency instead of average latency?

কারণ এরা ব্যবহারকারীরা আসলে অনুভব করে এমন স্লো টেইলকে লুকিয়ে রাখে। অ্যাভারেজগুলি ঠিক থাকা সত্ত্বেও p95 বা p99 অনেক অনুরোধের জন্য ভয়ানক হতে পারে—এটা ঠিক সেই অনুভূতি যা CRUD স্ক্রিনগুলোকে “র্যান্ডমলি ধীর” বানায়।

Q: What database signals should I measure first in PostgreSQL for CRUD apps?

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

Q: Which alerts should I set up first to avoid alert fatigue?

প্রথমত ব্যবহারকারী-লক্ষণে ভিত্তি করে এলার্ট দিন: দীর্ঘস্থায়ী 5xx রেট, পুসিত p95 ল্যাটেন্সি, অথবা সফল রিকোয়েস্টে হঠাৎ পতন। তারপরে “সম্ভাব্য কারণ” এলার্ট যোগ করুন (যেমন DB কানেকশন প্রায় লিমিটে, জব ব্যাকলগ বৃদ্ধি) যাতে অন কল সিগন্যাল বিশ্বাসযোগ্য ও কর্মযোগ্য থাকে।

Q: How do I tie incidents to deployments, especially with generated backends like AppMaster?

লগ, ড্যাশবোর্ড, এবং এলার্টে ভার্সন/বিল্ড মেটাডেটা লাগান এবং ডিপ্লয় মার্কার রেকর্ড করুন যাতে আপনি জানেন কখন চেঞ্জ শিপ হয়েছে। জেনারেটেড ব্যাকএন্ড (যেমন AppMaster-জেনারেটেড Go সার্ভিস) এর ক্ষেত্রে এটা বিশেষভাবে জরুরি, কারণ কোড রিজেনারেশন ও রিডিপ্লয় প্রায়ই হয় এবং আপনাকে দ্রুত যাচাই করতে হবে রিগ্রেশনটি রিলিজের পরে কি শুরু হয়েছে কিনা।

CRUD-ভিত্তিক ব্যাকএন্ডের জন্য ন্যূনতম অবজার্ভেবিলিটি: স্ট্রাকচারড লগ, মূল মেট্রিক্স, এবং বাস্তবসম্মত এলার্ট যাতে ধীর কুয়েরি, এরর এবং আউটেজ দ্রুত ধরা যায়।

CRUD-ভিত্তিক অ্যাপগুলিতে অবজার্ভেবিলিটি কোন সমস্যা সমাধান করে

CRUD-ভিত্তিক ব্যবসায়িক অ্যাপগুলো সাধারণত বিরক্তিকর, ব্যয়বহুল উপায়ে ফেল করে। একটি লিস্ট পেজ প্রতি সপ্তাহে ধীর হয়ে যায়, একটি সেভ বাটন মাঝে মাঝে টাইমআউট করে, এবং সাপোর্ট “র‌্যান্ডম 500s” রিপোর্ট করে যা আপনি পুনর্নির্মাণ করতে পারেন না। ডেভেলপমেন্টে কিছু ভাঙছে বলে মনে হয় না, কিন্তু প্রোডাকশন অনবিশ্বাস্য মনে হয়।

বাস্তব খরচ শুধু ইনসিডেন্ট নয়—এটা অনুমান করতে ব্যয় হওয়া সময়ও। স্পষ্ট সিগন্যাল না থাকলে টিমগুলো ঘোরে: “এটা নিশ্চয়ই ডাটাবেস,” “এটা নেটওয়ার্ক,” বা “এটা ঐ একটি এন্ডপয়েন্ট,” আর ব্যবহারকারীরা অপেক্ষা করে এবং বিশ্বাস কমে যায়।

অবজার্ভেবিলিটি সেই অনুমানগুলোকে উত্তরেই পরিণত করে। সহজভাবে: আপনি কি ঘটেছিল তা দেখে বুঝতে পারেন কেন ঘটেছে। সেটা অর্জন করা যায় তিন ধরনের সিগন্যাল দিয়ে:

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

CRUD অ্যাপ ও API সার্ভিসের জন্য এটি জটিল ড্যাশবোর্ডের চেয়ে দ্রুত ডায়াগনোসিসের ব্যাপার। যখন “Create invoice” কল ধীর হয়ে যায়, মিনিটের মধ্যে বলে দেওয়া উচিত বিলম্ব ডাটাবেস কুয়েরি থেকে এসেছে নাকি ডাউনস্ট্রিম API থেকে, অথবা ওভারলোডেড ওয়ার্কার থেকে।

একটা ন্যূনতম সেটআপ শুরু করার জন্য সেই প্রশ্নগুলো থেকে শুরু করুন যেগুলোর উত্তর একটি খারাপ দিনে আপনার দরকার:

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

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

ন্যূনতম সেটআপ: কী দরকার এবং কী বাদ দেওয়া যায়

একটি ন্যূনতম অবজার্ভেবিলিটি সেটআপের তিনটি স্তম্ভ আছে: লগ, মেট্রিক্স, এবং এলার্টস। ট্রেসিং উপকারী, কিন্তু অধিকাংশ CRUD-ভিত্তিক ব্যবসায়িক অ্যাপের জন্য তা একটি বোনাস।

লক্ষ্য সরল: আপনি জানতে পারবেন (1) কবে ব্যবহারকারীরা ব্যর্থ হচ্ছে, (2) কেন তারা ব্যর্থ হচ্ছে, এবং (3) সিস্টেমের কোথায় এটা ঘটছে। যদি আপনি দ্রুত সেই উত্তরগুলো না পেতে পারেন, আপনি অনুমান করে সময় নষ্ট করবেন এবং কী পরিবর্তিত হয়েছে তা নিয়ে তর্ক করবেন।

সিগন্যালের সবচেয়ে ছোট সেট যা সাধারণত আপনাকে সেখানে নিয়ে যায়, সেটা এমনঃ

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

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

একটি ব্যবহারিক নিয়ম: গুরুত্বপূর্ণ সিগন্যাল দেখার জন্য একটি মাত্র জায়গা বাছুন। লোগ টুল, মেট্রিক টুল, এবং আলাদা এলার্ট ইনবক্সের মধ্যে কনটেক্সট-সুইচিং ইনসিডেন্টে আপনাকে ধীর করে দেয়।

স্ট্রাকচারড লগ যা চাপের মধ্যে পড়লেও পাঠযোগ্য থাকে

কিছু ভেঙে পড়লে দ্রুত উত্তর পাওয়ার সবচেয়ে দ্রুত পথ সাধারণত: “এই ব্যবহারকারী কোন এক্স্যাক্ট রিকোয়েস্ট করেছিল?” এজন্যে একটি স্থিতিশীল কোরিলেশন ID প্রায় সব অন্য লগ টিউনের চেয়েও বেশি গুরুত্বপূর্ণ।

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

লগগুলো JSON-এ রাখুন, ফ্রি টেক্সট নয়। এতে লগ খোঁজার যোগ্য ও কনসিস্টেন্ট থাকে যখন আপনি ক্লান্ত, চাপাপ্রাপ্ত, এবং স্কিমিং করে পড়ছেন।

CRUD-ভিত্তিক API সার্ভিসের জন্য একটি সাধারণ ফিল্ড সেট বেশিরভাগ ক্ষেত্রে পর্যাপ্ত:

timestamp, level, service, env
request_id, route, method, status
duration_ms, db_query_count
tenant_id বা account_id (নিরাপদ শনাক্তকারী, ব্যক্তিগত ডেটা নয়)

লগগুলো আপনাকে সংকুচিতভাবে বলতে সাহায্য করবে “কোন ক্লায়েন্ট এবং কোন স্ক্রিন,” কিন্তু তা ডেটা লিকে পরিণত করা উচিত নয়। ডিফল্টভাবে নাম, ইমেইল, ফোন নম্বর, ঠিকানা, টোকেন, বা পুরো রিকোয়েস্ট বডি লগ করা এড়িয়ে চলুন। যদি গভীরে ডিবাগ লাগলে, কেবল অন-ডিমান্ড এবং রিড্যাকশন সহ লগ করুন।

CRUD সিস্টেমে দুটি ফিল্ড দ্রুত মূল্য দান করে: duration_ms এবং db_query_count. এগুলো ধীর হ্যান্ডলার ও আকস্মিক N+1 প্যাটার্নগুলো ট্রেসিং যোগ করার আগেই ধরতে সাহায্য করে।

লেভেলগুলোর সংজ্ঞা করুন যাতে সবাই একইভাবে ব্যবহার করে:

info: প্রত্যাশিত ইভেন্ট (রিকোয়েস্ট সম্পন্ন, জব শুরু)
warn: অস্বাভাবিক কিন্তু উদ্ধারযোগ্য (ধীর রিকোয়েস্ট, রিট্রাই সফল)
error: ব্যর্থ রিকোয়েস্ট বা জব (একসেপশন, টাইমআউট, খারাপ ডিপেন্ডেন্সি)

যদি আপনি AppMaster-এর মত প্ল্যাটফর্ম দিয়ে ব্যাকএন্ড তৈরি করেন, জেনারেটেড সার্ভিসগুলোর মধ্যে একই ফিল্ড নাম রাখুন যাতে “request_id দিয়ে সার্চ” সব জায়গায় কাজ করে।

CRUD ব্যাকএন্ড ও API-র জন্য সবচেয়ে গুরুত্বপূর্ণ কোর মেট্রিক্স

CRUD-ভিত্তিক অ্যাপগুলোর বেশিরভাগ ইনসিডেন্টে একই ধাঁচ দেখা যায়: এক-দুই এন্ডপয়েন্ট ধীর হয়, ডাটাবেস স্ট্রেস পায়, এবং ব্যবহারকারীরা স্পিনার বা টাইমআউট দেখে। আপনার মেট্রিক্সগুলোকে কয়েক মিনিটের মধ্যে সেই গল্পটি স্পষ্ট করে দিতে হবে।

একটি ন্যূনতম সেট সাধারণত পাঁচটি ক্ষেত্র কভার করে:

ট্রাফিক: প্রতিটি সেকেন্ডে রিকোয়েস্ট (route অনুযায়ী বা অন্তত সার্ভিস অনুযায়ী) এবং স্ট্যাটাস ক্লাস অনুযায়ী রিকোয়েস্ট রেট (2xx, 4xx, 5xx)
এররস: 5xx রেট, টাইমআউট কাউন্ট, এবং “বিজনেস এরর” হিসেবে ফিরে আসা 4xx এর আলাদা মেট্রিক (যাতে ব্যবহারকারীর ভুলের জন্য মানুষ পেজ না পান)
ল্যাটেন্সি (পার্সেন্টাইল): প50 সাধারণ অভিজ্ঞতার জন্য এবং প95 (কখনো কখনো প99) “কোথাও কিছু ভুল” সনাক্ত করার জন্য
স্যাচুরেশন: CPU ও মেমরি, প্লাস অ্যাপ-নির্দিষ্ট স্যাচুরেশন (ওয়ার্কার ইউটিলাইজেশন, থ্রেড/গোরুটিন প্রেসার যদি আপনি প্রকাশ করেন)
ডাটাবেস প্রেসার: কুয়েরি ডিউরেশন p95, কানেকশন পুল ইন-ইউজ বনাম ম্যাক্স, এবং লক ওয়েট টাইম (অথবা লক অপেক্ষায় থাকা কুয়েরির কাউন্ট)

দুটি বিশদ জিনিস মেট্রিক্সকে অনেক বেশি কার্যকর করে তোলে।

প্রথমত, ইন্টারেক্টিভ API রিকোয়েস্টগুলোকে ব্যাকগ্রাউন্ড কাজ থেকে আলাদা রাখুন। ধীর ইমেইল সেন্ডার বা webhook রিট্রাই লুপ CPU, DB কানেকশন, বা আউটগোয়িং নেটওয়ার্ককে স্টার্ভ করে API-কে “র‌্যান্ডমলি ধীর” করে তুলতে পারে। কিউ, রিট্রাই, এবং জব ডিউরেশনকে আলাদা টাইম সিরিজ হিসেবে ট্র্যাক করুন, যদিও তারা একই ব্যাকএন্ডে চলছে।

দ্বিতীয়ত, ড্যাশবোর্ড ও এলার্টসে সর্বদা ভার্সন/বিল্ড মেটাডেটা যোগ করুন। যখন আপনি একটি নতুন জেনারেটেড ব্যাকএন্ড ডিপ্লয় করবেন (উদাহরণস্বরূপ, AppMaster-এর মত নো-কোড টুল থেকে কোড রিজেনারেট করে), আপনি দ্রুত একটি প্রশ্নের উত্তর দিতে চাইবেন: কি রিলিজের পরে এরর রেট বা p95 ল্যাটেন্সি বৃদ্ধি পেয়েছে?

একটি সাধারণ নিয়ম: যদি কোনো মেট্রিক আপনাকে পরবর্তী কী করা উচিত তা বলে না (রোলব্যাক, স্কেল, কুয়েরি ফিক্স, অথবা জব বন্ধ), তবে এটা আপনার ন্যূনতম সেটে থাকা উচিত নয়।

ডাটাবেস সিগন্যাল: CRUD ব্যথার সাধারণ মূল কারণ

জবগুলোকে সমস্যাগ্রস্ত না হতে দিন

ব্যাকগ্রাউন্ড জব ও API ফ্লো গুলো আলাদা রাখুন যাতে ইনসিডেন্ট ডায়াগনোসিস সহজ হয়।

চেষ্টা করুন

CRUD-ভিত্তিক অ্যাপে ডাটাবেস প্রায়ই সেই জায়গা যেখানে “এটা ধীর লাগছে” বাস্তব ব্যবহারকারী ব্যথায় পরিণত হয়। একটি ন্যূনতম সেটআপ বোঝায় যখন বটলনেক PostgreSQL, নয় কি তা এবং কী ধরনের DB সমস্যা।

PostgreSQL-এ প্রথমে কী মাপবেন

আপনাকে দরকার নেই অসংখ্য ড্যাশবোর্ড। শুরু করুন এমন সিগন্যাল দিয়ে যা বেশিরভাগ ইনসিডেন্ট ব্যাখ্যা করে:

ধীর কুয়েরির হার ও p95/p99 কুয়েরি সময় (সাথে শীর্ষ ধীর কুয়েরিগুলো)
লক ওয়েট ও ডেডলক (কে কাকে ব্লক করছে)
কানেকশন ব্যবহার (এক্টিভ কানেকশন বনাম পুল লিমিট, ব্যর্থ কানেকশন)
ডিস্ক ও I/O চাপ (ল্যাটেন্সি, স্যাচুরেশন, ফ্রি স্পেস)
রেপ্লিকেশন লেগ (যদি আপনি রিড রেপ্লিকা চালান)

অ্যাপ সময় বনাম DB সময় আলাদা করা

API লেয়ারে একটি কুয়েরি টাইমিং হিস্টোগ্রাম যোগ করুন এবং এটিকে এন্ডপয়েন্ট বা ইউজ কেস দিয়ে ট্যাগ করুন (উদাহরণ: GET /customers, “search orders”, “update ticket status”)। এটা দেখায় একটি এন্ডপয়েন্ট কি অনেক ছোট কুয়েরি চালায় নাকি একটি বড় কুয়েরি চলাচ্ছে।

N+1 প্যাটার্নগুলি আগেভাগে ধরুন

CRUD স্ক্রিনগুলো প্রায়ই N+1 কুয়েরি ট্রিগার করে: একটি লিস্ট কুয়েরি, তারপর প্রতিটি সারির জন্য সম্পর্কিত ডেটা আনতে আলাদা কুয়েরি। এমন এন্ডপয়েন্টগুলো দেখুন যেখানে রিকোয়েস্ট সংখ্যা সমান থাকে কিন্তু প্রতিটি রিকোয়েস্টে DB কুয়েরি সংখ্যা বাড়ছে। যদি আপনি মডেল ও বিজনেস লজিক থেকে ব্যাকএন্ড জেনারেট করেন, এখানেই সাধারণত ফেচ প্যাটার্ন টিউন করেন।

যদি আপনার কাছে ইতিমধ্যে ক্যাশ থাকে, হিট রেট ট্র্যাক করুন। ভালো চার্ট পেতে কেবলমাত্র ক্যাশ যোগ করবেন না।

স্কিমা পরিবর্তন ও মাইগ্রেশনকে ঝুঁকি উইন্ডো হিসেবে দেখুন। কখনো শুরু ও শেষ রেকর্ড করুন, তারপর ওই উইন্ডোর সময় লক, কুয়েরি সময়, এবং কানেকশন এরর স্পাইক দেখুন।

সঠিক ব্যক্তিকে সঠিক কারণে জাগানোর মতো এলার্ট

একটি টেকসই CRUD অ্যাপ শিপ করুন

একটি ইন্টারনাল টুল বা অ্যাডমিন পোর্টাল তৈরি করুন এবং একটি কনসিস্টেন্ট স্ট্যাক দিয়ে পারফরম্যান্স প্রেডিক্টেবল রাখুন।

ফ্রি শুরু করুন

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

শুরুতে আপনি যদি কেবল তিনটি এলার্ট যোগ করেন, সেগুলো করুনঃ

বাড়তে থাকা 5xx রেট
স্থায়ী প95 ল্যাটেন্সি
সফল রিকোয়েস্টে হঠাৎ পতন

তারপর কিছু “সম্ভাব্য কারণ” এলার্ট যোগ করুন। CRUD ব্যাকএন্ডগুলো প্রিডিক্টেবল উপায়ে ব্যর্থ হয়: ডাটাবেস কানেকশন শেষ হয়ে যায়, ব্যাকগ্রাউন্ড কিউ জমে যায়, অথবা একটি একক এন্ডপয়েন্ট টাইমআউট হয়ে সামগ্রিক API-কে ধীর করে দেয়।

থ্রেশহোল্ড: বেসলাইন + মার্জিন, অনুমান নয়

“p95 > 200ms” ধরনের হার্ডকোড সংখ্যা সাধারণত পরিবেশভেদে কাজ করে না। একটি স্বাভাবিক সপ্তাহ পরিমাপ করুন, তারপর এলার্টটিকে স্বাভাবিকের একটু উপরে একটি সেফটি মার্জিন দিয়ে সেট করুন। উদাহরণস্বরূপ, যদি প95 ল্যাটেন্সি সাধারণত ব্যবসায়িক সময়ে 350-450ms হয়, 700ms-এ 10 মিনিটের জন্য এলার্ট দিন। যদি 5xx সাধারণত 0.1-0.3% হয়, 2%-এ 5 মিনিটের জন্য পেজ করুন।

থ্রেশহোল্ডগুলো স্থিতিশীল রাখুন; প্রতিদিন সেগুলো টিউন করবেন না। একটি ইনসিডেন্টের পর টিউন করুন, যখন আপনি পরিবর্তনের সাথে বাস্তব আউটকাম যুক্ত করতে পারেন।

পেজ বনাম টিকিট: প্রয়োজন পড়ার আগে সিদ্ধান্ত নিন

দুটি সেভারিটি ব্যবহার করুন যাতে মানুষ সিগন্যালকে বিশ্বাস করে:

পেজ করুন যখন ব্যবহারকারীরা ব্লকড অথবা ডেটা ঝুঁকিতে (উচ্চ 5xx, API টাইমআউট, DB কানেকশন পুল প্রায় ভরতি)
টিকিট তৈরি করুন যখন এটা ধীরে ধীরে খারাপ হচ্ছে কিন্তু জরুরি নয় (প95 ধীরে ধীরে বেড়ে যাওয়া, কিউ ব্যাকলগ বাড়ছে, ডিস্ক ইউসেজ ট্রেন্ডিং আপ)

ডিপ্লয় উইন্ডো ও পরিকল্পিত মেইনটেন্যান্সের সময় এলার্ট সাইলেন্স করুন।

এলার্টগুলোকে কর্মযোগ্য করে তুলুন। “প্রথমে কি চেক করবেন” (শীর্ষ এন্ডপয়েন্ট, DB কানেকশন, সাম্প্রতিক ডিপ্লয়) এবং “কি পরিবর্তিত হয়েছে” (নতুন রিলিজ, স্কিমা আপডেট) অন্তর্ভুক্ত করুন। যদি আপনি AppMaster ব্যবহার করেন, নোট করুন কোন ব্যাকএন্ড বা মডিউলটি সম্প্রতি রিজেনারেট এবং ডিপ্লয় করা হয়েছে—কারণ সেটাই প্রায়শই সবচেয়ে দ্রুত লিড দেয়।

ব্যবসায়িক অ্যাপের জন্য সহজ SLOs (এবং কিভাবে তা এলার্টগুলো গঠন করে)

একটি ন্যূনতম সেটআপ সহজ হয় যখন আপনি সিদ্ধান্ত নেন “ভালো পর্যাপ্ত” মানে কী। SLOs সেটাই করে: স্পষ্ট টার্গেট যা অস্পষ্ট মনিটরিংকে নির্দিষ্ট এলার্টে পরিণত করে।

শুরু করুন এমন SLIs থেকে যা ব্যবহারকারীর অনুভূতির সাথে মিল রাখে: অ্যাভিলেবিলিটি (ব্যবহারকারী রিকোয়েস্ট সম্পন্ন করতে পারে কি না), ল্যাটেন্সি (কত দ্রুত অ্যাকশন শেষ হয়), এবং এরর রেট (কত ঘন ঘন রিকোয়েস্ট ব্যর্থ হয়)।

এন্ডপয়েন্ট গ্রুপ প্রতি SLO সেট করুন, রুট প্রতি নয়। CRUD-ভিত্তিক অ্যাপের জন্য গ্রুপ করলে পড়তে সুবিধা হয়: রিডস (GET/list/search), রাইটস (create/update/delete), এবং অথ (login/token refresh)। এতে শত শত ছোট SLO এড়ানো যায় যেগুলো কেউ রক্ষণাবেক্ষণ করে না।

টিপিক্যাল উদাহরণ SLOs:

ইনটার্নাল CRUD অ্যাপ (অ্যাডমিন পোর্টাল): মাসিক 99.5% অ্যাভিলেবিলিটি, রিড অনুরোধের 95% < 800 ms, রাইট অনুরোধের 95% < 1.5 s, এরর রেট < 0.5%।
পাবলিক API: মাসিক 99.9% অ্যাভিলেবিলিটি, রিড অনুরোধের 99% < 400 ms, রাইট অনুরোধের 99% < 800 ms, এরর রেট < 0.1%।

এরর বাজেট হলো SLO-র ভেতরের অনুমোদিত “খারাপ সময়”। মাসিক 99.9% অ্যাভিলেবিলিটি SLO মানে প্রায় 43 মিনিট ডাউনটাইম মাসে অনুমোদিত। যদি সেটা আগেভাগে খরচ হয়ে যায়, ঝুঁকিপূর্ণ পরিবর্তনগুলো স্থগিত করুন যতক্ষণ না স্থিতিশীলতা ফিরে আসে।

SLOs ব্যবহার করুন সিদ্ধান্ত নেবার জন্য কি এলার্ট পাবেন বনাম কি কেবল ড্যাশবোর্ড ট্রেন্ড। যখন আপনি এরর বাজেট দ্রুত পোড়াচ্ছেন তখন এলার্ট দিন (ব্যবহারকারীরা সক্রিয়ভাবে ব্যর্থ হচ্ছে), কেবলমাত্র metric কিছুটা খারাপ হলে না।

যদি আপনি দ্রুত ব্যাকএন্ড তৈরি করেন (উদাহরণ: AppMaster থেকে Go সার্ভিস জেনারেট করা), SLOs ব্যবহার করে ব্যবহারকারী প্রভাব উপর ফোকাস রাখুন এমনকি যখন ইমপ্লিমেন্টেশন পরিবর্তিত হচ্ছে।

ধাপে ধাপে: এক দিনে একটি ন্যূনতম অবজার্ভেবিলিটি সেটআপ গঠন

API মনিটরিং সহজ করুন

নিয়মিত এন্ডপয়েন্ট সহ Go সার্ভিস জেনারেট করে আপনার ড্যাশবোর্ড পড়তে সহজ রাখুন।

এখনই তৈরি করুন

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

আপনার টপ এন্ডপয়েন্ট ও ব্যাকগ্রাউন্ড কাজগুলো লিখে নিন। CRUD ব্যবসায়িক অ্যাপের জন্য সাধারণত সেটা হলো লগইন, লিস্ট/search, create/update, এবং এক বা দুটো এক্সপোর্ট/ইম্পোর্ট জব। যদি আপনি AppMaster দিয়ে ব্যাকএন্ড বানিয়েছেন, আপনার জেনারেটেড এন্ডপয়েন্ট এবং যে কোনো Business Process ফ্লো যা শিডিউলে বা webhook-এ চলে সেগুলো অন্তর্ভুক্ত করুন।

এক দিনের পরিকল্পনা

ঘন্টা 1: আপনার শীর্ষ 5 এন্ডপয়েন্ট এবং 1-2 ব্যাকগ্রাউন্ড জব বাছুন। “ভাল” কেমন দেখায় লিখে নিন: টিপিক্যাল ল্যাটেন্সি, প্রত্যাশিত এরর রেট, নরমাল DB টাইম।
ঘন্টা 2-3: কনসিস্টেন্ট ফিল্ডসহ স্ট্রাকচারড লগ যোগ করুন: request_id, user_id (যদি থাকে), endpoint, status_code, latency_ms, db_time_ms, এবং একটি ছোট error_code পরিচিত ব্যর্থতাগুলোর জন্য।
ঘন্টা 3-4: কোর মেট্রিক্স যোগ করুন: requests per second, p95 latency, 4xx রেট, 5xx রেট, এবং DB টাইমিং (কুয়েরি ডিউরেশন এবং কানেকশন পুল স্যাচুরেশন যদি থাকে)।
ঘন্টা 4-6: তিনটি ড্যাশবোর্ড বানান: একটি ওভারভিউ (স্বাস্থ্য এক নজরে), একটি API ডিটেইল ভিউ (এন্ডপয়েন্ট ব্রেকডাউন), এবং একটি ডাটাবেস ভিউ (ধীর কুয়েরি, লক, কানেকশন ইউসেজ)।
ঘন্টা 6-8: এলার্ট যোগ করুন, একটি কন্ট্রোলড ফেলিওর ট্রিগার করুন, এবং নিশ্চিত করুন এলার্টটি কার্যকর।

এলার্টগুলো Few and focused রাখুন। আপনি এমন এলার্ট চান যা ব্যবহারকারীর প্রভাব দেখায়, “কাউকে কিছু পরিবর্তিত হয়েছে” না।

শুরু করার জন্য এলার্ট (5-8 টি)

একটি শক্তিশালী শুরু সেট: API p95 ল্যাটেন্সি অত্যাধিক, স্থায়ী 5xx রেট, 4xx-এ হঠাৎ স্পাইক (সাধারণত অথ বা ভ্যালিডেশন পরিবর্তন), ব্যাকগ্রাউন্ড জব ব্যর্থতা, DB ধীর কুয়েরি, DB কানেকশন প্রায় লিমিট, এবং নীচু ডিস্ক স্পেস (যদি self-hosted)।

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

সাধারণ ভুল যা মনিটরিংকে শব্দাক্ত বা অকেজো করে দেয়

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

সবচেয়ে সাধারণ ব্যর্থতা হলো এলার্ট ফ্যাটিগ: অতিরিক্ত এলার্ট, অল্প অ্যাকশন। আপনি যদি প্রতিটি स्पাইক-এ পেজ দেন, মানুষ দ্বিতীয় সপ্তাহের মধ্যে এলার্ট বিশ্বাস করা বন্ধ করে দেয়। একটি ভাল নিয়ম: একটি এলার্ট সম্ভবত একটি সম্ভাব্য ফিক্স নির্দেশ করা উচিত, কেবল “কিছু পরিবর্তিত” না।

আরেকটি ক্লাসিক ভুল হলো কোরিলেশন ID বাদ দেওয়া। যদি আপনি একটি এরর লগ, একটি ধীর রিকোয়েস্ট, এবং একটি DB কুয়েরি এক রিকোয়েস্টের সাথে ট্যাগ করতে না পারেন, আপনি ঘন্টা নষ্ট করবেন। নিশ্চিত করুন প্রতিটি রিকোয়েস্ট request_id পায় (এবং এটি লগ, ট্রেসে যদি থাকে, এবং নিরাপদ হলে রেসপন্সেও)।

সাধারণত কি গোলমাল তৈরি করে

শোরগোলপূর্ণ সিস্টেমগুলো সাধারণত একই সমস্যাগুলো শেয়ার করে:

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

CRUD অ্যাপগুলো বিশেষভাবে "গড়ের ফাঁদ"-এর প্রতি সংবেদনশীল। একটি একক ধীর কুয়েরি 5% অনুরোধকে কষ্টদায়ক করে তুলতে পারে যখন গড় ঠিক থাকে। টেইল ল্যাটেন্সি প্লাস এরর রেট একটি পরিষ্কার চিত্র দেয়।

ডিপ্লয় মার্কার যোগ করুন। আপনি CI থেকে শিপ করুন বা AppMaster-এর মত প্ল্যাটফর্ম থেকে কোড জেনারেট করুন—ভার্সন ও ডিপ্লয় সময় ইভেন্ট হিসেবে এবং লগেও রেকর্ড করুন।

দ্রুত চেকগুলি: একটি ন্যূন্যমাত্রার অবজার্ভেবিলিটি চেকলিস্ট

সাধারণ ফিচারগুলো সুরক্ষিতভাবে যোগ করুন

বিল্ট-ইন অথ ও ইন্টিগ্রেশন ব্যবহার করে কাস্টম গ্লু এড়িয়ে মনিটরিং সহজ রাখুন।

মডিউলগুলো দেখুন

আপনার সেটআপ কাজ করছে যখন আপনি দ্রুত কয়েকটি প্রশ্নের উত্তর পেতে পারেন, ড্যাশবোর্ড খুঁটিয়ে দেখতে 20 মিনিট ব্যয় না করে। যদি আপনি তাত্ক্ষণিকভাবে “হ্যাঁ/না” না পেতে পারেন, আপনি একটি মূল সিগন্যাল মিস করছেন বা আপনার ভিউগুলো খুব বিভক্ত।

ইনসিডেন্ট চলাকালীন দ্রুত চেক

আপনার অধিকাংশ কাজ এক মিনিটের মধ্যে করা উচিত:

কি আপনি একক এরর ভিউ (5xx, টাইমআউট, ব্যর্থ জব) থেকে বলতে পারবেন ব্যবহারকারীরা কি এখনই ব্যর্থ হচ্ছে (হ্যাঁ/না)?
কি আপনি সবচেয়ে ধীর এন্ডপয়েন্ট গ্রুপ এবং তার p95 ল্যাটেন্সি চোখে পড়া যায়, এবং দেখা যায় তা আরও খারাপ হচ্ছে কি না?
কি আপনি একটি রিকোয়েস্টের জন্য অ্যাপ টাইম বনাম DB টাইম আলাদা করতে পারেন (handler time, DB query time, বাহ্যিক কল)?
কি আপনি দেখতে পাচ্ছেন ডাটাবেস কানেকশন লিমিট নিকট কিংবা CPU লিমিটে পৌঁছাচ্ছে কি না, এবং কুয়েরি কি কিউ হচ্ছে?
যদি একটি এলার্ট ফায়ার করে, কি তা একটি পরবর্তী অ্যাকশন সাজেস্ট করে (রোলব্যাক, স্কেল, DB কানেকশন চেক, একটি নির্দিষ্ট এন্ডপয়েন্ট ইন্সপেক্ট), কেবলমাত্র “ল্যাটেন্সি উচ্চ” নয়?

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

লগ স্যানিটি চেক

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

আপনি যদি CRUD-ভিত্তিক ব্যাকএন্ড AppMaster দিয়ে তৈরি করেন, একটি একক “ইনসিডেন্ট ভিউ” লক্ষ্য করুন যা এই চেকগুলো মিলায়: এরর, এন্ডপয়েন্ট অনুযায়ী p95 ল্যাটেন্সি, এবং DB হেলথ। সেটাই বেশি বাস্তব ইনসিডেন্ট কভার করে।

উদাহরণ: সঠিক সিগন্যাল দিয়ে একটি ধীর CRUD স্ক্রিন ডায়গনোসিস করা

আপনার ইনসিডেন্ট চেকলিস্ট পরীক্ষা করুন

টপ 5 এন্ডপয়েন্ট দ্রুত প্রোটোটাইপ করুন এবং বাস্তব ট্রাফিকের বিরুদ্ধে আপনার ন্যূনতম এলার্ট যাচাই করুন।

AppMaster ব্যবহার করে দেখুন

একটি ইন্টার্নাল অ্যাডমিন পোর্টাল সকালে ঠিক ছিল, তারপর ব্যস্ত সময়ে খুব ধীর হয়ে যায়। ব্যবহারকারীরা অভিযোগ করে “Orders” লিস্ট খোলা ও এডিট সেভ করা 10-20 সেকেন্ড নিচ্ছে।

আপনি টপ-লেভেল সিগন্যাল দিয়ে শুরু করেন। API ড্যাশবোর্ড দেখায় রিড এন্ডপয়েন্টগুলোর p95 ল্যাটেন্সি প্রায় 300 ms থেকে 4-6 s-এ লাফিয়েছে, অথচ এরর রেট কমই আছে। একই সময়ে ডাটাবেস প্যানেল দেখায় একটিভ কানেকশন পুল লিমিটের কাছে এবং লক ওয়েট বাড়ছে। ব্যাকএন্ড নোডগুলোর CPU স্বাভাবিক, তাই এটা কণ্ঠকাঠিন্য সমস্যা নয়।

এরপর আপনি একটি ধীর রিকোয়েস্ট বাছেন এবং লগে তার পথে অনুসরণ করেন। GET /orders দিয়ে ফিল্টার করে ডিউরেশন অনুযায়ী সাজান। 6-সেকেন্ড রিকোয়েস্ট থেকে একটি request_id নিয়ে সার্ভিস জুড়ে সার্চ করুন। আপনি দেখেন হ্যান্ডলার দ্রুত শেষ করেছে, কিন্তু ঐ একই request_id-এর মধ্যে DB কুয়েরি লগ লাইনটি 5.4 সেকেন্ড দেখাচ্ছে, rows=50 এবং বড় lock_wait_ms সহ।

এবার আপনি নিশ্চিতভাবে কারণ বলতে পারেন: ধীরতা ডাটাবেস পাথে (ধীর কুয়েরি বা লক কনটেনশন) আছে, নেটওয়ার্ক বা ব্যাকএন্ড CPU নয়। এটা একটি ন্যূনতম সেটআপ আপনাকে দেয়: অনুসন্ধান দ্রুত সংকুচিত করা।

প্রথাগত ফিক্স গুলো, সুরক্ষার দিক থেকে অল্প ঝুঁকিযুক্ত থেকে বেশি ঝুঁকিযুক্তঃ

লিস্ট স্ক্রিনে ব্যবহৃত ফিল্টার/সোর্ট-এর জন্য ইনডেক্স যোগ বা সমন্বয় করুন।
N+1 কুয়েরি সরান: সম্পর্কিত ডেটা এক কুয়েরিতে বা একটি যোগে নিয়ে আসুন।
লোডের সময় DB স্টার্ভ না করার জন্য কানেকশন পুল টিউন করুন।
শুধুমাত্র স্থিতিশীল, রিড-হেভি ডেটার জন্য ক্যাশ যোগ করুন (এবং invalidation নিয়ম ডকুমেন্ট করুন)।

ফিডব্যাক ক্লোজ করুন একটি লক্ষ্যমাত্রিক এলার্ট দিয়ে। কেবল তখনই পেজ করুন যখন একটি এন্ডপয়েন্ট গ্রুপের p95 ল্যাটেন্সি আপনার থ্রেশহোল্ডের উপরে 10 মিনিট ধরে থাকে এবং DB কানেকশন ইউসেজ প্রায় (উদাহরণস্বরূপ) 80%। ওই সংমিশ্রণ নয়েজ এড়ায় এবং পরবর্তীতে দ্রুত ধরবে।

পরবর্তী ধাপ: ন্যূনতম রাখুন, তারপর বাস্তব ইনসিডেন্ট দিয়ে উন্নত করুন

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

প্রতিটি ইনসিডেন্টকে ফিডব্যাক হিসেবে নিন। ফিক্স শিপ হওয়ার পরে জিজ্ঞাসা করুন: কি থাকলে এটা দ্রুত খুঁজে পাওয়া যেত এবং সহজে ডায়াগনোসিস হত? কেবল সেইটুকুই যোগ করুন।

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

একটি ছোট রিলিজ শৃঙ্খলা দ্রুত ফল দেয়:

ডিপ্লয় মার্কার (ভার্সন, এনভায়রনমেন্ট, কমিট/বিল্ড ID) যোগ করুন যাতে আপনি দেখতে পারেন সমস্যা কি রিলিজের পরে শুরু হয়েছে কিনা।
টপ 3 এলার্টের জন্য একটি ছোট রানবুক লিখুন: এর মানে কী, প্রথম চেক, এবং কে দায়িত্বে।
প্রতিটি সার্ভিসের জন্য একটি “গোল্ডেন” ড্যাশবোর্ড রাখুন যা অপরিহার্যগুলো দেখায়।

আপনি যদি AppMaster দিয়ে ব্যাকএন্ড বানান, তবে observability ফিল্ড ও কোর মেট্রিক আগে থেকে প্ল্যান করা সুবিধা দেয় যাতে প্রতিটি নতুন API কনসিস্টেন্ট স্ট্রাকচারড লগ এবং হেলথ সিগন্যাল নিয়ে শিপ করে। যদি আপনি একটি শুরু করার জায়গা চান, AppMaster (appmaster.io) এমনভাবে ডিজাইন করা হয়েছে যাতে এটি প্রোডাকশন-রেডি ব্যাকএন্ড, ওয়েব, এবং মোবাইল অ্যাপ জেনারেট করে এবং ইমপ্লিমেন্টেশন পরিবর্তন হলে কনসিস্টেন্সি বজায় রাখে।

একটি সময়ে একটি উন্নতি বাছুন, বাস্তবে যা কষ্ট দিয়েছে তার উপরে ভিত্তি করে:

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

প্রতি বাস্তব ইনসিডেন্টের পরে সেই চক্রটি পুনরাবৃত্তি করুন। কয়েক সপ্তাহে আপনার কাছে এমন মনিটরিং হবে যা আপনার CRUD অ্যাপ এবং API ট্রাফিকের সাথে মানানসই, একটি জেনেরিক টেমপ্লেট নয়।

প্রশ্নোত্তর

প্রোডাকশনে সমস্যা ব্যাখ্যা করতে যেখানে সময় লাগে তার চেয়ে সমস্যাটি ঠিক করতে সময় কম লাগে—এসবক্ষেত্রে observability যোগ করা শুরু করুন। যদি আপনি “র‌্যান্ডম 500s,” ধীর লিস্ট পেজ, বা রিক্রিয়েট করতে না পারা টাইমআউট দেখেন, একটি ছোট সেট কনসিস্টেন্ট লগ, মেট্রিক্স, এবং এলার্টস ঘণ্টার উপর ঘণ্টা ভাঙচুর করা সময় বাঁচাবে।

মনিটরিং আপনাকে বলে দেয় কি ভুল হয়েছে; অবজার্ভেবিলিটি আপনাকে বোঝায় কেন সেটা হলো — প্রাসঙ্গিক কনটেক্সট-সমৃদ্ধ সিগন্যাল ব্যবহার করে যেগুলো আপনি সম্পর্কিত করতে পারবেন। CRUD API-গুলির বাস্তব লক্ষ্য হল দ্রুত ডায়াগনোসিস: কোন এন্ডপয়েন্ট, কোন ব্যবহারকারী/টেন্যান্ট, এবং সময়টা অ্যাপে না ডাটাবেসে কেটে গেছে কিনা।

সিউক্তি করে বললে: স্ট্রাকচারড রিকোয়েস্ট লগ, কয়েকটি কোর মেট্রিক্স, এবং কিছু ইউজার-ইমপ্যাক্ট এলার্ট দিয়ে শুরু করুন। ট্রেসিং অনেক CRUD অ্যাপের জন্য অপেক্ষা করতে পারে যদি আপনার কাছে ইতিমধ্যে duration_ms, db_time_ms (বা সমতুল্য) এবং খুঁজে পাওয়া যায় এমন একটি স্থিতিশীল request_id থাকে।

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

স্ট্রাকচারড লগে অন্তর্ভুক্ত করুন: timestamp, level, service, env, route, method, status, duration_ms, এবং নিরাপদ শনাক্তকারী যেমন tenant_id বা account_id। ডিফল্টভাবে ব্যক্তিগত ডেটা, টোকেন এবং পুরো রিকোয়েস্ট বডি লগ করা থেকে বিরত থাকুন; যদি গভীরে যেতে হয়, তা শুধু নির্দিষ্ট ত্রুটির জন্য রিড্যাকশন দিয়ে করুন।

রিকোয়েস্ট রেট, 5xx রেট, ল্যাটেন্সি পার্সেন্টাইল (কমপক্ষে p50 এবং p95), এবং বেসিক স্যাচুরেশন (CPU/memory এবং কোনো ওয়ার্কার বা কিউ প্রেসার)। ডাটাবেস সময় এবং কানেকশন পুল ইউসেজ শুধু শুরুতেই যোগ করুন, কারণ অনেক CRUD আউটেজ আসলে ডাটাবেস কনটেনশন বা পুল এক্সহস্টশনের কারণে হয়।

কারণ এরা ব্যবহারকারীরা আসলে অনুভব করে এমন স্লো টেইলকে লুকিয়ে রাখে। অ্যাভারেজগুলি ঠিক থাকা সত্ত্বেও p95 বা p99 অনেক অনুরোধের জন্য ভয়ানক হতে পারে—এটা ঠিক সেই অনুভূতি যা CRUD স্ক্রিনগুলোকে “র‌্যান্ডমলি ধীর” বানায়।

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

প্রথমত ব্যবহারকারী-লক্ষণে ভিত্তি করে এলার্ট দিন: দীর্ঘস্থায়ী 5xx রেট, পুসিত p95 ল্যাটেন্সি, অথবা সফল রিকোয়েস্টে হঠাৎ পতন। তারপরে “সম্ভাব্য কারণ” এলার্ট যোগ করুন (যেমন DB কানেকশন প্রায় লিমিটে, জব ব্যাকলগ বৃদ্ধি) যাতে অন কল সিগন্যাল বিশ্বাসযোগ্য ও কর্মযোগ্য থাকে।

লগ, ড্যাশবোর্ড, এবং এলার্টে ভার্সন/বিল্ড মেটাডেটা লাগান এবং ডিপ্লয় মার্কার রেকর্ড করুন যাতে আপনি জানেন কখন চেঞ্জ শিপ হয়েছে। জেনারেটেড ব্যাকএন্ড (যেমন AppMaster-জেনারেটেড Go সার্ভিস) এর ক্ষেত্রে এটা বিশেষভাবে জরুরি, কারণ কোড রিজেনারেশন ও রিডিপ্লয় প্রায়ই হয় এবং আপনাকে দ্রুত যাচাই করতে হবে রিগ্রেশনটি রিলিজের পরে কি শুরু হয়েছে কিনা।