プロダクションIoTデバイスの例外とエラーを追跡しますか？

現在、企業はIoTデバイス、ゲートウェイ、プラットフォームのエラーをどのように追跡していますか？私の会社はすべてのデバイスからのログを集約するためにpapertrailを使用していますが、これにより、実稼働でエラーが発生したときに、複数のシステム間で引っ掻き回されることがよくあります。

1つの場所（IoTプラットフォームなど）で生成された可能性があるが、他の場所の問題の結果として発生した例外を解決するときに、「根本原因になるまでの時間」を短縮する方法を探していますスタック—エッジデバイスからのデータエラーなど。

この分野で私が見つけた点では、SentryとRollbarはサーバーまたはアプリでの例外追跡には適していますが、前の段落で説明したようにカスケードエラーを追跡する手段は提供していません。

これをテキストロギングよりも上手に行うためのシステムはありますか？私は特に、Sentryから取得したブレッドクラムスタイルのイベントを利用しようとしていますが、分散システム全体を追跡しています。

分散トレース

価値ある分散トレースの背後にある考え方は、Dapperソリューションに関するこのGoogleホワイトペーパーで最もよく知られています。彼らがそれを発明したと言っているのではないことに注意してください。本質的にはIoTでも同じように機能し、バックエンドまたはエンドデバイスの端でトレースを開始するだけです。

Googleのホワイトペーパーは多かれ少なかれサーバー側のシステムに焦点を当てていますが、この概念はエンドデバイスを含めるように簡単に適合させることができます。トレースIDとスパンIDを使用してシステム全体のすべての情報をトレースする魔法は、Netflixが最近オープンソース化したVizceralを介して行うすべての視覚化で見ることができます。ブログの「Regional View」の下で視覚化されているのは、呼び出しがトレースIDによって関連付けられているライブログ分析に完全に基づいています。GoogleがDapperの論文で言及しているように、Netflixには、APIでパターン化された呼び出しのサンプルがあります。Googleは紙面に1：1000と書いてあります—これは数年前のものです。どうやらNetflixはすでにいくつかのリクエストタイプで100万に達しているようです。

私はあなたのシステムについては知りませんが、実際の100％トレースで開始できる可能性が非常に高いです。

どちらの方法でも、最初からトレースをIoTデバイスに一致させるか、最初にエンドポイントにトレースIDを作成できる限り、エッジデバイスを含む方法でこれらのアイデアを適応させることを妨げるものは何もありません。