أطلقنا قبل عام نسخة تجريبية من مشروع ترويجي لـ .
في البداية، كان المشروع يسمى Road-To-Barcelona، ثم أصبح فيما بعد Road-To-Berlin (وبالتالي R2B في لقطات الشاشة)، وفي النهاية تم تسميته xRide.
كانت الفكرة الرئيسية للمشروع هي: بدلاً من وجود خدمة تأجير سيارات أو سكوتر مركزية (نحن نتحدث عن الدراجات البخارية المعروفة أيضًا باسم الدراجات النارية الكهربائية، وليس الدراجات البخارية/الدراجات البخارية) أردنا إنشاء منصة للتأجير اللامركزي. وعن الصعوبات التي واجهناها .
في البداية، ركز المشروع على السيارات، ولكن بسبب المواعيد النهائية، والاتصالات الطويلة للغاية مع الشركات المصنعة وعدد كبير من قيود السلامة، تم اختيار الدراجات البخارية الكهربائية للطيار.
قام المستخدم بتثبيت تطبيق iOS أو Android على الهاتف، واقترب من السكوتر الذي أعجبه، وبعد ذلك قام الهاتف والسكوتر بإنشاء اتصال نظير إلى نظير، وتم تبادل ETH ويمكن للمستخدم بدء الرحلة عن طريق تشغيل السكوتر عبر الهاتف. وفي نهاية الرحلة، كان من الممكن أيضًا دفع ثمن الرحلة باستخدام إيثريوم من محفظة المستخدم على الهاتف.
بالإضافة إلى الدراجات البخارية، رأى المستخدم في التطبيق "شواحن ذكية"، من خلال زيارتها يمكن للمستخدم تغيير البطارية الحالية بنفسه إذا كانت منخفضة.
هذا هو عمومًا ما بدا عليه برنامجنا التجريبي، الذي تم إطلاقه في سبتمبر من العام الماضي في مدينتين ألمانيتين: بون وبرلين.
وبعد ذلك، في أحد الأيام، في بون، في الصباح الباكر، تم تنبيه فريق الدعم لدينا (الموجود في الموقع لصيانة الدراجات البخارية في حالة صالحة للعمل): اختفت إحدى الدراجات البخارية دون أن يترك أثراً.
كيفية العثور عليه وإعادته؟
سأتحدث في هذه المقالة عن هذا، ولكن أولاً - حول كيفية بناء منصة إنترنت الأشياء الخاصة بنا وكيف قمنا بمراقبتها.
ماذا ولماذا يجب مراقبته: الدراجات البخارية والبنية التحتية ومحطات الشحن؟
إذًا، ما الذي أردنا مراقبته في مشروعنا؟
بادئ ذي بدء، هذه هي الدراجات البخارية نفسها - الدراجات البخارية الكهربائية نفسها باهظة الثمن، ولا يمكنك إطلاق مثل هذا المشروع دون الاستعداد الكافي؛ إذا أمكن، تريد جمع أكبر قدر ممكن من المعلومات حول الدراجات البخارية: حول موقعها ومستوى الشحن ، إلخ.
بالإضافة إلى ذلك، أود مراقبة حالة البنية التحتية لتكنولوجيا المعلومات الخاصة بنا - قواعد البيانات والخدمات وكل ما يحتاجونه للعمل. وكان من الضروري أيضاً مراقبة حالة «الشواحن الذكية»، في حال تعطلها أو نفاد بطارياتها بالكامل.
سكوتر
ما هي دراجاتنا البخارية وماذا أردنا أن نعرف عنها؟
أول وأهم شيء هو إحداثيات نظام تحديد المواقع العالمي (GPS)، حيث بفضلها يمكننا أن نفهم مكان تواجدهم وأين يتحركون.
التالي هو شحن البطارية، والذي بفضله يمكننا تحديد أن شحن الدراجات البخارية يقترب من نهايته وإرسال عصارة أو على الأقل تحذير المستخدم.
بالطبع، من الضروري أيضًا التحقق مما يحدث مع مكونات أجهزتنا:
- هل يعمل البلوتوث؟
- هل تعمل وحدة GPS نفسها؟
- كانت لدينا أيضًا مشكلة في حقيقة أن نظام تحديد المواقع العالمي (GPS) قد يرسل إحداثيات غير صحيحة ويتعطل، ولا يمكن تحديد ذلك إلا من خلال عمليات فحص إضافية على السكوتر،
وإخطار الدعم في أقرب وقت ممكن لحل المشكلة
- كانت لدينا أيضًا مشكلة في حقيقة أن نظام تحديد المواقع العالمي (GPS) قد يرسل إحداثيات غير صحيحة ويتعطل، ولا يمكن تحديد ذلك إلا من خلال عمليات فحص إضافية على السكوتر،
وأخيرًا: فحص البرنامج، بدءًا من نظام التشغيل والمعالج، وتحميل الشبكة والقرص، وانتهاءً بفحص الوحدات النمطية الخاصة بنا والتي تكون أكثر تحديدًا بالنسبة لنا (, ).
أجهزة التبخير
ماذا كان الجزء "الحديدي" لدينا؟
مع الأخذ في الاعتبار أقصر إطار زمني ممكن والحاجة إلى النماذج الأولية السريعة، اخترنا الخيار الأسهل لتنفيذ واختيار المكونات - Raspberry Pi.
بالإضافة إلى Rpi نفسه، كان لدينا لوحة مخصصة (التي قمنا بتطويرها بأنفسنا وطلبناها من الصين لتسريع عملية تجميع الحل النهائي) ومجموعة من المكونات - مرحل (لتشغيل/إيقاف تشغيل السكوتر)، قارئ شحن البطارية، مودم، هوائيات. تم تجميع كل هذا بشكل مضغوط في "صندوق xRide" خاص.
تجدر الإشارة أيضًا إلى أن الصندوق بأكمله كان مدعومًا ببنك طاقة إضافي، والذي بدوره كان مدعومًا بالبطارية الرئيسية للسكوتر.
هذا جعل من الممكن استخدام المراقبة وتشغيل السكوتر حتى بعد نهاية الرحلة، حيث تم إيقاف تشغيل البطارية الرئيسية مباشرة بعد تحويل مفتاح الإشعال إلى وضع "إيقاف التشغيل".
عامل ميناء؟ لينكس عادي؟ والنشر
دعونا نعود إلى المراقبة، إذن التوت - ماذا لدينا؟
كان Docker من أول الأشياء التي أردنا استخدامها لتسريع عملية نشر المكونات وتحديثها وتسليمها إلى الأجهزة الفعلية.
لسوء الحظ، سرعان ما أصبح من الواضح أن Docker على RPi، على الرغم من أنه يعمل، لديه الكثير من النفقات العامة، لا سيما فيما يتعلق باستهلاك الطاقة.
كان الاختلاف في استخدام نظام التشغيل "الأصلي"، على الرغم من أنه ليس قويًا جدًا، إلا أنه لا يزال كافيًا لكي نكون حذرين من احتمال فقدان الشحن بسرعة كبيرة.
السبب الثاني كان إحدى المكتبات الشريكة لنا على Node.js (هكذا!) - المكون الوحيد للنظام الذي لم تتم كتابته بلغة Go/C/C++.
لم يكن لدى مؤلفي المكتبة الوقت الكافي لتقديم نسخة عمل بأي من اللغات "الأصلية".
ليس فقط أن العقدة نفسها ليست الحل الأكثر أناقة للأجهزة منخفضة الأداء، ولكن المكتبة نفسها كانت متعطشة للغاية للموارد.
لقد أدركنا أنه حتى لو أردنا ذلك، فإن استخدام Docker سيكون بمثابة عبئ كبير جدًا بالنسبة لنا. تم الاختيار لصالح نظام التشغيل الأصلي والعمل تحته مباشرة.
OS
نتيجة لذلك، اخترنا مرة أخرى الخيار الأبسط كنظام التشغيل واستخدمنا Raspbian (إصدار Debian لـ Pi).
نحن نكتب جميع برامجنا بلغة Go، لذلك قمنا أيضًا بكتابة وحدة وكيل الأجهزة الرئيسية في نظامنا بلغة Go.
هو المسؤول عن العمل مع نظام تحديد المواقع العالمي (GPS) والبلوتوث وقراءة الشحن وتشغيل السكوتر وما إلى ذلك.
نشر
نشأ السؤال على الفور حول الحاجة إلى تنفيذ آلية لتوصيل التحديثات إلى الأجهزة (OTA) - سواء تحديثات وكيلنا/تطبيقنا نفسه، أو تحديثات نظام التشغيل/البرنامج الثابت نفسه (نظرًا لأن الإصدارات الجديدة من الوكيل قد تتطلب تحديثات للنواة أو مكونات النظام والمكتبات وما إلى ذلك).
بعد تحليل طويل للسوق، اتضح أن هناك الكثير من الحلول لتوصيل التحديثات إلى الجهاز.
بدءًا من الأدوات المساعدة البسيطة نسبيًا والموجهة للتحديث/التمهيد المزدوج مثل swupd/SWUpdate/OSTree إلى الأنظمة الأساسية الكاملة مثل Mender وBalena.
بادئ ذي بدء، قررنا أننا مهتمون بالحلول الشاملة، لذلك وقع الاختيار على الفور على المنصات.
نفسها تم استبعاده لأنه يستخدم بالفعل نفس Docker داخل balenaEngine.
لكنني ألاحظ أنه على الرغم من ذلك، انتهى بنا الأمر إلى استخدام منتجهم باستمرار تعد برامج الفلاش الثابتة على بطاقات SD أداة مساعدة بسيطة ومريحة للغاية لهذا الغرض.
لذلك وقع الاختيار في النهاية . Mender عبارة عن منصة كاملة لتجميع البرامج الثابتة وتسليمها وتثبيتها.
بشكل عام، تبدو المنصة رائعة، لكن الأمر استغرق منا حوالي أسبوع ونصف فقط لبناء الإصدار الصحيح من البرامج الثابتة لدينا باستخدام منشئ الإصلاح.
وكلما انغمسنا أكثر في تعقيدات استخدامه، أصبح من الواضح أننا سنحتاج إلى وقت أطول بكثير مما كان لدينا لنشره بالكامل.
للأسف، كانت المواعيد النهائية الضيقة لدينا تعني أننا اضطررنا للتخلي عن استخدام Mender واختيار واحد أكثر بساطة.
Ansible
كان الحل الأبسط في حالتنا هو استخدام Ansible. كان هناك عدد من كتيبات اللعب كافية للبدء.
كان جوهرهم هو أننا ببساطة اتصلنا من المضيف (خادم CI) عبر ssh إلى التوت الخاص بنا وقمنا بتوزيع التحديثات عليهم.
في البداية، كان كل شيء بسيطًا - كان عليك أن تكون على نفس الشبكة مع الأجهزة، ويتم الصب عبر شبكة Wi-Fi.
في المكتب، كان هناك ببساطة عشرات من التوت الاختباري المتصل بالشبكة نفسها، وكان لكل جهاز عنوان IP ثابت محدد أيضًا في Ansible Inventory.
لقد كانت Ansible هي التي أوصلت وكيل المراقبة الخاص بنا إلى الأجهزة النهائية
3G / LTE
لسوء الحظ، حالة الاستخدام هذه لـ Ansible لا يمكن أن تعمل إلا في وضع التطوير قبل أن يكون لدينا دراجات بخارية فعلية.
لأن الدراجات البخارية، كما تفهم، لا تجلس متصلة بجهاز توجيه Wi-Fi واحد، وتنتظر باستمرار التحديثات عبر الشبكة.
في الواقع، لا يمكن للدراجات البخارية أن تتمتع بأي اتصال على الإطلاق بخلاف شبكة الجيل الثالث/LTE المحمولة (وحتى في هذه الحالة ليس طوال الوقت).
وهذا يفرض على الفور العديد من المشاكل والقيود، مثل سرعة الاتصال المنخفضة والتواصل غير المستقر.
ولكن الشيء الأكثر أهمية هو أنه في شبكة 3G/LTE لا يمكننا الاعتماد ببساطة على عنوان IP ثابت مخصص للشبكة.
يتم حل هذه المشكلة جزئيًا بواسطة بعض موفري بطاقات SIM، بل إن هناك بطاقات SIM خاصة مصممة لأجهزة إنترنت الأشياء ذات عناوين IP ثابتة. لكن لم نتمكن من الوصول إلى بطاقات SIM هذه ولم نتمكن من استخدام عناوين IP.
بالطبع، كانت هناك أفكار للقيام بنوع من تسجيل عناوين IP والمعروف أيضًا باسم اكتشاف الخدمة في مكان ما مثل Consul، ولكن كان علينا التخلي عن مثل هذه الأفكار، لأنه في اختباراتنا يمكن أن يتغير عنوان IP كثيرًا، مما أدى إلى عدم استقرار كبير.
لهذا السبب، فإن الاستخدام الأكثر ملاءمة لتقديم المقاييس لن يكون باستخدام نموذج السحب، حيث سنذهب إلى الأجهزة للحصول على المقاييس الضرورية، ولكن الدفع، وتسليم المقاييس من الجهاز مباشرة إلى الخادم
VPN
كحل لهذه المشكلة، اخترنا VPN - على وجه التحديد .
العملاء (الدراجات البخارية) في بداية النظام متصلون بخادم VPN وكانوا قادرين على الاتصال بهم. تم استخدام هذا النفق لتقديم التحديثات.
من الناحية النظرية، يمكن استخدام نفس النفق للمراقبة، لكن مثل هذا الاتصال كان أكثر تعقيدًا وأقل موثوقية من الدفع البسيط.
الموارد السحابية
أخيرًا، من الضروري مراقبة خدماتنا السحابية وقواعد بياناتنا، نظرًا لأننا نستخدم Kubernetes لها، بشكل مثالي بحيث يكون نشر المراقبة في المجموعة بسيطًا قدر الإمكان. من الناحية المثالية، باستخدام نظرًا لأنه بالنسبة للنشر، فإننا نستخدمه في معظم الحالات. وبطبيعة الحال، لمراقبة السحابة، تحتاج إلى استخدام نفس الحلول كما هو الحال مع الدراجات البخارية نفسها.
دانو
أوه، يبدو أننا قد قمنا بفرز الوصف، فلنضع قائمة بما نحتاجه في النهاية:
- حل سريع، حيث أن المراقبة ضرورية بالفعل أثناء عملية التطوير
- الحجم/الكمية – هناك حاجة إلى العديد من المقاييس
- مطلوب جمع السجل
- الموثوقية - البيانات أمر بالغ الأهمية لإطلاق النجاح
- لا يمكنك استخدام نموذج السحب - فأنت بحاجة إلى الدفع
- نحن بحاجة إلى مراقبة موحدة ليس فقط للأجهزة، ولكن أيضًا للسحابة
تبدو الصورة النهائية مثل هذا
اختيار المكدس
لذلك، واجهنا مسألة اختيار مكدس المراقبة.
بادئ ذي بدء، كنا نبحث عن الحل المتكامل الأكثر اكتمالاً والذي يغطي جميع متطلباتنا في الوقت نفسه، ولكن في الوقت نفسه يكون مرنًا بما يكفي لتكييف استخدامه مع احتياجاتنا. ومع ذلك، كان لدينا العديد من القيود التي فرضتها علينا الأجهزة والهندسة المعمارية والمواعيد النهائية.
هناك مجموعة كبيرة ومتنوعة من حلول المراقبة، بدءًا من الأنظمة الكاملة مثل , أو وتنتهي بالحلول الجاهزة لإدارة الأسطول.
في البداية، بدا هذا الأخير حلاً مثاليًا بالنسبة لنا، لكن البعض لم يكن لديه مراقبة كاملة، والبعض الآخر كان لديه قدرات محدودة للغاية للإصدارات المجانية، والبعض الآخر ببساطة لم يقم بتغطية "احتياجاتنا" أو لم تكن مرنة بما يكفي لتناسب سيناريوهاتنا. بعضها ببساطة عفا عليه الزمن.
بعد تحليل عدد من الحلول المماثلة، توصلنا بسرعة إلى استنتاج مفاده أنه سيكون من الأسهل والأسرع تجميع مجموعة مماثلة بأنفسنا. نعم، سيكون الأمر أكثر تعقيدًا بعض الشيء من نشر منصة إدارة الأسطول الجاهزة تمامًا، ولكن لن نضطر إلى تقديم تنازلات.
من المؤكد تقريبًا، في كل الوفرة الهائلة من الحلول، يوجد بالفعل حل جاهز يناسبنا تمامًا، ولكن في حالتنا كان من الأسرع بكثير تجميع مجموعة معينة بمفردنا وتخصيصها "لأنفسنا" بدلاً من اختبار المنتجات الجاهزة.
مع كل هذا، لم نسعى جاهدين لتجميع منصة مراقبة كاملة بأنفسنا، لكننا كنا نبحث عن الأكوام "الجاهزة" الأكثر وظيفية، فقط مع القدرة على تكوينها بمرونة.
(ب) الأيائل؟
الحل الأول الذي تم النظر فيه بالفعل هو مكدس ELK المعروف.
في الواقع، يجب أن يُطلق عليها اسم BELK، لأن كل شيء يبدأ بـ Beats -
وبطبيعة الحال، يعد ELK أحد أشهر وأقوى الحلول في مجال المراقبة، بل وأكثر من ذلك في جمع السجلات ومعالجتها.
كنا نعتزم استخدام ELK لجمع السجلات بالإضافة إلى تخزين المقاييس التي تم الحصول عليها من Prometheus على المدى الطويل.
للتصور يمكنك استخدام جرافان.
في الواقع، يمكن لمكدس ELK الجديد جمع المقاييس بشكل مستقل (metricbeat)، ويمكن لـ Kibana أيضًا عرضها.
ولكن مع ذلك، فقد نشأت ELK في البداية من السجلات، وحتى الآن فإن وظيفة المقاييس بها عدد من العيوب الخطيرة:
- أبطأ بكثير من بروميثيوس
- يتكامل في أماكن أقل بكثير من بروميثيوس
- من الصعب إعداد التنبيهات لهم
- المقاييس تشغل مساحة كبيرة
- يعد إعداد لوحات المعلومات بالمقاييس في كيبان أكثر تعقيدًا بكثير مما هو عليه في جرافان
بشكل عام، المقاييس في ELK ثقيلة وليست مريحة بعد كما هو الحال في الحلول الأخرى، والتي يوجد منها الآن أكثر بكثير من مجرد بروميثيوس: TSDB، وVictoria Metrics، وCortex، وما إلى ذلك، وما إلى ذلك. بالطبع، أود حقًا الحصول على حل متكامل وشامل على الفور، ولكن في حالة metricbeat، كان هناك الكثير من التنازلات.
ومكدس ELK نفسه لديه عدد من اللحظات الصعبة:
- إنه ثقيل، وأحيانا ثقيل للغاية إذا قمت بجمع كمية كبيرة إلى حد ما من البيانات
- أنت بحاجة إلى "معرفة كيفية طهيه" - تحتاج إلى توسيع نطاقه، لكن هذا ليس بالأمر الهين
- نسخة مجانية مجردة - لا تحتوي النسخة المجانية على تنبيه عادي، وفي وقت الاختيار لم تكن هناك مصادقة
يجب أن أقول إن النقطة الأخيرة أصبحت مؤخرًا أفضل بالإضافة إلى ذلك (بما في ذلك المصادقة) بدأ نموذج التسعير نفسه في التغير.
ولكن في الوقت الذي كنا نخطط فيه لنشر هذا الحل، لم يكن هناك تنبيه على الإطلاق.
ربما كان بإمكاننا أن نحاول بناء شيء ما باستخدام ElastAlert أو حلول مجتمعية أخرى، لكننا قررنا النظر في بدائل أخرى.
لوكي - جرافانا - بروميثيوس
في الوقت الحالي، قد يكون الحل الجيد هو بناء مكدس مراقبة يعتمد فقط على Prometheus كموفر للمقاييس، وLoki للسجلات، وللتصور يمكنك استخدام نفس Grafana.
لسوء الحظ، في وقت بدء الإصدار التجريبي للمبيعات للمشروع (سبتمبر-أكتوبر 19)، كان Loki لا يزال في الإصدار التجريبي 0.3-0.4، وفي وقت بدء التطوير لا يمكن اعتباره حلاً إنتاجيًا على الاطلاق.
ليس لدي خبرة حتى الآن في استخدام Loki فعليًا في المشاريع الجادة، لكن يمكنني القول أن Promtail (وكيل جمع السجلات) يعمل بشكل رائع لكل من المعدن العاري والقرون في kubernetes.
TICK
ربما لا يمكن الآن تسمية البديل الكامل المميز (الوحيد؟) لمكدس ELK إلا بمكدس TICK - Telegraf، InfluxDB، Chronograf، Kapacitor.
سأصف جميع المكونات أدناه بمزيد من التفصيل، ولكن الفكرة العامة هي كما يلي:
- Telegraf - وكيل لجمع المقاييس
- InfluxDB - قاعدة بيانات المقاييس
- Kapacitor - معالج مقاييس في الوقت الحقيقي للتنبيه
- Chronograf - لوحة ويب للتصور
بالنسبة إلى InfluxDB وKapacitor وChronograf، توجد مخططات قيادة رسمية استخدمناها لنشرها.
تجدر الإشارة إلى أنه في الإصدار الأخير من Influx 2.0 (بيتا)، أصبح Kapacitor وChronograf جزءًا من InfluxDB ولم يعدا موجودين بشكل منفصل
برقية
هو وكيل خفيف الوزن جدًا لجمع المقاييس على جهاز الحالة.
يمكنه مراقبة كمية هائلة من كل شيء، من إلى
الخادم .
لديها عدد من المزايا الرائعة:
- سريع وخفيف الوزن (مكتوب بلغة Go)
- يأكل الحد الأدنى من الموارد
- دفع المقاييس بشكل افتراضي
- يجمع كل المقاييس اللازمة
- مقاييس النظام دون أي إعدادات
- مقاييس الأجهزة مثل المعلومات الواردة من أجهزة الاستشعار
- من السهل جدًا إضافة المقاييس الخاصة بك
- الكثير من المكونات الإضافية خارج الصندوق
- يجمع السجلات
نظرًا لأن مقاييس الدفع كانت ضرورية بالنسبة لنا، كانت جميع المزايا الأخرى أكثر من مجرد إضافات ممتعة.
يعد تجميع السجلات بواسطة الوكيل نفسه أمرًا مريحًا للغاية أيضًا، نظرًا لعدم الحاجة إلى توصيل أدوات مساعدة إضافية لسجلات التسجيل.
يقدم Influx التجربة الأكثر ملاءمة للعمل مع السجلات إذا كنت تستخدمها .
يعد Telegraf بشكل عام وكيلًا رائعًا لجمع المقاييس، حتى إذا كنت لا تستخدم بقية حزمة ICK.
يتقاطعها العديد من الأشخاص مع ELK والعديد من قواعد بيانات السلاسل الزمنية الأخرى من أجل الراحة، حيث يمكنها كتابة المقاييس في أي مكان تقريبًا.
التدفق
InfluxDB هو النواة الرئيسية لمكدس TICK، أي قاعدة بيانات السلاسل الزمنية للمقاييس.
بالإضافة إلى المقاييس، يمكن لـ Influx أيضًا تخزين السجلات، على الرغم من أن السجلات الخاصة بها هي في الأساس نفس المقاييس، فقط بدلاً من المؤشرات الرقمية المعتادة، يتم تنفيذ الوظيفة الرئيسية من خلال سطر من نص السجل.
تمت كتابة InfluxDB أيضًا بلغة Go ويبدو أنه يعمل بشكل أسرع بكثير مقارنة بـ ELK في مجموعتنا (وليست الأقوى).
إحدى المزايا الرائعة لـ Influx ستتضمن أيضًا واجهة برمجة تطبيقات مريحة وغنية جدًا لاستعلامات البيانات، والتي استخدمناها بنشاط كبير.
العيوب - $$$ أو التحجيم؟
مكدس TICK له عيب واحد فقط اكتشفناه - وهو عزيز. أكثر من ذلك.
ما الذي تحتويه النسخة المدفوعة ولا تحتوي عليه النسخة المجانية؟
بقدر ما تمكنا من فهمه، فإن الاختلاف الوحيد بين الإصدار المدفوع من TICK Stack والإصدار المجاني هو إمكانيات التوسع.
وهي أنه يمكنك رفع مجموعة ذات توفر عالي فقط في .
إذا كنت ترغب في الحصول على HA كامل، فستحتاج إما إلى الدفع أو استخدام بعض العكازات. هناك بضعة حلول مجتمعية - على سبيل المثال يبدو وكأنه حل مختص، ولكن مكتوب أنه غير مناسب للإنتاج، وكذلك
- حل بسيط يتمثل في ضخ البيانات من خلال NATS (سيتعين أيضًا توسيع نطاقه، ولكن يمكن حل هذه المشكلة).
إنه أمر مؤسف، ولكن يبدو أن كلاهما قد تم التخلي عنهما - لا توجد التزامات جديدة، وأفترض أن المشكلة تكمن في الإصدار الجديد المتوقع قريبًا من الإصدار الجديد من Influx 2.0، والذي ستكون فيه أشياء كثيرة مختلفة (لا توجد معلومات حول التحجيم فيه حتى الآن).
رسميا هناك نسخة مجانية - في الواقع، هذا HA بدائي، ولكن فقط من خلال التوازن،
حيث سيتم كتابة جميع البيانات إلى جميع مثيلات InfluxDB خلف موازن التحميل.
لديه بعض مثل المشكلات المحتملة المتعلقة باستبدال النقاط والحاجة إلى إنشاء قواعد للمقاييس مسبقًا
(والذي يحدث تلقائيًا أثناء العمل العادي مع InfluxDB).
بالإضافة إلى ذلك ، وهذا يعني حملًا إضافيًا للمقاييس المكررة (كل من المعالجة والتخزين) التي قد لا تحتاج إليها، ولكن لا توجد طريقة للفصل بينهما.
فيكتوريا متريكس؟
ونتيجة لذلك، على الرغم من أننا راضون تمامًا عن مكدس TICK في كل شيء بخلاف القياس المدفوع، فقد قررنا معرفة ما إذا كانت هناك أي حلول مجانية يمكن أن تحل محل قاعدة بيانات InfluxDB، مع ترك مكونات T_CK المتبقية.
هناك الكثير من قواعد بيانات السلاسل الزمنية، ولكن أكثرها واعدة هي Victoria Metrics، فهي تتمتع بعدد من المزايا:
- سريع وسهل، على الأقل وفقا للنتائج
- هناك نسخة عنقودية، والتي توجد بها مراجعات جيدة الآن
- يمكنها أن تقشر
- يدعم بروتوكول InfluxDB
لم نكن ننوي إنشاء مكدس مخصص تمامًا استنادًا إلى Victoria وكان الأمل الرئيسي هو أن نتمكن من استخدامه كبديل مباشر لـ InfluxDB.
لسوء الحظ، هذا غير ممكن، على الرغم من أن بروتوكول InfluxDB مدعوم، فهو يعمل فقط لتسجيل المقاييس - فقط واجهة برمجة تطبيقات Prometheus متاحة "في الخارج"، مما يعني أنه لن يكون من الممكن ضبط Chronograf عليها.
علاوة على ذلك، يتم دعم القيم الرقمية فقط للمقاييس (استخدمنا قيم السلسلة للمقاييس المخصصة - المزيد عن ذلك في القسم ).
من الواضح، لنفس السبب، أن الجهاز الافتراضي لا يمكنه تخزين السجلات كما يفعل Influx.
وتجدر الإشارة أيضًا إلى أنه في وقت البحث عن الحل الأمثل، لم تكن شركة Victoria Metrics تحظى بشعبية كبيرة بعد، وكانت الوثائق أصغر بكثير وكانت الوظيفة أضعف
(لا أتذكر وصفًا تفصيليًا لإصدار المجموعة والتقسيم).
اختيار القاعدة
نتيجة لذلك، تقرر أنه بالنسبة للإصدار التجريبي، سنظل مقتصرين على عقدة InfluxDB واحدة.
وكانت هناك عدة أسباب رئيسية لهذا الاختيار:
- لقد أحببنا حقًا الوظيفة الكاملة لمكدس TICK
- لقد تمكنا بالفعل من نشره وعمل بشكل رائع
- كانت المواعيد النهائية تنفد ولم يتبق الكثير من الوقت لاختبار الخيارات الأخرى.
- لم نتوقع مثل هذا الحمل الثقيل
لم يكن لدينا العديد من الدراجات البخارية في المرحلة الأولى من الإصدار التجريبي، ولم يكشف الاختبار أثناء التطوير عن أي مشكلات في الأداء.
لذلك، قررنا أن عقدة Influx واحدة لهذا المشروع ستكون كافية بالنسبة لنا دون الحاجة إلى القياس (انظر الاستنتاجات في النهاية).
لقد قررنا ما يتعلق بالمكدس والقاعدة، والآن فيما يتعلق بالمكونات المتبقية من مكدس TICK.
مكثف
يعد Kapacitor جزءًا من TICK Stack، وهي خدمة يمكنها مراقبة المقاييس التي تدخل قاعدة البيانات في الوقت الفعلي وتنفيذ إجراءات مختلفة بناءً على القواعد.
بشكل عام، يتم وضعه كأداة لتتبع الشذوذ المحتمل والتعلم الآلي (لست متأكدًا من أن هذه الوظائف مطلوبة)، ولكن الحالة الأكثر شيوعًا لاستخدامه هي الأكثر شيوعًا - التنبيه.
هذه هي الطريقة التي استخدمناها للإخطارات. لقد قمنا بإعداد تنبيهات Slack عندما ينقطع اتصال سكوتر معين بالإنترنت، وتم فعل الشيء نفسه بالنسبة لأجهزة الشحن الذكية ومكونات البنية التحتية المهمة.
وقد جعل هذا من الممكن الاستجابة السريعة للمشاكل، وكذلك تلقي الإخطارات التي تفيد بأن كل شيء عاد إلى طبيعته.
مثال بسيط: تعطلت بطارية إضافية لتشغيل "الصندوق" الخاص بنا أو نفدت الطاقة لسبب ما؛ ببساطة عن طريق تركيب بطارية جديدة، بعد فترة من الوقت يجب أن نتلقى إشعارًا باستعادة وظائف السكوتر.
في Influx 2.0، أصبح المكثف جزءًا من قاعدة البيانات
كرونوجراف
لقد رأيت العديد من حلول واجهة المستخدم المختلفة للمراقبة، لكن يمكنني القول أنه من حيث الوظائف وتجربة المستخدم، لا شيء يقارن بـ Chronograf.
لقد بدأنا باستخدام TICK Stack، بشكل غريب، مع Grafan كواجهة ويب.
لن أصف وظيفتها، فالجميع يعرف إمكانياتها الواسعة لإعداد أي شيء.
ومع ذلك، لا تزال Grafana أداة عالمية تمامًا، في حين أن Chronograf مصمم بشكل أساسي للاستخدام مع Influx.
وبالطبع، بفضل هذا، يمكن لـ Chronograf توفير وظائف أكثر ذكاءً أو ملاءمة.
ربما تكون الميزة الرئيسية للعمل مع Chronograf هي أنه يمكنك عرض الأجزاء الداخلية لـ InfluxDB من خلال Explore.
يبدو أن Grafana لديها وظائف متطابقة تقريبًا، ولكن في الواقع، يمكن إعداد لوحة معلومات في Chronograf ببضع نقرات بالماوس (وفي نفس الوقت النظر إلى التصور هناك)، بينما في Grafana ستظل عاجلاً أم آجلاً لديك لتحرير تكوين JSON (بالطبع يسمح Chronograf بتحميل Dashas التي تم تكوينها يدويًا وتحريرها بتنسيق JSON إذا لزم الأمر - ولكن لم أضطر أبدًا إلى لمسها بعد إنشائها على واجهة المستخدم).
تتمتع Kibana بقدرات أكثر ثراءً لإنشاء لوحات المعلومات وعناصر التحكم لها، لكن تجربة المستخدم لمثل هذه العمليات معقدة للغاية.
سوف يستغرق الأمر بعض الفهم الجيد لإنشاء لوحة تحكم مريحة. وعلى الرغم من أن وظائف لوحات معلومات Chronograf أقل، إلا أن صنعها وتخصيصها يعد أسهل بكثير.
لوحات المعلومات نفسها، بصرف النظر عن النمط المرئي اللطيف، لا تختلف في الواقع عن لوحات المعلومات في Grafana أو Kibana:
وهذا ما تبدو عليه نافذة الاستعلام:
من المهم أن نلاحظ، من بين أمور أخرى، أن معرفة أنواع الحقول في قاعدة بيانات InfluxDB، يمكن أن يساعدك الكرونوغراف نفسه أحيانًا تلقائيًا في كتابة استعلام أو اختيار وظيفة التجميع الصحيحة مثل المتوسط.
وبطبيعة الحال، يعد Chronograf مناسبًا قدر الإمكان لعرض السجلات. تبدو هكذا:
بشكل افتراضي، يتم تصميم سجلات Influx لاستخدام سجل النظام، وبالتالي فهي تحتوي على معلمة مهمة - الخطورة.
يعد الرسم البياني في الأعلى مفيدًا بشكل خاص، حيث يمكنك من خلاله رؤية الأخطاء التي تحدث ويظهر اللون بوضوح على الفور ما إذا كانت الخطورة أعلى.
اكتشفنا أخطاء مهمة بهذه الطريقة عدة مرات، فذهبنا لعرض السجلات للأسبوع الماضي وشاهدنا ارتفاعًا أحمر.
بالطبع، سيكون من الأفضل إعداد تنبيهات لمثل هذه الأخطاء، حيث أن لدينا بالفعل كل شيء لهذا الغرض.
لقد قمنا بتشغيل هذا لفترة من الوقت، ولكن أثناء إعداد البرنامج التجريبي، اتضح أننا حصلنا على الكثير من الأخطاء (بما في ذلك أخطاء النظام مثل عدم توفر شبكة LTE)، والتي "أرسلت بريدًا عشوائيًا" إلى قناة Slack أيضًا كثيرا، دون أن يسبب أي مشاكل.فائدة عظيمة.
سيكون الحل الصحيح هو التعامل مع معظم هذه الأنواع من الأخطاء، وضبط مدى خطورتها، وبعد ذلك فقط تمكين التنبيه.
بهذه الطريقة، سيتم نشر الأخطاء الجديدة أو المهمة فقط في Slack. ببساطة، لم يكن هناك ما يكفي من الوقت لمثل هذا الإعداد نظراً للمواعيد النهائية الضيقة.
المصادقة
ومن الجدير بالذكر أيضًا أن Chronograf يدعم OAuth وOIDC كمصادقة.
يعد هذا أمرًا مريحًا للغاية، لأنه يسمح لك بإرفاقه بسهولة بالخادم الخاص بك وإنشاء تسجيل دخول موحّد (SSO) كامل.
في حالتنا، كان الخادم - تم استخدامه للاتصال بالمراقبة، ولكن تم استخدام نفس الخادم أيضًا لمصادقة الدراجات البخارية والطلبات إلى الواجهة الخلفية.
"مسؤل"
العنصر الأخير الذي سأصفه هو "لوحة الإدارة" المكتوبة ذاتيًا في Vue.
إنها في الأساس مجرد خدمة مستقلة تعرض معلومات السكوتر من قواعد البيانات والخدمات الصغيرة وبيانات المقاييس الخاصة بنا من InfluxDB في وقت واحد.
بالإضافة إلى ذلك، تم نقل العديد من الوظائف الإدارية إلى هناك، مثل إعادة التشغيل في حالات الطوارئ أو فتح قفل لفريق الدعم عن بعد.
وكانت هناك أيضًا خرائط. لقد ذكرت بالفعل أننا بدأنا باستخدام Grafana بدلاً من Chronograf - لأن خرائط Grafana متاحة في شكل مكونات إضافية، حيث يمكننا عرض إحداثيات الدراجات البخارية. لسوء الحظ، فإن إمكانيات عناصر واجهة المستخدم للخرائط في Grafana محدودة للغاية، ونتيجة لذلك، كان من الأسهل بكثير كتابة تطبيق الويب الخاص بك باستخدام الخرائط في غضون أيام قليلة، ليس فقط لرؤية الإحداثيات في الوقت الحالي، ولكن أيضًا لعرضها المسار الذي يسلكه السكوتر، نكون قادرين على تصفية البيانات الموجودة على الخريطة، وما إلى ذلك (كل تلك الوظائف التي لم نتمكن من تكوينها في لوحة معلومات بسيطة).
إحدى مزايا Influx المذكورة بالفعل هي القدرة على إنشاء المقاييس الخاصة بك بسهولة.
وهذا يسمح باستخدامه لمجموعة كبيرة ومتنوعة من السيناريوهات.
لقد حاولنا تسجيل جميع المعلومات المفيدة هناك: شحن البطارية، وحالة القفل، وأداء المستشعر، والبلوتوث، ونظام تحديد المواقع العالمي (GPS)، والعديد من الفحوصات الصحية الأخرى.
لقد عرضنا كل هذا على لوحة الإدارة.
بالطبع، كان المعيار الأكثر أهمية بالنسبة لنا هو حالة تشغيل السكوتر - في الواقع، يتحقق Influx من ذلك بنفسه ويظهره بـ "أضواء خضراء" في قسم العقد.
ويتم ذلك عن طريق الوظيفة - استخدمناها لفهم أداء صندوقنا وإرسال نفس التنبيهات إلى Slack.
بالمناسبة، قمنا بتسمية الدراجات البخارية بأسماء شخصيات من عائلة سمبسون - كان من السهل جدًا تمييزها عن بعضها البعض
وبشكل عام كان الأمر أكثر متعة بهذه الطريقة. وكانت عبارات مثل "يا شباب، سميثرز قد مات!" تُسمع باستمرار.
مقاييس السلسلة
من المهم أن InfluxDB يسمح لك بتخزين ليس فقط القيم الرقمية، كما هو الحال مع Victoria Metrics.
يبدو أن هذا ليس مهمًا جدًا - فبعد كل شيء، باستثناء السجلات، يمكن تخزين أي مقاييس في شكل أرقام (فقط أضف تعيينًا للحالات المعروفة - وهو نوع من التعداد)؟
في حالتنا، كان هناك سيناريو واحد على الأقل حيث كانت مقاييس السلسلة مفيدة جدًا.
لقد حدث أن مورد "أجهزة الشحن الذكية" الخاصة بنا كان طرفًا ثالثًا، ولم يكن لدينا أي سيطرة على عملية التطوير والمعلومات التي يمكن أن توفرها أجهزة الشحن هذه.
ونتيجة لذلك، كانت واجهة برمجة التطبيقات الخاصة بالشحن بعيدة كل البعد عن المثالية، ولكن المشكلة الرئيسية كانت أننا لم نتمكن دائمًا من فهم حالتها.
هذا هو المكان الذي جاء فيه Influx للإنقاذ. لقد كتبنا ببساطة حالة السلسلة التي وصلت إلينا في حقل قاعدة بيانات InfluxDB دون تغييرات.
لبعض الوقت، وصلت قيم مثل "متصل" و"غير متصل" فقط، وبناءً على المعلومات التي تم عرضها في لوحة الإدارة الخاصة بنا، وتم إرسال الإشعارات إلى Slack. ومع ذلك، في مرحلة ما، بدأت تظهر أيضًا قيم مثل "غير متصل".
كما اتضح لاحقًا، تم إرسال هذه الحالة مرة واحدة بعد فقدان الاتصال، إذا لم يتمكن الشاحن من إنشاء اتصال بالخادم بعد عدد معين من المحاولات.
وبالتالي، إذا استخدمنا فقط مجموعة ثابتة من القيم، فقد لا نرى هذه التغييرات في البرامج الثابتة في الوقت المناسب.
وبشكل عام، توفر مقاييس السلسلة إمكانيات أكثر بكثير للاستخدام، حيث يمكنك تسجيل أي معلومات فيها تقريبًا. على الرغم من أنك تحتاج بالطبع إلى استخدام هذه الأداة بعناية.
بالإضافة إلى المقاييس المعتادة، قمنا أيضًا بتسجيل معلومات موقع GPS في InfluxDB. كان هذا مفيدًا بشكل لا يصدق لمراقبة موقع الدراجات البخارية في لوحة الإدارة الخاصة بنا.
في الواقع، كنا نعرف دائمًا أين وأي سكوتر كان في الوقت الذي نحتاجه.
كان هذا مفيدًا جدًا لنا عندما كنا نبحث عن دراجة نارية (انظر الاستنتاجات في النهاية).
مراقبة البنية التحتية
بالإضافة إلى الدراجات البخارية نفسها، كنا بحاجة أيضًا إلى مراقبة بنيتنا التحتية بالكامل (الواسعة إلى حد ما).
تبدو الهندسة المعمارية العامة جدًا كما يلي:
إذا سلطنا الضوء على مكدس مراقبة خالص، فسيبدو كما يلي:
ما نود التحقق منه في السحابة هو:
- قواعد البيانات
- كيلوك
- الخدمات المصغرة
نظرا لأن جميع خدماتنا السحابية موجودة في Kubernetes، فسيكون من الجيد جمع معلومات حول حالتها.
لحسن الحظ، يمكن لـ Telegraf خارج الصندوق جمع عدد كبير من المقاييس حول حالة مجموعة Kubernetes، ويقدم Chronograf على الفور لوحات معلومات جميلة لهذا الغرض.
قمنا بشكل أساسي بمراقبة أداء القرون واستهلاك الذاكرة. في حالة السقوط، تنبيهات في سلاك.
هناك طريقتان لتتبع البودات في Kubernetes: DaemonSet وSidecar.
يتم وصف كلتا الطريقتين بالتفصيل .
استخدمنا Telegraf Sidecar، بالإضافة إلى المقاييس، قمنا بجمع سجلات البودات.
في حالتنا، كان علينا العبث بالسجلات. على الرغم من أن Telegraf يمكنه سحب السجلات من Docker API، فقد أردنا أن يكون لدينا مجموعة موحدة من السجلات مع أجهزتنا النهائية وسجل نظام مهيأ للحاويات لهذا الغرض. ربما لم يكن هذا الحل جميلاً، لكن لم تكن هناك شكاوى حول عمله وتم عرض السجلات بشكل جيد في Chronograf.
رصد المراقبة؟؟؟
في النهاية، نشأ السؤال القديم حول مراقبة أنظمة المراقبة، ولكن لحسن الحظ، أو لسوء الحظ، لم يكن لدينا ما يكفي من الوقت لذلك.
على الرغم من أن Telegraf يمكنها بسهولة إرسال مقاييسها الخاصة أو جمع المقاييس من قاعدة بيانات InfluxDB لإرسالها إما إلى نفس Influx أو إلى مكان آخر.
النتائج
ما هي الاستنتاجات التي استخلصناها من نتائج التجربة؟
كيف يمكنك أن تفعل الرصد؟
بادئ ذي بدء، حققت مجموعة TICK توقعاتنا بالكامل وأعطتنا فرصًا أكثر مما توقعنا في البداية.
جميع الوظائف التي نحتاجها كانت موجودة. كل ما فعلناه به نجح دون مشاكل.
أداء
المشكلة الرئيسية في مكدس TICK في الإصدار المجاني هي الافتقار إلى إمكانيات التوسع. لم تكن هذه مشكلة بالنسبة لنا.
لم نجمع بيانات/أرقام الحمولة الدقيقة، ولكننا جمعنا بيانات من حوالي 30 دراجة نارية في المرة الواحدة.
جمع كل واحد منهم أكثر من ثلاثين مقياسًا. وفي الوقت نفسه، تم جمع السجلات من الأجهزة. تم جمع البيانات وإرسالها كل 10 ثوانٍ.
ومن المهم أن نلاحظ أنه بعد أسبوع ونصف من التجربة، عندما تم تصحيح الجزء الأكبر من "تقرحات الطفولة" وتم بالفعل حل المشاكل الأكثر أهمية، كان علينا تقليل وتيرة إرسال البيانات إلى الخادم إلى 30 ثانية. أصبح هذا ضروريًا لأن حركة المرور على بطاقات LTE SIM الخاصة بنا بدأت تختفي بسرعة.
تم استهلاك الجزء الأكبر من حركة المرور بواسطة السجلات، ولم تهدر المقاييس نفسها عمليًا، حتى مع وجود فاصل زمني مدته 10 ثوانٍ.
نتيجة لذلك، بعد مرور بعض الوقت، قمنا بتعطيل مجموعة السجلات على الأجهزة بالكامل، حيث كانت المشكلات المحددة واضحة بالفعل حتى بدون التجميع المستمر.
في بعض الحالات، إذا كان عرض السجلات لا يزال ضروريًا، فقد قمنا ببساطة بالاتصال عبر WireGuard عبر VPN.
سأضيف أيضًا أن كل بيئة منفصلة تم فصلها عن بعضها البعض، وأن الحمل الموصوف أعلاه كان مناسبًا فقط لبيئة الإنتاج.
في بيئة التطوير، قمنا بطرح مثيل InfluxDB منفصل استمر في جمع البيانات كل 10 ثوانٍ ولم نواجه أية مشكلات في الأداء.
TICK - مثالي للمشروعات الصغيرة والمتوسطة
بناءً على هذه المعلومات، أود أن أستنتج أن حزمة TICK مثالية للمشاريع الصغيرة نسبيًا أو المشاريع التي لا تتوقع بالتأكيد أي حمل مرتفع.
إذا لم يكن لديك الآلاف من القرون أو مئات الأجهزة، فحتى مثيل InfluxDB واحد سيتعامل مع الحمل بشكل جيد.
في بعض الحالات، قد تكون راضيًا عن Influx Relay كحل بدائي عالي التوفر.
وبالطبع، لا أحد يمنعك من إعداد القياس "الرأسي" وتخصيص خوادم مختلفة لأنواع مختلفة من المقاييس.
إذا لم تكن متأكدًا من الحمل المتوقع على خدمات المراقبة، أو كنت مضمونًا أن لديك/سيكون لديك بنية "ثقيلة" للغاية، فلا أوصي باستخدام الإصدار المجاني من TICK Stack.
وبطبيعة الحال، سيكون الحل البسيط هو الشراء - ولكن هنا لا أستطيع التعليق بطريقة أو بأخرى، لأنني نفسي لست على دراية بالخفايا. بالإضافة إلى أنها باهظة الثمن وبالتأكيد غير مناسبة للشركات الصغيرة.
في هذه الحالة، اليوم، أوصي بالتطلع إلى جمع المقاييس من خلال Victoria Metrics والسجلات باستخدام Loki.
صحيح، سأحجز مرة أخرى أن Loki/Grafana أقل ملاءمة بكثير (نظرًا لتعدد استخداماتها) من TICK الجاهزة، لكنها مجانية.
من المهم: جميع المعلومات الموضحة هنا ذات صلة بالإصدار Influx 1.8، في الوقت الحالي، Influx 2.0 على وشك الإصدار.
على الرغم من أنه لم تتح لي الفرصة لتجربته في ظروف القتال ومن الصعب استخلاص استنتاجات حول التحسينات، فقد أصبحت الواجهة بالتأكيد أفضل، وتم تبسيط البنية (بدون مكثف وكرونوغراف)،
ظهرت القوالب ("الميزة القاتلة" - ). ولكن، لسوء الحظ، في الوقت الحالي، لا يحتوي الإصدار 2 على الشيء الرئيسي الذي اخترنا الإصدار الأول من أجله - لا توجد مجموعة سجلات.
ستظهر هذه الوظيفة أيضًا في Influx 2.0، لكن لم نتمكن من العثور على أي مواعيد نهائية، حتى تلك التقريبية.
كيف لا تصنع منصات إنترنت الأشياء (الآن)
في النهاية، بعد إطلاق البرنامج التجريبي، قمنا بأنفسنا بتجميع حزمة إنترنت الأشياء الكاملة الخاصة بنا، في ظل عدم وجود بديل مناسب وفقًا لمعاييرنا.
ومع ذلك، فقد أصبح متوفرًا مؤخرًا في الإصدار التجريبي - من المؤسف أنها لم تكن هناك عندما بدأنا في تنفيذ المشروع.
نحن راضون تمامًا عن النتيجة النهائية والمنصة القائمة على Ansible + TICK + WireGuard التي قمنا بتجميعها بأنفسنا. لكن اليوم، أوصي بإلقاء نظرة فاحصة على Balena قبل محاولة بناء منصة إنترنت الأشياء الخاصة بك بنفسك.
لأنه في نهاية المطاف يمكنه أن يفعل معظم ما فعلناه، وOpenBalena مجاني ومفتوح المصدر.
إنها تعرف بالفعل كيفية إرسال التحديثات ليس فقط، بل أيضًا شبكة VPN مدمجة بالفعل ومصممة للاستخدام في بيئة إنترنت الأشياء.
ومؤخرًا فقط، أطلقوا سراحهم ، والتي تتصل بسهولة بنظامها البيئي.
مهلا، ماذا عن السكوتر المفقود؟
فاختفى السكوتر "رالف" دون أن يترك أثرا.
ركضنا على الفور لإلقاء نظرة على الخريطة في "لوحة الإدارة" الخاصة بنا، مع بيانات مقاييس نظام تحديد المواقع العالمي (GPS) من InfluxDB.
بفضل بيانات المراقبة، تمكنا بسهولة من تحديد أن السكوتر غادر ساحة انتظار السيارات حوالي الساعة 21:00 في اليوم الماضي، وسافر لمدة نصف ساعة تقريبًا إلى بعض المناطق وظل متوقفًا حتى الساعة 5 صباحًا بجوار بعض المنازل الألمانية.
بعد الساعة 5 صباحًا، لم يتم تلقي أي بيانات مراقبة - وهذا يعني إما أن البطارية الإضافية قد تم تفريغها بالكامل، أو اكتشف المهاجم أخيرًا كيفية إزالة الأجهزة الذكية من السكوتر.
وعلى الرغم من ذلك، تم استدعاء الشرطة إلى العنوان الذي يوجد به السكوتر. السكوتر لم يكن هناك.
ومع ذلك، تفاجأ صاحب المنزل أيضًا بهذا، حيث أنه ركب هذا السكوتر إلى المنزل من المكتب الليلة الماضية.
وكما تبين، فقد وصل أحد موظفي الدعم في الصباح الباكر والتقط السكوتر، ورأى أن بطاريته الإضافية قد فرغت بالكامل وأخذها (سيراً على الأقدام) إلى موقف السيارات. وفشلت البطارية الإضافية بسبب الرطوبة.
لقد سرقنا السكوتر من أنفسنا. بالمناسبة، لا أعرف كيف ومن قام بحل المشكلة مع قضية الشرطة، لكن المراقبة عملت بشكل مثالي...
المصدر: www.habr.com