ورک شوی سکوټر بیرته راستانه کړئ ، یا د IoT څارنې کیسه

یو کال دمخه موږ د یوې پروموشنل پروژې پیلوټ نسخه پیل کړه د بریښنایی سکوټرونو غیر متمرکز کرایه.

په پیل کې، دا پروژه د بارسلونا څخه د سړک په نوم یادیږي، وروسته دا د برلین څخه سړک (له همدې امله R2B په سکرین شاټونو کې) شو، او په پای کې دا د xRide په نوم یاد شو.

د پروژې اصلي نظر دا و: د دې پرځای چې د مرکزي موټر یا سکوټر کرایه کولو خدمت ولرئ (موږ د سکوټرونو په اړه خبرې کوو چې بریښنایی موټرسایکلونه ، نه کیک سکوټر/سکوټرونه) موږ غوښتل د غیر متمرکز کرایې لپاره پلیټ فارم جوړ کړو. د هغه ستونزو په اړه چې موږ ورسره مخ شوي یو لا دمخه لیکلي دي.

په پیل کې، پروژه په موټرو متمرکزه وه، مګر د وخت نیټې، د تولید کونکو سره خورا اوږد اړیکو او د خوندیتوب محدودیتونو له امله، بریښنایی سکوټرونه د پیلوټ لپاره غوره شوي.

کارونکي په تلیفون کې د iOS یا Android اپلیکیشن نصب کړ، هغه سکوټر ته یې نږدې کړ چې د هغه خوښوي، وروسته له هغه چې تلیفون او سکوټر د پییر-ټو پییر اړیکه رامینځته کړه، ETH تبادله شو او کاروونکي کولی شي د سکوټر په بدلولو سره سفر پیل کړي. تلیفون د سفر په پای کې ، دا هم ممکنه وه چې په تلیفون کې د کارونکي بټوې څخه د ایتیریم په کارولو سره د سفر لپاره تادیه وکړئ.

د سکوټرونو سربیره، کاروونکي په اپلیکیشن کې "سمارټ چارجرونه" لیدلي، چې په لیدلو سره کاروونکي کولی شي اوسنی بیټرۍ پخپله بدل کړي که چیرې دا ټیټه وي.

دا عموما هغه څه دي چې زموږ پیلوټ ورته ښکاري، د تیر کال په سپټمبر کې د آلمان په دوو ښارونو کې پیل شوي: بون او برلین.

او بیا، یوه ورځ، په بون کې، سهار وختي، زموږ د ملاتړ ټیم (په کاري ترتیب کې د سکوټرونو ساتلو لپاره په سایټ کې موقعیت لري) خبرداری ورکړ: یو له سکوټرونو څخه پرته ورک شوی و.

څنګه یې پیدا کړو او بیرته یې راوګرځوو؟

پدې مقاله کې به زه د دې په اړه وغږیږم، مګر لومړی - د دې په اړه چې موږ څنګه خپل IoT پلیټ فارم جوړ کړ او څنګه یې څارنه وکړه.

څه او ولې څارنه وکړئ: سکوټرونه، زیربناوې، د چارج سټیشنونه؟

نو، موږ څه غوښتل چې زموږ په پروژه کې څارنه وکړو؟

له هرڅه دمخه ، دا پخپله سکوټرونه دي - بریښنایی سکوټرونه پخپله خورا ګران دي ، تاسو نشئ کولی دا ډول پروژه په کافي اندازه چمتو کولو پرته پیل کړئ؛ که امکان ولري ، تاسو غواړئ د سکوټرونو په اړه د امکان تر حده ډیر معلومات راټول کړئ: د دوی موقعیت ، د چارج کچه , etc.

برسېره پردې، زه غواړم زموږ د خپل معلوماتي ټیکنالوژۍ زیربنا حالت وڅیړم - ډیټابیسونه، خدمات او هرڅه چې دوی کار کولو ته اړتیا لري. دا هم اړینه وه چې د "سمارټ چارجرونو" وضعیت وڅیړئ، په هغه صورت کې چې دوی مات شوي یا بشپړ بیټرۍ پای ته رسیدلي.

سکوټر

زموږ سکوټرونه څه وو او موږ څه غوښتل د دوی په اړه پوه شو؟

لومړی او خورا مهم شی د GPS همغږي دي ، ځکه چې د دوی څخه مننه موږ پوهیږو چې دوی چیرې دي او چیرې حرکت کوي.

بل د بیټرۍ چارج دی ، له دې څخه مننه چې موږ کولی شو معلومه کړو چې د سکوټرونو چارج پای ته رسیدلی او یو جوسر واستوو یا لږترلږه کارونکي ته خبرداری ورکړو.

البته، دا هم اړینه ده چې وګورئ چې زموږ د هارډویر اجزاو سره څه پیښیږي:

• بلوتوث کار کوي؟
• ایا د GPS ماډل پخپله کار کوي؟
  • موږ د دې حقیقت سره هم ستونزه درلوده چې GPS کولی شي غلط همغږي واستوي او ودریږي، او دا یوازې په سکوټر کې د اضافي چکونو لخوا ټاکل کیدی شي،
    او د مسلې د حل لپاره ژر تر ژره ملاتړ ته خبر ورکړئ

او په نهایت کې: د سافټویر چیکونه ، د OS او پروسیسر سره پیل کیږي ، د شبکې او ډیسک بار سره ، زموږ د خپلو ماډلونو چیکونو سره پای ته رسیږي چې زموږ لپاره خورا مشخص دي (جولوکوم, کلیکل).

هډوتري

زموږ د "اوسپنې" برخه څه وه؟

د لنډ ممکن وخت چوکاټ او د ګړندي پروټوټایپ اړتیا په پام کې نیولو سره ، موږ د اجزاو پلي کولو او انتخاب لپاره ترټولو اسانه انتخاب غوره کړ - Raspberry Pi.
د Rpi پخپله سربیره ، موږ یو دودیز بورډ درلود (کوم چې موږ پخپله رامینځته کړی او له چین څخه یې امر کړی ترڅو د وروستي حل د مجلس پروسې ګړندي کړي) او د اجزاو سیټ - یو ریلی (د سکوټر فعالولو / بندولو لپاره) ، د بیټرۍ چارج ریډر، موډیم، انتن. دا ټول په ځانګړي ډول په ځانګړي "xRide بکس" کې بسته شوي.

دا هم باید په یاد ولرئ چې ټول بکس د اضافي بریښنا بانک لخوا ځواکمن شوی و، چې په پایله کې د سکوټر اصلي بیټرۍ لخوا ځواکمن شوی و.

دې د دې امکان رامینځته کړ چې نظارت وکاروئ او حتی د سفر پای ته رسیدو وروسته سکوټر چالان کړئ ، ځکه چې اصلي بیټرۍ د "بند" موقعیت ته د ایګیشن کیلي بدلولو وروسته سمدلاسه وتړل شوه.

ډاکر؟ ساده لینوکس؟ او ګمارل

راځئ چې نظارت ته راستون شو، نو راسبیري - موږ څه لرو؟

یو له لومړیو شیانو څخه چې موږ یې غوښتل فزیکي وسیلو ته د اجزاو ګمارلو ، تازه کولو او تحویلولو پروسې ګړندي کولو لپاره وکاروو ډاکر و.

له بده مرغه، دا په چټکۍ سره روښانه شوه چې په RPi کې ډاکر، که څه هم دا کار کوي، ډیر سر لري، په ځانګړې توګه د انرژي مصرف په برخه کې.

د "اصلي" OS په کارولو سره توپیر، که څه هم دومره پیاوړی نه و، مګر بیا هم زموږ لپاره کافي و چې د ډیر چټک چارج له لاسه ورکولو احتمال څخه محتاط واوسو.

دوهم دلیل په Node.js (sic!) کې زموږ د ملګرو کتابتونونو څخه یو و - د سیسټم یوازینۍ برخه چې په Go/C/C++ کې نه وه لیکل شوې.

د کتابتون لیکوالانو وخت نه درلود چې په هره "ملي" ژبو کې کاري نسخه چمتو کړي.

نه یوازې نوډ پخپله د ټیټ فعالیت وسیلو لپاره خورا په زړه پوری حل ندی ، مګر کتابتون پخپله خورا د سرچینې وږی و.

موږ پوهیږو چې حتی که موږ وغواړو ، د ډاکر کارول به زموږ لپاره خورا ډیر سر وي. انتخاب د اصلي OS په ګټه ترسره شوی او مستقیم د هغې لاندې کار کوي.

OS

د پایلې په توګه ، موږ بیا د OS په توګه ترټولو ساده اختیار غوره کړ او راسبیان (د Pi لپاره ډیبیان جوړ) وکاروه.

موږ خپل ټول سافټویر په Go کې لیکو، نو موږ په Go کې زموږ په سیسټم کې د اصلي هارډویر اجنټ ماډل هم لیکلي.

دا هغه څوک دی چې د GPS، بلوتوث سره کار کولو، د چارج لوستلو، د سکوټر چلولو، او داسې نورو مسولیت لري.

ګمارل

پوښتنه سمدلاسه د وسیلو (OTA) ته د تازه معلوماتو وړاندې کولو لپاره د میکانیزم پلي کولو اړتیا په اړه راپورته شوه - دواړه زموږ اجنټ/اپلیکیشن ته تازه کول ، او پخپله OS/فرم ویئر ته تازه کول (ځکه چې د اجنټ نوې نسخې کولی شي کرنل ته تازه معلوماتو ته اړتیا ولري. یا د سیسټم برخې، کتابتونونه، او نور).

د بازار د خورا اوږد تحلیل وروسته، دا معلومه شوه چې وسیله ته د تازه معلوماتو وړاندې کولو لپاره ډیری حلونه شتون لري.

له نسبتا ساده څخه، ډیری وختونه تازه/ډبل بوټ پر مخ تړل شوي اسانتیاوې لکه swupd/SWUpdate/OSTree بشپړ پلیټ فارمونو لکه مینډر او بالینا ته.

له هرڅه دمخه ، موږ پریکړه وکړه چې موږ د پای څخه تر پای حلونو سره علاقه لرو ، نو انتخاب سمدلاسه په پلیټ فارمونو کې راوتلی.

پخپله بالینا د دې حقیقت له امله خارج شوی و چې دا واقعیا د خپل بیلینا انجین دننه ورته ډاکر کاروي.

مګر زه یادونه کوم چې د دې سره سره، موږ په دوامداره توګه د دوی محصول کاروو بیلینا ایچر په SD کارتونو کې د فلش فرم ویئر لپاره - د دې لپاره یو ساده او خورا اسانه اسانتیا.

له همدې امله، په پای کې انتخاب راښکته شو مینډر. مینډر د فرم ویئر راټولولو ، تحویلولو او نصبولو لپاره بشپړ پلیټ فارم دی.

په ټولیز ډول پلیټ فارم خورا ښه ښکاري ، مګر دا موږ د مینڈر بلډر په کارولو سره زموږ د فرم ویئر سم نسخه جوړولو لپاره شاوخوا یوه نیمه اونۍ وخت واخیست.
او هرڅومره چې موږ د دې کارولو په پیچلتیاو کې ځان ډوب کړو ، هومره دا روښانه شوه چې د دې بشپړ ځای په ځای کولو لپاره به موږ د دې په پرتله ډیر وخت ته اړتیا ولرو.

افسوس، زموږ د سخت وخت نیټې معنی دا وه چې موږ مجبور شوي یو چې د مینډر کارول پریږدو او حتی ساده انتخاب غوره کړو.

ناڅاپي

زموږ په وضعیت کې ترټولو ساده حل د ځواب وړ کارول و. د پیل کولو لپاره یو څو د لوبو کتابونه کافي وو.

د دوی جوهر دا و چې موږ په ساده ډول د کوربه (CI سرور) څخه د ssh له لارې زموږ راسبیري سره وصل شو او دوی ته یې تازه معلومات توزیع کړل.

په پیل کې، هرڅه ساده وو - تاسو باید د وسیلو سره په ورته شبکه کې اوسئ، د وین فای له الرې اچول شوي.

په دفتر کې په ساده ډول د ورته شبکې سره یو درجن ټیسټ راسبیري وصل وو، هر وسیله یو جامد IP پته درلوده چې د ځواب وړ لیست کې هم مشخص شوي.

دا ځواب ورکوونکی و چې زموږ د څارنې اجنټ یې پای وسیلو ته وسپارل

3G / LTE

له بده مرغه، د ځواب وړ لپاره د دې کارولو قضیه یوازې د پراختیا په حالت کې کار کولی شي مخکې لدې چې موږ ریښتیني سکوټرونه ولرو.

ځکه چې سکوټرونه، لکه څنګه چې تاسو پوهیږئ، د یو وائی فای روټر سره وصل مه کېږئ، په دوامداره توګه د شبکې تازه معلوماتو ته انتظار کوئ.

په حقیقت کې، سکوټرونه نشي کولی د ګرځنده 3G/LTE پرته بل هیڅ اړیکه ونه لري (او حتی بیا هر وخت نه).

دا سمدلاسه ډیری ستونزې او محدودیتونه رامینځته کوي ، لکه د پیوستون ټیټ سرعت او بې ثباته اړیکه.

مګر ترټولو مهمه خبره دا ده چې په 3G/LTE شبکه کې موږ نشو کولی په ساده ډول شبکې ته ټاکل شوي جامد IP باندې تکیه وکړو.

دا په جزوي ډول د ځینې سیم کارت چمتو کونکو لخوا حل شوی؛ حتی ځانګړي سیم کارتونه شتون لري چې د IoT وسیلو لپاره د جامد IP پتې سره ډیزاین شوي. خو موږ دا ډول سیم کارتونو ته لاس رسی نه درلود او د آی پي ادرسونه مو نه شو کارولی.

البته، داسې نظرونه موجود وو چې د IP پتې د راجسټریشن یا د خدماتو کشف په کوم ځای کې د قونسل په څیر، مګر موږ باید دا ډول نظرونه پریږدو، ځکه چې زموږ په ازموینو کې د IP پته ډیری وختونه بدلیدلی شي، کوم چې د لوی بې ثباتۍ لامل شوی.

د دې دلیل لپاره ، د میټریکونو تحویلولو لپاره ترټولو اسانه کارول به د پل ماډل نه کارول وي ، چیرې چې موږ به د اړین میټریکونو لپاره وسیلو ته ځو ، مګر فشار راوړو ، له وسیلې څخه مستقیم سرور ته میټریک وړاندې کوو.

VPN

د دې ستونزې د حل په توګه، موږ VPN غوره کړ - په ځانګړې توګه وایبرګیډ.

پیرودونکي (سکوټرونه) د سیسټم په پیل کې د VPN سرور سره وصل شوي او د دوی سره وصل کیدو توان درلود. دا تونل د تازه معلوماتو وړاندې کولو لپاره کارول کیده.

په تیوري کې، ورته تونل د څارنې لپاره کارول کیدی شي، مګر دا ډول اړیکه د ساده فشار په پرتله خورا پیچلې او لږ باوري وه.

بادل سرچینې

په نهایت کې ، دا اړینه ده چې زموږ د کلاوډ خدماتو او ډیټابیسونو څارنه وکړو ، ځکه چې موږ د دوی لپاره کوبرنیټس کاروو ، په مثالي توګه نو په کلستر کې د نظارت ځای پرځای کول څومره چې امکان لري ساده وي. په مثالي توګه، کارول خولۍ، ځکه چې د ځای په ځای کولو لپاره ، موږ دا په ډیری قضیو کې کاروو. او البته، د بادل د څارنې لپاره تاسو اړتیا لرئ د سکوټرانو په څیر ورته حلونه وکاروئ.

ورکړل

اوه، داسې ښکاري چې موږ توضیحات ترتیب کړي، راځئ چې په پای کې د هغه څه لیست جوړ کړو چې موږ ورته اړتیا لرو:

• یو ګړندی حل ، ځکه چې نظارت دمخه د پراختیا پروسې په جریان کې اړین دی
• حجم / مقدار - ډیری میترونو ته اړتیا ده
• د ننوتلو راټولول اړین دي
• اعتبار - معلومات د بریالیتوب پیل کولو لپاره مهم دي
• تاسو نشئ کولی د پل ماډل وکاروئ - تاسو فشار ته اړتیا لرئ
• موږ نه یوازې د هارډویر متحد نظارت ته اړتیا لرو ، بلکه بادل هم

وروستی عکس داسې ښکاري

د سټیک انتخاب

نو، موږ د څارنې سټیک غوره کولو پوښتنې سره مخ شو.

له هرڅه دمخه ، موږ د خورا بشپړ بشپړ حل په لټه کې وو چې په ورته وخت کې به زموږ ټولې اړتیاوې پوښي ، مګر په ورته وخت کې دومره انعطاف وړ وي چې زموږ اړتیاو سره د هغې کارول تنظیم کړي. بیا هم ، موږ د هارډویر ، معمارۍ او وخت نیټې لخوا په موږ باندې ډیری محدودیتونه لګول شوي وو.

د څارنې حلونو ډیری ډولونه شتون لري، لکه د بشپړ سیسټمونو سره پیل کیږي نګیاس, شونډه او یا زبیبکس او د بیړۍ مدیریت لپاره چمتو شوي حلونو سره پای ته رسي.

په پیل کې، وروستی زموږ لپاره د مثالي حل په څیر بریښي، مګر ځینې یې بشپړ نظارت نه درلود، نورو د وړیا نسخو خورا محدود وړتیاوې درلودې، او نورو په ساده ډول زموږ "غوښتنې" نه پوښلې یا زموږ د سناریو سره د سمون لپاره کافي انعطاف وړ نه وو. ځینې ​​​​یې په ساده ډول زاړه دي.

د یو شمیر ورته حلونو تحلیل کولو وروسته ، موږ ژر تر ژره دې پایلې ته ورسیدو چې دا به اسانه او ګړندي وي چې پخپله ورته سټیک راټول کړئ. هو ، دا به د بشپړ چمتو شوي فلیټ مدیریت پلیټ فارم پلي کولو په پرتله یو څه ډیر پیچلي وي ، مګر موږ به اړ نه یو چې جوړجاړی وکړو.

البته، د حلونو په ټولو لوی کثرت کې، لا دمخه یو چمتو شوی دی چې موږ ته به په بشپړه توګه مناسب وي، مګر زموږ په قضیه کې دا خورا ګړندۍ وه چې پخپله یو ټاکلی سټیک راټول کړو او دا د "ځان لپاره" تنظیم کړو. د چمتو شوي محصولاتو ازموینه.

د دې ټولو سره، موږ هڅه نه ده کړې چې د څارنې ټول پلیټ فارم پخپله راټول کړو، مګر د خورا فعال "تیار شوي" سټیکونو په لټه کې یو، یوازې د دې وړتیا سره چې د انعطاف وړ تنظیم کولو وړتیا ولري.

(ب) ELK؟

لومړی حل چې واقعیا په پام کې نیول شوی و د ELK پیژندل شوی سټیک و.
په حقیقت کې، دا باید BELK وبلل شي، ځکه چې دا ټول د بیټس سره پیل کیږي - https://www.elastic.co/what-is/elk-stack

البته، ELK د څارنې په برخه کې یو له خورا مشهور او ځواکمن حلونو څخه دی، او حتی د لاګونو په راټولولو او پروسس کولو کې.

موږ اراده درلوده چې ELK به د لاګونو راټولولو او همدارنګه د پرومیټیوس څخه ترلاسه شوي میټریکونو اوږدمهاله ذخیره کولو لپاره وکارول شي.

د لید لپاره تاسو کولی شئ ګرافان وکاروئ.

په حقیقت کې، نوی ELK سټیک کولی شي په خپلواکه توګه میټریکونه راټول کړي (میټریک بیټ)، او کیبانا هم کولی شي دوی ښکاره کړي.

مګر بیا هم، ELK په پیل کې د لوګو څخه وده کړې او تر دې دمه د میټریک فعالیت یو شمیر جدي نیمګړتیاوې لري:

• د پرومیتیوس په پرتله د پام وړ ورو
• د پرومیتیوس په پرتله خورا لږ ځایونو کې مدغم کیږي
• د دوی لپاره د خبرتیاو ترتیب کول ستونزمن دي
• میټریک ډیر ځای نیسي
• په کبان کې د میټریکونو سره د ډشبورډونو تنظیم کول د ګرافان په پرتله خورا پیچلي دي

په عموم کې ، په ELK کې میټریکونه درانه دي او لاهم د نورو حلونو په څیر اسانه ندي ، چې له دې څخه اوس یوازې د پرومیټیوس څخه ډیر څه شتون لري: TSDB ، ویکټوریا میټریکس ، کورټیکس ، او داسې نور. البته ، زه واقعیا غواړم سمدلاسه یو بشپړ بشپړ حل ولرم ، مګر د میټریک بیټ په حالت کې خورا ډیر جوړجاړی شتون درلود.

او د ELK سټیک پخپله یو شمیر سختې شیبې لري:

• دا دروند دی، ځینې وختونه حتی خورا دروند دي که تاسو په کافي اندازه ډیټا راټول کړئ
• تاسو اړتیا لرئ پوه شئ چې دا څنګه پخلی کړئ - تاسو اړتیا لرئ دا اندازه کړئ ، مګر دا کول کوچني ندي
• وړیا نسخه لرې شوې - وړیا نسخه نورمال خبرتیا نلري ، او د انتخاب په وخت کې هیڅ تصدیق شتون نلري

زه باید ووایم چې پدې وروستیو کې وروستی ټکی ښه شوی او سربیره پردې د خلاصې سرچینې ایکس پیک کې محصول (د تصدیق په شمول) د نرخ ماډل پخپله بدلیدل پیل کړل.

مګر په هغه وخت کې چې موږ د دې حل پلي کولو لپاره روان وو، هیڅ خبرتیا شتون نلري.
شاید موږ هڅه کړې وای چې د ElastAlert یا نورو ټولنې حلونو په کارولو سره یو څه رامینځته کړو ، مګر موږ لاهم پریکړه کړې چې نور بدیلونه په پام کې ونیسو.

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

په اوس وخت کې ، یو ښه حل ممکن د نظارت سټیک رامینځته کول وي چې په خالص ډول د پرومیټیوس پراساس د میټریک چمتو کونکي په توګه ، لوکي د لاګونو لپاره ، او د لید لپاره تاسو ورته ګرافانا وکاروئ.

له بده مرغه، د پروژې د پلور پیلوټ پیل کولو په وخت کې (سپتمبر-اکتوبر 19)، لوکي لاهم د بیټا نسخه 0.3-0.4 کې و، او د پراختیا د پیل په وخت کې دا د تولید حل په توګه نشي ګڼل کیدی. هیڅکله.

زه لاهم په واقعیا کې په جدي پروژو کې د لوکي کارولو تجربه نلرم ، مګر زه کولی شم ووایم چې پرومټیل (د لاګونو راټولولو اجنټ) په کبرنیټس کې د فلزي او پوډونو دواړو لپاره عالي کار کوي.

ټیک

شاید د ELK سټیک لپاره خورا وړ (یوازې؟) بشپړ ب featuresه بدیل اوس یوازې د TICK سټیک په نوم ویل کیدی شي - ټیلګراف ، انفلوکس ډی بی ، کرونوګراف ، کاپیسیټر.

زه به لاندې ټولې برخې په تفصیل سره بیان کړم، مګر عمومي نظر دا دی:

• ټیلګراف - د میټریکونو راټولولو لپاره اجنټ
• InfluxDB - د میټریک ډیټابیس
• Kapacitor - د خبرتیا لپاره د ریښتیني وخت میټریک پروسیسر
• کرونوګراف - د لید لپاره ویب پینل

د InfluxDB، Kapacitor او Chronograph لپاره رسمي هیلم چارټونه شتون لري چې موږ یې ځای پرځای کولو لپاره کاروو.

دا باید په پام کې ونیول شي چې د انفلکس 2.0 (بیټا) په وروستي نسخه کې، کپیسیټر او کرونوګراف د InfluxDB برخه شوه او نور په جلا توګه شتون نلري.

ټیلګراف

ټیلګراف په دولتي ماشین کې د میټریکونو راټولولو لپاره خورا لږ وزن لرونکي اجنټ دی.

هغه کولی شي د هرڅه لوی مقدار وڅاري نګینکس پورې
سرور بوکسينگ.

دا یو شمیر ګرمې ګټې لري:

• ګړندی او سپک وزن (په ګو کې لیکل شوی)
  • لږ تر لږه منابع خوري
• د ډیفالټ له مخې میټریک فشار ورکړئ
• ټول اړین میټریکونه راټولوي
  • د سیسټم میټریکونه پرته له کوم ترتیباتو
  • د هارډویر میټریکونه لکه د سینسر څخه معلومات
  • د خپل میټریکونو اضافه کول خورا اسانه دي
• د بکس څخه ډیری پلگ انونه
• لاګونه راټولوي

څرنګه چې د فشار میټریکونه زموږ لپاره اړین وو، نورې ټولې ګټې د خوندور اضافو څخه ډیرې وې.

پخپله د اجنټ لخوا د لاګونو راټولول هم خورا اسانه دي ، ځکه چې د لاګ کولو لپاره اضافي اسانتیاو نښلولو ته اړتیا نشته.

انفلکس د لاګونو سره د کار کولو لپاره خورا اسانه تجربه وړاندې کوي که تاسو کاروئ سیسلاګ.

ټیلګراف عموما د میټریکونو راټولولو لپاره یو ښه اجنټ دی، حتی که تاسو د ICK پاتې برخه نه کاروئ.

ډیری خلک دا د اسانتیا لپاره د ELK او مختلف نورو وخت لړۍ ډیټابیسونو سره تیریږي ، ځکه چې دا تقریبا هرچیرې میټریک لیکلی شي.

InfluxDB

InfluxDB د TICK سټیک اصلي اساس دی ، د میټریکونو لپاره د وخت لړۍ ډیټابیس.
د میټریکونو سربیره، انفلکس کولی شي لاګونه هم ذخیره کړي، که څه هم، په حقیقت کې، د دې لپاره لاګونه یوازې ورته میټریکونه دي، یوازې د عادي شمیرو شاخصونو پرځای، اصلي دنده د لاګ متن د یوې کرښې لخوا ترسره کیږي.

InfluxDB په Go کې هم لیکل شوی او داسې بریښي چې زموږ (خورا ځواکمن نه) کلستر کې د ELK په پرتله خورا ګړندی پرمخ ځي.

د انفلوکس یوه په زړه پورې ګټې کې به د ډیټا پوښتنو لپاره خورا اسانه او بډایه API هم شامل وي ، کوم چې موږ خورا فعاله کارولې.

زیانونه - $$$ یا اندازه کول؟

د ټیک سټیک یوازې یو نیمګړتیا لري چې موږ وموندل - دا ګرانه. حتی نور.

تادیه شوی نسخه څه شی لري چې وړیا نسخه نلري؟

تر هغه ځایه چې موږ پوهیږو، د TICK سټیک تادیه شوي نسخه او وړیا نسخه ترمینځ یوازینی توپیر د پیمانه کولو وړتیاوې دي.

د بیلګې په توګه، تاسو کولی شئ یوازې د لوړ شتون سره کلستر پورته کړئ د سوداګرۍ نسخې.

که تاسو بشپړ HA غواړئ، تاسو اړتیا لرئ چې پیسې ورکړئ یا ځینې بیساکې وکاروئ. د ټولنې یو څو حلونه شتون لري - د مثال په توګه influxdb-ha د وړ حل په څیر ښکاري، مګر دا لیکل شوي چې دا د تولید لپاره مناسب ندي، او همدارنګه
influx-spout - د NATS له لارې د ډیټا پمپ کولو سره یو ساده حل (دا به هم اندازه شي ، مګر دا حل کیدی شي).

دا د افسوس خبره ده ، مګر دا دواړه پریښودل شوي ښکاري - هیڅ نوي ژمنې شتون نلري ، زه ګومان کوم چې مسله د انفلکس 2.0 نوې نسخه ډیر ژر تمه کیده خوشې کول دي ، په کوم کې چې ډیری شیان به توپیر ولري (په اړه هیڅ معلومات شتون نلري. تر اوسه پورې یې اندازه کول).

په رسمي توګه وړیا نسخه شتون لري ریل - په حقیقت کې، دا یو ابتدايي HA ​​دی، مګر یوازې د توازن له لارې،
ځکه چې ټول معلومات به د بار بیلانسر شاته ټولو InfluxDB مثالونو ته ولیکل شي.
هغه یو څه لري زیانونه لکه د بیا لیکلو پوائنټونو سره احتمالي ستونزې او دمخه د میټریکونو لپاره اډې رامینځته کولو اړتیا
(کوم چې د InfluxDB سره د نورمال کار پرمهال په اوتومات ډول پیښیږي).

بل څه شارډینګ نه ملاتړ کیږي، دا پدې معنی ده چې د نقل شوي میټریکونو (دواړه پروسس کولو او ذخیره کولو) لپاره اضافي سرې دي چې ممکن تاسو ورته اړتیا ونلرئ ، مګر د جلا کولو لپاره هیڅ لاره شتون نلري.

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

د پایلې په توګه، د دې حقیقت سره سره چې موږ د تادیه شوي پیمانه کولو پرته په هرڅه کې د TICK سټیک څخه په بشپړ ډول مطمین یو، موږ پریکړه وکړه چې وګورو چې ایا کوم وړیا حلونه شتون لري چې کولی شي د InfluxDB ډیټابیس ځای په ځای کړي، پداسې حال کې چې د T_CK پاتې برخې پریږدي.

د وخت لړۍ ډیری ډیټابیسونه شتون لري ، مګر ترټولو امید لرونکی یې ویکتوریا میټریک دی ، دا یو شمیر ګټې لري:

• ګړندی او اسانه ، لږترلږه د پایلو سره سم معیارونه
• دلته د کلستر نسخه شتون لري، چې په اړه یې اوس حتی ښه بیاکتنې شتون لري
  • هغه کولی شي ټوټه ټوټه کړي
• د InfluxDB پروتوکول ملاتړ کوي

موږ د ویکتوریا پراساس د بشپړ دودیز سټیک جوړولو اراده نه درلوده او اصلي هیله دا وه چې موږ وکولی شو دا د InfluxDB لپاره د ډراپ ان بدیل په توګه وکاروو.

له بده مرغه، دا ممکنه نه ده، سره له دې چې د InfluxDB پروتوکول ملاتړ شوی، دا یوازې د میټریک ثبتولو لپاره کار کوي - یوازې د پرومیټیوس API "بهر" شتون لري، پدې معنی چې دا به امکان ونلري چې په دې کې کرونوګراف تنظیم کړي.

سربیره پردې ، یوازې شمیري ارزښتونه د میټریکونو لپاره ملاتړ کیږي (موږ د ګمرکي میټریکونو لپاره د سټرینګ ارزښتونه کارولي - په دې برخه کې نور اډمین پینل).

په ښکاره ډول، د ورته دلیل لپاره، VM نشي کولی لاګونه ذخیره کړي لکه انفلوکس.

همدارنګه، دا باید په پام کې ونیول شي چې د غوره حل په لټه کې، ویکتوریا میټریک لا تر اوسه دومره مشهور نه و، اسناد خورا کوچني وو او فعالیت یې کمزوری و.
(زه د کلستر نسخه او شارډینګ تفصیلي توضیحات په یاد نه لرم).

د بنسټ انتخاب

د پایلې په توګه، دا پریکړه وشوه چې د پیلوټ لپاره موږ به لاهم خپل ځان په یو واحد InfluxDB نوډ پورې محدود کړو.

د دې انتخاب څو اصلي لاملونه وو:

• موږ واقعیا د ټیک سټیک ټول فعالیت خوښ کړ
• موږ دمخه د دې ځای په ځای کولو اداره کړې او دا عالي کار کړی
• ضرب الاجل پای ته رسیدلی و او د نورو انتخابونو ازموینې لپاره ډیر وخت پاتې نه و.
• موږ د دومره دروند بار تمه نه درلوده

موږ د پیلوټ د لومړي مرحلې لپاره ډیری سکوټرونه نه درلودل، او د پراختیا په جریان کې ازموینې د فعالیت کومه مسله څرګنده نه کړه.

له همدې امله، موږ پریکړه وکړه چې د دې پروژې لپاره یو د انفلوکس نوډ به زموږ لپاره د اندازه کولو اړتیا پرته کافي وي (په پای کې پایلې وګورئ).

موږ د سټیک او بیس په اړه پریکړه کړې - اوس د ټیک سټیک پاتې برخو په اړه.

کپیسیټر

Kapacitor د TICK سټیک برخه ده، یو خدمت چې کولی شي په ریښتیني وخت کې ډیټابیس ته د ننوتلو میټریک نظارت وکړي او د مقرراتو پراساس مختلف عملونه ترسره کړي.

په عموم کې، دا د احتمالي بې نظمۍ تعقیب او ماشین زده کړې لپاره د یوې وسیلې په توګه موقعیت لري (زه ډاډه نه یم چې دا دندې په تقاضا کې دي)، مګر د دې کارولو ترټولو مشهوره قضیه ډیره عامه ده - خبرتیا.

دا څنګه موږ دا د خبرتیاو لپاره وکاروو. موږ د سلیک الرټونه تنظیم کړل کله چې یو ځانګړی سکوټر آفلاین شو ، او ورته د سمارټ چارجرونو او مهم زیربنایی برخو لپاره ترسره شو.

دې کار دا ممکنه کړه چې ژر تر ژره ستونزو ته ځواب ووایی، او همدارنګه خبرتیاوې ترلاسه کړي چې هرڅه بیرته عادي حالت ته راځي.

یو ساده مثال: زموږ د "بکس" د بریښنا کولو لپاره اضافي بیټرۍ مات شوې یا د کوم دلیل لپاره بریښنا پای ته رسیدلې؛ په ساده ډول د نوي نصبولو سره ، یو څه وروسته موږ باید خبرتیا ترلاسه کړو چې د سکوټر فعالیت بحال شوی.

په Influx 2.0 Kapacitor د DB برخه شوه

کرونوګراف

ما د څارنې لپاره ډیری مختلف UI حلونه لیدلي، مګر زه کولی شم ووایم چې د فعالیت او UX په شرایطو کې، هیڅ شی د کرونوګراف سره پرتله نه کوي.

موږ د ټیک سټیک کارول پیل کړل ، په عجیب ډول ، د ګرافان سره د ویب انٹرفیس په توګه.
زه به د دې فعالیت تشریح نه کړم؛ هرڅوک د هر څه تنظیم کولو لپاره پراخه امکانات پیژني.

په هرصورت، ګرافانا لاهم یو بشپړ نړیوال وسیله ده، پداسې حال کې چې کرونوګراف په عمده ډول د انفلوکس کارولو لپاره ډیزاین شوی.

او البته، د دې څخه مننه، کرونوګراف کولی شي ډیر هوښیار یا مناسب فعالیت برداشت کړي.

شاید د کرونوګراف سره د کار کولو اصلي اسانتیا دا وي چې تاسو کولی شئ د سپړنې له لارې د خپل انفلوکس ډی بی دننه وګورئ.

داسې بریښي چې ګرافانا نږدې ورته فعالیت لري ، مګر په حقیقت کې ، په کرونوګراف کې د ډشبورډ تنظیم کول د یو څو موږک کلیکونو سره ترسره کیدی شي (په ورته وخت کې هلته لید ته ګوري) ، پداسې حال کې چې په ګرافانا کې به تاسو لاهم ژر یا وروسته ولرئ. د JSON ترتیب ترمیم کولو لپاره (البته کرونوګراف اجازه ورکوي چې ستاسو لاسي ترتیب شوي ډیشا اپلوډ کړئ او د اړتیا په صورت کې یې د JSON په توګه ترمیم کړئ - مګر ما هیڅکله د دوی په UI کې رامینځته کولو وروسته دوی ته لمس نه دی کړی).

کبانا د دوی لپاره د ډشبورډونو او کنټرولونو رامینځته کولو لپاره خورا بډایه وړتیاوې لري ، مګر د ورته عملیاتو لپاره UX خورا پیچلی دی.

دا به د یو مناسب ډشبورډ رامینځته کولو لپاره یو څه ښه پوهه واخلي. او که څه هم د کرونوګراف ډشبورډونو فعالیت لږ دی ، د دوی جوړول او تنظیم کول خورا ساده دي.

پخپله ډشبورډونه ، د خوندور لید سټایل سربیره ، په حقیقت کې په ګرافانا یا کبانا کې د ډشبورډونو څخه توپیر نلري:

دا هغه څه دي چې د پوښتنې کړکۍ داسې ښکاري:

دا مهمه ده چې یادونه وکړو، د نورو شیانو په منځ کې، چې د InfluxDB ډیټابیس کې د ساحو ډولونه پوهیدل، کرونوګراف پخپله ځینې وختونه کولی شي په اتوماتيک ډول تاسو سره د پوښتنې لیکلو یا د سمې راټولولو فعالیت غوره کولو کې مرسته وکړي لکه معنی.

او البته، کرونوګراف د لاګونو لیدلو لپاره د امکان تر حده مناسب دی. دا داسې ښکاري:

د ډیفالټ په توګه، د انفلوکس لاګونه د syslog کارولو لپاره مناسب دي او له همدې امله دوی یو مهم پیرامیټر لري - شدت.

په پورتنۍ برخه کې ګراف په ځانګړي توګه ګټور دی؛ په دې کې تاسو کولی شئ هغه غلطیان وګورئ چې پیښیږي او رنګ سمدلاسه په روښانه ډول ښیې که شدت لوړ وي.

یو څو ځله موږ پدې لاره کې مهمې کیګونه نیولي ، د تیرې اونۍ لاګونو لیدو ته ځو او یو سور سپیک لیدو.

البته، په مثالي توګه دا به د داسې غلطیو لپاره خبرتیاوې تنظیم کړي، ځکه چې موږ دمخه د دې لپاره هرڅه درلودل.

موږ حتی دا د یو څه مودې لپاره فعال کړ، مګر د پیلوټ چمتو کولو په بهیر کې دا معلومه شوه چې موږ ډیری غلطۍ ترلاسه کوو (د سیسټم په شمول د LTE شبکې نشتوالی)، کوم چې د سلیک چینل هم "سپیم" کړی. ډیر، پرته له کومې ستونزې رامینځته کول. لویه ګټه.

سم حل به دا وي چې د دې ډول ډیری غلطیتونو اداره کول، د دوی لپاره شدت تنظیم کړئ، او یوازې بیا خبرتیا فعال کړئ.

په دې توګه، یوازې نوې یا مهمې تېروتنې به سلیک ته ځړول شي. د سخت وخت نیټې په پام کې نیولو سره د داسې تنظیم لپاره کافي وخت نه و.

تصدیق کول

دا هم د یادولو وړ ده چې کرونوګراف د OAuth او OIDC د تصدیق په توګه ملاتړ کوي.

دا خورا اسانه دی ، ځکه چې دا تاسو ته اجازه درکوي په اسانۍ سره دا ستاسو سرور سره وصل کړئ او بشپړ SSO رامینځته کړئ.

زموږ په قضیه کې، سرور و کلیکل - دا د نظارت سره وصل کولو لپاره کارول کیده ، مګر ورته سرور هم د سکوټرونو تصدیق کولو او شاته پای ته غوښتنې لپاره کارول شوی و.

"اډمین"

وروستی برخه چې زه به یې تشریح کړم په Vue کې زموږ پخپله لیکل شوی "اډمین پینل" دی.
اساسا دا یوازې یو واحد خدمت دی چې زموږ د خپلو ډیټابیسونو ، مایکرو خدماتو ، او میټریک ډیټا څخه په ورته وخت کې د InfluxDB څخه د سکوټر معلومات ښیې.

سربیره پردې ، ډیری اداري دندې هلته لیږدول شوي ، لکه د بیړني ریبوټ یا د ملاتړ ټیم لپاره په لرې ډول د تالاش خلاصول.

نقشې هم وې. ما دمخه یادونه کړې چې موږ د کرونوګراف پرځای د ګرافانا سره پیل کړی - ځکه چې د ګرافانا نقشې د پلگ انونو په شکل کې شتون لري ، په کوم کې چې موږ کولی شو د سکوټرونو همغږي وګورو. له بده مرغه، د ګرافانا لپاره د نقشې ویجټونو وړتیاوې خورا محدودې دي، او د پایلې په توګه، په څو ورځو کې د نقشو سره ستاسو د ویب غوښتنلیک لیکل خورا اسانه وو، ترڅو نه یوازې دا مهال همغږي وګورئ، بلکې ښکاره کول هم. هغه لاره چې د سکوټر لخوا اخیستل شوې، د دې وړتیا ولرئ چې په نقشه کې ډاټا فلټر کړئ، او نور. (ټول هغه فعالیت چې موږ یې په ساده ډشبورډ کې نه شو تنظیمولی).

د انفلوکس یو له دمخه ذکر شوي ګټو څخه د دې وړتیا ده چې په اسانۍ سره خپل میټریکونه رامینځته کړئ.
دا دا اجازه ورکوي چې د ډیری سناریوګانو لپاره وکارول شي.

موږ هڅه وکړه چې ټول ګټور معلومات هلته ثبت کړو: د بیټرۍ چارج، د بند حالت، د سینسر فعالیت، بلوتوت، GPS، او ډیری نور روغتیایی معاینات.
موږ دا ټول په اډمین پینل کې ښودلي.

البته، زموږ لپاره ترټولو مهم معیار د سکوټر عملیاتي حالت و - په حقیقت کې، انفلوکس دا پخپله ګوري او د نوډز برخه کې د "شنه څراغونو" سره ښیي.

دا د فنکشن لخوا ترسره کیږي مړ سړی - موږ دا زموږ د بکس فعالیت پوهیدو لپاره کارولی او ورته ورته خبرتیاوې سلیک ته لیږو.

په لاره کې، موږ د سمپسن د کرکټرونو نومونو وروسته سکوټرونه نومول - دا خورا اسانه وه چې دوی له یو بل څخه توپیر کړو

او په عموم کې دا پدې لاره ډیر ساتیري وه. جملې لکه " هلکان ، سمیټرز مړ دی!" په دوامداره توګه اوریدل کیدل.

د سټینګ میټریکونه

دا مهمه ده چې InfluxDB تاسو ته اجازه درکوي نه یوازې شمیري ارزښتونه ذخیره کړئ، لکه څنګه چې د ویکتوریا میټریک سره قضیه ده.

داسې بریښي چې دا دومره مهم ندي - په هرصورت ، د لاګونو سربیره ، کوم میټریکونه د شمیرو په شکل کې زیرمه کیدی شي (یوازې د پیژندل شوي ایالتونو لپاره نقشه اضافه کړئ - یو ډول اینوم)؟

زموږ په قضیه کې، لږترلږه یوه سناریو وه چیرې چې د سټینګ میټریک خورا ګټور و.
دا یوازې داسې پیښ شوي چې زموږ د "سمارټ چارجرونو" عرضه کونکی دریم اړخ و ، موږ د پراختیا پروسې او هغه معلوماتو باندې هیڅ کنټرول نه درلود چې دا چارجر کولی شي چمتو کړي.

د پایلې په توګه، د چارج کولو API له مثالي څخه لرې و، مګر اصلي ستونزه دا وه چې موږ تل د دوی حالت نه شو درک کولی.

دا هغه ځای دی چې انفلیکس د ژغورنې لپاره راغلی. موږ په ساده ډول د تار حالت لیکلی چې موږ ته پرته له بدلونونو د InfluxDB ډیټابیس ډګر ته راغلی.

د یو څه وخت لپاره ، یوازې ارزښتونه لکه "آنلاین" او "آفلاین" هلته رسیدلي ، د کوم پراساس چې معلومات زموږ په اډمین پینل کې ښودل شوي ، او خبرتیاوې سلیک ته لیږل شوي. په هرصورت، په ځینو وختونو کې، د "منقطع شوي" په څیر ارزښتونه هم هلته څرګندیدل پیل کړل.

لکه څنګه چې وروسته معلومه شوه، دا حالت یو ځل د پیوستون له لاسه ورکولو وروسته لیږل شوی و، که چیرې چارجر نشي کولی د یو شمیر هڅو وروسته د سرور سره اړیکه جوړه کړي.

په دې توګه، که موږ یوازې د ارزښتونو یو ثابت سیټ وکاروو، موږ ممکن دا بدلونونه په سم وخت کې په فرم ویئر کې ونه ګورو.

او په عموم کې، د سټینګ میټریکونه د کارولو لپاره ډیر امکانات چمتو کوي؛ تاسو کولی شئ په دوی کې هر ډول معلومات ثبت کړئ. که څه هم، البته، تاسو باید دا وسیله په دقت سره وکاروئ.

د معمول میټریکونو سربیره، موږ په InfluxDB کې د GPS موقعیت معلومات هم ثبت کړل. دا زموږ په اډمین پینل کې د سکوټرونو موقعیت څارلو لپاره خورا په زړه پوري ګټور و.
په حقیقت کې، موږ تل پوهیږو چې چیرته او کوم سکوټر په هغه وخت کې چې موږ ورته اړتیا درلوده.

دا زموږ لپاره خورا ګټور و کله چې موږ د سکوټر په لټه کې وو (په پای کې پایلې وګورئ).

د زیربنا څارنه

پخپله د سکوټرونو سربیره، موږ هم اړتیا درلوده چې زموږ ټول (بلکه پراخه) زیربنا وڅاري.

یو ډیر عمومي جوړښت داسې ښکاري:

که موږ د خالص څارنې سټیک روښانه کړو، دا داسې ښکاري:

هغه څه چې موږ یې په بادل کې چیک کول غواړو دا دي:

• ډاټابیسزونه
• کلیکل
• کوچني خدمتونه

څرنګه چې زموږ ټول کلاوډ خدمات په کوبرنیټس کې موقعیت لري، نو دا به ښه وي چې د دې حالت په اړه معلومات راټول کړئ.

خوشبختانه ، د بکس څخه بهر ټیلګراف کولی شي د کوبرنیټس کلسټر حالت په اړه لوی شمیر میټریکونه راټول کړي ، او کرونوګراف سمدلاسه د دې لپاره ښکلي ډشبورډونه وړاندیز کوي.

موږ په عمده توګه د پوډونو فعالیت او د حافظې مصرف څارنه وکړه. د سقوط په صورت کې، په سلیک کې خبرتیاوې.

په کبرنیټس کې د پوډونو تعقیب لپاره دوه لارې شتون لري: ډیمون سیټ او سایډکار.
دواړه میتودونه په تفصیل سره تشریح شوي په دې بلاګ پوسټ کې.

موږ د Telegraph Sidecar څخه کار واخیست او د میټریکونو سربیره، د پوډ لاګ راټول کړل.

زموږ په قضیه کې، موږ باید د لوګو سره ټینکر وکړو. د دې حقیقت سره سره چې ټیلګراف کولی شي د ډاکر API څخه لاګونه راوباسي ، موږ غوښتل چې زموږ د پای وسیلو سره د لاګونو یونیفورم ټولګه ولرو او د دې لپاره د کانټینرونو لپاره سیسلاګ تنظیم کړو. شاید دا حل ښکلی نه و، مګر د دې کار په اړه هیڅ شکایت شتون نلري او لاګونه په کرونوګراف کې ښه ښودل شوي.

د څارنې څارنه؟؟؟

په پای کې، د څارنې سیسټمونو د عمر زوړ پوښتنه راپورته شوه، مګر خوشبختانه، یا له بده مرغه، موږ په ساده ډول د دې لپاره کافي وخت نه درلود.

که څه هم ټیلګراف کولی شي په اسانۍ سره خپل میټریکونه واستوي یا د انفلوکس ډی بی ډیټابیس څخه میټریکونه راټول کړي یا هم ورته انفلکس یا بل چیرې لیږلو لپاره.

موندنو

موږ د پیلوټ له پایلو څخه کومې پایلې ترلاسه کړې؟

تاسو څنګه څارنه کولی شئ؟

تر ټولو لومړی، د ټیک سټیک زموږ هیلې په بشپړه توګه پوره کړې او موږ ته یې د هغه څه څخه ډیر فرصتونه راکړل چې موږ یې په پیل کې تمه درلوده.

ټول هغه فعالیت چې موږ ورته اړتیا درلوده شتون درلود. هرڅه چې موږ ورسره وکړل پرته له کومې ستونزې کار وکړ.

محصولات

په وړیا نسخه کې د TICK سټیک سره اصلي ستونزه د اندازه کولو وړتیاو نشتوالی دی. دا زموږ لپاره کومه ستونزه نه وه.

موږ دقیق بار معلومات / ارقام راټول نه کړل، مګر موږ په یو وخت کې د 30 سکوټرونو څخه ډاټا راټول کړل.

هر یو له درې درجن څخه ډیر میټریکونه راټول کړل. په ورته وخت کې، د وسیلو څخه لاګونه راټول شوي. د معلوماتو راټولول او لیږل په هرو 10 ثانیو کې پیښیږي.

دا مهمه ده چې په یاد ولرئ چې د پیلوټ څخه د یوې نیمې اونۍ وروسته، کله چې د "ماشومۍ ستونزې" ډیری برخه سمه شوې او خورا مهمې ستونزې لا دمخه حل شوي، موږ باید سرور ته د معلوماتو لیږلو فریکوینسي کمه کړو. 30 ثانیې. دا اړینه شوه ځکه چې زموږ د LTE سیم کارتونو ترافیک په چټکۍ سره ورکیدل پیل کړل.

د ترافیک لویه برخه د لاګونو لخوا مصرف شوي؛ پخپله میټریکونه حتی د 10 ثانیو وقفې سره ، په عملي ډول یې ضایع نه کړل.

د پایلې په توګه ، د یو څه وخت وروسته موږ په وسیلو کې د لاګونو راټولول په بشپړ ډول غیر فعال کړل ، ځکه چې ځانګړي ستونزې لا دمخه څرګندې وې حتی د دوامداره راټولولو پرته.

په ځینو مواردو کې، که چیرې د لاګونو لیدل لاهم اړین وي، موږ په ساده ډول د VPN له لارې د WireGuard له لارې وصل شو.

زه به دا هم اضافه کړم چې هر جلا چاپیریال له یو بل څخه جلا شوی و، او پورته بیان شوي بار یوازې د تولید چاپیریال لپاره اړین و.

په پرمختیایي چاپیریال کې، موږ یو جلا InfluxDB بیلګه پورته کړه چې په هر 10 ثانیو کې د معلوماتو راټولولو ته دوام ورکوي او موږ د فعالیت کومې ستونزې سره مخ نه یو.

TICK - د کوچنیو او منځنیو پروژو لپاره مثالی

د دې معلوماتو پراساس، زه به دې پایلې ته ورسیږم چې د TICK سټیک د نسبتا کوچنیو پروژو یا پروژو لپاره مثالی دی چې یقینا د لوړ لوډ تمه نلري.

که تاسو زرګونه پوډونه یا سلګونه ماشینونه نلرئ، حتی د InfluxDB یوه بیلګه به بار په سمه توګه اداره کړي.

په ځینو حاالتو کې، تاسو ممکن د لومړني لوړ شتون حل په توګه د انفلوکس ریلی څخه راضي یاست.

او البته، هیڅوک تاسو د "عمودی" پیمانه کولو او په ساده ډول د مختلف ډولونو میټریکونو لپاره مختلف سرورونو تخصیص کولو څخه منع کوي.

که تاسو د څارنې خدماتو کې د متوقع بار په اړه ډاډه نه یاست، یا تاسو تضمین یاست چې یو ډیر "درانه" جوړښت ولرئ، زه به د TICK سټیک وړیا نسخه کارولو وړاندیز ونه کړم.

البته، یو ساده حل به د پیرودلو لپاره وي InfluxDB Enterprise - مګر دلته زه نشم کولی یو څه تبصره وکړم، ځکه چې زه پخپله د فرعياتو سره بلد نه یم. د دې حقیقت سربیره چې دا خورا ګران دی او یقینا د کوچني شرکتونو لپاره مناسب ندي.

په دې حالت کې، نن، زه به د ویکتوریا میټریکونو او لوکی په کارولو سره د لاګونو له لارې د میټریکونو راټولولو په لټه کې وړاندیز وکړم.

ریښتیا ، زه به بیا یو ریزرویشن وکړم چې لوکي / ګرافانا د چمتو شوي ټیک په پرتله خورا لږ اسانه دي (د دوی د لوی استعداد له امله) ، مګر دا وړیا دي.

مهم: ټول هغه معلومات چې دلته تشریح شوي د انفلکس 1.8 نسخې لپاره اړوند دي، دا مهال د انفلکس 2.0 د خپریدو په حال کې دی.

پداسې حال کې چې ما په جګړه ایزو شرایطو کې د دې هڅه کولو فرصت نه درلود او د پرمختګونو په اړه پایلې ترلاسه کول ستونزمن دي، انٹرفیس یقینا خورا ښه شوی، جوړښت ساده شوی (پرته د کپیسیټر او کرونوګراف)،
ټیمپلیټونه ښکاره شول ("وژونکي ځانګړتیا" - تاسو کولی شئ په فورټنایټ کې لوبغاړي تعقیب کړئ او خبرتیاوې ترلاسه کړئ کله چې ستاسو غوره لوبغاړی لوبه وګټي). مګر، له بده مرغه، دا مهال، نسخه 2 هغه کلیدي شی نلري چې موږ یې لومړۍ نسخه غوره کړې - د لاګ ټولګه شتون نلري.

دا فعالیت به په انفلوکس 2.0 کې هم څرګند شي، مګر موږ نشو موندلی چې هیڅ مهال ویش، حتی اټکل شوي.

څنګه د IoT پلیټ فارمونه نه جوړ کړئ (اوس)

په نهایت کې ، د پیلوټ په لاره اچولو سره ، موږ پخپله زموږ د معیارونو سره سم د بدیل په نشتوالي کې خپل بشپړ IoT سټیک راټول کړ.

په هرصورت، پدې وروستیو کې دا په بیټا نسخه کې شتون لري OpenBalena - دا د افسوس خبره ده چې هغه هلته نه وه کله چې موږ پروژه پیل کړه.

موږ د پای پایلې او د ځواب وړ + TICK + WireGuard پراساس پلیټ فارم څخه په بشپړ ډول مطمین یو چې موږ پخپله راټول کړي. مګر نن ورځ ، زه وړاندیز کوم چې د خپل IoT پلیټ فارم پخپله جوړولو هڅه کولو دمخه د بالینا ته نږدې کتنه وکړئ.

ځکه چې په نهایت کې دا کولی شي ډیری هغه څه وکړي چې موږ یې کړي، او OpenBalena وړیا او خلاص سرچینه ده.

دا دمخه پوهیږي چې څنګه نه یوازې تازه معلومات لیږل کیږي ، بلکه VPN لا دمخه جوړ شوی او د IoT چاپیریال کې د کارولو لپاره مناسب دی.

او په دې وروستیو کې، دوی حتی خپل خوشې کړل هډوتري، کوم چې په اسانۍ سره د دوی ایکوسیستم سره وصل کیږي.

اې، د ورک شوي سکوټر په اړه څه؟

نو سکوټر، "رالف" پرته له کومې نښې ورک شو.

موږ سمدلاسه د InfluxDB څخه د GPS میټریک ډیټا سره زموږ په "اډمین پینل" کې نقشې ته د لیدو لپاره ورغلو.

د معلوماتو د څارنې څخه مننه، موږ په اسانۍ سره معلومه کړه چې سکوټر تیره ورځ د 21:00 په شاوخوا کې د پارکینګ ځای څخه ووتل، شاوخوا نیم ساعت یې ځینې سیمې ته وګرځاوه او د جرمني کور ته نږدې د سهار تر 5 بجو پورې ولاړ و.

د سهار له 5 بجو وروسته، د څارنې هیڅ معلومات ترلاسه نه شول - د دې معنی دا وه چې یا اضافي بیټرۍ په بشپړه توګه خارج شوې، یا برید کونکي په پای کې معلومه کړه چې څنګه د سکوټر څخه سمارټ هارډویر لرې کړي.
سره له دې، پولیس لا هم هغه پته ته بلل شوي چې سکوټر موقعیت لري. سکوټر هلته نه و.

خو د کور خاوند هم په دې خبره حيران شو، ځکه چې تېره شپه يې په حقيقت کې دغه سکوټر له دفتر څخه کور ته وړی و.

لکه څنګه چې معلومه شوه، د ملاتړ کارمندانو څخه یو سهار وختي راغی او سکوټر یې پورته کړ، لیدل یې چې اضافي بیټرۍ یې په بشپړه توګه خارج شوې او د پارکینګ ځای ته یې (په پښو) کېښود. او اضافي بیټرۍ د لندبل له امله ناکامه شوه.

موږ له ځانه سکوټر غلا کړ. په لاره کې، زه نه پوهیږم چې څنګه او چا بیا د پولیسو قضیې سره مسله حل کړه، مګر نظارت په سمه توګه کار کاوه ...

سرچینه: www.habr.com