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

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

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

上記の状況が存在しないことが確認されているにもかかわらずメッセージの損失が続く場合は、ログトレースを使用して詳細な調査を行ってください。

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が接続を切断しました。
  • protocol_error: クライアントの非準拠動作によりEMQXが接続を切断しました。例として、同一接続内で複数のCONNECTパケットを送信した場合などがあります。
  • idle_timeout: TCP接続確立後15秒以内にクライアントからCONNECTパケットが受信できなかったため、EMQXが接続を切断しました。

また、ログトレースを使用して、指定したクライアントID、IP、トピックに関連するすべてのログを追跡し、切断原因を分析することも可能です。

ストレステスト実行時に接続数やスループットが期待より低かった場合、システムをどのようにチューニングすればよいですか？ ​

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

ユースケースによって最適なチューニングは異なります。一般的な用途向けのチューニングについては、パフォーマンスチューニングをご参照ください。

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

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

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

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

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

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

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

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

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

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