はじめに
新しいIoT ruleを作成した時、IoT ruleの設定を変更した時、その他諸々... IoT ruleの設定ミスでルーティングがうまくいかないことはありませんか？
そんな時、ささっとトラブルシューティングしたいですよね。
今回は簡単にトラブルシューティングを行う方法の一つとして、IoT ruleのエラーアクションを使ってIoT Coreのテストクライアント上でトラブルシューティングを行う方法を紹介します。
今回の方法はIoT ruleのルーティングが失敗した場合に有効な方法です。
ルーティングはできたけど、後続のサービスで処理が失敗した。という場合には別のアプローチが必要になります。
全体のイメージ
まずは通常のIoT ruleによるルーティングです。
下の図はIoTデバイスから受け取ったメッセージをDynamoDBにルーティングする図です。
今回は何らかの理由でDynamoDBへルーティングできなかったことを想定してトラブルシューティングをしてみたいと思います。
トラブルシューティングのために、ルーティングに失敗した場合はエラーアクションで別のトピックにRepublishするように設定します。
今回はこの一連の流れをテストクライアントを使って確認していきます。
やってみた
DynamoDBへのルーティング成功パターン
まずは普通にDynamoDBにルーティングが成功することを確認します。
IoT ruleで demo/success トピックにメッセージが届いた際、DynamoDBにルーティングするように設定します。
それではテストクライアントを使って以下のメッセージを demo/success トピックに送信します。
{ "deviceid": "demo_device01", "temperture": 22.5, "location": "osaka"}
テストクライアント上ではメッセージがサブスクライブされていますね。
ではメッセージがDynamoDBに登録されていることを確認します。
IoT ruleのルール通りにDynamoDBにデータが登録されていることが確認できます。
DynamoDBへのルーティング失敗パターン
次にIoT ruleが失敗するパターンを確認します。 今回はDynamoDBのテーブルを削除して、ルーティング先が存在しない状況を作ります。
それではテーブルを削除したあと、先ほどと同じようにテストクライアントからメッセージを送信します。
テストクライアント上はメッセージが表示されているのでルーティングされているように見えます。 しかし実際はテーブルが存在しないためエラーが出ています。
この時、IoT Coreのログを設定していればCloudWatchからエラーが出力されていることを確認できます。
ではこれをCloudWatchを使わずにIoT Coreのみで簡単に確認したいと思います。
DynamoDBへのルーティング失敗パターン(エラーアクション追加)
まずはIoT ruleのエラーアクションを追加します。
現在のIoT ruleを編集してエラー時に demo/errorトピックにRepublishするように設定します。
それでは再度テストクライアントからメッセージを送信します。
この時、エラーメッセージがRepublishされたことを確認できるように demo/error もサブスクライブしておきます。
画面上は先ほどと同じようにメッセージがサブスクライブされていますが、今回は demo/error にもメッセージが飛んでいますね。
それでは demo/error を見てみましょう。
何やらエラーメッセージを受け取ってますね。
内容を見てみましょう
DynamoDBv3 Put record failed. The error received was Requested resource not found (Service: AmazonDynamoDBv2...
テーブルが見つからなかったので書き込みが失敗したことが書かれています。
このようにルーティングが失敗した場合、別のトピックにRepublishすることでテストクライアント上ですぐに確認を行うことができます。
まとめ
エラーアクションで別のトピックにRepublishすることで、ルーティンが失敗した場合にテストクライアント上で原因を調査することができます。 ちょっとした検証や、新規作成時の動作確認などにチャチャっと設定できるので皆さんもぜひ使ってみて下さい。
8
