একটি হারিয়ে যাওয়া স্কুটার, বা একটি IoT পর্যবেক্ষণের গল্প ফেরত দিন

এক বছর আগে আমরা একটি প্রচারমূলক প্রকল্পের একটি পাইলট সংস্করণ চালু করেছি বৈদ্যুতিক স্কুটারের বিকেন্দ্রীকৃত ভাড়া.

প্রাথমিকভাবে, প্রকল্পটিকে রোড-টু-বার্সেলোনা বলা হয়েছিল, পরে এটি রোড-টু-বার্লিন হয়ে ওঠে (অতএব স্ক্রিনশটগুলিতে R2B), এবং শেষ পর্যন্ত এটিকে xRide বলা হয়।

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

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

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

স্কুটার ছাড়াও, ব্যবহারকারী অ্যাপ্লিকেশনটিতে "স্মার্ট চার্জার" দেখেছেন, যা ভিজিট করে ব্যবহারকারী বর্তমান ব্যাটারি কম হলে নিজেই পরিবর্তন করতে পারে।

সাধারণত আমাদের পাইলটের মতো দেখতে এইরকম, গত বছরের সেপ্টেম্বরে দুটি জার্মান শহরে চালু হয়েছিল: বন এবং বার্লিন৷

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

কিভাবে এটি খুঁজে পেতে এবং এটি ফেরত?

এই নিবন্ধে আমি এটি সম্পর্কে কথা বলব, তবে প্রথমে - আমরা কীভাবে আমাদের নিজস্ব আইওটি প্ল্যাটফর্ম তৈরি করেছি এবং কীভাবে আমরা এটি পর্যবেক্ষণ করেছি।

কী এবং কেন নিরীক্ষণ করবেন: স্কুটার, অবকাঠামো, চার্জিং?

সুতরাং, আমরা আমাদের প্রকল্পে কি নিরীক্ষণ করতে চেয়েছিলাম?

প্রথমত, এগুলি নিজেরাই স্কুটার - বৈদ্যুতিক স্কুটারগুলি নিজেই বেশ ব্যয়বহুল, আপনি পর্যাপ্তভাবে প্রস্তুত না হয়ে এই জাতীয় প্রকল্প চালু করতে পারবেন না; যদি সম্ভব হয়, আপনি স্কুটারগুলি সম্পর্কে যতটা সম্ভব তথ্য সংগ্রহ করতে চান: তাদের অবস্থান, চার্জ স্তর সম্পর্কে , ইত্যাদি

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

স্কুটার

আমাদের স্কুটারগুলি কী ছিল এবং আমরা সেগুলি সম্পর্কে কী জানতে চাই?

প্রথম এবং সবচেয়ে গুরুত্বপূর্ণ বিষয় হল জিপিএস স্থানাঙ্ক, যেহেতু তাদের ধন্যবাদ আমরা বুঝতে পারি তারা কোথায় এবং তারা কোথায় চলছে।

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

অবশ্যই, আমাদের হার্ডওয়্যার উপাদানগুলির সাথে কী ঘটছে তা পরীক্ষা করাও প্রয়োজনীয়:

• ব্লুটুথ কি কাজ করে?
• GPS মডিউল নিজেই কাজ করে?
  • আমাদের এও সমস্যা ছিল যে জিপিএস ভুল স্থানাঙ্ক পাঠাতে পারে এবং আটকে যেতে পারে এবং এটি শুধুমাত্র স্কুটারে অতিরিক্ত চেক দ্বারা নির্ধারিত হতে পারে,
    এবং সমস্যা সমাধানের জন্য যত তাড়াতাড়ি সম্ভব সহায়তাকে অবহিত করুন

এবং সবশেষে: সফ্টওয়্যার চেক, OS এবং প্রসেসর দিয়ে শুরু করে, নেটওয়ার্ক এবং ডিস্ক লোড, আমাদের নিজস্ব মডিউলগুলির চেক দিয়ে শেষ হয় যা আমাদের জন্য আরও নির্দিষ্ট (জোলোকম, চাবিকাঠি).

হার্ডওয়্যারের

আমাদের "লোহা" অংশ কি ছিল?

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

এটিও উল্লেখ করা উচিত যে পুরো বাক্সটি একটি অতিরিক্ত পাওয়ার ব্যাঙ্ক দ্বারা চালিত ছিল, যা স্কুটারের প্রধান ব্যাটারি দ্বারা চালিত হয়েছিল।

এটি ট্রিপ শেষ হওয়ার পরেও মনিটরিং ব্যবহার করা এবং স্কুটার চালু করা সম্ভব করেছে, যেহেতু প্রধান ব্যাটারিটি ইগনিশন কীটিকে "অফ" অবস্থানে চালু করার সাথে সাথেই বন্ধ হয়ে গিয়েছিল।

ডকার? প্লেইন লিনাক্স? এবং স্থাপনা

আসুন পর্যবেক্ষণে ফিরে আসি, তাই রাস্পবেরি - আমাদের কি আছে?

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

দুর্ভাগ্যবশত, এটি দ্রুত স্পষ্ট হয়ে ওঠে যে RPi-এ ডকার, যদিও এটি কাজ করে, বিশেষ করে পাওয়ার খরচের ক্ষেত্রে অনেক বেশি ওভারহেড রয়েছে।

"নেটিভ" OS ব্যবহার করে পার্থক্য, যদিও এতটা শক্তিশালী নয়, তবুও আমাদের জন্য খুব দ্রুত চার্জ হারানোর সম্ভাবনা থেকে সতর্ক থাকার জন্য যথেষ্ট।

দ্বিতীয় কারণটি ছিল Node.js (sic!)-তে আমাদের অংশীদার লাইব্রেরিগুলির মধ্যে একটি - সিস্টেমের একমাত্র উপাদান যা Go/C/C++ এ লেখা ছিল না।

লাইব্রেরির লেখকদের "নেটিভ" ভাষায় কোনও কার্যকরী সংস্করণ সরবরাহ করার সময় ছিল না।

কম-পারফরম্যান্স ডিভাইসের জন্য নোড নিজেই সবচেয়ে মার্জিত সমাধান নয়, তবে লাইব্রেরি নিজেই খুব সম্পদ-ক্ষুধার্ত ছিল।

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

OS

ফলস্বরূপ, আমরা আবার, OS হিসাবে সবচেয়ে সহজ বিকল্পটি বেছে নিয়েছি এবং রাস্পবিয়ান (Pi এর জন্য ডেবিয়ান বিল্ড) ব্যবহার করেছি।

আমরা Go-তে আমাদের সমস্ত সফ্টওয়্যার লিখি, তাই আমরা Go-তে আমাদের সিস্টেমের প্রধান হার্ডওয়্যার এজেন্ট মডিউলও লিখেছি।

জিপিএস, ব্লুটুথ, চার্জ পড়া, স্কুটার চালু করা ইত্যাদির জন্য তিনিই দায়ী।

স্থাপন করুন

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

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

তুলনামূলকভাবে সহজ, বেশিরভাগ আপডেট/ডুয়াল-বুট ওরিয়েন্টেড ইউটিলিটি যেমন swupd/SWUpdate/OSTree থেকে মেন্ডার এবং বালেনার মতো পূর্ণাঙ্গ প্ল্যাটফর্মে।

প্রথমত, আমরা সিদ্ধান্ত নিয়েছি যে আমরা শেষ থেকে শেষ সমাধানগুলিতে আগ্রহী, তাই পছন্দটি অবিলম্বে প্ল্যাটফর্মগুলিতে পড়ে।

নিজেই বলেনা এটি প্রকৃতপক্ষে তার balenaEngine এর ভিতরে একই ডকার ব্যবহার করে এই কারণে বাদ দেওয়া হয়েছিল।

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

অতএব, শেষ পর্যন্ত পছন্দ উপর পড়ে মেন্ডার. মেন্ডার ফার্মওয়্যার একত্রিত, বিতরণ এবং ইনস্টল করার জন্য একটি সম্পূর্ণ প্ল্যাটফর্ম।

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

হায়, আমাদের কঠোর সময়সীমার মানে হল যে আমরা মেন্ডারের ব্যবহার পরিত্যাগ করতে এবং আরও সহজ একটি বেছে নিতে বাধ্য হয়েছিলাম।

Ansible

আমাদের পরিস্থিতিতে সবচেয়ে সহজ সমাধান ছিল Ansible ব্যবহার করা। শুরু করার জন্য কয়েকটি প্লেবুকই যথেষ্ট ছিল।

তাদের সারমর্ম ছিল যে আমরা কেবল হোস্ট (CI সার্ভার) থেকে ssh এর মাধ্যমে আমাদের রাসবেরিগুলির সাথে সংযুক্ত করেছি এবং তাদের কাছে আপডেটগুলি বিতরণ করেছি।

একেবারে শুরুতে, সবকিছুই সহজ ছিল - আপনাকে ডিভাইসগুলির সাথে একই নেটওয়ার্কে থাকতে হবে, ঢালাও Wi-Fi এর মাধ্যমে করা হয়েছিল।

অফিসে একই নেটওয়ার্কের সাথে সংযুক্ত এক ডজন টেস্ট রাস্পবেরি ছিল, প্রতিটি ডিভাইসের একটি স্ট্যাটিক আইপি ঠিকানা ছিল যা উত্তরযোগ্য ইনভেন্টরিতেও নির্দিষ্ট ছিল।

এটি Ansible ছিল যা আমাদের মনিটরিং এজেন্টকে শেষ ডিভাইসে পৌঁছে দিয়েছে

3G / এলটিই

দুর্ভাগ্যবশত, Ansible-এর জন্য এই ব্যবহারের ক্ষেত্রে আমাদের প্রকৃত স্কুটার থাকার আগে শুধুমাত্র ডেভেলপমেন্ট মোডে কাজ করতে পারে।

কারণ স্কুটারগুলি, যেমন আপনি বোঝেন, একটি Wi-Fi রাউটারের সাথে সংযুক্ত হয়ে বসে থাকবেন না, ক্রমাগত নেটওয়ার্কে আপডেটের জন্য অপেক্ষা করছেন।

বাস্তবে, স্কুটারের মোবাইল 3G/LTE ছাড়া অন্য কোনো সংযোগ থাকতে পারে না (এবং তারপরেও সব সময় নয়)।

এটি অবিলম্বে অনেক সমস্যা এবং সীমাবদ্ধতা আরোপ করে, যেমন কম সংযোগের গতি এবং অস্থির যোগাযোগ।

কিন্তু সবচেয়ে গুরুত্বপূর্ণ বিষয় হল যে একটি 3G/LTE নেটওয়ার্কে আমরা নেটওয়ার্কে নির্ধারিত একটি স্ট্যাটিক আইপির উপর নির্ভর করতে পারি না।

এটি আংশিকভাবে কিছু সিম কার্ড প্রদানকারীর দ্বারা সমাধান করা হয়েছে; এমনকি স্ট্যাটিক আইপি ঠিকানা সহ IoT ডিভাইসের জন্য ডিজাইন করা বিশেষ সিম কার্ড রয়েছে। কিন্তু আমাদের এই ধরনের সিম কার্ডগুলিতে অ্যাক্সেস ছিল না এবং আইপি ঠিকানাগুলি ব্যবহার করতে পারিনি৷

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

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

ভিপিএন

এই সমস্যার সমাধান হিসাবে, আমরা VPN বেছে নিয়েছি - বিশেষভাবে ওয়্যারগার্ড.

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

তাত্ত্বিকভাবে, একই টানেল নিরীক্ষণের জন্য ব্যবহার করা যেতে পারে, তবে এই জাতীয় সংযোগটি সাধারণ ধাক্কার চেয়ে আরও জটিল এবং কম নির্ভরযোগ্য ছিল।

মেঘ সম্পদ

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

দেওয়া

উফফ, আমরা বর্ণনাটি সাজিয়ে ফেলেছি বলে মনে হচ্ছে, শেষ পর্যন্ত আমাদের কী প্রয়োজন ছিল তার একটি তালিকা তৈরি করা যাক:

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

চূড়ান্ত ইমেজ এই মত কিছু লাগছিল

স্ট্যাক নির্বাচন

সুতরাং, আমরা একটি মনিটরিং স্ট্যাক নির্বাচন করার প্রশ্নের সম্মুখীন হয়েছিলাম।

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

মনিটরিং সমাধানের একটি বিশাল বৈচিত্র্য আছে, যেমন পূর্ণাঙ্গ সিস্টেম থেকে শুরু করে Nagios, icinga বা zabbix এবং ফ্লিট ম্যানেজমেন্টের জন্য রেডিমেড সমাধান দিয়ে শেষ হচ্ছে।

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

বেশ কয়েকটি অনুরূপ সমাধান বিশ্লেষণ করার পরে, আমরা দ্রুত এই সিদ্ধান্তে পৌঁছেছি যে একই ধরনের স্ট্যাক একত্রিত করা সহজ এবং দ্রুত হবে। হ্যাঁ, এটি সম্পূর্ণরূপে তৈরি ফ্লিট ম্যানেজমেন্ট প্ল্যাটফর্ম স্থাপনের চেয়ে একটু বেশি জটিল হবে, তবে আমাদের আপস করতে হবে না।

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

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

(B)ELK?

প্রথম সমাধান যা আসলে বিবেচনা করা হয়েছিল তা হল সুপরিচিত ELK স্ট্যাক।
আসলে, এটিকে BELK বলা উচিত, কারণ এটি সমস্ত বিট দিয়ে শুরু হয় - https://www.elastic.co/what-is/elk-stack

অবশ্যই, ELK নিরীক্ষণের ক্ষেত্রে সবচেয়ে বিখ্যাত এবং শক্তিশালী সমাধানগুলির মধ্যে একটি, এবং আরও বেশি করে লগ সংগ্রহ এবং প্রক্রিয়াকরণের ক্ষেত্রে।

আমরা উদ্দেশ্য করেছি যে ELK লগ সংগ্রহ করতে এবং সেইসাথে প্রমিথিউস থেকে প্রাপ্ত মেট্রিক্সের দীর্ঘমেয়াদী স্টোরেজের জন্য ব্যবহার করা হবে।

ভিজ্যুয়ালাইজেশনের জন্য আপনি Grafan ব্যবহার করতে পারেন।

আসলে, নতুন ELK স্ট্যাক স্বাধীনভাবে মেট্রিক সংগ্রহ করতে পারে (মেট্রিকবিট), এবং কিবানাও সেগুলি প্রদর্শন করতে পারে।

কিন্তু তবুও, ELK প্রাথমিকভাবে লগের বাইরে বেড়েছে এবং এখন পর্যন্ত মেট্রিক্সের কার্যকারিতাতে বেশ কয়েকটি গুরুতর ত্রুটি রয়েছে:

• প্রমিথিউসের তুলনায় উল্লেখযোগ্যভাবে ধীর
• প্রমিথিউসের তুলনায় অনেক কম জায়গায় একত্রিত হয়
• তাদের জন্য সতর্কতা সেট আপ করা কঠিন
• মেট্রিক্স অনেক জায়গা নেয়
• কিবানে মেট্রিক্স সহ ড্যাশবোর্ড সেট আপ করা Grafan এর তুলনায় অনেক বেশি জটিল

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

এবং ELK স্ট্যাকের নিজেই বেশ কয়েকটি কঠিন মুহূর্ত রয়েছে:

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

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

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

লোকি - গ্রাফানা - প্রমিথিউস

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

দুর্ভাগ্যবশত, প্রোজেক্টের সেলস পাইলট শুরু হওয়ার সময় (সেপ্টেম্বর-অক্টোবর 19), লোকি এখনও বিটা সংস্করণ 0.3-0.4-এ ছিল এবং বিকাশের শুরুর সময় এটি একটি উত্পাদন সমাধান হিসাবে বিবেচিত হতে পারে না। মোটেও

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

টিক

সম্ভবত ELK স্ট্যাকের সবচেয়ে যোগ্য (একমাত্র?) পূর্ণ বৈশিষ্ট্যযুক্ত বিকল্পটিকে এখন শুধুমাত্র TICK স্ট্যাক বলা যেতে পারে - Telegraf, InfluxDB, Chronograf, Kapacitor।

আমি নীচের সমস্ত উপাদানগুলিকে আরও বিশদে বর্ণনা করব, তবে সাধারণ ধারণাটি হল:

• টেলিগ্রাফ - মেট্রিক্স সংগ্রহের জন্য এজেন্ট
• ইনফ্লাক্সডিবি - মেট্রিক্স ডাটাবেস
• ক্যাপাসিটর - সতর্ক করার জন্য রিয়েল-টাইম মেট্রিক্স প্রসেসর
• ক্রোনোগ্রাফ - ভিজ্যুয়ালাইজেশনের জন্য ওয়েব প্যানেল

InfluxDB, Kapacitor এবং Chronograf-এর জন্য অফিসিয়াল হেলম চার্ট আছে যেগুলো আমরা মোতায়েন করতাম।

এটি উল্লেখ করা উচিত যে ইনফ্লাক্স 2.0 (বিটা) এর সর্বশেষ সংস্করণে, ক্যাপাসিটর এবং ক্রোনোগ্রাফ ইনফ্লাক্সডিবির অংশ হয়ে উঠেছে এবং আর আলাদাভাবে বিদ্যমান নেই

টেলিগ্রাফ

টেলিগ্রাফ একটি রাষ্ট্র মেশিনে মেট্রিক্স সংগ্রহের জন্য একটি খুব হালকা এজেন্ট.

তিনি সবকিছু থেকে একটি বিশাল পরিমাণ নিরীক্ষণ করতে পারেন nginx থেকে
সার্ভার Minecraft.

এটির বেশ কয়েকটি শীতল সুবিধা রয়েছে:

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

যেহেতু পুশ মেট্রিক্স আমাদের জন্য প্রয়োজনীয় ছিল, অন্যান্য সমস্ত সুবিধাগুলি আনন্দদায়ক সংযোজনের চেয়ে বেশি ছিল।

এজেন্ট নিজেই লগ সংগ্রহ করা খুব সুবিধাজনক, যেহেতু লগিং লগগুলির জন্য অতিরিক্ত ইউটিলিটি সংযোগ করার প্রয়োজন নেই।

ইনফ্লাক্স আপনি ব্যবহার করলে লগের সাথে কাজ করার জন্য সবচেয়ে সুবিধাজনক অভিজ্ঞতা প্রদান করে syslog- র.

টেলিগ্রাফ সাধারণত মেট্রিক্স সংগ্রহের জন্য একটি দুর্দান্ত এজেন্ট, এমনকি আপনি যদি বাকি আইসিকে স্ট্যাক ব্যবহার না করেন।

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

ইনফ্লাক্সডিবি

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

InfluxDB Go-তেও লেখা আছে এবং আমাদের (সবচেয়ে শক্তিশালী নয়) ক্লাস্টারে ELK-এর তুলনায় অনেক দ্রুত চলে বলে মনে হচ্ছে।

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

অসুবিধা - $$$ বা স্কেলিং?

TICK স্ট্যাকের শুধুমাত্র একটি ত্রুটি রয়েছে যা আমরা আবিষ্কার করেছি - এটি মহার্ঘ. আরও বেশি.

প্রদত্ত সংস্করণে কী আছে যা বিনামূল্যে সংস্করণে নেই?

যতদূর আমরা বুঝতে পেরেছি, TICK স্ট্যাকের পেইড সংস্করণ এবং বিনামূল্যের মধ্যে পার্থক্য হল স্কেলিং ক্ষমতা।

যথা, আপনি শুধুমাত্র উচ্চ প্রাপ্যতা সহ একটি ক্লাস্টার বাড়াতে পারেন এন্টারপ্রাইজ সংস্করণ.

আপনি যদি পূর্ণাঙ্গ HA চান তবে আপনাকে হয় অর্থ প্রদান করতে হবে বা কিছু ক্রাচ ব্যবহার করতে হবে। কিছু সম্প্রদায় সমাধান আছে - উদাহরণস্বরূপ influxdb-ha একটি উপযুক্ত সমাধান মত দেখায়, কিন্তু এটা লেখা আছে যে এটি উত্পাদনের জন্য উপযুক্ত নয়, পাশাপাশি
influx- spout - NATS এর মাধ্যমে ডেটা পাম্পিং সহ একটি সহজ সমাধান (এটি স্কেলও করতে হবে, তবে এটি সমাধান করা যেতে পারে)।

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

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

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

ভিক্টোরিয়া মেট্রিক্স?

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

প্রচুর সময়-সিরিজ ডেটাবেস রয়েছে, তবে সবচেয়ে প্রতিশ্রুতিশীল একটি হল ভিক্টোরিয়া মেট্রিক্স, এর বেশ কয়েকটি সুবিধা রয়েছে:

• দ্রুত এবং সহজ, অন্তত ফলাফল অনুযায়ী বেঞ্চমার্ক
• একটি ক্লাস্টার সংস্করণ রয়েছে, যার সম্পর্কে এখন ভাল পর্যালোচনা রয়েছে
  • সে শার্ড করতে পারে
• InfluxDB প্রোটোকল সমর্থন করে

আমরা ভিক্টোরিয়ার উপর ভিত্তি করে একটি সম্পূর্ণ কাস্টম স্ট্যাক তৈরি করতে চাইনি এবং মূল আশা ছিল যে আমরা এটিকে InfluxDB-এর জন্য ড্রপ-ইন প্রতিস্থাপন হিসাবে ব্যবহার করতে পারি।

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

তাছাড়া, শুধুমাত্র সংখ্যাসূচক মানগুলি মেট্রিক্সের জন্য সমর্থিত (আমরা কাস্টম মেট্রিক্সের জন্য স্ট্রিং মান ব্যবহার করেছি - বিভাগে আরও অ্যাডমিন প্যানেল).

স্পষ্টতই, একই কারণে, ভিএম ইনফ্লাক্সের মতো লগ সংরক্ষণ করতে পারে না।

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

ভিত্তি নির্বাচন

ফলস্বরূপ, সিদ্ধান্ত নেওয়া হয়েছিল যে পাইলটের জন্য আমরা এখনও নিজেদেরকে একটি একক InfluxDB নোডে সীমাবদ্ধ রাখব।

এই পছন্দের জন্য বেশ কয়েকটি প্রধান কারণ ছিল:

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

পাইলটের প্রথম পর্যায়ের জন্য আমাদের কাছে অনেক স্কুটার ছিল না, এবং বিকাশের সময় পরীক্ষায় কোনও পারফরম্যান্স সমস্যা প্রকাশ করেনি।

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

আমরা স্ট্যাক এবং বেস সম্পর্কে সিদ্ধান্ত নিয়েছি - এখন TICK স্ট্যাকের অবশিষ্ট উপাদান সম্পর্কে।

ক্যাপাসিটর

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

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

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

এটি সমস্যার দ্রুত প্রতিক্রিয়া জানার পাশাপাশি সবকিছু স্বাভাবিক অবস্থায় ফিরে এসেছে বলে বিজ্ঞপ্তিগুলি গ্রহণ করা সম্ভব করেছে।

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

ইনফ্লাক্স 2.0 ক্যাপাসিটর ডিবির অংশ হয়ে ওঠে

ক্রোনোগ্রাফ

আমি নিরীক্ষণের জন্য অনেকগুলি ভিন্ন UI সমাধান দেখেছি, কিন্তু আমি বলতে পারি যে কার্যকারিতা এবং ইউএক্সের পরিপ্রেক্ষিতে, কিছুই ক্রোনোগ্রাফের সাথে তুলনা করে না।

আমরা TICK স্ট্যাক ব্যবহার শুরু করেছি, অদ্ভুতভাবে যথেষ্ট, একটি ওয়েব ইন্টারফেস হিসাবে Grafan এর সাথে।
আমি এর কার্যকারিতা বর্ণনা করব না; প্রত্যেকেই যে কোনও কিছু কাস্টমাইজ করার জন্য এর বিস্তৃত সম্ভাবনাগুলি জানেন।

যাইহোক, গ্রাফানা এখনও একটি সম্পূর্ণ সার্বজনীন যন্ত্র, যখন ক্রোনোগ্রাফ প্রধানত ইনফ্লাক্সের সাথে ব্যবহারের জন্য ডিজাইন করা হয়েছে।

এবং অবশ্যই, এর জন্য ধন্যবাদ, ক্রোনোগ্রাফ অনেক বেশি চতুর বা সুবিধাজনক কার্যকারিতা বহন করতে পারে।

সম্ভবত ক্রোনোগ্রাফের সাথে কাজ করার প্রধান সুবিধা হল আপনি এক্সপ্লোরের মাধ্যমে আপনার ইনফ্লাক্সডিবি-এর ভিতরের অংশ দেখতে পারেন।

দেখে মনে হবে যে Grafana এর প্রায় একই কার্যকারিতা রয়েছে, কিন্তু বাস্তবে, ক্রোনোগ্রাফে একটি ড্যাশবোর্ড সেট আপ করা কয়েকটি মাউস ক্লিকের মাধ্যমে করা যেতে পারে (একই সাথে সেখানে ভিজ্যুয়ালাইজেশনের দিকে তাকানো), গ্রাফনাতে আপনি এখনও তাড়াতাড়ি বা পরে পাবেন JSON কনফিগারেশন সম্পাদনা করতে (অবশ্যই ক্রোনোগ্রাফ আপনার হাতে-কনফিগার করা ড্যাশাগুলি আপলোড করার অনুমতি দেয় এবং প্রয়োজনে JSON হিসাবে সেগুলি সম্পাদনা করতে দেয় - তবে UI তে সেগুলি তৈরি করার পরে আমাকে কখনও স্পর্শ করতে হয়নি)।

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

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

সুন্দর ভিজ্যুয়াল স্টাইল ছাড়াও ড্যাশবোর্ডগুলি আসলে গ্রাফনা বা কিবানার ড্যাশবোর্ড থেকে আলাদা নয়:

এই ক্যোয়ারী উইন্ডোর মত দেখাচ্ছে:

অন্যান্য বিষয়গুলির মধ্যে এটি লক্ষ করা গুরুত্বপূর্ণ যে, InfluxDB ডাটাবেসের ক্ষেত্রের প্রকারগুলি জেনে, ক্রোনোগ্রাফ নিজেই কখনও কখনও আপনাকে একটি প্রশ্ন লিখতে বা গড়ের মতো সঠিক সমষ্টি ফাংশন বেছে নিতে স্বয়ংক্রিয়ভাবে সাহায্য করতে পারে৷

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

ডিফল্টরূপে, ইনফ্লাক্স লগগুলি সিসলগ ব্যবহার করার জন্য তৈরি করা হয় এবং তাই তাদের একটি গুরুত্বপূর্ণ প্যারামিটার রয়েছে - তীব্রতা।

উপরের গ্রাফটি বিশেষভাবে উপযোগী; এতে আপনি যে ত্রুটিগুলি ঘটছে তা দেখতে পাবেন এবং তীব্রতা বেশি হলে রঙ অবিলম্বে স্পষ্টভাবে দেখায়।

কয়েকবার আমরা এইভাবে গুরুত্বপূর্ণ বাগগুলি ধরেছি, গত সপ্তাহের লগগুলি দেখতে গিয়ে একটি লাল স্পাইক দেখেছি।

অবশ্যই, আদর্শভাবে এই ধরনের ত্রুটির জন্য সতর্কতা সেট আপ করা হবে, যেহেতু আমাদের কাছে ইতিমধ্যেই এর জন্য সবকিছু ছিল।

এমনকি আমরা এটিকে কিছুক্ষণের জন্য চালু করেছি, কিন্তু পাইলট প্রস্তুত করার প্রক্রিয়াতে দেখা গেছে যে আমরা অনেক ত্রুটি পেয়েছি (এলটিই নেটওয়ার্কের অনুপলব্ধতার মতো সিস্টেমগুলি সহ), যা স্ল্যাক চ্যানেলটিকেও "স্প্যাম" করেছে। অনেক, কোন সমস্যা সৃষ্টি ছাড়াই. মহান সুবিধা.

সঠিক সমাধান হ'ল এই ধরণের বেশিরভাগ ত্রুটিগুলি পরিচালনা করা, তাদের জন্য তীব্রতা সামঞ্জস্য করা এবং কেবলমাত্র সতর্কতা সক্ষম করা।

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

প্রমাণীকরণ

এটিও উল্লেখ করার মতো যে Chronograf প্রমাণীকরণ হিসাবে OAuth এবং OIDC সমর্থন করে।

এটি খুবই সুবিধাজনক, কারণ এটি আপনাকে সহজেই এটিকে আপনার সার্ভারে সংযুক্ত করতে এবং পূর্ণাঙ্গ SSO তৈরি করতে দেয়৷

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

"অ্যাডমিন"

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

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

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

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

আমরা সেখানে সমস্ত দরকারী তথ্য রেকর্ড করার চেষ্টা করেছি: ব্যাটারি চার্জ, লক স্ট্যাটাস, সেন্সর পারফরম্যান্স, ব্লুটুথ, জিপিএস এবং অন্যান্য অনেক স্বাস্থ্য পরীক্ষা।
আমরা এডমিন প্যানেলে এই সব প্রদর্শন করেছি।

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

এই ফাংশন দ্বারা সম্পন্ন করা হয় মৃত মানুষ — আমরা আমাদের বক্সের পারফরম্যান্স বুঝতে এবং স্ল্যাকে একই সতর্কবার্তা পাঠাতে এটি ব্যবহার করেছি।

যাইহোক, আমরা দ্য সিম্পসনসের চরিত্রগুলির নাম অনুসারে স্কুটারগুলির নামকরণ করেছি - তাদের একে অপরের থেকে আলাদা করা এত সুবিধাজনক ছিল

এবং সাধারণভাবে এটা এই ভাবে আরো মজা ছিল. "গায়েস, স্মিথার্স মারা গেছে!" এর মত বাক্যাংশ ক্রমাগত শোনা যাচ্ছিল।

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

এটা গুরুত্বপূর্ণ যে InfluxDB আপনাকে শুধুমাত্র সাংখ্যিক মান সংরক্ষণ করতে দেয় না, যেমনটি ভিক্টোরিয়া মেট্রিক্সের ক্ষেত্রে।

দেখে মনে হবে এটি এত গুরুত্বপূর্ণ নয় - সর্বোপরি, লগগুলি ছাড়াও, কোনও মেট্রিক্স সংখ্যার আকারে সংরক্ষণ করা যেতে পারে (শুধু পরিচিত রাজ্যগুলির জন্য ম্যাপিং যুক্ত করুন - এক ধরণের এনাম)?

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

ফলস্বরূপ, চার্জিং API আদর্শ থেকে অনেক দূরে ছিল, কিন্তু প্রধান সমস্যা ছিল যে আমরা সবসময় তাদের অবস্থা বুঝতে পারি না।

এখানেই ইনফ্লাক্স উদ্ধারে এসেছিল। আমরা সহজভাবে স্ট্রিং স্ট্যাটাস লিখেছি যা আমাদের কাছে InfluxDB ডাটাবেস ক্ষেত্রে পরিবর্তন ছাড়াই এসেছে।

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

এটি পরে পরিণত হয়েছে, এই স্ট্যাটাসটি সংযোগ হারানোর পরে একবার পাঠানো হয়েছিল, যদি চার্জার নির্দিষ্ট সংখ্যক প্রচেষ্টার পরে সার্ভারের সাথে সংযোগ স্থাপন করতে না পারে।

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

এবং সাধারণভাবে, স্ট্রিং মেট্রিক্স ব্যবহারের জন্য অনেক বেশি সম্ভাবনা প্রদান করে; আপনি তাদের মধ্যে কার্যত যেকোন তথ্য রেকর্ড করতে পারেন। যদিও, অবশ্যই, আপনাকে এই সরঞ্জামটি সাবধানে ব্যবহার করতে হবে।

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

যখন আমরা একটি স্কুটার খুঁজছিলাম তখন এটি আমাদের জন্য খুব দরকারী ছিল (শেষে উপসংহার দেখুন)।

অবকাঠামো পর্যবেক্ষণ

স্কুটারগুলি ছাড়াও, আমাদের আমাদের সম্পূর্ণ (বরং ব্যাপক) অবকাঠামো নিরীক্ষণ করতে হবে।

একটি খুব সাধারণীকৃত আর্কিটেকচার এইরকম কিছু দেখায়:

যদি আমরা একটি বিশুদ্ধ মনিটরিং স্ট্যাক হাইলাইট করি, তাহলে এটি এইরকম দেখায়:

আমরা ক্লাউডে যা পরীক্ষা করতে চাই তা হল:

• ডেটাবেস
• চাবিকাঠি
• মাইক্রোসার্ভিস

যেহেতু আমাদের সমস্ত ক্লাউড পরিষেবাগুলি Kubernetes-এ অবস্থিত, এটির অবস্থা সম্পর্কে তথ্য সংগ্রহ করা ভাল হবে৷

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

আমরা প্রধানত পড এবং মেমরি খরচ কর্মক্ষমতা নিরীক্ষণ. পতনের ক্ষেত্রে, স্ল্যাকে সতর্কতা।

কুবারনেটসে পড ট্র্যাক করার দুটি উপায় রয়েছে: ডেমনসেট এবং সাইডকার।
উভয় পদ্ধতি বিস্তারিত বর্ণনা করা হয় এই ব্লগ পোস্টে.

আমরা টেলিগ্রাফ সাইডকার ব্যবহার করেছি এবং মেট্রিক্স ছাড়াও পড লগ সংগ্রহ করেছি।

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

মনিটরিং মনিটরিং???

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

যদিও টেলিগ্রাফ সহজেই তার নিজস্ব মেট্রিক্স পাঠাতে পারে বা একই ইনফ্লাক্সে বা অন্য কোথাও পাঠানোর জন্য InfluxDB ডাটাবেস থেকে মেট্রিক্স সংগ্রহ করতে পারে।

তথ্যও

পাইলটের ফলাফল থেকে আমরা কী সিদ্ধান্তে আঁকতে পেরেছি?

আপনি কিভাবে মনিটরিং করতে পারেন?

প্রথমত, TICK স্ট্যাক সম্পূর্ণরূপে আমাদের প্রত্যাশা পূরণ করেছে এবং আমরা প্রাথমিকভাবে যা আশা করেছিলাম তার থেকেও বেশি সুযোগ দিয়েছে।

আমাদের প্রয়োজনীয় সমস্ত কার্যকারিতা উপস্থিত ছিল। আমরা এটির সাথে যা করেছি তা সমস্যা ছাড়াই কাজ করেছে।

উৎপাদনশীলতা

বিনামূল্যে সংস্করণে TICK স্ট্যাকের সাথে প্রধান সমস্যা হল স্কেলিং ক্ষমতার অভাব। এটি আমাদের জন্য একটি সমস্যা ছিল না.

আমরা সঠিক লোড ডেটা/পরিসংখ্যান সংগ্রহ করিনি, তবে আমরা একবারে প্রায় 30টি স্কুটার থেকে ডেটা সংগ্রহ করেছি।

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

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

ট্র্যাফিকের বেশিরভাগই লগ দ্বারা গ্রাস করা হয়েছিল; মেট্রিক্স নিজেই, এমনকি 10-সেকেন্ডের ব্যবধানেও, কার্যত এটি নষ্ট করেনি।

ফলস্বরূপ, কিছু সময়ের পরে আমরা ডিভাইসগুলিতে লগগুলির সংগ্রহ সম্পূর্ণরূপে অক্ষম করে দিয়েছি, যেহেতু নির্দিষ্ট সমস্যাগুলি ধ্রুবক সংগ্রহ ছাড়াই ইতিমধ্যে স্পষ্ট ছিল।

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

আমি আরও যোগ করব যে প্রতিটি পৃথক পরিবেশ একে অপরের থেকে আলাদা ছিল এবং উপরে বর্ণিত লোড শুধুমাত্র উত্পাদন পরিবেশের জন্য প্রাসঙ্গিক ছিল।

উন্নয়ন পরিবেশে, আমরা একটি পৃথক InfluxDB দৃষ্টান্ত উত্থাপন করেছি যা প্রতি 10 সেকেন্ডে ডেটা সংগ্রহ করতে থাকে এবং আমরা কোনো কর্মক্ষমতা সমস্যায় পড়িনি।

TICK - ছোট থেকে মাঝারি প্রকল্পের জন্য আদর্শ

এই তথ্যের উপর ভিত্তি করে, আমি উপসংহারে পৌঁছেছি যে TICK স্ট্যাক তুলনামূলকভাবে ছোট প্রকল্প বা প্রকল্পগুলির জন্য আদর্শ যেগুলি অবশ্যই কোনো হাইলোড আশা করে না।

আপনার যদি হাজার হাজার পড বা শত শত মেশিন না থাকে, এমনকি একটি ইনফ্লাক্সডিবি উদাহরণও লোডটি ঠিকঠাকভাবে পরিচালনা করবে।

কিছু ক্ষেত্রে, আপনি একটি আদিম উচ্চ প্রাপ্যতা সমাধান হিসাবে ইনফ্লাক্স রিলেতে সন্তুষ্ট হতে পারেন।

এবং, অবশ্যই, কেউ আপনাকে "উল্লম্ব" স্কেলিং সেট আপ করতে এবং বিভিন্ন ধরণের মেট্রিক্সের জন্য বিভিন্ন সার্ভার বরাদ্দ করতে বাধা দিচ্ছে না।

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

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

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

সত্য, আমি আবার একটি রিজার্ভেশন করব যে Loki/Grafana রেডিমেড TICK-এর তুলনায় অনেক কম সুবিধাজনক (তাদের বহুমুখীতার কারণে), কিন্তু তারা বিনামূল্যে।

গুরুত্বপূর্ণ: এখানে বর্ণিত সমস্ত তথ্য ইনফ্লাক্স 1.8 সংস্করণের জন্য প্রাসঙ্গিক, এই মুহুর্তে ইনফ্লাক্স 2.0 প্রকাশিত হতে চলেছে৷

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

এই কার্যকারিতা ইনফ্লাক্স 2.0-এও উপস্থিত হবে, কিন্তু আমরা কোনো সময়সীমা খুঁজে পাইনি, এমনকি আনুমানিকও।

কীভাবে আইওটি প্ল্যাটফর্ম তৈরি করবেন না (এখন)

শেষ পর্যন্ত, পাইলট চালু করার পরে, আমরা নিজেরাই আমাদের নিজস্ব পূর্ণাঙ্গ IoT স্ট্যাক একত্রিত করেছি, আমাদের মান অনুসারে উপযুক্ত বিকল্পের অনুপস্থিতিতে।

তবে সম্প্রতি এটি বিটা সংস্করণে পাওয়া যাচ্ছে ওপেনবালেনা - এটা দুঃখজনক যে আমরা যখন প্রকল্পটি তৈরি করা শুরু করি তখন তিনি সেখানে ছিলেন না।

আমরা শেষ ফলাফল এবং Ansible + TICK + WireGuard এর উপর ভিত্তি করে প্ল্যাটফর্ম নিয়ে সম্পূর্ণ সন্তুষ্ট যা আমরা নিজেদেরকে একত্রিত করেছি। কিন্তু আজ, আমি আপনার নিজের আইওটি প্ল্যাটফর্ম নিজেই তৈরি করার চেষ্টা করার আগে বালেনাকে আরও ঘনিষ্ঠভাবে দেখার পরামর্শ দেব।

কারণ শেষ পর্যন্ত এটি আমরা যা করেছি তার বেশিরভাগই করতে পারে এবং OpenBalena বিনামূল্যে এবং ওপেন সোর্স।

এটি ইতিমধ্যেই জানে কিভাবে শুধুমাত্র আপডেট পাঠাতে হয় না, একটি VPN ইতিমধ্যেই তৈরি করা হয়েছে এবং একটি IoT পরিবেশে ব্যবহারের জন্য তৈরি করা হয়েছে।

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

আরে, হারিয়ে যাওয়া স্কুটারের কী হবে?

সুতরাং স্কুটার, "রাল্ফ", একটি ট্রেস ছাড়াই অদৃশ্য হয়ে গেল।

আমরা অবিলম্বে ইনফ্লাক্সডিবি থেকে জিপিএস মেট্রিক্স ডেটা সহ আমাদের "অ্যাডমিন প্যানেলে" মানচিত্রটি দেখতে ছুটে যাই।

তথ্য পর্যবেক্ষণ করার জন্য ধন্যবাদ, আমরা সহজেই নির্ধারণ করেছি যে স্কুটারটি গত দিন 21:00-এর দিকে পার্কিং লট ছেড়েছে, প্রায় আধাঘণ্টা গাড়ি চালিয়ে কিছু এলাকায় গেছে এবং কিছু জার্মান বাড়ির পাশে সকাল 5টা পর্যন্ত পার্ক করা হয়েছে।

সকাল 5 টার পরে, কোনও পর্যবেক্ষণ ডেটা পাওয়া যায়নি—এর মানে হয় অতিরিক্ত ব্যাটারি সম্পূর্ণরূপে নিষ্কাশন করা হয়েছে, অথবা আক্রমণকারী অবশেষে কীভাবে স্কুটার থেকে স্মার্ট হার্ডওয়্যারটি সরাতে হবে তা খুঁজে বের করেছে৷
তা সত্ত্বেও, স্কুটারটি যে ঠিকানায় ছিল সেখানে পুলিশকে ডাকা হয়েছিল। স্কুটার ছিল না।

যাইহোক, বাড়ির মালিকও এতে অবাক হয়েছিলেন, কারণ তিনি গতকাল রাতে অফিস থেকে এই স্কুটারে চড়ে বাড়ি ফিরেছিলেন।

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

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

উত্স: www.habr.com