Sentry না Better Stack—error context আর uptime একই কাজ নয়

অ্যাপের ভেতরে ত্রুটির কারণ খোঁজা প্রধান প্রয়োজন হলে Sentry দিয়ে শুরু করুন। সাইট বা এপিআই বাইরে থেকে সাড়া দিচ্ছে কি না দেখা এবং বিভ্রাটে দায়িত্বপ্রাপ্ত ব্যক্তিকে জানানো বেশি জরুরি হলে Better Stack আগে বসান। দুই ধরনের সংকেতই প্রয়োজন হলে সেবা দুটি একসঙ্গে ব্যবহার করা যায়; লগ সংরক্ষণের সিদ্ধান্তটি আলাদা করে নিতে হবে।

ফিচারে কিছু মিল আছে: Better Stack প্ল্যাটফর্মেও এরর ট্র্যাকিং আছে। তবু একটি ত্রুটির স্ট্যাক ট্রেস, সেবার বাইরে থেকে পাওয়া সাড়া এবং ঘটনার সময়ের লগ ভিন্ন প্রশ্নের উত্তর দেয়। স্টার্টআপের জন্য প্রথম সিদ্ধান্ত তাই কোন নামের প্যাকেজে বেশি সুবিধা আছে, তা নয়; কোন ব্যর্থতার খবর এখন সবচেয়ে সহজে চোখ এড়িয়ে যেতে পারে, সেটি।

অ্যাপ সচল, কিন্তু একটি কাজ ব্যর্থ হচ্ছে

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

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

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

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

পুরো সেবা বন্ধ হলে বাইরের পরীক্ষা জরুরি

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

Better Stack-এর মনিটরিং নির্দেশিকায় বাইরে থেকে ওয়েব ঠিকানা পরীক্ষা, প্রত্যাশিত সফল এইচটিটিপি সাড়া না পেলে ইনসিডেন্ট তৈরি এবং দায়িত্বে থাকা ব্যক্তিকে সতর্ক করার ব্যবস্থা বর্ণিত আছে। তিনি সাড়া না দিলে সতর্কবার্তা দলের অন্য সদস্যদের কাছেও যেতে পারে। ফলে পরীক্ষা, সতর্কবার্তা ও দায়িত্ব বদলের পথ একই ইনসিডেন্টের অংশ হয়; গ্রাহকদের জন্য স্ট্যাটাস পেজ সেই ইনসিডেন্ট সম্পর্কে যোগাযোগের আরেকটি স্তর।

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

ঘটনার লগ হারালে কী জানা যায় না

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

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

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

বিনামূল্যের সীমা, সংরক্ষণ ও আসনের দাম

PennyBlack-এর তুলনায় Sentry প্ল্যাটফর্মের বিনামূল্যের Developer স্তরে মাসে ৫,০০০ ত্রুটি এবং ইস্যু দেখার ৩০ দিনের মেয়াদ উল্লেখ আছে; একই সংস্থার একাধিক প্রকল্প ওই ত্রুটি-সীমা ভাগ করে। ফলে একটি পণ্যে যথেষ্ট মনে হওয়া সীমা কয়েকটি অ্যাপ চালানো প্রতিষ্ঠানে দ্রুত ফুরাতে পারে। ওই মেয়াদকে লগ বা রিপ্লের মেয়াদ বলে ধরে নেওয়াও ঠিক হবে না।

Better Stack-এর মূল্যতালিকায় ব্যক্তিগত প্রকল্পের বিনামূল্যের স্তরে ১০টি মনিটর ও হার্টবিট, একটি স্ট্যাটাস পেজ, মাসে ১,০০,০০০টি এক্সসেপশন এবং মাসে ৩ জিবি লগ ৩ দিন রাখার সীমা দেখানো হয়েছে; এরর ট্র্যাকিংয়ের সংরক্ষণকাল ৯০ দিন, আর অর্থপ্রদানের দায়িত্বপ্রাপ্ত ব্যক্তির আসন বার্ষিক বিলিংয়ে মাসে ২৯ ডলার বা মাসিক বিলিংয়ে ৩৪ ডলার থেকে শুরু। বিনামূল্যের স্তরটি ব্যক্তিগত প্রকল্পের জন্য দেখানো, তাই দলীয় ব্যবহারের হিসাব করার সময় সেটির শর্ত মিলিয়ে নিতে হবে। আসনের দামকে সব ধরনের অতিরিক্ত ব্যবহারসহ পুরো পর্যবেক্ষণ ব্যবস্থার মোট খরচ ভাবা যাবে না।

এই সংখ্যাগুলো সরাসরি সমান মাপের প্যাকেজের তুলনা নয়। Sentry প্ল্যাটফর্মের ত্রুটির সংখ্যা, Better Stack প্ল্যাটফর্মের মনিটর ও এক্সসেপশনের সংখ্যা এবং লগের পরিমাণ ভিন্ন ভিন্ন সীমা। কোনটি আগে ব্যয়সাপেক্ষ হবে, তা আপনার পণ্যে ত্রুটি কত তৈরি হয়, কোন ঠিকানাগুলো দেখতে হয়, কত লগ আসে এবং কতজনকে ইনসিডেন্টের দায়িত্ব দিতে হয়—এসবের ওপর নির্ভর করবে।

কোন ব্যবস্থা আগে বসাবেন

ব্যবহারকারীর কাজ মাঝপথে ভাঙছে অথচ সেবা সচল—এটাই প্রধান ঝুঁকি হলে প্রথমে অ্যাপের ত্রুটি সংগ্রহ বসান। Sentry প্ল্যাটফর্মের কোড ও সেশনের প্রেক্ষাপট সেই প্রয়োজনের সঙ্গে সরাসরি মেলে; এক সেবায় সব রাখতে চাইলে Better Stack প্ল্যাটফর্মের এরর ট্র্যাকিং আপনার ঘটনার জন্য যথেষ্ট তথ্য দিচ্ছে কি না দেখুন। পুরো সেবা অপ্রাপ্য হওয়ার খবর দেরিতে পাওয়াই বড় ঝুঁকি হলে আগে বাইরের পরীক্ষা ও দায়িত্বপ্রাপ্ত ব্যক্তির সতর্কবার্তা চালু করুন।

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

আরও পড়ুন:

• Claude Code খরচ বাড়ে পুরোনো context-এ: কমানোর ছয়টি বাস্তব উপায়
• বাস্তব office context-এ AI agent-এর pass rate নেমেছে ৬৮.২%-এ
• বাংলাদেশে AI-তে ৫৩.৮ লাখ কাজ ঝুঁকিতে: কোন দক্ষতা আগে বদলাবে