SRE (সাইট নির্ভরযোগ্যতা প্রকৌশল) হল ওয়েব প্রকল্পের প্রাপ্যতা নিশ্চিত করার একটি পদ্ধতি। এটি DevOps-এর জন্য একটি কাঠামো হিসাবে বিবেচিত হয় এবং DevOps অনুশীলনগুলি প্রয়োগ করার ক্ষেত্রে কীভাবে সাফল্য অর্জন করা যায় সে সম্পর্কে কথা বলে। এই নিবন্ধে অনুবাদ অধ্যায় 6 মনিটরিং ডিস্ট্রিবিউটেড সিস্টেম বই সাইট নির্ভরযোগ্যতা প্রকৌশল গুগল থেকে। আমি নিজে এই অনুবাদটি প্রস্তুত করেছি এবং পর্যবেক্ষণ প্রক্রিয়াগুলি বোঝার ক্ষেত্রে আমার নিজের অভিজ্ঞতার উপর নির্ভর করেছি। টেলিগ্রাম চ্যানেলে @monitorim_it и মিডিয়াম ব্লগ আমি পরিষেবা স্তরের লক্ষ্য সম্পর্কে একই বইয়ের 4 অধ্যায়ের অনুবাদের একটি লিঙ্কও প্রকাশ করেছি।

বিড়াল দ্বারা অনুবাদ. পড়া ভোগ!

Google-এর SRE টিমের মৌলিক নীতি এবং সফল পর্যবেক্ষণ এবং বিজ্ঞপ্তি সিস্টেম তৈরির জন্য সর্বোত্তম অনুশীলন রয়েছে। এই অধ্যায়টি একটি ওয়েব পেজ ভিজিটর কোন সমস্যাগুলির সম্মুখীন হতে পারে এবং ওয়েব পেজগুলিকে প্রদর্শন করা কঠিন করে এমন সমস্যাগুলি কীভাবে সমাধান করা যায় সে সম্পর্কে নির্দেশিকা প্রদান করে৷

নির্ধারণ করা

মনিটরিং সম্পর্কিত বিষয় নিয়ে আলোচনা করার জন্য কোন একক শব্দভান্ডার ব্যবহার করা হয় না। এমনকি Google-এ, নীচের পদগুলি সাধারণত ব্যবহৃত হয় না, তবে আমরা সবচেয়ে সাধারণ ব্যাখ্যাগুলি তালিকাভুক্ত করব৷

পর্যবেক্ষণ

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

হোয়াইট-বক্স পর্যবেক্ষণ

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

ব্ল্যাক-বক্স পর্যবেক্ষণ

ব্যবহারকারীর দৃষ্টিকোণ থেকে অ্যাপ্লিকেশন আচরণ পরীক্ষা করা।

ড্যাশবোর্ড

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

সতর্কতা (বিজ্ঞপ্তি)

ইমেল বা অন্যান্য উপায়ে একজন ব্যক্তির দ্বারা প্রাপ্ত করার উদ্দেশ্যে বিজ্ঞপ্তি, যা ত্রুটি বা অনুরোধের সারিতে বৃদ্ধির কারণে ট্রিগার হতে পারে। বিজ্ঞপ্তিগুলিকে শ্রেণীবদ্ধ করা হয়েছে: টিকিট, ইমেল সতর্কতা এবং তাত্ক্ষণিক বার্তাবাহক বার্তা৷

মূল কারণ

একটি সফ্টওয়্যার ত্রুটি বা মানব ত্রুটি যা একবার সংশোধন করা হলে আবার ঘটতে হবে না। সমস্যাটির বেশ কয়েকটি প্রধান কারণ থাকতে পারে: অপর্যাপ্ত প্রক্রিয়া অটোমেশন, সফ্টওয়্যার ত্রুটি, অ্যাপ্লিকেশন যুক্তির অপর্যাপ্ত বিশদ বিবরণ। এই কারণগুলির প্রতিটি মূল কারণ হতে পারে, এবং তাদের প্রতিটি নির্মূল করা আবশ্যক।

নোড এবং মেশিন (নোড এবং মেশিন)

একটি ফিজিক্যাল সার্ভার, ভার্চুয়াল মেশিন, বা কন্টেইনারে চলমান অ্যাপ্লিকেশনের একটি একক দৃষ্টান্ত উল্লেখ করার জন্য বিনিময়যোগ্য পদ। একটি মেশিন বিভিন্ন পরিষেবা হোস্ট করতে পারে। পরিষেবাগুলি হতে পারে:

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

ধাক্কা

সফ্টওয়্যার কনফিগারেশনে কোনো পরিবর্তন।

কেন পর্যবেক্ষণ প্রয়োজন?

অ্যাপ্লিকেশনগুলিকে নিরীক্ষণ করার জন্য বেশ কয়েকটি কারণ রয়েছে:

দীর্ঘমেয়াদী প্রবণতা বিশ্লেষণ

ডাটাবেস কত বড় এবং কত দ্রুত বাড়ছে? কিভাবে ব্যবহারকারীদের দৈনিক সংখ্যা পরিবর্তন হয়?

কর্মক্ষমতা তুলনা

Ajax DB 2.72 এর তুলনায় বাইট 3.14 এর Acme বাকেটের অনুরোধগুলি কি দ্রুত? একটি অতিরিক্ত নোডের উপস্থিতির পরে অনুরোধগুলি ক্যাশে করা কতটা ভাল? সাইটটি কি গত সপ্তাহের তুলনায় ধীর গতিতে চলছে?

সতর্কতা (বিজ্ঞপ্তি)

কিছু ভেঙ্গে গেছে এবং কাউকে এটা ঠিক করতে হবে। অথবা কিছু শীঘ্রই ভেঙ্গে যাবে এবং কাউকে শীঘ্রই এটি পরীক্ষা করা দরকার।

ড্যাশবোর্ড তৈরি করা হচ্ছে

ড্যাশবোর্ডে মৌলিক প্রশ্নের উত্তর দেওয়া উচিত এবং এর থেকে কিছু অন্তর্ভুক্ত করা উচিত "4টি সুবর্ণ সংকেত" — বিলম্ব (লেটেন্সি), ট্রাফিক (ট্র্যাফিক), ত্রুটি (ত্রুটি) এবং লোডের আকার (স্যাচুরেশন)।

পূর্ববর্তী বিশ্লেষণ পরিচালনা করা (ডিবাগিং)

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

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

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

মনিটরিং সিস্টেমের জন্য যুক্তিসঙ্গত প্রত্যাশা সেট করা

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

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

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

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

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

লক্ষণ বনাম কারণ

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

লক্ষণ
কারণ

HTTP ত্রুটি 500 বা 404 পাচ্ছেন
ডাটাবেস সার্ভার সংযোগ প্রত্যাখ্যান করে

ধীর সার্ভার প্রতিক্রিয়া
উচ্চ CPU ব্যবহার বা ক্ষতিগ্রস্ত ইথারনেট তারের

অ্যান্টার্কটিকার ব্যবহারকারীরা বিড়ালের জিআইএফ পাচ্ছেন না
আপনার CDN বিজ্ঞানী এবং বিড়ালদের ঘৃণা করে, তাই কিছু আইপি ঠিকানা কালো তালিকাভুক্ত করা হয়েছে

ব্যক্তিগত বিষয়বস্তু সব জায়গা থেকে উপলব্ধ করা হয়েছে
একটি নতুন সফ্টওয়্যার রিলিজের রোলআউট ফায়ারওয়ালকে সমস্ত ACL ভুলে গেছে এবং সবাইকে প্রবেশ করতে দিয়েছে৷

সর্বাধিক সংকেত এবং সর্বনিম্ন শব্দ সহ একটি ভাল মনিটরিং সিস্টেম তৈরি করার জন্য "কি" এবং "কেন" সবচেয়ে গুরুত্বপূর্ণ বিল্ডিং ব্লকগুলির মধ্যে একটি।

ব্ল্যাক-বক্স বনাম হোয়াইট-বক্স

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

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

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

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

চারটি সোনালী সংকেত

চারটি সোনালী পর্যবেক্ষণ সংকেত হল লেটেন্সি, ট্রাফিক, ত্রুটি এবং স্যাচুরেশন। আপনি যদি শুধুমাত্র চারটি ব্যবহারকারী সিস্টেম মেট্রিক্স পরিমাপ করতে পারেন, তাহলে সেই চারটিতে ফোকাস করুন।

বিলম্ব

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

ট্রাফিক

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

ত্রুটি

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

পরিপৃক্তি

মেট্রিক দেখায় যে আপনার পরিষেবা কতটা নিবিড়ভাবে ব্যবহার করা হয়েছে। এটি একটি সিস্টেম মনিটরিং পরিমাপ যা সর্বাধিক সীমাবদ্ধ সংস্থানগুলি সনাক্ত করে (উদাহরণস্বরূপ, একটি মেমরি-সীমাবদ্ধ সিস্টেমে, মেমরি দেখায়, একটি I/O- সীমাবদ্ধ সিস্টেমে, I/Os সংখ্যা দেখায়)। লক্ষ্য করুন যে অনেক সিস্টেম 100% ব্যবহারে পৌঁছানোর আগেই কর্মক্ষমতা হ্রাস করে, তাই একটি ব্যবহারের লক্ষ্য থাকা গুরুত্বপূর্ণ।

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

অবশেষে, সম্পৃক্তি আসন্ন স্যাচুরেশন সম্পর্কে ভবিষ্যদ্বাণীগুলির সাথেও যুক্ত, উদাহরণস্বরূপ: "মনে হচ্ছে আপনার ডাটাবেস আপনার হার্ড ড্রাইভ 4 ঘন্টার মধ্যে পূরণ করবে।"

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

"লেজ" (বা যন্ত্র এবং কর্মক্ষমতা) নিয়ে উদ্বিগ্ন

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

ধীর গড় এবং অনুরোধের খুব ধীর লেজের মধ্যে পার্থক্য করার সবচেয়ে সহজ উপায় হল প্রকৃত বিলম্বের পরিবর্তে পরিসংখ্যানে প্রকাশিত অনুরোধের পরিমাপ সংগ্রহ করা (প্রদর্শনের জন্য একটি ভাল টুল হল হিস্টোগ্রাম) এবং 0 ms, 10 ms এবং 10 ms এর মধ্যে, 30 ms এবং 30 ms এর মধ্যে, 100 ms এবং 100 ms এর মধ্যে, ইত্যাদি। হিস্টোগ্রামের সীমানা আনুমানিকভাবে প্রসারিত করা (300 এর আনুমানিক ফ্যাক্টর দ্বারা) প্রায়শই বিতরণটি কল্পনা করার একটি সহজ উপায় অনুরোধ

পরিমাপের জন্য যথাযথ স্তরের বিশদ নির্বাচন করা

সিস্টেমের বিভিন্ন উপাদান বিশদ বিভিন্ন স্তরে পরিমাপ করা আবশ্যক. উদাহরণ স্বরূপ:

• নির্দিষ্ট সময়ের মধ্যে CPU ব্যবহার নিরীক্ষণ করা দীর্ঘমেয়াদী স্পাইক দেখাবে না যা উচ্চ বিলম্বের দিকে পরিচালিত করে।
• অন্যদিকে, প্রতি বছর 9 ঘন্টার বেশি ডাউনটাইম (99,9% বার্ষিক আপটাইম) লক্ষ্য করে একটি ওয়েব পরিষেবার জন্য, HTTP 200 প্রতিক্রিয়ার জন্য প্রতি মিনিটে একবার বা দুইবার চেক করা অপ্রয়োজনীয়ভাবে ঘন ঘন হতে পারে।
• একইভাবে, প্রতি 99,9-1 মিনিটে একবারের বেশি 2% উপলব্ধতার জন্য হার্ড ড্রাইভের স্থান পরীক্ষা করা সম্ভবত প্রয়োজনীয় নয়।

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

1. প্রতি সেকেন্ডে CPU লোড পরিমাপ করুন।
2. বিস্তারিত কমিয়ে 5% করুন।
3. প্রতি মিনিটে মোট মেট্রিক্স।

এই কৌশলটি আপনাকে উচ্চ বিশ্লেষণ এবং স্টোরেজ ওভারহেড খরচ না করে একটি উচ্চ গ্রানুলিটিতে ডেটা সংগ্রহ করার অনুমতি দেবে।

যতটা সম্ভব সহজ, কিন্তু সহজ নয়

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

• অনুরোধ প্রক্রিয়াকরণের বিলম্বের জন্য বিভিন্ন থ্রেশহোল্ড অনুযায়ী সতর্কতা, বিভিন্ন শতাংশে, সব ধরনের বিভিন্ন সূচকের জন্য।
• সম্ভাব্য কারণ সনাক্ত এবং সনাক্ত করতে অতিরিক্ত কোড লেখা।
• সমস্যার সম্ভাব্য প্রতিটি কারণের জন্য সম্পর্কিত ড্যাশবোর্ড তৈরি করুন।

সম্ভাব্য জটিলতার উত্স কখনও শেষ হয় না। সমস্ত সফ্টওয়্যার সিস্টেমের মতো, মনিটরিং এত জটিল হয়ে উঠতে পারে যে এটি ভঙ্গুর এবং পরিবর্তন এবং বজায় রাখা কঠিন হয়ে পড়ে।

অতএব, আপনার মনিটরিং সিস্টেমটিকে যতটা সম্ভব সহজ করার জন্য ডিজাইন করুন। কী ট্র্যাক করবেন তা বেছে নেওয়ার সময়, নিম্নলিখিতগুলি মনে রাখবেন:

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

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

একসাথে মূলনীতি বাঁধা

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

পর্যবেক্ষণ এবং সতর্কতার নিয়ম তৈরি করার সময়, নিম্নলিখিত প্রশ্ন জিজ্ঞাসা করা আপনাকে মিথ্যা ইতিবাচক এবং অপ্রয়োজনীয় সতর্কতা এড়াতে সাহায্য করতে পারে:

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

এই প্রশ্নগুলি সতর্কতা এবং সতর্কতা ব্যবস্থার মৌলিক দর্শনকে প্রতিফলিত করে:

• প্রতিবার যখনই একটি সতর্কতা আসে, আমাকে অবিলম্বে প্রতিক্রিয়া জানাতে হয়। আমি ক্লান্ত হওয়ার আগে দিনে কয়েকবার জরুরিভাবে প্রতিক্রিয়া জানাতে পারি।
• প্রতিটি সতর্কতা অবশ্যই প্রাসঙ্গিক হতে হবে।
• একটি সতর্কতার প্রতিটি প্রতিক্রিয়ার জন্য অবশ্যই মানুষের হস্তক্ষেপ প্রয়োজন। যদি বিজ্ঞপ্তিটি স্বয়ংক্রিয়ভাবে প্রক্রিয়া করা যায় তবে এটি পৌঁছানো উচিত নয়।
• সতর্কতা একটি নতুন সমস্যা বা ইভেন্ট সম্পর্কে হওয়া উচিত যা আগে বিদ্যমান ছিল না।

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

দীর্ঘমেয়াদী পর্যবেক্ষণ

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

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

বিগটেবল এসআরই: ওভার-সতর্কতার গল্প

Google-এর অভ্যন্তরীণ অবকাঠামো সাধারণত একটি পরিষেবা স্তরের (SLO) সাথে পরিমাপ করা হয়। অনেক বছর আগে, Bigtable-এর পরিষেবা SLO একটি লাইভ ক্লায়েন্টকে অনুকরণ করে একটি সিন্থেটিক লেনদেনের গড় কর্মক্ষমতার উপর ভিত্তি করে ছিল। Bigtable এবং স্টোরেজ স্ট্যাকের নিম্ন স্তরের সমস্যাগুলির কারণে, গড় কর্মক্ষমতা একটি "বড়" লেজের দ্বারা চালিত হয়েছিল: সবচেয়ে খারাপ 5% প্রশ্নগুলি প্রায়ই বাকিগুলির তুলনায় উল্লেখযোগ্যভাবে ধীর ছিল।

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

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

এই কৌশলটি ক্রমাগত কৌশলগত সমস্যাগুলি ঠিক করার পরিবর্তে বিগটেবল এবং স্টোরেজ স্ট্যাকের নিম্ন স্তরে দীর্ঘমেয়াদী সমস্যাগুলি সমাধান শুরু করার জন্য আমাদের শ্বাস-প্রশ্বাসের ঘরের অনুমতি দিয়েছে। প্রকৌশলীরা আসলে সব সময় সতর্কতার সাথে বোমাবর্ষণ না করেই কাজটি সম্পন্ন করতে পারে। শেষ পর্যন্ত, সতর্কতা প্রক্রিয়াকরণ সাময়িকভাবে স্থগিত করা আমাদের পরিষেবার মান উন্নত করার অনুমতি দিয়েছে।

Gmail: অনুমানযোগ্য, অ্যালগরিদমিক মানব প্রতিক্রিয়া

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

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

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

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

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

দীর্ঘ মেয়াদী

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

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

উপসংহার

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

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

শেষ পর্যন্ত অনুবাদ পড়ার জন্য আপনাকে ধন্যবাদ. মনিটরিং সম্পর্কে আমার টেলিগ্রাম চ্যানেলে সাবস্ক্রাইব করুন @monitorim_it и মিডিয়াম ব্লগ.

উত্স: www.habr.com