EMQX Enterprise

日本語

简体中文
English

日本語

简体中文
English

Appearance

お問い合わせ
お問い合わせ

Usage FAQs ​

ライセンスの有効期限が切れたらどうなりますか？ ​

EMQX Enterpriseユーザーの場合、ライセンスの有効期限が切れると、ノード起動時に有効期限切れを通知する警告が表示されます。ライセンスタイプに応じて、以下の追加制限が適用される場合があります。

  • 「小規模」顧客向けまたはトライアルライセンスの場合： ライセンスで指定された接続数の上限に達していなくても、新しいMQTT接続は許可されません。既存の接続は切断されませんが、切断された場合は再接続できなくなります。
  • 「小規模」顧客向けまたはトライアル以外のライセンスの場合： 合計接続数が最大上限を超えない限り、新しいMQTT接続は引き続き許可されます。

ご自身のライセンスタイプが不明な場合は、アカウントマネージャーにご確認ください。

ライセンスを更新するにはどうすればよいですか？ ​

以下のコマンドを使用して、EMQX Enterpriseのライセンスを更新できます。

bash
./bin/emqx ctl

    license info             # ライセンス情報を表示
    license update <License> # ライセンス文字列を指定して更新

また、ダッシュボードからもライセンスを更新可能です。ライセンスの申請およびダッシュボード経由での更新方法については、EMQX Enterpriseライセンスの取り扱いをご参照ください。

共有サブスクリプションを使用しているとき、なぜ保持メッセージを受信できないのですか？ ​

MQTTプロトコルにより、クライアントが共有サブスクリプションを使用している場合、サーバーはそのクライアントに保持メッセージを送信してはなりません。

共有サブスクリプションを使用するとき、なぜメッセージが時々失われるのですか？ ​

共有サブスクライバーの接続が切断されてもセッションがアクティブな場合、サーバーは引き続きメッセージをそのサブスクライバーに配信し、メッセージは一時的にセッション内に保存されます。そのため、他のアクティブな共有サブスクライバーはすべてのメッセージを消費していないように見えることがあります。さらに、共有サブスクライバーが再接続時に新しいセッションを作成すると、古いセッションにキャッシュされたメッセージは永久に失われます。

上記の状況が存在しないことを確認してもメッセージの損失が続く場合は、Log Traceを使用してさらに調査してください。

SSL/TLS接続失敗の原因をどのようにトラブルシューティングすればよいですか？ ​

通常、SSL/TLS接続のハンドシェイクが失敗すると、EMQXはログに対応する失敗理由を出力します。以下はログに現れる一般的なキーワードとその意味です。

  • certificate_expired

    ログにcertificate_expiredが表示された場合、証明書の有効期限が切れているため、速やかに更新してください。

  • no_suitable_cipher

    ログにno_suitable_cipherが表示された場合、ハンドシェイク時に適切な暗号スイートが見つからなかったことを示します。証明書の種類と暗号スイートが一致しない、サーバーとクライアント双方でサポートされる暗号スイートが存在しないなどが考えられます。

  • handshake_failure

    ログにhandshake_failureが表示された場合、多くの原因が考えられます。クライアントのエラーと合わせて分析してください。例えば、クライアントが接続先サーバーのアドレスとサーバー証明書のドメイン名が一致しないと判断する場合があります。

  • unknown_ca

    ログにunknown_caが表示された場合、証明書の検証に失敗しています。中間CA証明書の省略、ルートCA証明書の未指定、誤ったルートCA証明書の指定などが一般的な原因です。相互認証の場合は、ログの他の情報からサーバー側またはクライアント側の証明書設定の誤りを判断できます。

    サーバー証明書に問題がある場合、エラーログは通常以下のようになります。

    {ssl_error,{tls_alert,{unknown_ca,"TLS server: In state certify received CLIENT ALERT: Fatal - Unknown CA\n"}}}

    CLIENT ALERTはクライアントからの警告メッセージであり、サーバー証明書がクライアントの検証に失敗したことを示します。

    クライアント証明書に問題がある場合、エラーログは通常以下のようになります。

    {ssl_error,{tls_alert,{unknown_ca,"TLS server: In state certify at ssl_handshake.erl:1887 generated SERVER ALERT: Fatal - Unknown CA\n"}}}

    SERVER ALERTはサーバーがクライアント証明書の認証に失敗したことを示し、クライアントはサーバーからこの警告を受け取ります。

  • protocol_version

    ログにprotocol_versionが表示された場合、クライアントとサーバーでサポートされるTLSプロトコルのバージョンが一致していません。

MQTTクライアントの異常切断の原因をどのようにトラブルシューティングすればよいですか？ ​

Shellでemqx ctl listenersを実行すると、各リスナーの切断統計情報が返されます。切断理由と切断回数が含まれます。例：

$ . /bin/emqx ctl listeners
tcp:default
  listen_on : 0.0.0.0:1883
  acceptors : 16
  proxy_protocol : false
  running : true
  current_conn : 9
  max_conns : infinity
  shutdown_count : [{keepalive_timeout,1},{idle_timeout,2}]

よくある切断理由は以下の通りです。

  • keepalive_timeout：クライアントのハートビートがタイムアウトし、EMQXが接続を切断した。
  • tcp_closed：クライアントがDISCONNECTパケットを送信せずにTCP接続を直接閉じた。
  • frame_too_large：クライアントが送信したパケットのサイズが最大制限を超えたため、EMQXが接続を切断した。
  • connect_packet_too_large：クライアントがmqtt.max_connect_packet_sizeを超えるCONNECTパケットを送信したため、EMQXが接続を切断した。
  • protocol_error：クライアントが非準拠の動作（例：同一接続内で複数のCONNECTパケット送信）をしたため、EMQXが接続を切断した。
  • idle_timeout：TCP接続確立後15秒以内にクライアントからCONNECTパケットを受信できなかったため、EMQXが接続を切断した。

また、Log Traceを使って、指定したクライアントID、IP、トピックに関連するすべてのログを追跡し、切断原因を分析できます。

ストレステスト実行時に接続数やスループットが期待より低かった場合、システムを最大限活用するためのチューニング方法は？ ​

ストレステストを実行する際は、必要なハードウェアリソースの確保に加え、OSやErlang VMのチューニングが必要です。代表的なチューニング項目は、ファイルハンドルのグローバル制限とユーザー制限、TCPのバックログやバッファ、Erlang VMのプロセス数制限などです。クライアント側も、すべてのサブスクライブとパブリッシュを処理できる能力とリソースを持つように調整してください。

ユースケースにより最適なチューニングは異なります。一般的なチューニング方法については、パフォーマンスチューニングを参照してください。

クライアントの接続、パブリッシュ、サブスクライブに関する問題（接続失敗、異常切断など）が発生した場合、どのようにトラブルシューティングすればよいですか？ ​

EMQXのデバッグログにはすべての動作や現象が記録されています。デバッグログを確認することで、クライアントがいつ接続を開始したか、接続時に指定したパラメーター、接続の成功や拒否の有無とその理由などを把握できます。ただし、デバッグモードのログは情報量が多いため、個別のクライアントやトピックの分析が困難になる場合があります。

このため、EMQXはLog Trace機能を提供しています。トレースしたいクライアントやトピックを指定すると、それらに関連するすべてのデバッグログを指定ログファイルに出力します。これにより、自己分析やコミュニティへの問い合わせが容易になります。

なお、クライアントがネットワーク障害によりEMQXに接続できない場合、EMQXはメッセージを受信しないため、ログトレース機能は役に立ちません。このような場合は、ファイアウォールやセキュリティグループなどのネットワーク設定によるサーバーポートの閉鎖が原因であることが多く、特にクラウド環境でのEMQXデプロイ時に多発します。したがって、ログトレースに加えて、ポートの占有状況、リスニング状態、ネットワーク設定の確認も必要です。

「CENSYS」などの見慣れないクライアントIDがあるのはなぜですか？ ​

CENSYSはインターネットのスキャンおよび偵察ツールで、IPv4アドレス空間を定期的にスキャンし、HTTP、SSH、MQTTなどの各種プロトコルのデフォルトポートを特定します。そのため、MQTTブローカーに「CENSYS」などのクライアントIDを持つ見慣れないクライアントがアクセスしている場合、セキュリティ保護レベルが比較的低いことを示しています。この問題に効果的に対処するため、以下の対策を検討してください。

  1. EMQXのHTTP APIアクセス権限確認に使用されるAppIDやAppSecretなど、デフォルト設定を避ける。
  2. パスワード認証やJWT認証などの認証機構を有効にし、IPアドレスの知識だけでログインできないようにする。
  3. TLS相互認証を有効にし、有効な証明書を持つクライアントのみアクセスを許可する。
  4. 適切な認可機構を有効にし、認可されていないデバイスによる機密データへのアクセスを制限する。
  5. 不要なポートを可能な限り閉じるようにファイアウォールを設定する。

ダッシュボードのログインパスワードを忘れた場合、どうリセットすればよいですか？ ​

ダッシュボードの初期ユーザー名とパスワードはそれぞれadminとpublicです。セキュリティ上の理由から、初回ログイン時にパスワードの変更が強制されます。以前設定したパスワードを忘れた場合は、以下のコマンドで旧パスワードを入力せずに新しいパスワードを設定できます。

bash
./bin/emqx ctl admins passwd <Username> <Password>