セルラー IoT デバイスの監視では、1 つの監視方法だけで状態を言い切れません。デバイスが動いているかどうかを確認する監視（死活監視）でも、デバイス側から状態を送る監視と、クラウド側から確認しに行く監視では、確認できる範囲が異なります。データが届かないときや応答が返らないときに、どこまで確認できていて、どこから先を切り分けるかを整理しやすくするため、このページでは、デバイス側で何を監視データに含め、クラウド側で何を確認するかを分けて、監視設計の指針を整理します。
この内容が役立つケース
- デバイスが急に停止したときに、まず異常に気づき、次に何を確認するか分かるようにしたい。
- デバイスからデータが来ないときに、どの部分から調査するかの方針を決めたい。
- デバイスから状態を送る監視と、クラウド側から確認しに行く監視の違いを理解したい。
- 定期送信をしないユースケースでも、ping 応答や HTTP 応答を含めた監視方法を設計したい。
- 多数デバイスの通信量異常や停止傾向を早めに把握したい。
監視方式の概要
このページでは、監視の起点をデバイス起点監視（Push 型）とクラウド起点監視（Pull 型）に分けて整理します。あわせて、全体傾向を見る補助信号として通信量監視も扱います。
| 監視方式 | このページでの意味 | 主な監視信号 | 向いているケース |
|---|---|---|---|
| デバイス起点監視（Push 型） | デバイスから送られた状態をもとに、クラウド側で状態を確認する監視 | 送信データの到着、No data | 定期送信があるユースケース、継続監視 |
| クラウド起点監視（Pull 型） | クラウドからデバイスへ要求を送り、応答があるかどうかを確認する監視 | ping 応答、HTTP 応答 | 定期送信が少ないユースケース、補助的な疎通確認 |
| 通信量監視 | SORACOM 側で集計される通信量をもとに、全体の異常傾向を監視する方法 | 日次・月次通信量 | グループ / オペレーター単位の全体傾向監視 |
監視方式を整理するときの見かた
実装や設定に落とし込むときは、次の順で確認すると整理しやすくなります。
- まずデバイス側で、どの構成要素の状態を監視データに含めるか決めます。
- 次にクラウド側で、送信データ、ping 応答、HTTP 応答、通信量をどう組み合わせて判断するか決めます。
- そのうえで、アラート条件、通信量しきい値、復旧方針を決めます。
- 実装や設定の詳細は、末尾の関連する SORACOM ドキュメントと元資料を確認します。
具体手法と確認できる範囲
手法ごとに、確認できる範囲と限界を分けて設計します。
| 具体手法 | 監視方式 | 主に確認できる範囲 | 主な注意点 | 主な SORACOM 機能 |
|---|---|---|---|---|
| 送信データ監視（No data を含む） | デバイス起点監視（Push 型） | アプリケーション、オペレーティング・システム (Operating System, OS)、ファームウェア、通信モジュール、送信先までの経路 | 送信周期が長すぎると異常検知も遅くなる。Alert の評価間隔と評価範囲の設計が必要。 | SORACOM Harvest Data、SORACOM Lagoon 3 |
| 通信量監視 | 通信量監視 | グループ / オペレーター単位の利用傾向 | 個々のデバイスが動いているかどうかの判断には向かない。しきい値超過以外の傾向監視は別の監視基盤も検討する。 | イベントハンドラー、SORACOM API |
| ping 応答監視 | クラウド起点監視（Pull 型） | 通信モジュール、セッション、回線疎通 | モデムだけが応答する場合がある。ping が通ってもデータ送受信は失敗しうる。 | デバイスへの疎通を確認する (ping 送信)、SORACOM Flux |
| HTTP 応答監視 | クラウド起点監視（Pull 型） | Web サーバーを持つデバイス / ゲートウェイの応答処理（アプリケーションを含む） | デバイス側 Web サーバーとアクセス経路が必要。 | SORACOM Napter、SORACOM Gate |
デバイス側で監視データに含める項目
デバイス側では、どの構成要素の状態を監視データに含めるかを先に決めます。特に、アプリケーション、OS、ファームウェア、通信モジュールに分けて考えると、収集漏れを防ぎやすくなります。
| デバイスアーキテクチャの要素 | 代表的な監視項目 | 取得方法の例 | クラウド側での使い方 |
|---|---|---|---|
| アプリケーション | 送信成功/失敗、キュー滞留、最終送信時刻 | アプリログ、ヘルスカウンター | 送信データ監視の主信号として利用する |
| OS | プロセス再起動回数、メモリ使用率、時刻同期状態 | OS メトリクス、監視エージェント | しきい値監視や運用ダッシュボードに利用する |
| ファームウェア | バージョン、更新結果、ブート回数、ホスト側とモジュール側インターフェースのエラー回数（AT タイムアウト、UART/USB エラー、初期化失敗） | バージョン情報の定期送信、ファームウェア内エラーカウンター | 更新影響とインターフェース異常の切り分けに利用する |
| 通信モジュール | 電波強度、セッション状態、再接続回数 | モデム AT 応答、メタデータ | 回線状態の補助信号として利用する |
デバイス側で監視データに含める項目を決めたら、次はクラウド側でどの信号をどう組み合わせて判断するかを整理します。クラウド側では、デバイス側から送られた信号と SORACOM 側で取得できる信号を組み合わせて判断します。
デバイス起点監視（Push 型）を設計する
送信データ監視
デバイス起点監視（Push 型）は、多くのケースで基本となる監視方法です。デバイスが一定間隔でデータを送信し、そのデータが届いているかどうかで、個々のデバイスが動いているかどうかを継続的に確認します。定期データが届いていることを確認できれば、少なくともその時点では、アプリケーション、OS、ファームウェア、通信モジュール、セルラー回線、送信先までの経路が動いていると考えられます。
定期的な状態報告として送るデータは、異常時だけでなく平常時にも送るようにします。異常時だけしか送らない設計では、「異常がない」のか「そもそも送れなくなっている」のかを区別しにくくなるためです。
Lagoon 3 の No data 監視は評価間隔と評価範囲を合わせます
SORACOM Lagoon 3 でデータの有無を監視するときは、Alert rule の評価間隔と評価範囲を、利用プランのデータ取得間隔に合わせて設計してください。直近すぎる時間範囲を評価すると、データが届いていても No data になることがあります。
デバイス起点監視（Push 型）は、SORACOM Harvest Data と SORACOM Lagoon 3 を組み合わせる構成例がありますが、送信先は自社サーバーやクラウドサービスでも構いません。重要なのは、「定期送信が止まったこと」をクラウド側で確認できることです。
通信量監視で全体の異常傾向を見る
通信量監視は、個々のデバイスが動いているかどうかを見るというより、グループやオペレーター全体で異常が起きていないかを見るための監視です。たとえば、想定外の再送やループで通信量が急増したときに早めに気づけます。
イベントハンドラー では、グループ / オペレーターに紐づく全 IoT SIM の日次・月次データ通信量合計に対して、しきい値を超えたときの通知を設定できます。
通信量監視は補助信号として使います
通信量監視は、「増えすぎ」には気づきやすい一方で、個々のデバイスが動いているかどうかの確認には向きません。個々のデバイスの継続監視は、デバイス起点監視（Push 型）やクラウド起点監視（Pull 型）で行い、通信量監視は全体傾向の把握に使います。
また、しきい値超過だけでなく「想定より通信量が少ない」「いつもと傾向が違う」を見たい場合は、グループ / オペレーターの通信量を外部の監視基盤に保存し、時系列で評価する方法も検討します。たとえば、Amazon CloudWatch のような監視基盤に定期的に保存してトレンドを見る方法が考えられます。
クラウド起点監視（Pull 型）を設計する
ping 応答監視
ping 応答監視は、オンラインの IoT SIM を利用するデバイスに対して、SORACOM から ping を送信して応答を確認する方法です。ユーザーコンソールから手動で実行するだけでなく、SORACOM Flux のインターバルタイマーイベントソース と SORACOM API アクション を組み合わせると、定期実行と通知をまとめて構成できます。実際の構成例は、SORACOM API アクションを利用して IoT デバイスを死活監視する を参照してください。
ping だけでデバイス全体の正常性は判断しません
- デバイスではなく、モデムが SORACOM からの ping に応答する場合があります。
- ping が成功しても、実際のデータ送信先までデータが届くとは限りません。
- ping を送れるのは、IoT SIM のセッションが オンライン のときだけです。
そのため、ping 応答監視は「クラウド側からの疎通を補助的に確認する方法」として使い、デバイス起点監視（Push 型）と組み合わせるのが基本です。
HTTP 応答監視
HTTP 応答監視は、デバイスやゲートウェイが Web サーバーや Web API を持っているときに、その応答を確認する方法です。ping よりもアプリケーション寄りの状態まで確認できますが、前提条件が増えます。
- デバイス側で Web サーバーが動いている必要があります。
- IoT SIM はプライベート IP アドレスで通信するため、インターネットから直接 HTTP アクセスはできません。
- 定常的な監視には SORACOM Gate のような常設経路、一時的な確認には SORACOM Napter のようなオンデマンド接続が向きます。
HTTP 応答監視は、もともと管理画面や API を持つデバイスでは有効ですが、監視専用のために Web サーバーを追加するかどうかは、運用負担と合わせて判断してください。
監視データに含めると運用しやすい情報
アラート運用を安定させるために、監視用データには状態把握に役立つ補助情報も含めておきます。
電波強度
デバイスが観測している電波強度は、調査時に見たい情報になりやすいため、デバイス側で取得して残す設計にしておくことを推奨します。ユーザーコンソールのセッション確認だけでは追いにくい情報のため、あとから調査できる形で残しておくことが重要です。
- 時系列で変化を見たい場合は、SORACOM Harvest Data などの送信データに含めます。
- 最新値だけをすぐ参照したい場合は、メタデータサービス を使ってタグに保持する方法もあります。
バッテリー残量
バッテリー駆動のデバイスでは、通信異常と見えていたものが実際には電源要因であることがあります。監視用のデータには、電波強度に加えてバッテリー残量も含めておくと、切り分けがしやすくなります。
監視だけでなく復旧方針も決める
セルラーセッションは、移動、電波状況、電源状態、基地局側の都合などで意図しないタイミングに切れることがあります。したがって、セッション切断そのものを即座に異常と決めつけるのではなく、切れたときにどう再試行し、アプリケーションがどう振る舞うかを先に決めておくことが重要です。
- 無制限な再試行や頻繁な再起動は避けます。
- 送れなかったデータを一時保存し、指数関数的バックオフで再試行します。
- アプリケーション側で、再接続後に送信を再開できるようにします。
再試行や回復設計については、以下のページもあわせて参照してください。
監視方式の組み合わせ例
迷ったときは、以下の 3 つの観点で組み合わせると整理しやすくなります。
- 基本の継続監視
デバイスから小さな定期データを送信し、デバイス起点監視（Push 型）で送信データの有無を監視する。 - 補助的な疎通確認
必要に応じて、クラウド起点監視（Pull 型）として SORACOM からの ping を定期実行し、セルラー疎通を別信号で確認する。 - 全体傾向の監視
グループ / オペレーター単位の通信量を監視して、増えすぎや運用異常を早めに把握する。
デバイスに Web サーバーや Web API があり、応答処理の確認まで必要な場合だけ、HTTP 応答監視を追加します。
関連する SORACOM ドキュメント
- SORACOM からの ping: デバイスへの疎通を確認する (ping 送信)
- 定期 ping の構成例: SORACOM API アクションを利用して IoT デバイスを死活監視する
- セッション確認と見え方: IoT SIM の通信状況 (セッション) を確認する
- データ蓄積: SORACOM Harvest
- No data を含む Alert 設計: Alert rule を設定する
- Alert の時間設計: Alert の概要
- 通知結果の確認: Alert group を確認する
- 通信量しきい値監視: イベントハンドラーのルール
- 一時的な HTTP / TCP アクセス: SORACOM Napter
- 常設のプライベートアクセス: SORACOM Gate
- タグの活用: デバイスで IoT SIM の情報を利用する (メタデータサービス)
元記事・元資料
このページは、以下の記事・資料をもとにしています。
正確な内容や最新の情報を確認するときは、元の記事・資料もあわせて参照してください。
- SORACOM 公式ブログ: デバイスの通信量を監視しよう！ ～オペレーターやグループ単位で通信量が取れるようになりました～
- SORACOM Users: SORACOM API アクションを利用して IoT デバイスを死活監視する
- Speaker Deck: IoTデバイスの死活監視を考える