আরেকটি মনিটরিং সিস্টেম

16টি মডেম, 4টি সেলুলার অপারেটর = আউটগোয়িং স্পিড 933.45 Mbit/s

ভূমিকা

হ্যালো! এই নিবন্ধটি আমরা নিজেদের জন্য একটি নতুন মনিটরিং সিস্টেম কিভাবে লিখেছি সে সম্পর্কে। উচ্চ-ফ্রিকোয়েন্সি সিঙ্ক্রোনাস মেট্রিক্স এবং খুব কম রিসোর্স খরচ প্রাপ্ত করার ক্ষমতার ক্ষেত্রে এটি বিদ্যমান থেকে আলাদা। 0.1 ন্যানোসেকেন্ডের মেট্রিক্সের মধ্যে সিঙ্ক্রোনাইজেশন নির্ভুলতার সাথে ভোটদানের হার 10 মিলিসেকেন্ডে পৌঁছাতে পারে। সমস্ত বাইনারি ফাইল 6 মেগাবাইট দখল করে।

প্রকল্প সম্পর্কে

আমরা একটি বরং নির্দিষ্ট পণ্য আছে. আমরা ডেটা ট্রান্সমিশন চ্যানেলগুলির থ্রুপুট এবং ত্রুটি সহনশীলতার সংক্ষিপ্তসারের জন্য একটি ব্যাপক সমাধান তৈরি করি। এটি হল যখন বেশ কয়েকটি চ্যানেল থাকে, ধরা যাক Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ অন্য কিছু (5 Mbit/s), ফলাফল হল একটি স্থিতিশীল এবং দ্রুত চ্যানেল, যার গতি এমন কিছু হবে এটি: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

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

বেশ কয়েক বছর ধরে, আমরা একটি মাল্টি-লেভেল, দ্রুত, ক্রস-প্ল্যাটফর্ম এবং লাইটওয়েট মনিটরিং সিস্টেম তৈরি করতে পেরেছি। এটা আমরা আমাদের সম্মানিত সম্প্রদায়ের সাথে শেয়ার করতে চাই।

সমস্যা গঠন

মনিটরিং সিস্টেম দুটি মৌলিকভাবে ভিন্ন শ্রেণীর মেট্রিক্স প্রদান করে: রিয়েল-টাইম মেট্রিক্স এবং অন্য সব। পর্যবেক্ষণ সিস্টেমের শুধুমাত্র নিম্নলিখিত প্রয়োজনীয়তা ছিল:

1. রিয়েল-টাইম মেট্রিক্সের উচ্চ-ফ্রিকোয়েন্সি সিঙ্ক্রোনাস অধিগ্রহণ এবং বিলম্ব ছাড়াই যোগাযোগ ব্যবস্থাপনা সিস্টেমে তাদের স্থানান্তর।
   উচ্চ ফ্রিকোয়েন্সি এবং বিভিন্ন মেট্রিক্সের সিঙ্ক্রোনাইজেশন শুধুমাত্র গুরুত্বপূর্ণ নয়, এটি ডেটা ট্রান্সমিশন চ্যানেলগুলির এনট্রপি বিশ্লেষণের জন্য গুরুত্বপূর্ণ। যদি একটি ডেটা ট্রান্সমিশন চ্যানেলে গড় বিলম্ব 30 মিলিসেকেন্ড হয়, তবে মাত্র এক মিলিসেকেন্ডের অবশিষ্ট মেট্রিক্সের মধ্যে সিঙ্ক্রোনাইজেশনে একটি ত্রুটির ফলে চ্যানেলের গতি প্রায় 5% হ্রাস পাবে। যদি আমরা 1টি চ্যানেল জুড়ে 4 মিলিসেকেন্ড সময় ভুল করে থাকি, তাহলে গতির অবনতি সহজেই 30% এ নেমে যেতে পারে। উপরন্তু, চ্যানেলগুলিতে এনট্রপি খুব দ্রুত পরিবর্তিত হয়, তাই আমরা যদি প্রতি 0.5 মিলিসেকেন্ডে একবারেরও কম পরিমাপ করি, অল্প বিলম্বের সাথে দ্রুত চ্যানেলগুলিতে আমরা উচ্চ গতির অবক্ষয় পাব। অবশ্যই, এই ধরনের নির্ভুলতা সমস্ত মেট্রিক্সের জন্য প্রয়োজন হয় না এবং সব অবস্থায় নয়। যখন চ্যানেলে বিলম্ব হয় 500 মিলিসেকেন্ড, এবং আমরা এটির সাথে কাজ করি, তখন 1 মিলিসেকেন্ডের একটি ত্রুটি প্রায় লক্ষণীয় হবে না। এছাড়াও, লাইফ সাপোর্ট সিস্টেম মেট্রিক্সের জন্য, আমাদের কাছে 2 সেকেন্ডের পর্যাপ্ত পোলিং এবং সিঙ্ক্রোনাইজেশন রেট রয়েছে, তবে পর্যবেক্ষণ সিস্টেমকে অবশ্যই অতি-উচ্চ ভোটদানের হার এবং মেট্রিক্সের অতি-নির্দিষ্ট সিঙ্ক্রোনাইজেশনের সাথে কাজ করতে সক্ষম হতে হবে।
2. ন্যূনতম সম্পদ খরচ এবং একটি একক স্ট্যাক।
   শেষ ডিভাইসটি হয় একটি শক্তিশালী অন-বোর্ড কমপ্লেক্স হতে পারে যা রাস্তার পরিস্থিতি বিশ্লেষণ করতে পারে বা মানুষের বায়োমেট্রিক রেকর্ডিং পরিচালনা করতে পারে, অথবা একটি পাম-আকারের একক-বোর্ড কম্পিউটার যা একটি বিশেষ বাহিনীর সৈনিক তার শরীরের বর্মের নীচে ভিডিও প্রেরণের জন্য পরে থাকে। খারাপ যোগাযোগ পরিস্থিতিতে বাস্তব সময়। এই ধরনের বিভিন্ন আর্কিটেকচার এবং কম্পিউটিং ক্ষমতা থাকা সত্ত্বেও, আমরা একই সফ্টওয়্যার স্ট্যাক রাখতে চাই।
3. ছাতা স্থাপত্য
   মেট্রিক্স অবশ্যই শেষ ডিভাইসে সংগ্রহ এবং একত্রিত করতে হবে, স্থানীয়ভাবে সংরক্ষণ করতে হবে এবং বাস্তব সময়ে এবং পূর্ববর্তীভাবে ভিজ্যুয়ালাইজ করতে হবে। একটি সংযোগ থাকলে, কেন্দ্রীয় মনিটরিং সিস্টেমে ডেটা স্থানান্তর করুন। যখন কোন সংযোগ নেই, পাঠানোর সারি জমা হওয়া উচিত এবং RAM গ্রাস করা উচিত নয়।
4. গ্রাহকের মনিটরিং সিস্টেমে একীকরণের জন্য API, কারণ কারোরই অনেক মনিটরিং সিস্টেমের প্রয়োজন নেই। গ্রাহককে একটি একক পর্যবেক্ষণে যেকোনো ডিভাইস এবং নেটওয়ার্ক থেকে ডেটা সংগ্রহ করতে হবে।

কি হলো

ইতিমধ্যে চিত্তাকর্ষক লংরেড বোঝা না করার জন্য, আমি সমস্ত পর্যবেক্ষণ সিস্টেমের উদাহরণ এবং পরিমাপ দেব না। এটি অন্য নিবন্ধে নিয়ে যাবে। আমি শুধু বলব যে আমরা এমন একটি মনিটরিং সিস্টেম খুঁজে পাইনি যা 1 মিলিসেকেন্ডের কম ত্রুটির সাথে একসাথে দুটি মেট্রিক নিতে সক্ষম এবং এটি 64 MB RAM সহ ARM আর্কিটেকচারে এবং 86 সহ x64_32 আর্কিটেকচারে সমানভাবে কার্যকরভাবে কাজ করে RAM এর GB। অতএব, আমরা আমাদের নিজের লেখার সিদ্ধান্ত নিয়েছি, যা এই সব করতে পারে। আমরা যা পেয়েছি তা এখানে:

বিভিন্ন নেটওয়ার্ক টপোলজির জন্য তিনটি চ্যানেলের থ্রুপুট সংক্ষিপ্ত করা

কিছু মূল মেট্রিক্সের ভিজ্যুয়ালাইজেশন

স্থাপত্য

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

সিস্টেমটি ক্লাসিক মডুলার নীতি অনুসারে প্রয়োগ করা হয় এবং এতে বেশ কয়েকটি সাবসিস্টেম রয়েছে:

1. মেট্রিক্স নিবন্ধন.
   প্রতিটি মেট্রিক তার নিজস্ব থ্রেড দ্বারা পরিবেশিত হয় এবং চ্যানেল জুড়ে সিঙ্ক্রোনাইজ করা হয়। আমরা 10 ন্যানোসেকেন্ড পর্যন্ত সিঙ্ক্রোনাইজেশন নির্ভুলতা অর্জন করতে সক্ষম হয়েছি।
2. মেট্রিক্স স্টোরেজ
   আমরা টাইম সিরিজের জন্য আমাদের নিজস্ব স্টোরেজ লেখার মধ্যে বা ইতিমধ্যে উপলব্ধ কিছু ব্যবহার করার মধ্যে বেছে নিচ্ছিলাম। পরবর্তী ভিজ্যুয়ালাইজেশন সাপেক্ষে রেট্রোস্পেক্টিভ ডেটার জন্য ডাটাবেস প্রয়োজন। অর্থাৎ, এতে প্রতি 0.5 মিলিসেকেন্ডে চ্যানেলে বিলম্ব বা পরিবহন নেটওয়ার্কে ত্রুটি রিডিং সংক্রান্ত ডেটা থাকে না, তবে প্রতিটি ইন্টারফেসে প্রতি 500 মিলিসেকেন্ডে গতি থাকে। ক্রস-প্ল্যাটফর্ম এবং কম সম্পদ খরচের জন্য উচ্চ প্রয়োজনীয়তা ছাড়াও, প্রক্রিয়া করতে সক্ষম হওয়া আমাদের জন্য অত্যন্ত গুরুত্বপূর্ণ। ডেটা যেখানে সংরক্ষণ করা হয়। এটি প্রচুর কম্পিউটিং সংস্থান সংরক্ষণ করে। আমরা 2016 সাল থেকে এই প্রকল্পে ট্যারান্টুল ডিবিএমএস ব্যবহার করছি এবং এখনও পর্যন্ত আমরা দিগন্তে এটির প্রতিস্থাপন দেখতে পাচ্ছি না। নমনীয়, সর্বোত্তম সম্পদ খরচ সহ, পর্যাপ্ত প্রযুক্তিগত সহায়তার চেয়ে বেশি। Tarantool একটি GIS মডিউলও প্রয়োগ করে। অবশ্যই, এটি পোস্টজিআইএসের মতো শক্তিশালী নয়, তবে এটি কিছু অবস্থান-সম্পর্কিত মেট্রিক্স (পরিবহনের জন্য প্রাসঙ্গিক) সংরক্ষণ করার জন্য আমাদের কাজের জন্য যথেষ্ট।
3. মেট্রিক্সের ভিজ্যুয়ালাইজেশন
   এখানে সবকিছু তুলনামূলকভাবে সহজ। আমরা গুদাম থেকে ডেটা নিয়ে থাকি এবং তা রিয়েল টাইমে বা পূর্ববর্তীভাবে প্রদর্শন করি।
4. কেন্দ্রীয় মনিটরিং সিস্টেমের সাথে ডেটা সিঙ্ক্রোনাইজেশন।
   কেন্দ্রীয় মনিটরিং সিস্টেম সমস্ত ডিভাইস থেকে ডেটা গ্রহণ করে, এটি একটি নির্দিষ্ট ইতিহাসের সাথে সংরক্ষণ করে এবং API এর মাধ্যমে গ্রাহকের মনিটরিং সিস্টেমে পাঠায়। ক্লাসিক মনিটরিং সিস্টেমের বিপরীতে, যেখানে "মাথা" ঘুরে বেড়ায় এবং ডেটা সংগ্রহ করে, আমাদের বিপরীত স্কিম রয়েছে। সংযোগ থাকলে ডিভাইসগুলি নিজেই ডেটা পাঠায়। এটি একটি অত্যন্ত গুরুত্বপূর্ণ বিষয়, যেহেতু এটি আপনাকে সেই সময়ের জন্য ডিভাইস থেকে ডেটা গ্রহণ করতে দেয় যে সময় এটি উপলব্ধ ছিল না এবং ডিভাইসটি অনুপলব্ধ থাকাকালীন চ্যানেল এবং সংস্থানগুলি লোড করতে পারে না৷ আমরা একটি কেন্দ্রীয় মনিটরিং সিস্টেম হিসাবে ইনফ্লাক্স মনিটরিং সার্ভার ব্যবহার করি। এর অ্যানালগগুলির বিপরীতে, এটি পূর্ববর্তী ডেটা আমদানি করতে পারে (অর্থাৎ, মেট্রিক্স প্রাপ্তির মুহুর্ত থেকে আলাদা একটি টাইম স্ট্যাম্প সহ)। সংগৃহীত মেট্রিকগুলি গ্রাফানা দ্বারা কল্পনা করা হয়, একটি ফাইলের সাথে পরিবর্তিত হয়। এই স্ট্যান্ডার্ড স্ট্যাকটিও বেছে নেওয়া হয়েছিল কারণ এতে প্রায় যেকোনো গ্রাহক পর্যবেক্ষণ সিস্টেমের সাথে তৈরি API ইন্টিগ্রেশন রয়েছে।
5. একটি কেন্দ্রীয় ডিভাইস ম্যানেজমেন্ট সিস্টেমের সাথে ডেটা সিঙ্ক্রোনাইজেশন।
   ডিভাইস ম্যানেজমেন্ট সিস্টেম জিরো টাচ প্রভিশনিং (ফার্মওয়্যার, কনফিগারেশন, ইত্যাদি আপডেট করা) প্রয়োগ করে এবং মনিটরিং সিস্টেমের বিপরীতে, প্রতি ডিভাইসে শুধুমাত্র সমস্যা হয়। এগুলি হল অন-বোর্ড হার্ডওয়্যার ওয়াচডগ পরিষেবাগুলির অপারেশন এবং লাইফ সাপোর্ট সিস্টেমের সমস্ত মেট্রিক্সের জন্য ট্রিগার: CPU এবং SSD তাপমাত্রা, CPU লোড, ফাঁকা স্থান এবং ডিস্কে স্মার্ট স্বাস্থ্য। সাবসিস্টেম স্টোরেজ টারান্টুলেও তৈরি করা হয়েছে। এটি আমাদের হাজার হাজার ডিভাইস জুড়ে টাইম সিরিজ একত্রিত করার ক্ষেত্রে উল্লেখযোগ্য গতি দেয় এবং এই ডিভাইসগুলির সাথে ডেটা সিঙ্ক্রোনাইজ করার সমস্যাটি সম্পূর্ণভাবে সমাধান করে। Tarantool এর একটি চমৎকার সারিবদ্ধ এবং নিশ্চিত ডেলিভারি সিস্টেম রয়েছে। আমরা এই গুরুত্বপূর্ণ বৈশিষ্ট্যটি বাক্সের বাইরে পেয়েছি, দুর্দান্ত!

নেটওয়ার্ক ম্যানেজমেন্ট সিস্টেম

পরবর্তী কি

এখন পর্যন্ত, আমাদের সবচেয়ে দুর্বল লিঙ্ক কেন্দ্রীয় মনিটরিং সিস্টেম. এটি একটি স্ট্যান্ডার্ড স্ট্যাকে 99.9% প্রয়োগ করা হয় এবং এর বেশ কয়েকটি অসুবিধা রয়েছে:

1. পাওয়ার হারিয়ে গেলে InfluxDB ডেটা হারায়। একটি নিয়ম হিসাবে, গ্রাহক ডিভাইসগুলি থেকে আসা সমস্ত কিছু অবিলম্বে সংগ্রহ করে এবং ডাটাবেসেই 5 মিনিটের বেশি পুরানো ডেটা থাকে না, তবে ভবিষ্যতে এটি একটি ব্যথা হতে পারে।
2. গ্রাফনার ডেটা একত্রিতকরণ এবং এর প্রদর্শনের সিঙ্ক্রোনাইজেশন নিয়ে বেশ কয়েকটি সমস্যা রয়েছে। সবচেয়ে সাধারণ সমস্যা হল যখন ডাটাবেসে 2:00:00 থেকে শুরু করে 00 সেকেন্ডের ব্যবধান সহ একটি টাইম সিরিজ থাকে এবং Grafana +1 সেকেন্ড থেকে একত্রিতভাবে ডেটা দেখানো শুরু করে। ফলস্বরূপ, ব্যবহারকারী একটি নাচের গ্রাফ দেখতে পান।
3. থার্ড-পার্টি মনিটরিং সিস্টেমের সাথে API ইন্টিগ্রেশনের জন্য অতিরিক্ত পরিমাণ কোড। এটি অনেক বেশি কম্প্যাক্ট করা যেতে পারে এবং অবশ্যই গো-তে পুনরায় লেখা)

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

উপসংহার

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

এই নিবন্ধের সুযোগের বাইরে কারো যদি প্রশ্ন থাকে, আপনি আমাকে a.rodin @ qedr.com এ লিখতে পারেন

উত্স: www.habr.com