اسکوتر گم شده یا داستان یک نظارت IoT را برگردانید

یک سال پیش نسخه آزمایشی یک پروژه تبلیغاتی را راه اندازی کردیم اجاره غیرمتمرکز اسکوتر برقی.

در ابتدا این پروژه Road-To-Barcelona نام داشت، بعداً به Road-To-Berlin تبدیل شد (از این رو R2B در تصاویر) و در پایان xRide نام گرفت.

ایده اصلی پروژه این بود: به جای داشتن یک سرویس اجاره ماشین یا اسکوتر متمرکز (ما در مورد اسکوترها با نام موتورسیکلت های برقی صحبت می کنیم، نه kickscooter/scooter) ما می خواستیم بستری برای اجاره غیرمتمرکز ایجاد کنیم. در مورد مشکلاتی که با آن مواجه شدیم قبلا نوشته بود.

در ابتدا، این پروژه بر روی خودروها متمرکز بود، اما به دلیل ضرب الاجل ها، ارتباطات بسیار طولانی با تولید کنندگان و تعداد زیادی محدودیت ایمنی، اسکوترهای برقی برای خلبان انتخاب شدند.

کاربر یک برنامه iOS یا اندروید را روی گوشی نصب کرد، به اسکوتر مورد علاقه خود نزدیک شد، پس از آن گوشی و اسکوتر ارتباط همتا به همتا برقرار کردند، ETH رد و بدل شد و کاربر می‌توانست با روشن کردن اسکوتر از طریق آن، سواری را شروع کند. تلفن. در پایان سفر، امکان پرداخت هزینه سفر با استفاده از اتریوم از کیف پول کاربر روی گوشی نیز وجود داشت.

علاوه بر اسکوترها، کاربر «شارژرهای هوشمند» را نیز در اپلیکیشن مشاهده کرد که با مراجعه به آن کاربر می‌توانست باتری فعلی را در صورت کم شدن باتری خود تغییر دهد.

این به طور کلی شبیه خلبان ما است که در سپتامبر سال گذشته در دو شهر آلمان راه اندازی شد: بن و برلین.

و سپس، یک روز، در بن، در اوایل صبح، به تیم پشتیبانی ما (واقع در محل برای حفظ وضعیت کار اسکوترها) هشدار داده شد: یکی از اسکوترها بدون هیچ اثری ناپدید شده بود.

چگونه آن را پیدا کرده و برگردانیم؟

در این مقاله من در مورد این صحبت خواهم کرد، اما ابتدا - در مورد اینکه چگونه پلتفرم IoT خودمان را ساختیم و چگونه آن را نظارت کردیم.

چه چیزی و چرا باید نظارت شود: اسکوترها، زیرساخت ها، شارژ؟

بنابراین، چه چیزی را می خواستیم در پروژه خود نظارت کنیم؟

اول از همه، اینها خود اسکوترها هستند - اسکوترهای برقی خود بسیار گران هستند، شما نمی توانید چنین پروژه ای را بدون آمادگی کافی راه اندازی کنید؛ در صورت امکان، می خواهید تا حد امکان اطلاعات بیشتری در مورد اسکوترها جمع آوری کنید: در مورد مکان آنها، سطح شارژ ، و غیره.

علاوه بر این، من می‌خواهم وضعیت زیرساخت‌های فناوری اطلاعات خودمان - پایگاه‌های اطلاعاتی، سرویس‌ها و همه چیزهایی که برای کار کردن نیاز دارند را نظارت کنم. همچنین لازم بود وضعیت "شارژرهای هوشمند" در صورت خراب شدن یا تمام شدن باتری آنها نظارت شود.

اسکوتر

اسکوترهای ما چه بودند و چه چیزی می خواستیم در مورد آنها بدانیم؟

اولین و مهمترین چیز مختصات GPS است، زیرا به لطف آنها می توانیم بفهمیم کجا هستند و کجا حرکت می کنند.

بعدی شارژ باتری است که به لطف آن می توانیم مشخص کنیم که شارژ اسکوترها به پایان می رسد و آبمیوه گیری را ارسال می کنیم یا حداقل به کاربر هشدار می دهیم.

البته، همچنین لازم است بررسی کنیم که چه اتفاقی برای قطعات سخت افزاری ما می افتد:

• آیا بلوتوث کار می کند؟
• آیا خود ماژول GPS کار می کند؟
  • ما همچنین مشکل داشتیم که GPS می تواند مختصات نادرست ارسال کند و گیر کند و این فقط با بررسی های اضافی روی اسکوتر مشخص می شود.
    و در اسرع وقت به پشتیبانی اطلاع دهید تا مشکل حل شود

و در آخر: بررسی نرم‌افزار، از سیستم‌عامل و پردازنده، بارگذاری شبکه و دیسک شروع می‌شود و با بررسی ماژول‌های خودمان که مختص ما هستند، خاتمه می‌یابد.جولوکام, شنل کلید).

سخت افزار

بخش "آهن" ما چه بود؟

با در نظر گرفتن کوتاه‌ترین زمان ممکن و نیاز به نمونه‌سازی سریع، ساده‌ترین گزینه را برای پیاده‌سازی و انتخاب قطعات - Raspberry Pi انتخاب کردیم.
علاوه بر خود Rpi، ما یک برد سفارشی داشتیم (که خودمان آن را توسعه دادیم و از چین برای تسریع روند مونتاژ راه حل نهایی سفارش دادیم) و مجموعه ای از قطعات - یک رله (برای روشن / خاموش کردن اسکوتر)، شارژر خوان، مودم، آنتن. همه اینها به طور فشرده در یک "جعبه xRide" مخصوص بسته بندی شده بود.

همچنین لازم به ذکر است که کل جعبه توسط یک پاوربانک اضافی تغذیه می شد که به نوبه خود از باتری اصلی اسکوتر تغذیه می کرد.

این امکان استفاده از نظارت و روشن کردن اسکوتر را حتی پس از پایان سفر فراهم کرد، زیرا باتری اصلی بلافاصله پس از چرخاندن کلید احتراق به حالت "خاموش" خاموش شد.

داکر؟ لینوکس ساده؟ و استقرار

بیایید به نظارت برگردیم، پس تمشک - چه داریم؟

یکی از اولین چیزهایی که می‌خواستیم برای سرعت بخشیدن به فرآیند استقرار، به‌روزرسانی و تحویل اجزا به دستگاه‌های فیزیکی استفاده کنیم، Docker بود.

متأسفانه، به سرعت مشخص شد که Docker در RPi، اگرچه کار می کند، اما سربار زیادی دارد، به ویژه از نظر مصرف انرژی.

تفاوت در استفاده از سیستم عامل "بومی"، اگرچه چندان قوی نیست، اما همچنان برای ما کافی بود تا نسبت به احتمال از دست دادن سریع شارژ محتاط باشیم.

دلیل دوم یکی از کتابخانه های شریک ما در Node.js (sic!) بود - تنها جزء سیستم که در Go/C/C++ نوشته نشده بود.

نویسندگان کتابخانه وقت نداشتند نسخه ای کارآمد را به هیچ یک از زبان های "بومی" ارائه کنند.

نه تنها خود گره زیباترین راه حل برای دستگاه های با کارایی پایین نیست، بلکه خود کتابخانه نیز بسیار تشنه منابع بود.

ما متوجه شدیم که حتی اگر بخواهیم، ​​استفاده از Docker برای ما بسیار زیاد است. این انتخاب به نفع سیستم عامل بومی و کار مستقیم تحت آن انجام شد.

OS

در نتیجه، ما دوباره ساده ترین گزینه را به عنوان سیستم عامل انتخاب کردیم و از Raspbian (ساخت دبیان برای Pi) استفاده کردیم.

ما همه نرم افزارهای خود را در Go می نویسیم، بنابراین ماژول اصلی عامل سخت افزار را نیز در سیستم خود در Go نوشتیم.

این اوست که مسئول کار با GPS، بلوتوث، خواندن شارژ، روشن کردن اسکوتر و غیره است.

مستقر کنید

بلافاصله این سوال در مورد نیاز به اجرای مکانیزمی برای ارائه به‌روزرسانی‌ها به دستگاه‌ها (OTA) مطرح شد - هم به‌روزرسانی‌ها برای خود عامل/برنامه ما و هم به‌روزرسانی‌های خود سیستم‌عامل/سیستم‌افزار (زیرا نسخه‌های جدید عامل ممکن است به به‌روزرسانی هسته نیاز داشته باشند. یا اجزای سیستم، کتابخانه ها و غیره).

پس از تجزیه و تحلیل طولانی مدت بازار، مشخص شد که راه حل های بسیار زیادی برای ارائه به روز رسانی به دستگاه وجود دارد.

از ابزارهای نسبتا ساده، عمدتاً به روز رسانی/دو بوت گرا مانند swupd/SWUpdate/OSTree تا پلتفرم های کامل مانند Mender و Balena.

اول از همه، ما تصمیم گرفتیم که به راه حل های انتها به انتها علاقه مندیم، بنابراین انتخاب بلافاصله بر روی پلت فرم ها افتاد.

خیلی بالنا به دلیل این واقعیت که در واقع از همان Docker در داخل balenaEngine خود استفاده می کند، حذف شد.

اما توجه دارم که با وجود این، ما به طور مداوم از محصول آنها استفاده کردیم بالنا اچر برای سیستم عامل فلش در کارت های SD - یک ابزار ساده و بسیار راحت برای این.

بنابراین، در نهایت انتخاب سقوط کرد مندر. Mender یک پلتفرم کامل برای مونتاژ، تحویل و نصب سیستم عامل است.

به طور کلی پلتفرم عالی به نظر می رسد، اما فقط یک هفته و نیم طول کشید تا نسخه صحیح سیستم عامل خود را با استفاده از سازنده mender بسازیم.
و هر چه بیشتر در پیچیدگی های استفاده از آن غوطه ور می شدیم، بیشتر مشخص می شد که برای استقرار کامل آن به زمان بسیار بیشتری از آنچه در اختیار داشتیم نیاز داریم.

افسوس، ضرب‌الاجل‌های فشرده ما به این معنی بود که ما مجبور شدیم استفاده از Mender را کنار بگذاریم و حتی ساده‌تر را انتخاب کنیم.

غیر ممکن

ساده ترین راه حل در شرایط ما استفاده از Ansible بود. چند کتاب بازی برای شروع کافی بود.

ماهیت آنها این بود که ما به سادگی از میزبان (سرور CI) از طریق ssh به rasberries خود متصل می شدیم و به روز رسانی ها را برای آنها توزیع می کردیم.

در همان ابتدا، همه چیز ساده بود - باید با دستگاه ها در یک شبکه قرار می گرفتید، ریختن از طریق Wi-Fi انجام می شد.

در دفتر به سادگی یک دوجین تمشک آزمایشی متصل به یک شبکه وجود داشت، هر دستگاه یک آدرس IP ثابت نیز در فهرست Ansible مشخص شده بود.

این Ansible بود که عامل نظارت ما را به دستگاه های نهایی تحویل داد

3G / LTE

متأسفانه، این مورد استفاده برای Ansible فقط می‌توانست در حالت توسعه کار کند، قبل از اینکه اسکوترهای واقعی داشته باشیم.

زیرا همانطور که می دانید اسکوترها به یک روتر Wi-Fi متصل نیستند و دائماً منتظر به روز رسانی از طریق شبکه هستند.

در واقعیت، اسکوترها به هیچ وجه نمی توانند اتصالی به جز 3G/LTE موبایل داشته باشند (و حتی در آن زمان نه همیشه).

این بلافاصله مشکلات و محدودیت های زیادی مانند سرعت اتصال کم و ارتباطات ناپایدار را تحمیل می کند.

اما مهمترین چیز این است که در یک شبکه 3G/LTE نمی توانیم به سادگی به یک IP ثابت اختصاص داده شده به شبکه تکیه کنیم.

این مشکل تا حدی توسط برخی از ارائه دهندگان سیم کارت حل شده است؛ حتی سیم کارت های ویژه ای برای دستگاه های IoT با آدرس های IP ثابت طراحی شده اند. اما ما به چنین سیم کارت هایی دسترسی نداشتیم و نمی توانستیم از آدرس های IP استفاده کنیم.

البته، ایده‌هایی برای انجام نوعی ثبت آدرس‌های IP به نام کشف سرویس در جایی مانند Consul وجود داشت، اما مجبور شدیم چنین ایده‌هایی را کنار بگذاریم، زیرا در آزمایش‌های ما آدرس IP ممکن است اغلب تغییر کند، که منجر به بی‌ثباتی بزرگ شد.

به همین دلیل، راحت‌ترین استفاده برای تحویل معیارها، استفاده از مدل کشش نیست، جایی که برای معیارهای لازم به سراغ دستگاه‌ها می‌رویم، بلکه با فشار دادن، معیارها را مستقیماً از دستگاه به سرور تحویل می‌دهیم.

VPN

به عنوان راه حلی برای این مشکل، ما به طور خاص VPN را انتخاب کردیم محافظ سیم.

کلاینت ها (روروک مخصوص بچه ها) در ابتدای سیستم به سرور VPN متصل شدند و توانستند به آنها متصل شوند. این تونل برای ارائه به روز رسانی استفاده می شد.

در تئوری، می توان از همان تونل برای نظارت استفاده کرد، اما چنین اتصالی پیچیده تر و کمتر از فشار ساده بود.

منابع ابری

در نهایت، نظارت بر سرویس‌های ابری و پایگاه‌های داده ضروری است، زیرا ما از Kubernetes برای آنها استفاده می‌کنیم، به‌طور ایده‌آل به طوری که استقرار نظارت در خوشه تا حد امکان ساده باشد. در حالت ایده آل، با استفاده از سکان، از آنجایی که برای استقرار، در اکثر موارد از آن استفاده می کنیم. و البته، برای نظارت بر ابر، باید از همان راه حل هایی استفاده کنید که برای خود اسکوترها وجود دارد.

داده شده

وای، به نظر می رسد که شرح را مرتب کرده ایم، بیایید لیستی از آنچه در پایان نیاز داشتیم تهیه کنیم:

• یک راه حل سریع، زیرا نظارت از قبل در طول فرآیند توسعه ضروری است
• حجم / کمیت - بسیاری از معیارهای مورد نیاز
• جمع آوری گزارش مورد نیاز است
• قابلیت اطمینان - داده ها برای موفقیت راه اندازی بسیار مهم هستند
• شما نمی توانید از مدل کشش استفاده کنید - به فشار نیاز دارید
• ما به نظارت یکپارچه نه تنها سخت افزار، بلکه ابر نیز نیاز داریم

تصویر نهایی چیزی شبیه به این بود

انتخاب پشته

بنابراین، ما با سوال انتخاب یک پشته نظارت مواجه شدیم.

اول از همه، ما به دنبال کامل ترین راه حل همه کاره بودیم که به طور همزمان تمام نیازهای ما را پوشش دهد، اما در عین حال به اندازه کافی انعطاف پذیر باشد تا استفاده از آن را با نیازهای ما منطبق کند. با این حال، ما محدودیت‌های زیادی را بر اساس سخت‌افزار، معماری و ضرب‌الاجل‌ها بر ما تحمیل کرده بود.

راه حل های نظارتی بسیار متنوعی وجود دارد که از سیستم های تمام عیار شروع می شود Nagios, آیسینگ یا zabbix و در پایان با راهکارهای آماده مدیریت ناوگان.

در ابتدا، دومی برای ما راه‌حلی ایده‌آل به نظر می‌رسید، اما برخی نظارت کامل نداشتند، برخی دیگر قابلیت‌های نسخه‌های رایگان بسیار محدودی داشتند، و برخی دیگر به سادگی «خواست‌های» ما را پوشش نمی‌دادند یا به اندازه کافی انعطاف‌پذیر نبودند تا با سناریوهای ما سازگار شوند. برخی از آنها به سادگی منسوخ شده اند.

پس از تجزیه و تحلیل تعدادی از راه حل های مشابه، ما به سرعت به این نتیجه رسیدیم که آسان تر و سریع تر است که یک پشته مشابه را خودمان جمع کنیم. بله، این کار کمی پیچیده تر از استقرار یک پلتفرم مدیریت ناوگان کاملاً آماده خواهد بود، اما ما مجبور نخواهیم بود که مصالحه کنیم.

تقریباً به طور قطع، در بسیاری از راه حل ها، یک راه حل آماده وجود دارد که کاملاً مناسب ما باشد، اما در مورد ما، جمع آوری یک پشته خاص به تنهایی و سفارشی کردن آن "برای خود" بسیار سریعتر بود تا اینکه تست محصولات آماده

با همه اینها، ما سعی نکردیم خودمان یک پلت فرم نظارت کامل را جمع کنیم، بلکه به دنبال کاربردی ترین پشته های "آماده" بودیم، فقط با قابلیت پیکربندی انعطاف پذیر آنها.

(ب) ELK؟

اولین راه حلی که در واقع مورد توجه قرار گرفت، پشته معروف ELK بود.
در واقع باید آن را BELK نامید، زیرا همه چیز با Beats شروع می شود - https://www.elastic.co/what-is/elk-stack

البته ELK یکی از معروف ترین و قدرتمندترین راه حل ها در زمینه مانیتورینگ و حتی بیشتر در جمع آوری و پردازش لاگ ها می باشد.

ما در نظر داشتیم که ELK برای جمع‌آوری سیاهه‌ها و همچنین ذخیره‌سازی طولانی‌مدت معیارهای به‌دست‌آمده از Prometheus استفاده شود.

برای تجسم می توانید از Grafan استفاده کنید.

در واقع، پشته جدید ELK می تواند معیارها را به طور مستقل جمع آوری کند (متریک بیت)، و Kibana نیز می تواند آنها را نمایش دهد.

اما با این حال، ELK در ابتدا از لاگ‌ها خارج شد و تا کنون عملکرد معیارها دارای تعدادی اشکالات جدی است:

• به طور قابل توجهی کندتر از پرومتئوس
• در مکان های بسیار کمتری نسبت به پرومتئوس ادغام می شود
• تنظیم هشدار برای آنها دشوار است
• متریک ها فضای زیادی را اشغال می کنند
• تنظیم داشبورد با معیارها در Kiban بسیار پیچیده تر از Grafan است

به طور کلی، معیارهای ELK سنگین هستند و هنوز به اندازه راه حل های دیگر راحت نیستند، که اکنون بسیار بیشتر از Prometheus وجود دارد: TSDB، Victoria Metrics، Cortex، و غیره و غیره. البته، من واقعاً دوست دارم فوراً یک راه حل همه کاره کامل داشته باشم، اما در مورد metricbeat سازش های زیادی وجود داشت.

و خود پشته ELK چند لحظه سخت دارد:

• اگر حجم نسبتاً زیادی داده جمع آوری کنید، سنگین است، گاهی اوقات حتی بسیار سنگین است
• شما باید "آشپزی" آن را بدانید - باید آن را مقیاس کنید، اما انجام این کار بی اهمیت نیست.
• نسخه رایگان حذف شده - نسخه رایگان هشدار معمولی ندارد و در زمان انتخاب هیچ احراز هویتی وجود نداشت

باید بگویم که اخیراً نکته آخر بهتر شده است و علاوه بر آن خروجی در بسته منبع باز X (از جمله احراز هویت) خود مدل قیمت گذاری شروع به تغییر کرد.

اما در زمانی که قرار بود این راه حل را به کار بگیریم، هیچ هشداری وجود نداشت.
شاید می‌توانستیم با استفاده از ElastAlert یا راه‌حل‌های دیگر جامعه چیزی بسازیم، اما همچنان تصمیم گرفتیم جایگزین‌های دیگری را در نظر بگیریم.

لوکی - گرافانا - پرومتئوس

در حال حاضر، یک راه حل خوب ممکن است ایجاد یک پشته نظارتی صرفاً بر اساس Prometheus به عنوان ارائه‌دهنده معیارها، Loki برای گزارش‌ها، و برای تجسم می‌توانید از همان Grafana استفاده کنید.

متاسفانه در زمان شروع پایلوت فروش پروژه (سپتامبر تا مهر 19)، لوکی هنوز در نسخه بتای 0.3-0.4 بود و در زمان شروع توسعه نمی‌توان آن را به عنوان یک راه‌حل تولیدی در نظر گرفت. اصلا

من هنوز تجربه استفاده واقعی از Loki در پروژه‌های جدی را ندارم، اما می‌توانم بگویم که Promtail (عاملی برای جمع‌آوری سیاهه‌ها) هم برای بره‌متال و هم برای pods در kubernetes کار می‌کند.

تیک بزنید

شاید شایسته ترین (تنها؟) جایگزین با امکانات کامل برای پشته ELK اکنون فقط بتوان پشته TICK نامید - Telegraf، InfluxDB، Chronograf، Kapacitor.

من تمام اجزای زیر را با جزئیات بیشتر توضیح خواهم داد، اما ایده کلی این است:

• Telegraf - عامل جمع آوری معیارها
• InfluxDB - پایگاه داده متریک
• خازن - پردازنده متریک زمان واقعی برای هشدار
• Chronograf - پانل وب برای تجسم

برای InfluxDB، Kapacitor و Chronograf نمودارهای فرمان رسمی وجود دارد که ما از آنها استفاده کردیم.

لازم به ذکر است که در آخرین نسخه Influx 2.0 (بتا)، Kapacitor و Chronograf بخشی از InfluxDB شدند و دیگر به طور جداگانه وجود ندارند.

تلگراف

تلگراف یک عامل بسیار سبک وزن برای جمع آوری معیارها در یک ماشین حالت است.

او می تواند مقدار زیادی از همه چیز را تحت نظر داشته باشد انجیناکس به
سرور کمیته مبارزه با سانسور.

چندین مزیت جالب دارد:

• سریع و سبک (نوشته شده در Go)
  • حداقل منابع را می خورد
• به طور پیش‌فرض معیارهای فشاری
• تمام معیارهای لازم را جمع آوری می کند
  • معیارهای سیستم بدون هیچ تنظیماتی
  • معیارهای سخت افزاری مانند اطلاعات حسگرها
  • اضافه کردن معیارهای خود بسیار آسان است
• تعداد زیادی افزونه خارج از جعبه
• سیاهههای مربوط را جمع آوری می کند

از آنجایی که معیارهای فشار برای ما ضروری بود، همه مزیت های دیگر بیشتر از افزودن های دلپذیر بود.

جمع آوری سیاهههای مربوط توسط خود عامل نیز بسیار راحت است، زیرا نیازی به اتصال ابزارهای اضافی برای ورود به سیستم نیست.

Influx در صورت استفاده راحت‌ترین تجربه را برای کار با گزارش‌ها ارائه می‌دهد syslog.

Telegraf به طور کلی یک عامل عالی برای جمع آوری معیارها است، حتی اگر از بقیه پشته ICK استفاده نکنید.

بسیاری از مردم برای راحتی، آن را با ELK و دیگر پایگاه‌های داده سری زمانی تطبیق می‌دهند، زیرا تقریباً در هر جایی می‌تواند معیارها را بنویسد.

InfluxDB

InfluxDB هسته اصلی پشته TICK است، یعنی پایگاه داده سری زمانی برای معیارها.
علاوه بر معیارها، Influx همچنین می تواند گزارش ها را ذخیره کند، اگرچه در اصل، گزارش ها برای آن فقط معیارهای مشابه هستند، فقط به جای شاخص های عددی معمول، عملکرد اصلی توسط یک خط متن گزارش انجام می شود.

InfluxDB نیز در Go نوشته شده است و به نظر می رسد در مقایسه با ELK در خوشه (نه قدرتمندترین) ما بسیار سریعتر اجرا می شود.

یکی از مزایای جالب Influx همچنین یک API بسیار راحت و غنی برای پرس و جوهای داده است که ما به طور فعال از آن استفاده کردیم.

معایب - $$$ یا پوسته پوسته شدن؟

پشته TICK تنها یک اشکال دارد که ما کشف کردیم - آن عزیزم. حتی بیشتر.

نسخه پولی چه چیزی دارد که نسخه رایگان ندارد؟

تا آنجا که ما توانستیم درک کنیم، تنها تفاوت بین نسخه پولی پشته TICK و نسخه رایگان، قابلیت های مقیاس بندی است.

یعنی، شما می توانید یک خوشه با دسترسی بالا را فقط در داخل افزایش دهید نسخه های سازمانی.

اگر HA کامل می خواهید، یا باید هزینه کنید یا از عصا استفاده کنید. چند راه حل اجتماعی وجود دارد - برای مثال influxdb-ha به نظر یک راه حل مناسب است، اما نوشته شده است که برای تولید مناسب نیست، و همچنین
هجوم-فشار - یک راه حل ساده با پمپاژ داده ها از طریق NATS (همچنین باید مقیاس شود، اما این قابل حل است).

حیف است، اما به نظر می رسد هر دوی آنها رها شده اند - هیچ تعهد جدیدی وجود ندارد، من فرض می کنم که موضوع انتشار نسخه جدید Influx 2.0 به زودی مورد انتظار است، که در آن بسیاری از چیزها متفاوت خواهد بود (هیچ اطلاعاتی در مورد آن وجود ندارد هنوز پوسته پوسته شدن در آن).

به طور رسمی یک نسخه رایگان وجود دارد رله - در واقع، این یک HA اولیه است، اما فقط از طریق متعادل کردن،
از آنجایی که تمام داده ها در تمام نمونه های InfluxDB در پشت متعادل کننده بار نوشته می شود.
او مقداری دارد کاستی مانند مشکلات احتمالی در بازنویسی نقاط و نیاز به ایجاد پایه برای معیارها از قبل
(که به طور خودکار در طول کار معمولی با InfluxDB اتفاق می افتد).

علاوه بر این اشتراک گذاری پشتیبانی نمی شود، این به معنای سربار اضافی برای معیارهای تکراری (هم پردازش و هم ذخیره سازی) است که ممکن است به آنها نیاز نداشته باشید، اما راهی برای جدا کردن آنها وجود ندارد.

ویکتوریا متریک؟

در نتیجه، علی‌رغم این واقعیت که ما از پشته TICK در همه چیز به جز مقیاس‌بندی پولی کاملاً راضی بودیم، تصمیم گرفتیم ببینیم آیا راه‌حل‌های رایگانی وجود دارد که بتواند جایگزین پایگاه داده InfluxDB شود، در حالی که اجزای باقی‌مانده T_CK را ترک کنیم.

پایگاه‌های داده سری زمانی زیادی وجود دارد، اما امیدوارکننده‌ترین آنها Victoria Metrics است که دارای تعدادی مزیت است:

• سریع و آسان، حداقل با توجه به نتایج معیارها
• یک نسخه خوشه ای وجود دارد که در حال حاضر حتی بررسی های خوبی در مورد آن وجود دارد
  • او می تواند خرد کند
• از پروتکل InfluxDB پشتیبانی می کند

ما قصد نداشتیم یک پشته کاملا سفارشی بر اساس ویکتوریا بسازیم و امید اصلی این بود که بتوانیم از آن به عنوان جایگزینی برای InfluxDB استفاده کنیم.

متأسفانه، با وجود پشتیبانی از پروتکل InfluxDB، این امکان پذیر نیست، اما فقط برای ضبط معیارها کار می کند - فقط Prometheus API "خارج" در دسترس است، به این معنی که امکان تنظیم Chronograf روی آن وجود ندارد.

علاوه بر این، فقط مقادیر عددی برای معیارها پشتیبانی می شوند (ما از مقادیر رشته ای برای معیارهای سفارشی استفاده کردیم - بیشتر در مورد آن در بخش منطقه مدیریت).

بدیهی است که به همین دلیل، VM نمی‌تواند گزارش‌ها را مانند Influx ذخیره کند.

همچنین، لازم به ذکر است که در زمان جستجوی راه حل بهینه، ویکتوریا متریک هنوز آنقدر محبوب نبود، اسناد بسیار کوچکتر و عملکرد ضعیف تر بود.
(توضیح دقیقی از نسخه کلاستر و اشتراک گذاری به خاطر ندارم).

انتخاب پایه

در نتیجه، تصمیم گرفته شد که برای خلبان همچنان خود را به یک گره InfluxDB محدود کنیم.

چندین دلیل اصلی برای این انتخاب وجود داشت:

• ما واقعاً کل عملکرد پشته TICK را دوست داشتیم
• ما قبلاً موفق شده بودیم آن را مستقر کنیم و عالی کار کرد
• ضرب الاجل ها رو به اتمام بود و زمان زیادی برای آزمایش گزینه های دیگر باقی نمانده بود.
• انتظار چنین بار سنگینی را نداشتیم

ما اسکوترهای زیادی برای فاز اول آزمایشی نداشتیم و آزمایش در حین توسعه هیچ مشکل عملکردی را نشان نداد.

بنابراین، تصمیم گرفتیم که برای این پروژه یک گره Influx بدون نیاز به مقیاس‌بندی برای ما کافی باشد (به نتیجه‌گیری در پایان مراجعه کنید).

ما در مورد پشته و پایه تصمیم گرفته ایم - اکنون در مورد اجزای باقی مانده از پشته TICK.

خازن

Kapacitor بخشی از پشته TICK است، سرویسی که می تواند معیارهای ورودی به پایگاه داده را در زمان واقعی نظارت کند و اقدامات مختلفی را بر اساس قوانین انجام دهد.

به طور کلی، آن را به عنوان ابزاری برای ردیابی ناهنجاری های بالقوه و یادگیری ماشین قرار می دهد (من مطمئن نیستم که این توابع مورد تقاضا هستند)، اما محبوب ترین مورد استفاده از آن رایج تر است - هشدار.

به این ترتیب ما از آن برای اعلان ها استفاده کردیم. هنگامی که یک اسکوتر خاص آفلاین شد، هشدارهای Slack را تنظیم کردیم و همین کار برای شارژرهای هوشمند و اجزای زیرساختی مهم انجام شد.

این امکان پاسخگویی سریع به مشکلات و همچنین دریافت اعلان هایی مبنی بر بازگشت همه چیز به حالت عادی را فراهم کرد.

یک مثال ساده: یک باتری اضافی برای تغذیه «جعبه» ما خراب شده یا به دلایلی شارژش تمام شده است؛ به سادگی با نصب یک باتری جدید، پس از مدتی باید اعلانی دریافت کنیم که عملکرد اسکوتر بازیابی شده است.

در Influx 2.0 Capacitor بخشی از DB شد

کرونوگراف

راه‌حل‌های UI مختلف زیادی برای نظارت دیده‌ام، اما می‌توانم بگویم که از نظر عملکرد و UX، هیچ چیز با Chronograf قابل مقایسه نیست.

ما شروع به استفاده از پشته TICK، به اندازه کافی عجیب، با Grafan به عنوان یک رابط وب کردیم.
من عملکرد آن را توضیح نمی دهم؛ همه از امکانات گسترده آن برای تنظیم هر چیزی می دانند.

با این حال، Grafana هنوز یک ساز کاملاً جهانی است، در حالی که Chronograf عمدتاً برای استفاده با Influx طراحی شده است.

و البته، به لطف این، Chronograf می تواند عملکرد بسیار هوشمندانه یا راحت تری را ارائه دهد.

شاید راحتی اصلی کار با Chronograf این باشد که می‌توانید داخل InfluxDB خود را از طریق Explore مشاهده کنید.

به نظر می رسد که Grafana عملکرد تقریبا یکسانی دارد، اما در واقع، راه اندازی داشبورد در Chronograf را می توان با چند کلیک ماوس انجام داد (در عین حال به تجسم در آنجا نگاه می کنید)، در حالی که در Grafana هنوز دیر یا زود خواهید داشت. برای ویرایش پیکربندی JSON (البته Chronograf به شما اجازه می دهد داشاهای پیکربندی شده با دست خود را آپلود کنید و در صورت لزوم آنها را به عنوان JSON ویرایش کنید - اما من هرگز پس از ایجاد آنها در UI آنها را لمس نکردم).

کیبانا قابلیت های بسیار غنی تری برای ایجاد داشبورد و کنترل برای آنها دارد، اما UX برای چنین عملیاتی بسیار پیچیده است.

ایجاد یک داشبورد راحت نیاز به درک خوبی دارد. و اگرچه عملکرد داشبوردهای Chronograf کمتر است، ساخت و سفارشی کردن آنها بسیار ساده تر است.

خود داشبوردها، جدا از سبک بصری دلپذیر، در واقع هیچ تفاوتی با داشبوردهای Grafana یا Kibana ندارند:

پنجره پرس و جو به این صورت است:

مهم است که از جمله موارد دیگر توجه داشته باشید که با دانستن انواع فیلدها در پایگاه داده InfluxDB، خود کرنوگراف گاهی اوقات می تواند به طور خودکار در نوشتن یک Query یا انتخاب تابع تجمع درست مانند میانگین به شما کمک کند.

و البته، Chronograf تا حد امکان برای مشاهده سیاههها راحت است. به نظر می رسد این است:

به طور پیش‌فرض، گزارش‌های Influx برای استفاده از syslog طراحی شده‌اند و بنابراین یک پارامتر مهم دارند - شدت.

نمودار بالا به ویژه مفید است؛ روی آن می توانید خطاهای رخ داده را ببینید و رنگ بلافاصله به وضوح نشان می دهد که آیا شدت آن بیشتر است.

چند بار از این طریق اشکالات مهمی را گرفتیم، به مشاهده سیاهههای مربوط به هفته گذشته رفتیم و یک سنبله قرمز دیدیم.

البته، در حالت ایده آل، تنظیم هشدار برای چنین خطاهایی است، زیرا ما قبلاً همه چیز را برای این کار داشتیم.

ما حتی برای مدتی این را روشن کردیم، اما در فرآیند آماده سازی آزمایشی، معلوم شد که خطاهای بسیار زیادی دریافت می کنیم (از جمله موارد سیستمی مانند در دسترس نبودن شبکه LTE)، که کانال Slack را "اسپم" می کند. بیش از حد، بدون ایجاد مشکل.

راه حل صحیح این است که اکثر این نوع خطاها را مدیریت کنید، شدت آنها را تنظیم کنید و تنها پس از آن هشدار را فعال کنید.

به این ترتیب، فقط خطاهای جدید یا مهم به Slack ارسال می شود. با توجه به ضرب الاجل های فشرده، زمان کافی برای چنین تنظیمی وجود نداشت.

احراز هویت

همچنین لازم به ذکر است که Chronograf از OAuth و OIDC به عنوان احراز هویت پشتیبانی می کند.

این بسیار راحت است، زیرا به شما امکان می دهد به راحتی آن را به سرور خود متصل کنید و SSO کامل ایجاد کنید.

در مورد ما سرور بود شنل کلید - برای اتصال به مانیتورینگ استفاده شد، اما از همان سرور برای احراز هویت اسکوترها و درخواست‌ها به بک‌اند نیز استفاده شد.

"مدیر"

آخرین مؤلفه ای که توضیح خواهم داد «پانل مدیریت» خودنویس ما در Vue است.
اساساً این فقط یک سرویس مستقل است که اطلاعات اسکوتر را از پایگاه‌های اطلاعاتی، میکروسرویس‌ها و داده‌های معیارهای InfluxDB به طور همزمان نمایش می‌دهد.

علاوه بر این، بسیاری از عملکردهای اداری مانند راه اندازی مجدد اضطراری یا باز کردن قفل از راه دور برای تیم پشتیبانی به آنجا منتقل شدند.

نقشه ها هم بود. قبلاً اشاره کردم که ما به جای Chronograf با Grafana شروع کردیم - زیرا نقشه های Grafana به شکل پلاگین در دسترس هستند که می توانیم مختصات اسکوترها را روی آنها مشاهده کنیم. متأسفانه قابلیت های ابزارک نقشه برای گرافانا بسیار محدود است و در نتیجه نوشتن برنامه وب خود با نقشه ها در عرض چند روز بسیار ساده تر بود تا نه تنها مختصات را در لحظه مشاهده کنید بلکه نمایش دهید. مسیر طی شده توسط روروک مخصوص بچه ها، قادر به فیلتر کردن داده ها بر روی نقشه و غیره (همه قابلیت هایی که ما نتوانستیم در یک داشبورد ساده پیکربندی کنیم).

یکی از مزایای Influx که قبلاً ذکر شد، توانایی ایجاد آسان معیارهای خود است.
این اجازه می دهد تا از آن برای طیف وسیعی از سناریوها استفاده شود.

ما سعی کردیم تمام اطلاعات مفید را در آنجا ثبت کنیم: شارژ باتری، وضعیت قفل، عملکرد سنسور، بلوتوث، GPS و بسیاری دیگر از بررسی های سلامت.
همه اینها را در پنل مدیریت نمایش دادیم.

البته مهمترین معیار برای ما وضعیت عملکرد اسکوتر بود - در واقع Influx خود این را بررسی می کند و با "چراغ سبز" در بخش Nodes نشان می دهد.

این کار توسط تابع انجام می شود مرده - ما از آن برای درک عملکرد جعبه خود و ارسال همان هشدارها به Slack استفاده کردیم.

به هر حال، ما اسکوترها را با نام شخصیت های سیمپسون ها نام گذاری کردیم - تشخیص آنها از یکدیگر بسیار راحت بود.

و در کل اینجوری سرگرم کننده تر بود. عباراتی مانند «بچه ها، اسمیترز مرده است!» مدام شنیده می شد.

متریک رشته

مهم است که InfluxDB به شما اجازه می دهد تا نه تنها مقادیر عددی را ذخیره کنید، همانطور که در مورد ویکتوریا متریک وجود دارد.

به نظر می رسد که این خیلی مهم نیست - به هر حال، جدا از گزارش ها، هر معیاری را می توان به شکل اعداد ذخیره کرد (فقط نقشه برداری را برای حالت های شناخته شده اضافه کنید - نوعی enum)؟

در مورد ما، حداقل یک سناریو وجود داشت که در آن معیارهای رشته بسیار مفید بودند.
اتفاقاً تأمین‌کننده «شارژرهای هوشمند» ما شخص ثالثی بود، ما هیچ کنترلی بر فرآیند توسعه و اطلاعاتی که این شارژرها می‌توانستند ارائه کنند نداشتیم.

در نتیجه، API شارژ با ایده آل فاصله زیادی داشت، اما مشکل اصلی این بود که ما همیشه نمی توانستیم وضعیت آنها را درک کنیم.

اینجاست که Influx به کمک آمد. ما به سادگی وضعیت رشته ای را که برای ما آمده بود در قسمت پایگاه داده InfluxDB بدون تغییر نوشتیم.

برای مدتی فقط مقادیری مانند "آنلاین" و "آفلاین" به آنجا می رسید که بر اساس آنها اطلاعات در پنل مدیریت ما نمایش داده می شد و اعلان ها به Slack ارسال می شد. با این حال، در نقطه ای، مقادیری مانند "قطع شده" نیز در آنجا ظاهر می شوند.

همانطور که بعدا مشخص شد، این وضعیت یک بار پس از قطع اتصال ارسال شد، در صورتی که شارژر پس از تعداد معینی تلاش نتوانست با سرور ارتباط برقرار کند.

بنابراین، اگر فقط از مجموعه ای ثابت از مقادیر استفاده کنیم، ممکن است این تغییرات را در زمان مناسب در سیستم عامل مشاهده نکنیم.

و به طور کلی، متریک های رشته ای امکانات بسیار بیشتری را برای استفاده فراهم می کنند؛ شما می توانید تقریباً هر اطلاعاتی را در آنها ثبت کنید. اگرچه، البته، شما نیز باید با دقت از این ابزار استفاده کنید.

علاوه بر معیارهای معمول، اطلاعات موقعیت مکانی GPS را نیز در InfluxDB ثبت کردیم. این برای نظارت بر موقعیت اسکوترها در پنل مدیریت ما بسیار مفید بود.
در واقع، ما همیشه می دانستیم که در لحظه ای که به آن نیاز داریم کجا و کدام اسکوتر است.

هنگامی که به دنبال یک روروک مخصوص بچه ها بودیم، این برای ما بسیار مفید بود (به نتیجه گیری در پایان مراجعه کنید).

نظارت بر زیرساخت

علاوه بر خود اسکوترها، ما نیاز به نظارت بر کل زیرساخت (نسبتاً گسترده) خود داشتیم.

یک معماری بسیار کلی چیزی شبیه به این بود:

اگر یک پشته نظارت خالص را برجسته کنیم، به نظر می رسد:

آنچه ما می خواهیم در فضای ابری بررسی کنیم این است:

• پایگاه های داده
• شنل کلید
• میکروسرویس ها

از آنجایی که همه سرویس‌های ابری ما در Kubernetes قرار دارند، جمع‌آوری اطلاعات در مورد وضعیت آن خوب است.

خوشبختانه، Telegraf خارج از جعبه می تواند تعداد زیادی معیار در مورد وضعیت خوشه Kubernetes جمع آوری کند، و Chronograf بلافاصله داشبوردهای زیبایی را برای این کار ارائه می دهد.

ما عمدتاً عملکرد پادها و مصرف حافظه را زیر نظر داشتیم. در صورت سقوط، در Slack هشدار می دهد.

دو راه برای ردیابی پادها در Kubernetes وجود دارد: DaemonSet و Sidecar.
هر دو روش به تفصیل شرح داده شده است در این پست وبلاگ.

ما از Telegraf Sidecar استفاده کردیم و علاوه بر معیارها، لاگ های غلاف را جمع آوری کردیم.

در مورد ما، ما باید با سیاهههای مربوط به سرهم بندی کردن. علیرغم این واقعیت که Telegraf می‌تواند گزارش‌ها را از Docker API بکشد، ما می‌خواستیم مجموعه‌ای یکنواخت از گزارش‌ها را با دستگاه‌های نهایی خود داشته باشیم و syslog را برای کانتینرها برای این کار پیکربندی کنیم. شاید این راه حل زیبا نبود، اما هیچ شکایتی از کار آن وجود نداشت و لاگ ها به خوبی در Chronograf نمایش داده شدند.

مانیتورینگ ؟؟؟

در نهایت، سوال قدیمی سیستم های نظارتی به وجود آمد، اما خوشبختانه یا متاسفانه ما به سادگی زمان کافی برای این کار نداشتیم.

اگرچه Telegraf می تواند به راحتی معیارهای خود را ارسال کند یا معیارهایی را از پایگاه داده InfluxDB برای ارسال به همان Influx یا جای دیگری جمع آوری کند.

یافته ها

از نتایج خلبان چه نتیجه ای گرفتیم؟

چگونه می توانید نظارت انجام دهید؟

اول از همه، پشته TICK به طور کامل انتظارات ما را برآورده کرد و حتی بیشتر از آنچه در ابتدا انتظار داشتیم به ما فرصت داد.

تمام عملکردی که نیاز داشتیم وجود داشت. هر کاری که با آن انجام دادیم بدون مشکل کار کرد.

کارایی

مشکل اصلی پشته TICK در نسخه رایگان نبود قابلیت مقیاس بندی است. این برای ما مشکلی نداشت.

ما داده ها/ارقام دقیق بار را جمع آوری نکردیم، اما داده ها را از حدود 30 اسکوتر در یک زمان جمع آوری کردیم.

هر یک از آنها بیش از سه دوجین معیار را جمع آوری کردند. در همان زمان، لاگ از دستگاه ها جمع آوری شد. جمع آوری و ارسال داده ها هر 10 ثانیه صورت می گیرد.

ذکر این نکته ضروری است که پس از یک هفته و نیم آزمایش، زمانی که بخش عمده ای از "مشکلات دوران کودکی" اصلاح شد و مهمترین مشکلات حل شده بود، مجبور شدیم فرکانس ارسال داده ها به سرور را کاهش دهیم. 30 ثانیه. این امر ضروری شد زیرا ترافیک سیم کارت های LTE ما به سرعت از بین رفت.

بخش عمده ای از ترافیک توسط لاگ ها مصرف می شد؛ خود معیارها، حتی با فاصله 10 ثانیه ای، عملاً آن را هدر ندادند.

در نتیجه، پس از مدتی، ما به طور کامل جمع آوری گزارش ها را در دستگاه ها غیرفعال کردیم، زیرا مشکلات خاص از قبل حتی بدون جمع آوری مداوم نیز آشکار بود.

در برخی موارد، اگر مشاهده گزارش‌ها هنوز ضروری بود، ما به سادگی از طریق WireGuard از طریق VPN متصل می‌شویم.

همچنین اضافه می‌کنم که هر محیط جداگانه از یکدیگر جدا شده بود و بار توضیح داده شده در بالا فقط برای محیط تولید مرتبط بود.

در محیط توسعه، یک نمونه InfluxDB جداگانه ارائه کردیم که به جمع‌آوری داده‌ها در هر 10 ثانیه ادامه می‌داد و با هیچ مشکلی در عملکرد مواجه نشدیم.

تیک - ایده آل برای پروژه های کوچک تا متوسط

بر اساس این اطلاعات، من نتیجه می‌گیرم که پشته TICK برای پروژه‌های نسبتاً کوچک یا پروژه‌هایی که قطعاً انتظار هیچ HighLoad ندارند، ایده‌آل است.

اگر هزاران پاد یا صدها دستگاه ندارید، حتی یک نمونه InfluxDB به خوبی بار را کنترل می کند.

در برخی موارد، ممکن است از Influx Relay به عنوان یک راه حل ابتدایی High Availability راضی باشید.

و البته، هیچ کس شما را از تنظیم مقیاس "عمودی" و اختصاص سرورهای مختلف برای انواع مختلف معیارها باز نمی دارد.

اگر در مورد بار مورد انتظار روی سرویس‌های نظارت مطمئن نیستید، یا مطمئن هستید که معماری بسیار «سنگین» دارید، استفاده از نسخه رایگان پشته TICK را توصیه نمی‌کنم.

البته یک راه حل ساده خرید خواهد بود InfluxDB Enterprise - اما در اینجا نمی توانم به نحوی نظر بدهم، زیرا خودم با ظرافت ها آشنا نیستم. علاوه بر این که بسیار گران است و قطعا برای شرکت های کوچک مناسب نیست.

در این مورد، امروز، من توصیه می‌کنم به دنبال جمع‌آوری معیارها از طریق Victoria Metrics و لاگ‌ها با استفاده از Loki باشید.

درست است، من دوباره رزرو می کنم که Loki/Grafana (به دلیل تطبیق پذیری بیشتر) نسبت به تیک آماده بسیار کمتر راحت هستند، اما رایگان هستند.

این مهم است: تمام اطلاعات توضیح داده شده در اینجا مربوط به نسخه Influx 1.8 است، در حال حاضر Influx 2.0 در شرف انتشار است.

در حالی که من فرصتی برای آزمایش آن در شرایط جنگی نداشته ام و نتیجه گیری در مورد پیشرفت ها دشوار است، رابط قطعاً حتی بهتر شده است، معماری ساده شده است (بدون خازن و کرونوگراف)،
الگوها ظاهر شدند ("ویژگی قاتل" - می‌توانید بازیکنان را در فورتنایت ردیابی کنید و زمانی که بازیکن مورد علاقه‌تان در بازی برنده شد، اعلان‌ها را دریافت کنید). اما، متأسفانه، در حال حاضر، نسخه 2 کلیدی را که ما نسخه اول را برای آن انتخاب کردیم، ندارد - هیچ مجموعه گزارشی وجود ندارد.

این قابلیت در Influx 2.0 نیز ظاهر خواهد شد، اما ما نتوانستیم مهلت‌هایی، حتی مهلت‌های تقریبی پیدا کنیم.

چگونه پلتفرم های اینترنت اشیا را نسازیم (اکنون)

در پایان، پس از راه‌اندازی پایلوت، ما خودمان پشته کامل اینترنت اشیاء خود را در غیاب جایگزینی مناسب با استانداردهایمان مونتاژ کردیم.

با این حال، اخیراً در نسخه بتا در دسترس است OpenBalena - حیف که وقتی ساخت پروژه را شروع کردیم او آنجا نبود.

ما از نتیجه نهایی و پلتفرم مبتنی بر Ansible + TICK + WireGuard که خودمان مونتاژ کردیم کاملا راضی هستیم. اما امروز، توصیه می‌کنم قبل از اینکه خودتان پلتفرم اینترنت اشیا خود را بسازید، نگاهی دقیق‌تر به Balena بیندازید.

زیرا در نهایت می تواند بیشتر کارهایی را که ما انجام دادیم انجام دهد و OpenBalena رایگان و متن باز است.

از قبل می‌داند که چگونه نه تنها به‌روزرسانی‌ها را ارسال کند، بلکه یک VPN از قبل برای استفاده در یک محیط IoT ساخته شده است.

و به تازگی، آنها حتی خود را منتشر کردند سخت افزار، که به راحتی به اکوسیستم آنها متصل می شود.

هی، در مورد اسکوتر گم شده چطور؟

بنابراین اسکوتر "رالف" بدون هیچ ردی ناپدید شد.

ما بلافاصله دویدیم تا نقشه را در "پانل مدیریت" خود با داده های سنجه GPS از InfluxDB نگاه کنیم.

به لطف داده های نظارتی، ما به راحتی تشخیص دادیم که اسکوتر حدود ساعت 21:00 روز گذشته پارکینگ را ترک کرد، حدود نیم ساعت به منطقه ای رانندگی کرد و تا ساعت 5 صبح در کنار خانه ای آلمانی پارک شده بود.

پس از ساعت 5 صبح، هیچ داده نظارتی دریافت نشد - این بدان معنی بود که یا باتری اضافی کاملاً تخلیه شده است، یا مهاجم بالاخره متوجه شده است که چگونه سخت افزار هوشمند را از اسکوتر خارج کند.
با وجود این، پلیس همچنان به آدرسی که اسکوتر در آن قرار داشت فراخوانده شد. اسکوتر آنجا نبود.

با این حال، صاحب خانه نیز از این موضوع شگفت زده شد، زیرا او در واقع دیشب با این اسکوتر از دفتر به خانه رفت.

همانطور که مشخص شد، یکی از کارکنان پشتیبانی صبح زود رسید و اسکوتر را برداشت و دید که باتری اضافی آن کاملاً تخلیه شده و آن را (با پای پیاده) به پارکینگ برد. و باتری اضافی به دلیل رطوبت از کار افتاد.

اسکوتر را از خودمان دزدیدیم. ضمناً من نمی‌دانم چگونه و چه کسی مشکل را با پرونده پلیس حل کرد، اما نظارت کاملاً کار کرد ...

منبع: www.habr.com