ログ

ログは、EMQX ブローカーのデプロイメントにおける問題のトラブルシューティングやパフォーマンス最適化に欠かせない重要なリソースです。デプロイメントログには、アクセス、操作、ネットワークイベントに関する情報が記録されます。EMQX Cloud コンソールを通じて、ログをリアルタイムで閲覧したり、オフライン解析のためにダウンロードしたりできます。

デプロイメントログの表示

デプロイメントログにアクセスするには、EMQX Cloud コンソールで対象のデプロイメントに移動し、Diagnostics -> Logs を選択して Logs ページを開きます。

時間によるフィルター

デフォルトでは、Logs ページには過去3日間のログが表示されます。以下の事前定義された時間範囲でログをフィルターできます。

• 過去1時間
• 過去12時間
• 過去1日
• 過去3日

また、カレンダーピッカーを使ってカスタムの時間範囲を選択できます。ただし、

• 一度に選択できる最大時間範囲は3日間です。
• 過去7日間までのログを閲覧可能です。

より長期のログ保存には、デプロイメントが EMQX Tables 統合をサポートしている場合、EMQX Tables をご利用ください。

ログレベルによるフィルター

デプロイメントログは以下の5つの重大度レベルに分類されています。

• Warning（警告）
• Error（エラー）
• Critical（重大）
• Alert（アラート）
• Emergency（緊急）

ドロップダウンボックスから重大度レベルを選択し、「検索」ボタンをクリックしてログをフィルターできます。

エラータイプによるフィルター

特定のエラーカテゴリでログをフィルターできます。

• データ統合：MySQLのオフライン、認可失敗、スキーマ問題などデータ統合関連のエラー。
• クライアント：認証情報の誤り、アクセス制御情報の誤り、接続不可のその他理由などクライアント関連のエラー。
• メッセージ：エンコード問題、メッセージの損失やドロップなどメッセージ関連のエラー。
• 認証：対応するバックエンドサービスに接続できないことによる拡張認証エラーなど認証関連のエラー。
• 認可：認可ルールの適用失敗など認可関連のエラー。

アラートタイプによるフィルター

Alert Type のドロップダウンからアラートタイプでログをフィルターできます。アラートタイプは以下の3カテゴリに分類されています。

認証とアクセス制御

• 認証失敗の大量発生
• ACL拒否の大量発生
• 外部認証モジュールの異常状態
• 外部ACLモジュールの異常状態
• 接続フラッピングによるクライアント禁止

クライアントとメッセージ

• メッセージドロップ
• 大量クライアント切断

データ統合

• コネクターの異常状態
• SQLマッチング失敗
• アクション実行失敗
• アクションの異常状態

クライアントID、クライアントIPなどによるフィルター

以下のフィールドでログをフィルターできます。

• クライアントID
• クライアントIP

さらに詳細なフィルターオプションは More Filters のドロップダウンから開けます。内容は以下の通りです。

• ユーザー名
• トピック
• コネクター名
• アクション名
• ルールID

AIログ解析

任意のログエントリに対して、Ask AI ボタンをクリックすると、AIによる説明と推奨アクションが表示され、ログの意味を素早く理解できます。

注意

ユーザーごとに1時間あたり最大10件のログエントリに対してAI解析を開始できます。

ログのリセットとダウンロード

• Reset をクリックすると、ログ表示をデフォルトに戻せます。
• Download をクリックすると、検索結果から最大1,000件のログレコードをエクスポートできます。

よくあるログ解析

このセクションでは、EMQX ブローカーでよく見られる warning および error ログの例、問題の原因、推奨される対処方法をまとめており、運用やトラブルシューティングの参考になります。

クライアント接続および認可ログ

[Warning] クライアント認証失敗

ログ例：

clientid: xx, peername: xxx:xx, username: 1, pid: <0.99601.0>, reason: not_authorized, tag: AUTHN, msg: authentication_failure

このログは、対応する MQTT ユーザー名の認証データが見つからなかったことを示します。

clientid: xx, peername: xxx:xx, username: test, pid: <0.15269.0>, reason: bad_username_or_password, tag: AUTHN, msg: authentication_failure

このログは、MQTT ユーザー名は見つかったものの、パスワード検証に失敗したことを示します。

対処方法：
クライアントに設定されているユーザー名とパスワードが正しいか確認してください。

[Warning] クライアントACL認可失敗

ログ例：

clientid: xx, peername: xxx:xx, username: test, topic: test, pid: <0.34387.0>, action: SUBSCRIBE(Q0), source: built_in_database, tag: AUTHZ, msg: authorization_permission_denied

問題点：
クライアントは認証に成功したものの、許可されていないトピックへのサブスクライブやパブリッシュを試み、認可拒否が発生しました。

対処方法：

• アクセス制御（ACL）設定が正しいか確認してください。
• 現在のユーザーが指定されたトピックにアクセスする権限を持っているか確認してください。

[Warning] 非標準MQTTプロトコル接続失敗

ログ例：

[MQTT] Parse failed for function_clause[{emqx_frame,parse_packet,[{mqtt_packet_header,4,false,3,true}

問題点：
クライアントが非標準の MQTT プロトコルや誤ったパケット形式で接続を試みました。

対処方法：
クライアントが標準の MQTT プロトコルバージョン（例：3.1.1 または 5.0）を使用していることを確認してください。

メッセージ配信およびフロー制御ログ

[Warning] メッセージドロップ（キュー満杯）

ログ例：

clientid: xx, peername: xxx:xx, username: test, topic: test, pid: <0.198894.0>, payload: xxxxxxxxxx, payload_encode: hex, queue: {"store_qos0":true,"max_len":1000,"len":1000,"dropped":56942}, msg: dropped_msg_due_to_mqueue_is_full

問題点：
クライアントがオフラインかメッセージの消費が遅いため、サーバー側のキューが満杯になりメッセージがドロップされました。

対処方法：

1. クライアントが頻繁にオフラインになる場合：
   • clean session = true を設定してください。
   • 切断後のセッション喪失を防ぐため、自動再接続を有効にしてください。
2. クライアントのメッセージ消費が遅い場合：
   • クライアントSDKを最適化して消費速度を改善してください。
   • 共有サブスクリプションを利用してメッセージ負荷を分散してください。

[Warning] TPS制限超過

ログ例：

clientid: xx, peername: xxx:xx, username: test, topic: test, pid: <0.194662.0>, reason: {failed_to_consume_from_limiter,{{listener,'tcp:default'},messages}}, tag: QUOTA, msg: cannot_publish_to_topic_due_to_quota_exceeded

問題点：
クライアントのパブリッシュレートが、デプロイメントで定義された TPS（Transactions Per Second）制限を超えました。

対処方法：

• クライアントのメッセージパブリッシュレートを制限内に抑えてください。
• または、ビジネス要件に応じてデプロイメントの TPS クォータを調整してください。

デプロイメントのデータ統合ログ

[Error] MySQLコネクター起動失敗

ログ例：

[warning] tag: CONNECTOR/MYSQL, msg: start_resource_failed, reason: {start_pool_failed,<<"connector:mysql:test">>,{shutdown,#{cause => ehostunreach,port => 3306,user => <<"root">>,host => "xxx",database => <<"mqtt">>}}}, resource_id: <<"connector:mysql:test">>

問題点：
MySQLデータコネクターの初期化に失敗しました。データベースサービスが到達不能か接続設定が誤っている可能性があります。

対処方法：

• MySQLサーバーの状態とネットワーク接続を確認してください。
• コネクターの設定（ホスト、ポート、ユーザー名、データベース名など）を検証してください。

[Error] HTTPコネクター起動失敗

ログ例：

pid: <0.28885448.0>, line: 810, reason: timeout, resource_id: connector:http:c-xxX, tag: CONNECTOR/WEBHOOK, msg: start_resource_failed

問題点：
WebhookまたはHTTPコネクターの起動に失敗しました。通常はHTTPサービスへの接続タイムアウトが原因です。

対処方法：

• 対象のHTTPサービスがアクセス可能か確認してください。
• HTTPコネクター設定のURL、ポート、認証設定が正しいか確認してください。

[Error] RocketMQコネクター起動失敗

ログ例：

[error] crasher: initial call: rocketmq_client:init/1, pid: <0.5161.0>, exit: {fail_to_connect_rocketmq_server,...}
[warning] tag: CONNECTOR/ROCKETMQ, msg: start_resource_failed, reason: {fail_to_connect_rocketmq_server,...}, resource_id: <<"connector:rocketmq:test">>

問題点：
RocketMQクライアントがターゲットサーバーに接続できず、コネクターの初期化に失敗しました。

対処方法：

• RocketMQサービスが正常に稼働しているか確認してください。
• コネクター設定（アドレス、ポート、認証情報など）を検証してください。

[Error] Kafkaリソース例外

ログ例：

topic: xxx, pid: <0.25097.0>, group: ..., reason: failed_to_fetch_metadata, msg: failed_to_refresh_partition_count_will_retry
topic: xxx, pid: <0.25048.0>, errors: [{"reason":"connection_timed_out","host":"xxx:xx"}], msg: failed_to_fetch_metadata

問題点：
Kafkaコネクターがトピックのメタデータ取得に失敗しました。接続タイムアウトやKafkaクラスター設定の誤りが考えられます。

対処方法：

• Kafkaサービスの稼働状況と接続性を確認してください。
• アクションで設定したKafkaトピックがKafkaクラスター内に既に作成されていることを確認してください。

[Error] MQTTリソース例外

ログ例：

pid: <0.5959.0>, line: 59, reason: timeout, resource_id: connector:mqtt:c-xxx, tag: RESOURCE, msg: start_ecpool_error
pid: <0.5959.0>, line: 895, reason: timeout, resource_id: connector:mqtt:c-xxx, tag: CONNECTOR/MQTT, msg: start_resource_failed

問題点：
MQTTコネクターの初期化がタイムアウトしました。ターゲットMQTTサービスが到達不能か設定ミスの可能性があります。

対処方法：

• ターゲットMQTTブローカーの状態とネットワーク接続を確認してください。
• MQTTコネクターの設定（ホスト、ポート、認証など）が正しいか検証してください。