স্পোর্টমাস্টার মনিটর - কিভাবে এবং কি সঙ্গে

আমরা পণ্য দল গঠনের পর্যায়ে একটি মনিটরিং সিস্টেম তৈরি করার কথা ভেবেছিলাম। এটা স্পষ্ট হয়ে গেল যে আমাদের ব্যবসা-শোষণ- এই দলগুলোর মধ্যে পড়ে না। কেন এমন হল?

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

আমাদের দল, পরিবর্তে, এমন সিস্টেমগুলির সাথে কাজ করে যা একে অপরের সাথে খুব দৃঢ়ভাবে একত্রিত হয়: তাদের মধ্যে অনেকগুলি সংযোগ রয়েছে, এটি একটি খুব বড় অবকাঠামো। এবং অনলাইন স্টোরের অপারেশন এই সমস্ত সিস্টেমের উপর নির্ভর করে (যার মধ্যে আমাদের কাছে একটি বিশাল সংখ্যা রয়েছে)।

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

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

• সদর
• মধ্যবর্তী অফিস
• ব্যাক অফিস

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

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

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

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

সিস্টেম গঠন এবং স্ট্যাক

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

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

তাই, তারা হাতিটিকে ভাগ করে খাওয়ার সিদ্ধান্ত নিয়েছে।

আমাদের সিস্টেমের মধ্যে রয়েছে:

• হার্ডওয়্যার;
• অপারেটিং সিস্টেম;
• সফটওয়্যার;
• পর্যবেক্ষণ অ্যাপ্লিকেশনে UI অংশ;
• ব্যবসার পরিমাপ;
• ইন্টিগ্রেশন অ্যাপ্লিকেশন;
• তথ্য নিরাপত্তা;
• নেটওয়ার্ক;
• ট্রাফিক ব্যালেন্সার

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

সুতরাং, স্ট্যাক সম্পর্কে.

আমরা ওপেন সোর্স সফটওয়্যার ব্যবহার করি। কেন্দ্রে আমাদের Zabbix আছে, যা আমরা প্রাথমিকভাবে একটি সতর্কতা ব্যবস্থা হিসেবে ব্যবহার করি। সবাই জানে যে এটি অবকাঠামো পর্যবেক্ষণের জন্য আদর্শ। এটার মানে কি? ঠিক সেই নিম্ন-স্তরের মেট্রিকগুলি যা প্রতিটি কোম্পানির নিজস্ব ডেটা সেন্টার রক্ষণাবেক্ষণ করে (এবং স্পোর্টমাস্টারের নিজস্ব ডেটা সেন্টার রয়েছে) - সার্ভারের তাপমাত্রা, মেমরি স্ট্যাটাস, রেইড, নেটওয়ার্ক ডিভাইস মেট্রিক্স।

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

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

অন্যান্য স্তরগুলির জন্য ডেটা উত্স, উদাহরণস্বরূপ, ব্যবসায়িক মেট্রিক্স, তিনটি উপাদানে বিভক্ত।

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

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

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

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

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

পর্যবেক্ষণের আরেকটি অপরিহার্য বৈশিষ্ট্য হল ভিজ্যুয়ালাইজেশন। আমাদের Grafana উপর ভিত্তি করে. এটি অন্যান্য ভিজ্যুয়ালাইজেশন সিস্টেমের মধ্যে আলাদা যে এটি আপনাকে ড্যাশবোর্ডে বিভিন্ন ডেটা উত্স থেকে মেট্রিকগুলি কল্পনা করতে দেয়৷ আমরা একটি অনলাইন স্টোরের জন্য টপ-লেভেল মেট্রিক্স সংগ্রহ করতে পারি, উদাহরণস্বরূপ, ডিবিএমএস থেকে শেষ ঘন্টায় কতগুলি অর্ডার দেওয়া হয়েছে, যে OSটিতে এই অনলাইন স্টোরটি Zabbix থেকে চলছে তার পারফরম্যান্স মেট্রিক্স এবং এই অ্যাপ্লিকেশনের উদাহরণগুলির জন্য মেট্রিক্স প্রমিথিউস থেকে। এবং এই সব একটি ড্যাশবোর্ডে হবে. পরিষ্কার এবং অ্যাক্সেসযোগ্য।

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

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

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

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

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

সম্ভাবনা

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

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

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

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

এই সব একটি সতর্কতা নির্মাণের জন্য প্রয়োজনীয়তা সম্পর্কে. তারপর পরিস্থিতি দুটি দিকে বিকশিত হতে পারে - হয় একটি সমস্যা আছে এবং সমাধান করা প্রয়োজন, বা পর্যবেক্ষণ ব্যবস্থায় একটি ব্যর্থতা হয়েছে। কিন্তু যাই হোক না কেন, আপনাকে যেতে হবে এবং এটি বের করতে হবে।

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

আমরা যে সিস্টেমগুলি পরিচালনা করি সেগুলি পর্যবেক্ষণ করা এবং আমাদের পক্ষে গুরুত্বপূর্ণ হিসাবে বিবেচিত মেট্রিকগুলি সংগ্রহ করার পাশাপাশি, মনিটরিং সিস্টেম আমাদের পণ্য দলের জন্য ডেটা সংগ্রহ করতে দেয়৷ তারা আমাদের পর্যবেক্ষণ করা তথ্য সিস্টেমের মধ্যে মেট্রিক্সের গঠনকে প্রভাবিত করতে পারে।

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

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

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

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

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

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

উত্স: www.habr.com