監視

監査ログ

監査ログには、ユーザーが処理したセキュリティ関連の操作が表示されます。例えば、ユーザーがゲートウェイにログインすると監査ログが生成されます。

監査ログの表示

監査ログリストを表示するには、アカウントメニューの監査ログをクリックします。ログエントリごとに、次の情報が表示されます。

列	説明
サーバー時間	オペレーションが処理されたサーバー時刻
イベント	オペレーションのタイプ。例えば「アラームが作成されました」「スマートルールが削除されました」など。その下には、処理したユーザーが表示されます
説明	オペレーションに応じて、デバイス名、アラーム テキスト、操作ステータスなどの詳細情報を提供します
デバイス時間	オペレーションが処理されたデバイス時刻。サーバー時間と異なる場合があります

最新の100件のログのみが表示されます。さらにログエントリを表示するには、ページを下にスクロールしてさらに読み込むをクリックします。

ログのフィルタリング

ログを簡単に検索するために、次の要素で絞り込むことができます。

• タイプ（アラーム、操作、スマートルールなど）
• デバイス時間（「From」および／または「To」入力欄で日付範囲を指定）
• ユーザー

フィルターを適用するには、各フィルター フィールドの横にある フィルターを適用 ボタンをクリックします。フィルターを破棄するには、フィルターを適用 ボタンの横にある アイコンをクリックします（フィルターが設定されている場合にのみ表示されます）。

監査ログの種類

監査の種類	アクション
アラーム	アラームが作成されました アラームが更新されました
アプリケーション	アプリケーションが有効化されました アプリケーションがサブスクライブされました アプリケーションのサブスクライブが解除されました アプリケーションがデプロイされました アプリケーションのデプロイに失敗しました アプリケーションがアンデプロイされました アプリケーションが再スケーリングされました アプリケーションが削除されました このタイプの監査ログは、ホストされたアプリケーションとマイクロサービスの両方に対して作成される場合があります。
一括操作	一括操作が作成されました 一括操作が更新されました 一括操作が削除されました
データブローカーコネクタ	コネクタが作成されました コネクタが更新されました コネクタが削除されました
デバイス可用性監視	デバイス可用性が有効化されました デバイス可用性が無効化されました デバイス可用性の間隔が更新されました デバイスがメンテナンス状態になりました
グローバルロール	グローバルロールが更新されました グローバルロール権限が更新されました グローバルロールのデバイス権限が更新されました
インベントリ	マネージドオブジェクトが削除されました トークンが見つからないため、デバイスの登録に失敗しました トークンが無効なため、デバイスの登録に失敗しました デバイス登録の試行失敗の最大数に達しました
インベントリロール	インベントリロールが作成されました インベントリロールが更新されました インベントリロールが削除されました
オペレーション	オペレーションが作成されました オペレーションが更新されました
オプション	オプションが作成されました オプションが更新されました オプションが削除されました
信頼性の高い通知	信頼性の高い通知トークンが作成されました 信頼性の高い通知サブスクリプションが作成されました 信頼性の高い通知サブスクリプションが削除されました
レポート	テストテナント統計にアクセスしました 実テナント統計にアクセスしました
シングルサインオン	SSOログイン SSOログアウト SSO ログアウトに失敗しました
スマートルール	スマートルールが作成されました スマートルールが更新されました スマートルールが有効化されました スマートルールが無効化されました スマートルールが削除されました
テナント	テナントが作成されました テナントが更新されました テナントが一時停止されました テナントが有効化されました テナントが削除されました
テナント認証の構成	認証設定が追加されました 認証設定が更新されました 認証設定が削除されました
信頼できる証明書	信頼できる証明書がアップロードされました 信頼できる証明書が更新されました 信頼できる証明書が削除されました
テナント証明機関	テナント証明機関（CA）が作成されました テナント証明機関（CA）が更新されました テナント証明機関（CA）の更新に失敗しました テナント証明機関（CA）が証明書に署名しました
ユーザー	ユーザーが作成されました ユーザーが更新されました ユーザーのユーザー名が更新されました ユーザーパスワードが更新されました ユーザーのロールが更新されました ユーザーのグループが更新されました ユーザーの権限委譲が更新されました ユーザー所有者が更新されました ユーザーインベントリの割り当てが更新されました ユーザーのデバイス権限が更新されました ユーザーが削除されました ユーザーのデバイスプロビジョニング証明書が作成されました ユーザーのデバイスプロビジョニング証明書が削除されました
ユーザーログイン	ユーザーログイン ユーザーのログアウト Basic認証を使用する場合、このタイプのエントリは作成されないことに注意してください。

メッセージングサービス

Messaging Serviceは、Things Cloudプラットフォームに組み込まれたpublish/subscribeメッセージングおよびメッセージストリーミングのコンポーネントです。 これは、プラットフォームコンポーネント間の非同期通信と、リアルタイムデータをプラットフォームに入出力するためのユーザー向け機能を提供します。 Messaging Serviceを使用する機能には、マイクロサービスベースのデータブローカー、Notifications 2.0、およびMQTT Serviceが含まれます。

トピックは、Messaging Serviceを使用するすべての機能の基礎となる中核概念です。 トピックは、パブリッシャーからサブスクライバーにメッセージを配信するための論理チャネルです。 各トピックには任意の数のパブリッシャーとサブスクライバーを設定でき、一般に、あるトピックのすべてのサブスクライバーは、そのトピックのすべてのパブリッシャーが送信したメッセージを受信します。 トピックのすべてのサブスクライバーは、公開されたメッセージを同じ順序で受信します。 トピックは、すべてのサブスクライバーが正常に受信したことを確認応答するまで、公開されたメッセージを永続的に保存します。 これは、Messaging Serviceが公開されたすべてのメッセージをすべてのサブスクライバーに配信することを保証できることを意味します。

以下のセクションでは、Messaging Serviceを使用する各サービスについて、お使いのテナントでの利用状況を監視する方法を示します。

トピックを表示するには

ナビゲータの監視メニューでMessaging Serviceをクリックすると、Messaging Serviceを使用しているすべての機能の一覧が表示されます。 機能名の横には、トピック数、パブリッシャー数、サブスクライバー数など、その機能のMessaging Service利用状況に関する基本情報が表示されます。 機能を選択してクリックすると、詳細が表示されます。これにより、その機能で使用されているすべてのトピックの一覧と、それぞれのトピックに適用されている制限が表示されます。

トピック一覧

トピック一覧には、各トピックについて次の情報が表示されます。

列名	説明	危険範囲
Name	トピック名。これを特定のソースに対応付ける方法の詳細については、以下の機能別ドキュメントを参照してください。	-
Message rate in (msg/s)	そのトピックで1秒あたりに公開されるメッセージの合計レート。	-
Message rate out (msg/s)	そのトピックのサブスクライバーに1秒あたりにディスパッチされるメッセージの合計レート。ディスパッチには追加のバッチ処理およびキューイングメカニズムが含まれるため、このレートはサブスクライバーの確認応答レートと異なる場合があります。	-
Subscribers	登録されているサブスクライバーの合計数。これには、アクティブに消費しているサブスクライバーと、現在切断されていてメッセージを消費していないサブスクライバーの両方が含まれます。	> 5
Message backlog	未消費メッセージが占有するサイズに対応する、バイト単位のバックログサイズ。	> 20 MB
Used backlog	バックログクォータ制限の使用率（パーセンテージ）。	> 80%

トピック名をソースに対応付ける方法、および安全でない範囲に達したときにバックログをクリアする方法の詳細については、以下の機能別ドキュメントを参照してください。

Messaging Serviceの制限

トピック一覧ビューの上部に表示されるすべてのバックログ制限は、トピックごとに適用されます。つまり、バックログクォータが25MBに設定されている場合、各トピックは設定された制限に達するまでメッセージをキューに入れます。 制限はThings Cloudプラットフォーム全体に適用され、変更できるのはOperationsチームのみです。

トピックの詳細を表示するには

選択したトピック名をクリックすると、トピック詳細ビューに移動します。 ビューには、上部にトピック情報、その下にそのトピックのすべてのサブスクライバーの一覧が表示されます。

サブスクライバー一覧

サブスクライバー一覧には、各サブスクライバーについて次の情報が表示されます。

列名	説明	危険範囲
Name	サブスクライバー名。これを特定の宛先に対応付ける方法の詳細については、以下の機能別ドキュメントを参照してください。	-
Connected clients	現在接続されていてメッセージを消費しているクライアント数。	-
Acknowledgment rate (msg/s)	コンシューマーによって完全に処理された（消費、処理、確認応答された）メッセージの現在の1秒あたりのレート。	-
Last acknowledged	メッセージがコンシューマーによって完全に処理された最新のタイムスタンプ。	>= 1 day
Unacknowledged messages	このサブスクライバーの未消費メッセージ数。	> 1000
Used backlog	サブスクライバーによるバックログクォータ制限の使用率（パーセンテージ）。	> 80%

サブスクライバー名を宛先に対応付ける方法、および安全でない範囲に達したときにバックログをクリアする方法の詳細については、以下の機能別ドキュメントを参照してください。

Notifications 2.0の監視

トピックとサブスクライバー

トピック名は、Notifications 2.0 Subscriptions APIおよびNotifications 2.0 Tokens APIで使用されるsubscriptionフィールドと同じです。

サブスクライバー名は、Notifications 2.0 Tokens APIで使用されるsubscriberフィールドと同じです。

サブスクライバーは、指定されたsubscription名とsubscriber名を持つトークンを使用してNotifications 2.0 WebSocket接続が初めて確立されたときに作成されます。 トピック自体は、指定されたsubscription名を持つトークンを使用して何らかのNotifications 2.0 WebSocket接続が初めて確立されたときに作成されます。 ただし、一度サブスクライバーが作成されると、WebSocket接続が切断されても削除されません。 つまり、Messaging Serviceは、メッセージが消費されるか、設定されたtime-to-live（TTL）間隔に達するか、またはサブスクライバーが明示的にサブスクライブ解除されるまで、指定されたトピックの下でメッセージを収集して永続化します。 詳細については、コンシューマーのライフサイクルを参照してください。

バックログをクリアする

Messaging Serviceのバックログがいっぱいになると、クリアされるまで新しいメッセージをバックログに追加できません。 通知も生成することになっているRESTリクエストは、バックログクォータに達したことを示すメッセージとともに500ステータスコードで失敗します。 Things Cloudを使用するクライアントは、この状況を認識し、適切にエラーを処理する必要があります。 この状況では、作業を継続する前にバックログをクリアする必要があります。Notifications 2.0トピックからバックログをクリアする方法はいくつかあります。

メッセージを消費する

トピックとサブスクライバーが作成されている場合、Messaging Serviceには消費すべき重要なメッセージも保存されている可能性があります。 指定されたトピックとサブスクライバーのメッセージを消費して確認応答するには:

• 選択したトピックとサブスクライバーに対するNotifications 2.0 Tokenを作成します。
• そのトークンを使用して、トピックへのNotifications 2.0 WebSocket接続を作成します。
• WebSocket接続経由で受信したすべてのメッセージを処理し、確認応答します。

これにより、Messaging Serviceからメッセージが削除され、指定されたトピックとサブスクライバーのバックログがクリアされますが、このアクションは永続的ではありません。 Notifications 2.0サブスクリプションとサブスクライバーは引き続き存在するため、継続的に消費されなければ、新しいメッセージによってバックログが再びいっぱいになる可能性があります。

Notifications 2.0 APIを使用してサブスクライバーをサブスクライブ解除する

サブスクライバーがもはや不要で、消費すべき重要なメッセージもない場合、サブスクライバーをサブスクライブ解除できます。 これを行うには:

• 選択したトピックとサブスクライバーに対するNotifications 2.0 Tokenを作成します。
• そのトークンを使用して、Notifications 2.0 Token Unsubscribe APIを呼び出し、トピックからサブスクライバーをサブスクライブ解除します。

これにより、Messaging Serviceからサブスクライバーが削除され、指定されたサブスクライバーのバックログがクリアされます。また、未消費メッセージを持つサブスクライバーが他にいない場合は、トピック全体もクリアされる可能性があります。 サブスクライバーが、トピックへのNotifications 2.0 WebSocket接続を確立することで再作成されない限り、このアクションは永続的です。つまり、バックログが再び増加することはありません。 トピックにアクティブなサブスクライバーがもういない場合は、Notifications 2.0 Subscriptionも削除することを推奨します。

UI経由でサブスクライバーをサブスクライブ解除する

サブスクライバーがもはや不要で、消費すべき重要なメッセージもない場合、UIから直接サブスクライバーをサブスクライブ解除できます。 これを行うには、Messaging Serviceページのサブスクライバー一覧からサブスクライバーを選択し、サブスクライブ解除アイコンをクリックします。 このアクションは、Notifications 2.0 APIを使用してサブスクライバーをサブスクライブ解除することと同等です。 これが永続的なアクションであること、およびバックログのクリアに関するすべての情報は、上記の説明と同じです。

MQTT Serviceの監視

トピックとサブスクライバー

トピック名は、MQTT Serviceクライアントで使用されるトピック名に1:1で対応します。

MQTT Service SDKを使用する場合、サブスクライバー名はサブスクライバー設定で定義された名前と同じです。

MQTTクライアントによって作成されたサブスクライバーは、クライアントが切断されると自動的に削除されるため、長期間残存して手動クリーンアップが必要になる可能性は低いです。

バックログをクリアする

Messaging Serviceのバックログがいっぱいになると、クリアされるまで新しいメッセージをバックログに追加できません。 この状況では、クライアントの動作は使用しているMQTTプロトコルバージョンによって異なります:

• プロトコルバージョン3.1.1を使用するMQTTクライアントは、単純に切断されます。
• プロトコルバージョン5を使用するMQTTクライアントは、理由コード0x97（quota exceeded）を含む否定的なPUBACKレスポンスを受け取りますが、接続は維持されます。

MQTT Serviceに接続する実装は、この状況を認識し、これらのエラーを適切に処理する必要があります。 いずれの場合も、作業を継続する前にバックログをクリアする必要があります。MQTT Serviceトピックからバックログをクリアする方法はいくつかあります。

メッセージを消費する

トピックとサブスクライバーが作成されている場合、Messaging Serviceには消費すべき重要なメッセージも保存されている可能性があります。 指定されたトピックとサブスクライバーのメッセージを消費して確認応答するには、MQTT Service SDKを使用します。

すべてのメッセージを消費すると、バックログはクリアされ、トピックは新しいメッセージを保存できる状態になります。

MQTT Service SDKを使用してサブスクライバーをサブスクライブ解除する

サブスクライバーがもはや不要で、消費すべき重要なメッセージもない場合、サブスクライバーをサブスクライブ解除できます。 MQTT Service SDKのサブスクライブ解除アクションを使用します。 これにより、Messaging Serviceからサブスクライバーが削除され、指定されたサブスクライバーのバックログがクリアされます。また、未消費メッセージを持つサブスクライバーが他にいない場合は、トピック全体もクリアされる可能性があります。

UI経由でサブスクライバーをサブスクライブ解除する

サブスクライバーがもはや不要で、消費すべき重要なメッセージもない場合、UIから直接サブスクライバーをサブスクライブ解除できます。 これを行うには、Messaging Serviceページのサブスクライバー一覧からサブスクライバーを選択し、サブスクライブ解除アイコンをクリックします。 このアクションは、MQTT Service SDKを使用してサブスクライバーをサブスクライブ解除することと同等です。

よくある質問（FAQ）

トピック数が多い場合はどうすればよいですか?

多数のデバイスを扱う場合、トピック数が多いことは通常の動作である可能性がありますが、新しいトピックが不必要に生成されている状況も考えられます:

• 一度もクリアされていないテストトピック - クリーンアップできる未使用のトピックがないか確認してください。
• 同じデータを運ぶトピック - 不要なリソース消費を避けるため、可能な限りトピック名を再利用する必要があります。同じデータを運ぶ複数のトピックがある場合は、1つのトピックに統合することを検討してください。

サブスクライバー数が多い場合はどうすればよいですか?

単一のマイクロサービスまたは単一のクライアントでMessaging Serviceからメッセージを消費している場合、通常はサブスクライバーは1つだけであるはずです。 クライアントで使用しているサブスクライバー名が一意であり、Messaging Serviceへの接続時に一貫して再利用されているか確認してください。 よくある落とし穴は、Messaging Serviceへの新しい接続が確立されるたびにランダムなサブスクライバー名を生成してしまうことです。

複数の異なるクライアントが同じトピックから消費する場合、または共有コンシューマートークンを使用する場合は、複数のサブスクライバーが存在することが想定されます。