Bioyino - বিতরণ করা, পরিমাপযোগ্য মেট্রিক্স এগ্রিগেটর

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

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

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

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

যেমন ছিল

এটা কেমন হওয়া উচিত ছিল

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

এবং অবশেষে দাবি এক্স. লেখার সময়, আমরা এটিকে 14টি কম বা বেশি কার্যকরী statsd বাস্তবায়নের কাছে উপস্থাপন করতে প্রস্তুত যা আমরা খুঁজে পেয়েছি। আসুন কল্পনা করি যে কিছু একক পরিকাঠামো এতটাই বেড়েছে যে 4 মিলিয়ন এমপিএস গ্রহণ করা আর যথেষ্ট নয়। অথবা এমনকি যদি এটি এখনও বড় না হয়, কিন্তু মেট্রিক্স ইতিমধ্যে আপনার জন্য এত গুরুত্বপূর্ণ যে এমনকি ছোট, 2-3 মিনিটের চার্টে ডিপ করা ইতিমধ্যেই সমালোচনামূলক হয়ে উঠতে পারে এবং পরিচালকদের মধ্যে অপ্রতিরোধ্য হতাশার কারণ হতে পারে। যেহেতু বিষণ্নতার চিকিৎসা করা একটি অকৃতজ্ঞ কাজ, প্রযুক্তিগত সমাধান প্রয়োজন।

প্রথমত, ত্রুটি সহনশীলতা, যাতে সার্ভারে হঠাৎ সমস্যা অফিসে একটি মানসিক জম্বি অ্যাপোক্যালিপস সৃষ্টি না করে। দ্বিতীয়ত, লিনাক্স নেটওয়ার্ক স্ট্যাকের গভীরে খনন না করে এবং শান্তভাবে প্রয়োজনীয় আকারে "প্রস্থে" বৃদ্ধি না করে 4 মিলিয়নের বেশি MPS গ্রহণ করতে সক্ষম হওয়ার জন্য স্কেলিং।

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

আপনি যদি সমস্যাটি সম্পর্কে একটু চিন্তা করেন এবং একই সাথে একটি বেলচা দিয়ে তুষার খনন করেন, তবে নিম্নলিখিত সুস্পষ্ট ধারণাটি মনে আসতে পারে: আপনার একটি স্ট্যাটসডি প্রয়োজন যা বিতরণ মোডে কাজ করতে পারে। অর্থাৎ, সময় এবং মেট্রিক্সের মধ্যে নোডের মধ্যে সিঙ্ক্রোনাইজেশন প্রয়োগ করে। "অবশ্যই, এই জাতীয় সমাধান সম্ভবত ইতিমধ্যেই বিদ্যমান," আমরা বলেছিলাম এবং গুগলে গিয়েছিলাম…। এবং তারা কিছুই খুঁজে পায়নি। বিভিন্ন statsd এর জন্য ডকুমেন্টেশনের মাধ্যমে যাওয়ার পরে (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 ডিসেম্বর, XNUMX পর্যন্ত), আমরা একেবারে কিছুই খুঁজে পাইনি। স্পষ্টতই, বিকাশকারী বা এই সমাধানগুলির ব্যবহারকারীরা এখনও অনেকগুলি মেট্রিকের মুখোমুখি হননি, অন্যথায় তারা অবশ্যই কিছু নিয়ে আসবে।

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

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

কি লিখব? অবশ্যই, মরিচা মধ্যে. কেন?

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

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

ক্স...

অবশেষে, বেশ কয়েকটি ব্যর্থ প্রচেষ্টার পরে, প্রথম কার্যকরী সংস্করণ প্রস্তুত ছিল। কি হলো? এটাই হযেছিল.

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

মেট্রিক্স সহ UDP প্যাকেটগুলি একটি সাধারণ রাউন্ড রবিনের মাধ্যমে নেটওয়ার্ক সরঞ্জামগুলিতে নোডগুলির মধ্যে ভারসাম্যহীন। অবশ্যই, নেটওয়ার্ক হার্ডওয়্যার প্যাকেটের বিষয়বস্তু পার্স করে না এবং তাই প্রতি সেকেন্ডে 4M প্যাকেটের বেশি টানতে পারে, এমন মেট্রিক্সের কথা উল্লেখ না করার জন্য যা এটি কিছুই জানে না। যদি আমরা বিবেচনা করি যে মেট্রিক্স প্রতিটি প্যাকেটে একবারে আসে না, তাহলে আমরা এই জায়গায় কোনও পারফরম্যান্স সমস্যার পূর্বাভাস দিই না। একটি সার্ভার ক্র্যাশ হলে, নেটওয়ার্ক ডিভাইস দ্রুত (1-2 সেকেন্ডের মধ্যে) এই সত্যটি সনাক্ত করে এবং ক্র্যাশ হওয়া সার্ভারটিকে ঘূর্ণন থেকে সরিয়ে দেয়। এর ফলস্বরূপ, প্যাসিভ (অর্থাৎ, নন-লিডার) নোডগুলি চার্টে ড্রডাউনগুলি লক্ষ্য না করে কার্যত চালু এবং বন্ধ করা যেতে পারে। আমরা সর্বাধিক হারাতে পারি তা হল মেট্রিক্সের অংশ যা শেষ সেকেন্ডে এসেছিল। একটি নেতার হঠাৎ ক্ষতি/শাটডাউন/সুইচ এখনও একটি ছোটখাটো অসঙ্গতি তৈরি করবে (30 সেকেন্ডের ব্যবধান এখনও সিঙ্কের বাইরে রয়েছে), কিন্তু যদি নোডগুলির মধ্যে যোগাযোগ থাকে, তাহলে এই সমস্যাগুলি হ্রাস করা যেতে পারে, উদাহরণস্বরূপ, সিঙ্ক্রোনাইজেশন প্যাকেটগুলি পাঠানোর মাধ্যমে .

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

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

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

মন্তব্য

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

অবশেষে, চার্ট প্রেমীদের জন্য কিছু চার্ট।

প্রতিটি সার্ভারের জন্য ইনকামিং মেট্রিক্সের সংখ্যার পরিসংখ্যান: 2 মিলিয়নের বেশি MPS।

একটি নোড নিষ্ক্রিয় করা এবং আগত মেট্রিক্স পুনরায় বিতরণ করা।

বহির্গামী মেট্রিক্সের পরিসংখ্যান: শুধুমাত্র একটি নোড সবসময় পাঠায় - রেইড বস।

প্রতিটি নোডের অপারেশনের পরিসংখ্যান, বিভিন্ন সিস্টেম মডিউলের ত্রুটি বিবেচনা করে।

ইনকামিং মেট্রিক্সের বিশদ বিবরণ (মেট্রিকের নাম লুকানো আছে)।

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

অবশ্যই, প্রকল্পের উন্নয়নে সাহায্য করার জন্য সবাইকে স্বাগত জানাই: জনসংযোগ, সমস্যা তৈরি করুন, সম্ভব হলে আমরা প্রতিক্রিয়া জানাব, উন্নতি করব ইত্যাদি।

সেই সাথে বলা হচ্ছে, এই সব লোক, আমাদের হাতি কিনুন!

উত্স: www.habr.com