紛失したスクーターの返却、または XNUMX つの IoT 監視の話

XNUMX 年前、私たちはプロモーション プロジェクトのパイロット版を立ち上げました。 電動スクーターの分散レンタル.

当初、このプロジェクトは Road-To-Barcelona と呼ばれていましたが、後に Road-To-Berlin (したがってスクリーンショットでは R2B) になり、最終的には xRide と呼ばれるようになりました。

このプロジェクトの主なアイデアは次のとおりです。集中型の車やスクーターのレンタル サービス (キックスクーター/スクーターではなく、スクーター、別名電動バイクについて話しています) の代わりに、分散型レンタルのプラットフォームを作りたいと考えていました。 私たちが遭遇した困難について すでに以前に書いた.

当初、プロジェクトは自動車に焦点を当てていましたが、期限、メーカーとの非常に長いコミュニケーション、および膨大な数の安全制限のため、電動スクーターがパイロットに選ばれました。

ユーザーは携帯電話に iOS または Android アプリケーションをインストールし、気に入ったスクーターに近づきました。その後、携帯電話とスクーターがピアツーピア接続を確立し、ETH が交換され、ユーザーはスクーターの電源をオンにして乗り始めることができました。電話。 旅行の終わりには、携帯電話上のユーザーのウォレットからイーサリアムを使用して旅行代金を支払うことも可能でした。

スクーターに加えて、ユーザーはアプリケーションに「スマート充電器」を表示し、現在のバッテリーが低下した場合にユーザーが自分で交換できるようになりました。

これは、昨年 XNUMX 月にドイツの XNUMX つの都市、ボンとベルリンで開始されたパイロット版の全体的な様子です。

そしてある日、ボンで早朝に私たちのサポート チーム (スクーターを正常に動作できる状態に維持するために現場に常駐) に、スクーター XNUMX 台が跡形もなく消えたという通報が入りました。

どうやって見つけて返すのですか？

この記事ではこれについて説明しますが、その前に、独自の IoT プラットフォームをどのように構築し、それをどのように監視したかについて説明します。

スクーター、インフラ、充電ステーションなど、何を監視する必要がありますか?またその理由は何ですか?

では、プロジェクトで何を監視したかったのでしょうか?

まず第一に、これらはスクーター自体です。電動スクーター自体は非常に高価なので、十分な準備ができていないとそのようなプロジェクトを立ち上げることはできません。可能であれば、スクーターに関するできるだけ多くの情報 (場所、充電レベルなど) を収集したいと考えています。 、など。

さらに、データベース、サービス、およびそれらが機能するために必要なものすべてなど、自社の IT インフラストラクチャの状態を監視したいと考えています。 また、「スマート充電器」が故障したり、バッテリーが切れたりした場合に備えて、その状態を監視する必要もありました。

原付

私たちのスクーターとは何ですか?そしてそれについて何を知りたかったのですか?

まず最も重要なことは GPS 座標です。GPS 座標のおかげで、私たちは彼らがどこにいるのか、どこを移動しているのかを理解できるからです。

次はバッテリーの充電です。これにより、スクーターの充電が終わりに近づいていることを判断して、ジューサーを送信するか、少なくともユーザーに警告することができます。

もちろん、ハードウェア コンポーネントで何が起こっているかを確認することも必要です。

• ブルートゥースは機能しますか？
• GPSモジュール自体は機能しますか？
  • また、GPS が誤った座標を送信してスタックする可能性があるという問題も抱えていました。これはスクーターの追加チェックによってのみ判断できました。
    問題を解決するためにできるだけ早くサポートに通知してください

そして最後に、OS とプロセッサー、ネットワークとディスクの負荷から始まり、より具体的な独自のモジュールのチェックで終わるソフトウェアのチェックです (ホロコム, キークローク).

Hardware

私たちの「鉄」の部分は何でしたか？

可能な限り短い時間枠とラピッドプロトタイピングの必要性を考慮して、コンポーネントの実装と選択に最も簡単なオプションである Raspberry Pi を選択しました。
Rpi自体に加えて、カスタムボード（最終ソリューションの組み立てプロセスをスピードアップするために私たち自身が開発して中国に注文しました）とコンポーネントのセット（スクーターのオン/オフを切り替えるための）リレーがありました。バッテリー充電リーダー、モデム、アンテナ。 これらすべてを専用の「xRideボックス」にコンパクトにパッケージしました。

また、ボックス全体が追加のモバイルバッテリーから電力を供給され、さらにそのモバイルバッテリーがスクーターのメインバッテリーから電力を供給されていることにも注意してください。

これにより、イグニッションキーを「オフ」位置にするとすぐにメインバッテリーがオフになるため、旅行終了後でもモニタリングを使用してスクーターの電源を入れることが可能になりました。

ドッカー？ 普通の Linux ですか？ そして展開

モニタリングの話に戻りましょう。ラズベリーには何があるでしょうか?

物理デバイスへのコンポーネントのデプロイ、更新、配信のプロセスを高速化するために私たちが最初に使用したいと考えていたものの XNUMX つは、Docker でした。

残念ながら、RPi 上の Docker は機能しますが、特にエネルギー消費の点で多くのオーバーヘッドがあることがすぐに明らかになりました。

「ネイティブ」OS を使用した場合の違いは、それほど強力ではありませんでしたが、充電が急速に失われる可能性について警戒するには十分でした。

XNUMX 番目の理由は、Go/C/C++ で書かれていないシステムの唯一のコンポーネントである Node.js (原文どおり!) 上のパートナー ライブラリの XNUMX つでした。

ライブラリの作成者には、「ネイティブ」言語で実用的なバージョンを提供する時間がありませんでした。

ノード自体が低パフォーマンスのデバイスにとって最も洗練されたソリューションではないだけでなく、ライブラリ自体も非常に多くのリソースを消費していました。

たとえ使いたくても、Docker を使用するとオーバーヘッドが大きすぎることに気づきました。 ネイティブ OS を優先し、その下で直接動作することが選択されました。

OS

その結果、やはり OS として最も単純なオプションを選択し、Raspbian (Pi 用の Debian ビルド) を使用しました。

私たちはすべてのソフトウェアを Go で作成しているため、システム内のメインのハードウェア エージェント モジュールも Go で作成しました。

GPS、Bluetooth の操作、充電量の読み取り、スクーターの電源投入などを担当するのは彼です。

展開する

デバイスに更新を配信するためのメカニズム (OTA) を実装する必要性についての疑問がすぐに生じました。エージェント/アプリケーション自体の更新と、OS/ファームウェア自体の更新の両方です (エージェントの新しいバージョンではカーネルの更新が必要になる可能性があるため)またはシステムコンポーネント、ライブラリなど）。

市場をかなり長い間分析した結果、デバイスにアップデートを配信するためのソリューションが非常にたくさんあることがわかりました。

swupd/SWUpdate/OSTree などの比較的単純で主に更新/デュアルブート指向のユーティリティから、Mender や Balena などの本格的なプラットフォームまで。

まず第一に、私たちはエンドツーエンドのソリューションに興味があると判断したため、すぐにプラットフォームを選択することになりました。

自体 バレナ は、balenaEngine 内で実際に同じ Docker を使用しているという事実により除外されました。

しかし、それにもかかわらず、私たちは最終的に彼らの製品を使い続けることになったことに注意してください。 バリーナエッチャー SD カード上のフラッシュ ファームウェア用 - シンプルで非常に便利なユーティリティです。

ということで、最終的に選んだのは、 修理人。 Mender は、ファームウェアを組み立て、配信し、インストールするための完全なプラットフォームです。

全体的にプラットフォームは素晴らしく見えますが、Mender Builder を使用して正しいバージョンのファームウェアを構築するだけで約 XNUMX 週間半かかりました。
そして、その使用方法の複雑さに没頭すればするほど、それを完全に導入するには、これまでよりもはるかに多くの時間が必要であることが明らかになりました。

悲しいことに、締め切りが厳しかったため、Mender の使用を放棄し、よりシンプルなものを選択せざるを得なくなりました。

Ansible

私たちの状況における最も簡単な解決策は、Ansible を使用することでした。 始めるには、いくつかのプレイブックで十分でした。

その本質は、単にホスト (CI サーバー) から ssh 経由でラズベリーに接続し、更新を配布するということでした。

当初はすべてが単純でした。デバイスと同じネットワーク上にある必要があり、注ぐのは Wi-Fi 経由で行われました。

オフィスには、単純に XNUMX 台のテスト用ラズベリーが同じネットワークに接続されており、各デバイスには Ansible Inventory でも指定された静的 IP アドレスがありました。

監視エージェントをエンドデバイスに配信したのは Ansible でした

3G / LTE

残念ながら、Ansible のこのユースケースは、実際のスクーターが登場する前は開発モードでのみ動作できました。

ご存知のとおり、スクーターは XNUMX 台の Wi-Fi ルーターに接続されておらず、ネットワーク上の更新を常に待機しているためです。

実際には、スクーターはモバイル 3G/LTE 以外にはまったく接続できません (そして、常に接続できるわけではありません)。

これにより、接続速度が遅くなったり、通信が不安定になったりするなど、すぐに多くの問題や制限が生じます。

しかし、最も重要なことは、3G/LTE ネットワークでは、ネットワークに割り当てられた静的 IP に単純に依存することはできないということです。

この問題は一部の SIM カード プロバイダーによって部分的に解決されており、静的 IP アドレスを持つ IoT デバイス用に設計された特別な SIM カードもあります。 しかし、私たちはそのような SIM カードにアクセスできず、IP アドレスを使用できませんでした。

もちろん、Consul のような場所で IP アドレスの登録、つまりサービス検出を行うというアイデアもありましたが、テストでは IP アドレスが頻繁に変更される可能性があり、非常に不安定になる可能性があったため、そのようなアイデアは放棄しなければなりませんでした。

このため、メトリクスを配信するための最も便利な使用法は、必要なメトリクスを取得するためにデバイスにアクセスするプル モデルを使用するのではなく、デバイスからサーバーにメトリクスを直接配信するプッシュ型モデルを使用することになります。

VPN

この問題の解決策として、私たちは VPN を選択しました。 ワイヤーガード.

システム起動時のクライアント（スクーター）はVPNサーバーに接続し、接続することができました。 このトンネルは更新を配信するために使用されました。

理論的には、同じトンネルをモニタリングに使用できますが、そのような接続は単純なプッシュよりも複雑で信頼性が低くなります。

クラウドリソース

最後に、クラウド サービスとデータベースには Kubernetes を使用しているため、それらを監視する必要があります。これにより、クラスター内での監視の展開ができるだけ簡単になることが理想的です。 理想的には、 ヘルメット、デプロイメントの場合、ほとんどの場合それを使用するためです。 そしてもちろん、クラウドを監視するには、スクーター自体と同じソリューションを使用する必要があります。

与えられた

ふう、説明は整理できたようです。最後に必要なもののリストを作成しましょう。

• 開発プロセス中にすでにモニタリングが必要であるため、迅速な解決策
• ボリューム/数量 - 多くの指標が必要
• ログ収集が必要です
• 信頼性 - 立ち上げを成功させるにはデータが重要です
• プルモデルは使用できません - プッシュが必要です
• ハードウェアだけでなくクラウドも一元的に監視する必要がある

最終的なイメージはこんな感じになりました

スタックの選択

そこで、監視スタックの選択という問題に直面しました。

まず最初に、すべての要件を同時にカバーし、同時にニーズに合わせて使用​​方法を調整できる柔軟性を備えた、最も完全なオールインワン ソリューションを探していました。 それでも、ハードウェア、アーキテクチャ、期限によって多くの制限が課せられていました。

のような本格的なシステムをはじめ、監視ソリューションは多種多様です。 Nagios, アイシング または ザビックス そして最後に、フリート管理のための既製のソリューションで終わります。

当初、後者は私たちにとって理想的なソリューションのように思えましたが、完全な監視ができないものもあれば、無料版の機能が大幅に制限されているものもあり、単に私たちの「要望」をカバーできなかったり、シナリオに適合するほど柔軟性がなかったりするものもありました。 単に時代遅れになっているものもあります。

多数の同様のソリューションを分析した結果、同様のスタックを自分で組み立てる方が簡単かつ迅速であるという結論にすぐに達しました。 はい、完全に既製のフリート管理プラットフォームを導入するよりも少し複雑になりますが、妥協する必要はありません。

ほぼ確実に、膨大な数のソリューションの中に、私たちに完全に適合する既製のソリューションがすでに存在しますが、私たちの場合は、特定のスタックを自分で組み立てて「自分用に」カスタマイズするほうがはるかに高速でした。既製品のテスト。

これらすべてを考慮して、私たちは監視プラットフォーム全体を自分たちで組み立てようとはせず、柔軟に構成できる機能を備えた、最も機能的な「既製」スタックを探していました。

(B)エルク?

実際に検討された最初のソリューションは、よく知られた ELK スタックでした。
すべては Beats から始まるので、実際には BELK と呼ぶべきです。 - https://www.elastic.co/what-is/elk-stack

もちろん、ELK は監視の分野で最も有名で強力なソリューションの XNUMX つであり、ログの収集と処理の分野ではさらに重要です。

私たちは、ELK をログの収集と、Prometheus から取得したメトリクスの長期保存に使用することを意図していました。

視覚化には Grafan を使用できます。

実際、新しい ELK スタックはメトリクスを独立して収集でき (metricbeat)、Kibana はメトリクスを表示することもできます。

しかしそれでも、ELK は当初ログから成長したため、これまでのところメトリクスの機能には多くの重大な欠点があります。

• プロメテウスよりも大幅に遅い
• プロメテウスよりもはるかに少ない場所に統合されます
• アラートを設定するのは難しい
• メトリクスは多くのスペースを占有します
• Kiban でのメトリクスを使用したダッシュボードの設定は、Grafan よりもはるかに複雑です

一般に、ELK のメトリクスは重く、他のソリューションほど便利ではありません。現在、そのメトリクスには Prometheus だけでなく、TSDB、Victoria Metrics、Cortex などがあります。 もちろん、本格的なオールインワンソリューションをすぐにでも実現したいのですが、metricbeat の場合は妥協が多すぎました。

そして、ELK スタック自体にもいくつかの困難な瞬間があります。

• かなり大量のデータを収集すると重くなり、場合によっては非常に重くなることもあります
• それを「調理する方法を知る」必要があります - スケールを調整する必要がありますが、これを行うのは簡単ではありません
• 必要なものを取り除いた無料バージョン - 無料バージョンには通常のアラートがなく、選択時に認証がありませんでした。

最近、最後の点が良くなってきていると言わざるを得ません。 オープンソース X-pack での出力 (認証を含む) 価格モデル自体が変わり始めました。

しかし、このソリューションを導入しようとした時点では、アラートはまったくありませんでした。
おそらく、ElastAlert や他のコミュニティ ソリューションを使用して何かを構築しようとすることもできましたが、それでも他の代替案を検討することにしました。

ロキ - グラファナ - プロメテウス

現時点では、良い解決策は、メトリクス プロバイダーとして Prometheus、ログ用に Loki、視覚化には同じ Grafana を使用することのみに基づいた監視スタックを構築することです。

残念ながら、プロジェクトの販売パイロット開始時点（19年0.3月～0.4月）では、Lokiはまだベータ版XNUMX～XNUMXであり、開発開始時点では製品版のソリューションとして考慮することができませんでした。全然。

私は本格的なプロジェクトで実際に Loki を使用した経験はまだありませんが、Promtail (ログ収集エージェント) は、Kubernetes のベアメタルとポッドの両方でうまく機能すると言えます。

ティック

おそらく、ELK スタックに代わる最も価値のある (唯一の?) フル機能の代替品は、現在、TICK スタック (Telegraf、InfluxDB、Chronograf、Kapacitor) としか呼ばれません。

以下ですべてのコンポーネントについて詳しく説明しますが、一般的な考え方は次のとおりです。

• Telegraf - メトリクスを収集するエージェント
• InfluxDB - メトリクス データベース
• Kapacitor - アラート用のリアルタイム メトリクス プロセッサ
• Chronograf - 視覚化のための Web パネル

InfluxDB、Kapacitor、および Chronograf については、それらをデプロイするために使用した公式の Helm チャートがあります。

Influx 2.0 (ベータ版) の最新バージョンでは、Kapacitor と Chronograf が InfluxDB の一部となり、個別に存在しなくなったことに注意してください。

テレグラフ

テレグラフ は、ステート マシンでメトリクスを収集するための非常に軽量のエージェントです。

彼はあらゆるものを大量に監視できます。 nginx до
サーバー minecraft.

これには多くの優れた利点があります。

• 高速かつ軽量 (Go で書かれている)
  • 最小限のリソースを消費します
• デフォルトでメトリクスをプッシュする
• 必要なすべてのメトリクスを収集します
  • 設定なしのシステムメトリクス
  • センサーからの情報などのハードウェアメトリクス
  • 独自のメトリクスを追加するのは非常に簡単です
• すぐに使える豊富なプラグイン
• ログを収集します

私たちにとってプッシュ メトリクスは必要であったため、その他の利点はすべて楽しい追加以上のものでした。

エージェント自体によるログの収集も、ログを記録するために追加のユーティリティを接続する必要がないため、非常に便利です。

Influx は、次の場合にログを操作するための最も便利なエクスペリエンスを提供します。 syslog.

Telegraf は、ICK スタックの残りの部分を使用しない場合でも、一般にメトリクスを収集するための優れたエージェントです。

ほとんどどこにでもメトリクスを書き込むことができるため、多くの人が利便性のために ELK やその他のさまざまな時系列データベースと組み合わせています。

流入DB

InfluxDB は TICK スタックの主要なコア、つまりメトリクスの時系列データベースです。
メトリクスに加えて、Influx はログも保存できます。ただし、本質的に、Influx のログはメトリクスとまったく同じですが、通常の数値インジケータの代わりに、主な機能がログ テキストの行によって実行されるだけです。

InfluxDB も Go で書かれており、(最も強力ではない) クラスター上の ELK と比較してはるかに高速に動作するようです。

Influx の優れた利点の XNUMX つは、データ クエリ用の非常に便利で豊富な API も含まれており、私たちはこれを非常に積極的に使用しました。

欠点 - $$$ またはスケーリング?

TICK スタックには、私たちが発見した欠点が XNUMX つだけあります。 ダーリン。 さらに。

有料版にあって無料版にはないものは何ですか?

私たちが理解できる限り、TICK スタックの有料バージョンと無料バージョンの唯一の違いはスケーリング機能です。

つまり、高可用性を備えたクラスターを構築できるのは、 エンタープライズ版.

本格的な HA が必要な場合は、料金を支払うか、松葉杖を使用する必要があります。 コミュニティ ソリューションがいくつかあります。たとえば、 influxdb-ha 有能なソリューションのように見えますが、本番環境には適していないことが書かれています。
流入口 - NATS を介してデータをポンピングするシンプルなソリューション (拡張する必要もありますが、これは解決できます)。

残念ですが、両方とも放棄されたようです。新しいコミットはありません。問題は、多くの点が異なる Influx 2.0 の新しいバージョンの近日リリースが予定されているためだと思います (情報はありません)まだスケーリング中です）。

公式には無料版があります リレー - 実際、これは原始的な HA ですが、バランスをとることによってのみ、
すべてのデータはロード バランサーの背後にあるすべての InfluxDB インスタンスに書き込まれるためです。
彼はいくつか持っています 制限 ポイントの上書きに関する潜在的な問題や、事前にメトリクスのベースを作成する必要性など
(これは InfluxDB の通常の作業中に自動的に行われます)。

そのほか シャーディングはサポートされていませんこれは、必要のない重複メトリクス (処理とストレージの両方) のための追加のオーバーヘッドを意味しますが、それらを分離する方法はありません。

ビクトリアメトリクス?

その結果、有料スケーリング以外のすべてにおいて TICK スタックに完全に満足していたにもかかわらず、残りの T_CK コンポーネントを残したまま、InfluxDB データベースを置き換えることができる無料のソリューションがないかどうかを確認することにしました。

時系列データベースは数多くありますが、最も有望なものは Victoria Metrics です。これには多くの利点があります。

• 少なくとも結果によれば、速くて簡単 ベンチマーク
• クラスターバージョンがあり、現在では良いレビューもあります
  • 彼女はシャードできる
• InfluxDBプロトコルをサポート

私たちは Victoria をベースにした完全なカスタム スタックを構築するつもりはなく、InfluxDB のドロップイン代替品として使用できることが主な希望でした。

残念ながら、InfluxDB プロトコルがサポートされているにもかかわらず、これは不可能です。InfluxDB プロトコルはメトリクスの記録にのみ機能します。「外部」で利用できるのは Prometheus API のみです。つまり、それに Chronograf を設定することはできません。

さらに、メトリクスでは数値のみがサポートされています (カスタム メトリクスには文字列値を使用しました - 詳細についてはセクションで説明します) 管理パネル).

明らかに、同じ理由で、VM は Influx のようにログを保存できません。

また、最適なソリューションを探していた時点では、Victoria Metrics はまだそれほど普及しておらず、ドキュメントがはるかに小さく、機能も弱かったことにも注意してください。
(クラスターのバージョンとシャーディングの詳細な説明は覚えていません)。

ベースの選択

その結果、パイロットでは引き続き単一の InfluxDB ノードに制限することが決定されました。

この選択には主な理由がいくつかありました。

• TICK スタックの機能全体がとても気に入りました
• すでに導入に成功しており、うまくいきました
• 締め切りは迫っており、他のオプションをテストする時間はあまり残されていませんでした。
• これほど重い負荷は予想していませんでした

パイロットの最初のフェーズでは多くのスクーターがありませんでしたが、開発中のテストではパフォーマンスの問題は明らかになりませんでした。

したがって、このプロジェクトでは、スケーリングの必要がなく、XNUMX つの Influx ノードで十分であると判断しました (最後の結論を参照)。

スタックとベースを決定しました。次に、TICK スタックの残りのコンポーネントについて説明します。

コンデンサ

Kapacitor は、データベースに入力されるメトリクスをリアルタイムで監視し、ルールに基づいてさまざまなアクションを実行できるサービスである TICK スタックの一部です。

一般に、これは潜在的な異常追跡と機械学習のためのツールとして位置付けられていますが (これらの機能が需要があるかどうかはわかりません)、最も一般的な使用例は、より一般的なアラートです。

それが通知に使用する方法です。 特定のスクーターがオフラインになったときに Slack アラートを設定し、スマート充電器や重要なインフラストラクチャ コンポーネントに対しても同じことを行いました。

これにより、問題に迅速に対応できるだけでなく、すべてが正常に戻ったという通知を受け取ることが可能になりました。

簡単な例: 「ボックス」に電力を供給する追加のバッテリーが故障したか、何らかの理由で電力が切れた場合、新しいバッテリーを取り付けるだけで、しばらくするとスクーターの機能が回復したという通知を受け取ることができます。

Influx 2.0 では、Kapacitor が DB の一部になりました

クロノグラフ

これまでさまざまな監視 UI ソリューションを見てきましたが、機能と UX の点で Chronograf に匹敵するものはないと言えます。

奇妙なことに、Web インターフェイスとして Grafan を使用して TICK スタックの使用を開始しました。
その機能については説明しませんが、あらゆるものをカスタマイズできる幅広い可能性は誰もが知っています。

ただし、Grafana は依然として完全に汎用的な機器ですが、Chronograf は主に Influx で使用するために設計されています。

そしてもちろん、このおかげで、クロノグラフはさらに賢くて便利な機能を搭載できるようになりました。

おそらく、Chronograf を使用する主な便利な点は、Explore を通じて InfluxDB の内部を表示できることです。

Grafana にはほぼ同じ機能があるように見えますが、実際には、Chronograf でのダッシュボードのセットアップはマウスを数回クリックするだけで (同時に視覚化を確認しながら) 行うことができますが、Grafana では遅かれ早かれ、 JSON 設定を編集します (もちろん、Chronograf では、手動で設定したダシャをアップロードし、必要に応じて JSON として編集できます。ただし、UI で作成した後にそれらを操作する必要はありませんでした)。

Kibana には、ダッシュボードとそのコントロールを作成するためのより豊富な機能がありますが、そのような操作の UX は非常に複雑です。

便利なダッシュボードを作成するには、ある程度の理解が必要です。 また、Chronograf ダッシュボードの機能は少ないものの、作成とカスタマイズははるかに簡単です。

ダッシュボード自体は、快適なビジュアル スタイルを除けば、実際には Grafana や Kibana のダッシュボードと何ら変わりません。

クエリ ウィンドウは次のようになります。

とりわけ、InfluxDB データベース内のフィールドのタイプを知ると、クロノグラフ自体がクエリの作成や平均値などの正しい集計関数の選択に自動的に役立つ場合があることに注意することが重要です。

そしてもちろん、Chronograf はログを表示するのに可能な限り便利です。 次のようになります。

デフォルトでは、Influx ログは syslog を使用するように調整されているため、重大度という重要なパラメータがあります。

上部のグラフは特に便利で、発生したエラーが表示され、重大度が高いかどうかが色ですぐにわかります。

この方法で重要なバグを何度か捕捉し、先週のログを表示して赤いスパイクを確認しました。

もちろん、このようなエラーに対するアラートを設定するのが理想的です。これについてはすでにすべてが揃っているためです。

しばらくの間これをオンにしていましたが、パイロットの準備の過程で、かなり多くのエラー (LTE ネットワークが利用できないなどのシステムエラーを含む) が発生し、Slack チャネルにも「スパム」が発生していることが判明しました。何も問題を引き起こすこともなく、大きなメリットがあります。

正しい解決策は、この種のエラーのほとんどを処理し、重大度を調整してからアラートを有効にすることです。

こうすることで、新しいエラーまたは重要なエラーのみが Slack に投稿されます。 厳しい締め切りを考えると、そのようなセットアップを行うには十分な時間がありませんでした。

認証

Chronograf が認証として OAuth と OIDC をサポートしていることにも言及する価値があります。

これは、サーバーに簡単に接続して本格的な SSO を作成できるため、非常に便利です。

私たちの場合、サーバーは キークローク — モニタリングに接続するために使用されましたが、スクーターとバックエンドへのリクエストの認証にも同じサーバーが使用されました。

「管理者」

最後に説明するコンポーネントは、Vue で独自に作成した「管理パネル」です。
基本的には、独自のデータベース、マイクロサービス、InfluxDB のメトリクス データからのスクーター情報を同時に表示する単なるスタンドアロン サービスです。

さらに、緊急の再起動やサポート チームのリモートによるロックの解除など、多くの管理機能がそこに移動されました。

地図もありました。 Chronograf ではなく Grafana から始めたことはすでに述べました。Grafana ではマップがプラグインの形式で利用可能であり、スクーターの座標を表示できるからです。 残念ながら、Grafana のマップ ウィジェットの機能は非常に限られているため、現時点での座標を確認するだけでなく、スクーターが通ったルート、地図上のデータをフィルタリングできるなど (単純なダッシュボードでは構成できなかったすべての機能)。

すでに述べた Influx の利点の XNUMX つは、独自のメトリクスを簡単に作成できることです。
これにより、さまざまなシナリオでの使用が可能になります。

私たちは、バッテリー充電、ロック状態、センサーのパフォーマンス、Bluetooth、GPS、その他多くのヘルスチェックなど、すべての有用な情報をそこに記録しようとしました。
これらすべてを管理パネルに表示しました。

もちろん、私たちにとって最も重要な基準はスクーターの動作状態でした。実際、Influx 自体がこれをチェックし、ノード セクションに「青信号」で表示します。

これは関数によって行われます 死人 — これを使用してボックスのパフォーマンスを理解し、同じアラートを Slack に送信しました。

ちなみに、私たちはスクーターに『シンプソンズ』の登場人物の名前にちなんで名付けました。お互いに区別するのにとても便利でした。

そして一般的には、こちらの方が楽しかったです。 「みんな、スミザーズは死んだ！」のようなフレーズが絶えず聞かれました。

文字列メトリクス

Victoria Metrics の場合のように、InfluxDB では数値だけでなく保存できることが重要です。

これはそれほど重要ではないように思えますが、結局のところ、ログとは別に、あらゆるメトリクスを数値の形式で保存できます (既知の状態のマッピングを追加するだけです - 一種の列挙型です)。

私たちの場合、文字列メトリクスが非常に役立つシナリオが少なくとも XNUMX つありました。
たまたま、当社の「スマート充電器」のサプライヤーがサードパーティであったため、開発プロセスとこれらの充電器が提供できる情報を当社は制御できませんでした。

結果として、課金 API は理想からはほど遠いものになりましたが、主な問題は、その状態を常に把握できないことでした。

ここでInfluxが助けになりました。 受け取った文字列ステータスを変更せずに InfluxDB データベース フィールドに書き込むだけです。

しばらくの間は、「オンライン」や「オフライン」などの値のみが取得され、その情報に基づいて管理パネルに表示され、通知が Slack に送信されました。 しかし、いつからかそこには「断絶」といった価値観も現れ始めた。

後で判明したことですが、このステータスは、一定回数試行しても充電器がサーバーとの接続を確立できなかった場合に、接続が失われた後に XNUMX 回送信されたものでした。

したがって、固定の値セットのみを使用した場合、適切なタイミングでファームウェアにこれらの変更が表示されない可能性があります。

また、一般に、文字列メトリクスは使用できる可能性がはるかに高く、事実上あらゆる情報を文字列メトリクスに記録できます。 もちろん、このツールを慎重に使用する必要もあります。

通常のメトリクスに加えて、GPS 位置情報も InfluxDB に記録しました。 これは、管理パネルでスクーターの位置を監視するのに非常に役立ちました。
実際、必要なときにどのスクーターがどこにあるかを常に知っていました。

これは、スクーターを探していたときに非常に役立ちました (最後に結論を参照)。

インフラ監視

スクーター自体に加えて、(かなり広範囲にわたる) インフラストラクチャ全体を監視する必要もありました。

非常に一般的なアーキテクチャは次のようになります。

純粋な監視スタックを強調表示すると、次のようになります。

クラウド上で確認したいことは次のとおりです。

• データベース
• キークローク
• マイクロサービス

すべてのクラウド サービスは Kubernetes に配置されているため、その状態に関する情報を収集するとよいでしょう。

幸いなことに、Telegraf はそのままの状態で Kubernetes クラスターの状態に関する膨大な数のメトリクスを収集でき、Chronograf はこれのための美しいダッシュボードをすぐに提供します。

主にポッドのパフォーマンスとメモリ消費量を監視しました。 転倒の場合は、Slack でアラートが送信されます。

Kubernetes でポッドを追跡するには、DaemonSet と Sidecar の XNUMX つの方法があります。
どちらの方法も詳しく説明されています このブログ投稿で.

Telegraf Sidecar を使用し、メトリクスに加えてポッド ログを収集しました。

私たちの場合、ログをいじる必要がありました。 Telegraf は Docker API からログを取得できるという事実にもかかわらず、エンド デバイスでログを均一に収集したいと考え、そのためにコンテナ用に syslog を構成しました。 おそらくこのソリューションは美しくありませんでしたが、その動作については不満はなく、ログは Chronograf で適切に表示されました。

モニター監視???

結局、監視システムの監視という長年の問題が浮上しましたが、幸か不幸か、これには十分な時間がありませんでした。

ただし、Telegraf は独自のメトリクスを簡単に送信したり、InfluxDB データベースからメトリクスを収集して同じ Influx または別の場所に送信したりできます。

所見

パイロットの結果からどのような結論が得られましたか?

モニタリングはどのように行うことができますか?

まず第一に、TICK スタックは私たちの期待を完全に満たし、当初の期待よりもさらに多くの機会を与えてくれました。

必要な機能はすべて揃っていました。 私たちがそれを使ってやったことはすべて問題なく動作しました。

Производительность

無料版の TICK スタックの主な問題は、スケーリング機能が欠如していることです。 これは私たちにとって問題ではありませんでした。

正確な負荷データ/数値は収集しませんでしたが、一度に約 30 台のスクーターからデータを収集しました。

それぞれが 10 を超えるメトリクスを収集しました。 同時に、デバイスからのログも収集されました。 データの収集と送信は XNUMX 秒ごとに行われました。

パイロットの 30 週間半後、「子供時代の問題」の大部分は修正され、最も重要な問題はすでに解決されていたため、サーバーにデータを送信する頻度を減らす必要があったことに注意することが重要です。 XNUMX秒。 LTE SIM カードのトラフィックがすぐになくなり始めたため、これが必要になりました。

トラフィックの大部分はログによって消費され、メトリクス自体は、10 秒間隔であっても実質的に無駄にはなりませんでした。

その結果、一定の問題を継続的に収集しなくても特定の問題がすでに明らかであったため、しばらくしてからデバイス上のログの収集を完全に無効にしました。

場合によっては、それでもログの表示が必要な場合は、VPN 経由で Wi​​reGuard 経由で接続するだけで済みました。

また、それぞれの環境は互いに分離されており、上記の負荷は実稼働環境にのみ関連するものであることも付け加えておきます。

開発環境では、10 秒ごとにデータを収集し続ける別の InfluxDB インスタンスを起動しましたが、パフォーマンスの問題は発生しませんでした。

TICK - 小規模から中規模のプロジェクトに最適

この情報に基づいて、TICK スタックは比較的小規模なプロジェクト、または高負荷がまったく期待されないプロジェクトに最適であると結論付けます。

数千のポッドや数百のマシンがない場合は、XNUMX つの InfluxDB インスタンスでも負荷を適切に処理できます。

場合によっては、原始的な高可用性ソリューションとしての Influx Relay に満足するかもしれません。

そしてもちろん、「垂直」スケーリングを設定し、さまざまな種類のメトリクスにさまざまなサーバーを割り当てることを妨げる人は誰もいません。

監視サービスに予想される負荷がわからない場合、または非常に「重い」アーキテクチャになることが確実な場合、または今後使用することが確実な場合は、TICK スタックの無料バージョンを使用することはお勧めしません。

もちろん、簡単な解決策は購入することです InfluxDB エンタープライズ - しかし、私自身がその微妙な点に精通していないため、ここではどういうわけかコメントできません。 それに加えて、それは非常に高価であり、中小企業には明らかに適していません。

この場合、今日は、Victoria Metrics を通じてメトリクスを収集し、Loki を使用してログを収集することを検討することをお勧めします。

確かに、Loki/Grafana は既製の TICK に比べて (汎用性が高いため) はるかに便利ではありませんが、無料です。

それが重要だ: ここで説明されている情報はすべて、バージョン Influx 1.8 に関連しており、現時点では Influx 2.0 がリリースされようとしています。

戦闘環境で試す機会がなかったので改善点について結論を出すのは難しいですが、インターフェイスは間違いなくさらに良くなり、アーキテクチャは簡素化されました（コンデンサーとクロノグラフなし）。
テンプレートの登場 (「キラー機能」 - Fortnite でプレイヤーを追跡し、お気に入りのプレイヤーがゲームに勝ったときに通知を受け取ることができます）。 しかし、残念ながら、現時点では、バージョン 2 には、最初のバージョンを選択した重要な機能がありません。つまり、ログ収集がありません。

この機能は Influx 2.0 でも登場する予定ですが、おおよその期限さえも見つけることができませんでした。

IoTプラットフォームを作らない方法（今）

最終的に、パイロットを開始した後、私たちの基準に適した代替手段が存在しない中で、私たち自身が独自の本格的な IoT スタックを組み立てました。

ただし、最近ベータ版で利用できるようになりました オープンバレナ — 私たちがプロジェクトを作り始めたときに彼女がいなかったのは残念です。

最終結果と、自分たちで組み立てた Ansible + TICK + WireGuard をベースにしたプラットフォームに完全に満足しています。 しかし今日は、独自の IoT プラットフォームを自分で構築してみる前に、Balena を詳しく見てみることをお勧めします。

なぜなら、最終的には私たちが行ったことのほとんどを実行でき、OpenBalena は無料でオープンソースだからです。

アップデートを送信する方法だけでなく、VPN もすでに組み込まれており、IoT 環境での使用に合わせて調整されています。

そしてつい最近、彼らは Hardware、エコシステムに簡単に接続できます。

ねえ、行方不明のスクーターはどうしたの？

こうしてスクーター「ラルフ」は跡形もなく消えた。

私たちはすぐに走って、InfluxDB からの GPS メトリクス データを含む「管理パネル」の地図を確認しました。

監視データのおかげで、スクーターが昨日の21時頃に駐車場を出て、約00分かけてある地域まで走り、ドイツ人の家の隣で午前5時まで駐車されていたことが容易に判明しました。

午前 5 時以降、監視データは受信されませんでした。これは、追加のバッテリーが完全に放電したか、攻撃者がスクーターからスマート ハードウェアを取り外す方法を最終的に見つけたかのいずれかを意味します。
それにもかかわらず、スクーターが置かれていた住所に警察が呼び出された。 スクーターはそこにはありませんでした。

しかし、家の所有者も、昨夜、実際にこのスクーターに乗って会社から帰ってきたので、これには驚いていました。

結局のところ、サポート従業員の XNUMX 人が早朝に到着し、スクーターを引き取り、追加のバッテリーが完全に放電しているのを見て、(徒歩で) 駐車場まで運びました。 そして、追加のバッテリーが湿気のせいで故障しました。

私たちは自分たちからスクーターを盗みました。 ちなみに、警察の事件は誰がどのように解決したのかは分かりませんが、監視は完璧に機能していました...

出所： habr.com