মনিটরিং কি মৃত? - দীর্ঘ লাইভ পর্যবেক্ষণ

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

আমি বিশ্বাস করি যে একটি সঠিক মনিটরিং সিস্টেম সংগঠিত একটি সমস্যা আছে. যদি কোন সমস্যা না হত, তাহলে আমার বক্তৃতায় একটি থিসিস থাকত: "দয়া করে প্রমিথিউস + গ্রাফানা এবং প্লাগইন 1, 2, 3 ইনস্টল করুন।" দুর্ভাগ্যক্রমে, এটি আর সেভাবে কাজ করে না। এবং প্রধান সমস্যা হল যে সবাই সফ্টওয়্যার উপাদানগুলির পরিপ্রেক্ষিতে 2008 সালে বিদ্যমান কিছুতে বিশ্বাস করে চলেছে।

মনিটরিং সিস্টেমের সংগঠন সম্পর্কে, আমি বলতে চাই যে... উপযুক্ত পর্যবেক্ষণ সহ প্রকল্পগুলি বিদ্যমান নেই। এবং পরিস্থিতি এতটাই খারাপ যে কিছু পড়ে গেলে, এটি অলক্ষিত হওয়ার ঝুঁকি রয়েছে - সর্বোপরি, সবাই নিশ্চিত যে "সবকিছু পর্যবেক্ষণ করা হয়।"
সম্ভবত সবকিছু পর্যবেক্ষণ করা হচ্ছে। কিন্তু কিভাবে?

আমরা সকলেই নিম্নলিখিতগুলির মতো একটি গল্পের মুখোমুখি হয়েছি: একজন নির্দিষ্ট ডেভপস, একজন নির্দিষ্ট প্রশাসক কাজ করছেন, একটি উন্নয়ন দল তাদের কাছে আসে এবং বলে - "আমরা মুক্তি পেয়েছি, এখন মনিটর করুন।" কি মনিটর? কিভাবে এটা কাজ করে?

ঠিক আছে. আমরা পুরানো পদ্ধতিতে নজরদারি করি। এবং এটি ইতিমধ্যেই পরিবর্তিত হচ্ছে, এবং দেখা যাচ্ছে যে আপনি পরিষেবা A নিরীক্ষণ করেছেন, যা পরিষেবা B হয়ে উঠেছে, যা পরিষেবা C এর সাথে যোগাযোগ করে। কিন্তু উন্নয়ন দল আপনাকে বলে: "সফ্টওয়্যার ইনস্টল করুন, এটি সবকিছু পর্যবেক্ষণ করা উচিত!"

তাহলে কি পরিবর্তন হয়েছে? - সব কিছু বদলে গেছে!

2008 সবকিছু ঠিক আছে

কয়েকটা ডেভেলপার আছে, একটা সার্ভার, একটা ডাটাবেস সার্ভার। এখান থেকে সব যায়। আমাদের কাছে কিছু তথ্য আছে, আমরা zabbix, Nagios, cacti ইনস্টল করি। এবং তারপরে আমরা CPU, ডিস্ক অপারেশন এবং ডিস্ক স্পেসে পরিষ্কার সতর্কতা সেট করি। সাইটটি সাড়া দিচ্ছে এবং ডাটাবেসে অর্ডার আসছে তা নিশ্চিত করতে আমরা কয়েকটি ম্যানুয়াল চেকও করি। এবং এটিই - আমরা কমবেশি সুরক্ষিত।

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

2010 ভার বাড়ছে

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

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

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

দ্রষ্টব্য: আমি 3 বার "স্ক্রিপ্টের একটি সেট" লিখেছি। অর্থাৎ, নিরীক্ষণের জন্য দায়ী ব্যক্তিটি আর নয় যে কেবল জ্যাবিক্স ইনস্টল করে। এটি এমন একজন ব্যক্তি যিনি কোডিং শুরু করেন। কিন্তু এখনও দলের মনে কিছুই বদলায়নি।

কিন্তু পৃথিবী বদলে যাচ্ছে, আরও জটিল হচ্ছে। একটি ভার্চুয়ালাইজেশন স্তর এবং বেশ কয়েকটি নতুন সিস্টেম যুক্ত করা হয়েছে। তারা একে অপরের সাথে যোগাযোগ শুরু করে। কে বলেছে "মাইক্রোসার্ভিসের মতো গন্ধ?" কিন্তু প্রতিটি পরিষেবা এখনও পৃথকভাবে একটি ওয়েবসাইটের মত দেখায়। আমরা এটির দিকে ফিরে যেতে পারি এবং বুঝতে পারি যে এটি প্রয়োজনীয় তথ্য সরবরাহ করে এবং নিজে থেকে কাজ করে। এবং আপনি যদি 5-7-10 বছর ধরে বিকাশমান একটি প্রকল্পের সাথে ক্রমাগত জড়িত একজন প্রশাসক হন, তাহলে এই জ্ঞানটি জমা হয়: একটি নতুন স্তর উপস্থিত হয় - আপনি এটি উপলব্ধি করেছেন, অন্য একটি স্তর উপস্থিত হয় - আপনি এটি উপলব্ধি করেছেন ...

কিন্তু খুব কমই কেউ 10 বছরের জন্য একটি প্রকল্পের সাথে থাকে।

মনিটরিংম্যানের জীবনবৃত্তান্ত

ধরুন আপনি একটি নতুন স্টার্টআপে এসেছেন যেটি অবিলম্বে 20 জন বিকাশকারীকে নিয়োগ করেছে, 15টি মাইক্রোসার্ভিস লিখেছে এবং আপনি একজন প্রশাসক যাকে বলা হয়েছে: "সিআই/সিডি তৈরি করুন৷ অনুগ্রহ." আপনি CI/CD তৈরি করেছেন এবং হঠাৎ আপনি শুনতে পাচ্ছেন: "আমাদের জন্য একটি "কিউব"-এ উত্পাদনের সাথে কাজ করা কঠিন, অ্যাপ্লিকেশনটি কীভাবে কাজ করবে তা না বুঝে। একই "কিউব"-এ আমাদের একটি স্যান্ডবক্স তৈরি করুন।
আপনি এই ঘনক্ষেত্রে একটি স্যান্ডবক্স তৈরি করুন। তারা অবিলম্বে আপনাকে বলে: "আমরা একটি স্টেজ ডাটাবেস চাই যা প্রতিদিন উত্পাদন থেকে আপডেট হয়, যাতে আমরা বুঝতে পারি যে এটি ডাটাবেসে কাজ করে, কিন্তু একই সাথে উত্পাদন ডাটাবেসটি নষ্ট না করে।"

আপনি এই সব বাস. মুক্তির আগে 2 সপ্তাহ বাকি আছে, তারা আপনাকে বলে: "এখন আসুন এই সমস্ত পর্যবেক্ষণ করি..." অর্থাৎ। ক্লাস্টার অবকাঠামো নিরীক্ষণ করুন, মাইক্রোসার্ভিস আর্কিটেকচার নিরীক্ষণ করুন, বাহ্যিক পরিষেবাগুলির সাথে কাজ মনিটর করুন...

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

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

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

আসুন একটি একেবারে স্বাভাবিক কেস মনে রাখি: কিছু পরিষেবা পিএইচপি-তে, কিছু পরিষেবা গো-তে, কিছু পরিষেবা JS-তে। তারা কোন না কোনভাবে একে অপরের সাথে কাজ করে। এখানেই "মাইক্রোসার্ভিস" শব্দটি এসেছে: এখানে অনেকগুলি পৃথক সিস্টেম রয়েছে যে বিকাশকারীরা পুরো প্রকল্পটি বুঝতে পারে না। দলের একটি অংশ JS-তে পরিষেবাগুলি লেখে যা তাদের নিজস্ব কাজ করে এবং বাকি সিস্টেমগুলি কীভাবে কাজ করে তা জানে না। অন্য অংশটি পাইথনে পরিষেবাগুলি লেখে এবং অন্যান্য পরিষেবাগুলি কীভাবে কাজ করে তাতে হস্তক্ষেপ করে না; তারা তাদের নিজস্ব এলাকায় বিচ্ছিন্ন। তৃতীয়টি হল পিএইচপি বা অন্য কিছুতে পরিষেবা লেখা।
এই 20 জন লোককে 15টি পরিষেবাতে বিভক্ত করা হয়েছে, এবং শুধুমাত্র একজন প্রশাসক আছেন যাকে এই সব বুঝতে হবে। থামো! আমরা সিস্টেমটিকে 15টি মাইক্রোসার্ভিসে বিভক্ত করেছি কারণ 20 জন লোক পুরো সিস্টেমটি বুঝতে পারে না।

তবে এটি কোনওভাবে পর্যবেক্ষণ করা দরকার ...

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

আমি কি বলতে পারি... হিউস্টন, আমাদের সমস্যা আছে।

একটি আধুনিক সফ্টওয়্যার প্রকল্প পর্যবেক্ষণ করা নিজেই একটি সফ্টওয়্যার প্রকল্প

মনিটরিং হচ্ছে সফ্টওয়্যার এই মিথ্যা বিশ্বাস থেকে, আমরা অলৌকিকতার উপর বিশ্বাস গড়ে তুলি। কিন্তু অলৌকিক ঘটনা, হায়, ঘটবে না। আপনি zabbix ইনস্টল করতে এবং সবকিছু কাজ করার আশা করতে পারবেন না। Grafana ইনস্টল করার এবং সবকিছু ঠিক হয়ে যাবে এমন আশা করার কোন মানে নেই। বাহ্যিক সিস্টেমগুলি কীভাবে কাজ করে তা পরীক্ষা করে, পরিষেবাগুলির পরিচালনার চেক এবং একে অপরের সাথে তাদের মিথস্ক্রিয়া সংগঠিত করতে বেশিরভাগ সময় ব্যয় করা হবে। প্রকৃতপক্ষে, 90% সময় স্ক্রিপ্ট লেখার জন্য নয়, সফ্টওয়্যার তৈরিতে ব্যয় করা হবে। এবং এটি এমন একটি দল দ্বারা পরিচালনা করা উচিত যা প্রকল্পের কাজ বোঝে।
এ অবস্থায় একজনকে নজরদারিতে নিক্ষেপ করলে বিপর্যয় ঘটবে। যা সর্বত্র ঘটে।

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

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

সুতরাং কিভাবে একটি প্রকল্প শুরু থেকে শুরু করে নিরীক্ষণ করা যায়, এবং আপনি যদি এমন একটি প্রকল্প পান যেটি নিরীক্ষণ করা প্রয়োজন, তবে আপনি কোথায় শুরু করবেন তা জানেন না?

প্রথমত, আপনাকে পরিকল্পনা করতে হবে।

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

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

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

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

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

স্তর দ্বারা সবকিছু

এইভাবে আমি একটি পর্যবেক্ষণ সিস্টেমের সংগঠন দেখতে.

1) আবেদন স্তর:

• অ্যাপ্লিকেশন ব্যবসায়িক যুক্তি পর্যবেক্ষণ;
• সেবার স্বাস্থ্য পরিমাপ পর্যবেক্ষণ;
• ইন্টিগ্রেশন পর্যবেক্ষণ।

2) অবকাঠামো স্তর:

• অর্কেস্ট্রেশন স্তর পর্যবেক্ষণ;
• সিস্টেম সফ্টওয়্যার পর্যবেক্ষণ;
• আয়রন স্তর পর্যবেক্ষণ।

3) আবার অ্যাপ্লিকেশন স্তর - কিন্তু একটি প্রকৌশল পণ্য হিসাবে:

• অ্যাপ্লিকেশন লগ সংগ্রহ এবং পর্যবেক্ষণ;
• এপিএম;
• ট্রেসিং

4) সতর্কতা:

• একটি সতর্কতা সিস্টেমের সংগঠন;
• একটি দায়িত্ব সিস্টেমের সংগঠন;
• ঘটনা প্রক্রিয়াকরণের জন্য একটি "জ্ঞানের ভিত্তি" এবং কর্মপ্রবাহের সংগঠন।

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

অ্যাপ্লিকেশন স্তর - ব্যবসা লজিক পর্যবেক্ষণ

এখানে আমরা অ্যাপ্লিকেশনটি ব্যবহারকারীর জন্য কাজ করে কিনা তা যাচাই করার বিষয়ে কথা বলছি।

এই স্তর উন্নয়ন পর্বের সময় করা উচিত. উদাহরণস্বরূপ, আমাদের একটি শর্তাধীন প্রমিথিউস আছে: এটি সার্ভারে যায় যা চেক করে, এন্ডপয়েন্ট টানে এবং এন্ডপয়েন্ট যায় এবং API চেক করে।

সাইটটি কাজ করছে কিনা তা নিশ্চিত করার জন্য যখন প্রায়ই হোম পেজ নিরীক্ষণ করতে বলা হয়, তখন প্রোগ্রামাররা একটি হ্যান্ডেল দেয় যা প্রত্যেকবার তাদের এপিআই কাজ করছে কিনা তা নিশ্চিত করার জন্য টেনে নেওয়া যেতে পারে। এবং এই মুহুর্তে প্রোগ্রামাররা এখনও /api/test/helloworld নেয় এবং লেখে
সবকিছু কাজ করে তা নিশ্চিত করার একমাত্র উপায়? - না!

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

প্রযুক্তিগত টিপস:

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

অ্যাপ্লিকেশন স্তর - স্বাস্থ্য মেট্রিক্স পর্যবেক্ষণ

এখন আমরা পরিষেবার বাহ্যিক স্বাস্থ্য মেট্রিক্স সম্পর্কে কথা বলছি।

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

কীভাবে এটি সঠিকভাবে প্রযুক্তিগতভাবে বাস্তবায়ন করা যায়: প্রতিটি পরিষেবা তার বর্তমান কার্যকারিতা সম্পর্কে একটি শেষ বিন্দু প্রকাশ করে এবং গ্রাফনা (বা অন্য কোনও অ্যাপ্লিকেশন) এর গ্রাফে আমরা সমস্ত পরিষেবার অবস্থা দেখতে পাই।

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

অ্যাপ্লিকেশন লেয়ার - ইন্টিগ্রেশন মনিটরিং

ইন্টিগ্রেশন মনিটরিং ব্যবসা-সমালোচনামূলক সিস্টেমের মধ্যে যোগাযোগ পর্যবেক্ষণের উপর দৃষ্টি নিবদ্ধ করে।

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

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

আমি যা করার পরামর্শ দিচ্ছি:

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

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

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

অবকাঠামো স্তর

অবকাঠামো পর্যবেক্ষণ এমন একটি বিষয় যা দীর্ঘদিন ধরে নিজেকে পর্যবেক্ষণ বলে মনে করা হয়।

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

একটি ব্যবসায়িক ইউনিট হিসাবে অ্যাপ্লিকেশন স্তর

গুরুত্বপূর্ণ দিক:

• ELK. এই শিল্প মান. কোনো কারণে আপনি লগ একত্রিত না হলে, অবিলম্বে তা করা শুরু করুন।
• এপিএম বাহ্যিক APMগুলি দ্রুত অ্যাপ্লিকেশন পর্যবেক্ষণ বন্ধ করার উপায় হিসাবে (NewRelic, BlackFire, Datadog)। আপনার সাথে কী ঘটছে তা অন্তত কোনওভাবে বোঝার জন্য আপনি সাময়িকভাবে এই জিনিসটি ইনস্টল করতে পারেন।
• ট্রেসিং। কয়েক ডজন মাইক্রোসার্ভিসে, আপনাকে সবকিছু ট্রেস করতে হবে, কারণ অনুরোধটি আর নিজে থেকে থাকে না। এটি পরে যোগ করা খুব কঠিন, তাই অবিলম্বে উন্নয়নে ট্রেসিং নির্ধারণ করা ভাল - এটি বিকাশকারীদের কাজ এবং উপযোগিতা। আপনি যদি এখনও এটি বাস্তবায়ন না করে থাকেন তবে এটি বাস্তবায়ন করুন! জেগার/জিপকিন দেখুন

সতর্কতা

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

প্রযুক্তি স্ট্যাক

আসুন কল্পনা করি যে আমাদের স্ট্যাকটি নিম্নরূপ:

• তথ্য সংগ্রহ - প্রমিথিউস + গ্রাফানা;
• লগ বিশ্লেষণ - ELK;
• এপিএম বা ট্রেসিংয়ের জন্য - জাইগার (জিপকিন)।

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

কয়েকটি প্রযুক্তিগত পয়েন্ট যা আমি ইদানীং সর্বত্র দেখতে পাচ্ছি:

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

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

তথ্যও

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

এটি সেন্ট হাইলোড++ সম্মেলনে প্রতিবেদনের একটি বর্ধিত সংস্করণ।

আপনি যদি এটি এবং সম্পর্কিত বিষয়গুলিতে আমার ধারণা এবং চিন্তাভাবনাগুলিতে আগ্রহী হন তবে আপনি এখানে করতে পারেন চ্যানেল পড়ুন 🙂

উত্স: www.habr.com