IBM MQ のトラブルシューティング
遭遇する可能性のある問題のほとんどは、 IBM MQ の接続と権限に関連しています。 以下の問題を参照してください:
IBM MQ センサーのトラブルシューティング
遭遇する可能性のある問題のほとんどは、 IBM MQ の接続と権限に関連しています。 以下の問題を参照してください:
ローカルバインディングモードの問題
実行中のキューマネージャーについては、ユーザーに特権を付与した後、セキュリティ設定が機能することを確認してください。 付与した権限を有効にするには、次の IBM MQ runmqscコマンドを実行してセキュリティを更新するか、キューマネージャを再起動する必要があります。
REFRESH SECURITY
IBM i ローカル結合モード
IBM i の IBM MQ にローカルバインディングモードで接続する場合、環境変数が設定されていないために接続に失敗することがあります。
エラー・コード: RC 2012 - MQRC_ENVIRONMENT_ERROR
Instana エージェントのログメッセージ:
Connecting to {queue_manager_name} in local binding mode failed, error: MQJE001: Completion Code '2', Reason '2012'.
解決策:
次の環境変数を ファイル
<instana-agent-dir>/bin/setenvに追加してください:export QIBM_MULTI_THREADED=Y export QIBM_USE_DESCRIPTOR_STDIO=I export QSH_REDIRECTION_TEXTDATA=Yこれらの環境変数は、新しいバージョンのエージェントアセンブリではデフォルトで設定されています。 {: note}
変更を反映させるには、 Instana エージェントを再起動してください。
クライアントバインディングモードにおける接続または権限の問題
クライアントバインディングモードでは、 IBM MQ センサーはクライアントアプリケーションとして動作し、キューマネージャに接続します。 したがって、このセンサーは、 MQ Explorer や amqsputcMQ サンプルアプリケーションなどと同様に、キューマネージャに接続してデータを照会するために、他のアプリケーションと同じ権限を必要とします。 キューマネージャが設定したパラメータで接続できない場合、 MQ エクスプローラーで接続パラメータを試してキューマネージャに接続し、接続できるかどうかを確認できます。
以下の問題を参照してください:
RC 2538 - MQRC_HOST_NOT_AVAILABLE
Instana エージェントログメッセージ:
Listener not started on{host}:{port} ({exceptionCode}) {message}.リスナーは起動されていません。
解決策: リスナーを起動する。 リスナーを起動するには、次の IBM MQ
runmqscコマンドを実行します:START LISTENER($Listener_Name)Qmgr@host 見つかりません。 キューマネージャとホスト名が正しく、接続可能かどうかを確認してください。
解決策:キューマネージャおよびホスト名の接続パラメータが正しく、接続可能かどうかを確認してください。 または、ファイアウォールが接続をブロックしていないか確認してください。
ホストとポートは、 Kubernetes クラスタ内のエージェント設定ファイルで設定されます。
Kubernetes クラスタにおいて、キューマネージャが再起動されると、ホストIPが変更されます。 したがって、 IBM MQ センサーはキューマネージャーへの接続に失敗します。
解決策: ホストとポート情報を自動的に検出するには、 Kubernetes クラスタ内のホストエージェントのエージェント設定ファイルからホストとポートを削除してください。
RC 2540 - チャネルが定義されていません。
Instana エージェントログメッセージ:
Channel {channel} is not defined ({exceptionCode}). {message}.解決策: エージェント
configuration.yaml設定ファイルで正しい SVRCONN チャネルが設定されているか確認してください。RC 2035 - 権限の問題。
Instana エージェントログメッセージ:
Channel {channel} authorization failed for user {username} ({exceptionCode}). {message}.この問題は権限の問題によって引き起こされており、 MQ の設定が異なる場合、原因も異なる可能性があります。 権限の問題をデバッグするには、チャネルセキュリティが有効かどうかを確認してください:
- チャネルセキュリティが無効化されている場合、かつユーザーに権限が存在しないと報告された場合、 MQ アプリケーションはユーザーに権限がないことを主張します。 どのユーザーが使用されているかを確認し、このユーザーに適切な権限を付与するか、または別の適切なユーザーに変更してキューマネージャに接続してください。
- チャネルセキュリティが有効になっている場合。 提供されたユーザー名とパスワードが、キューマネージャーに接続するための適切な権限を持っているかどうかを確認してください。 TLS が有効な場合、キューマネージャに接続するには正しい
keystore,cipherSuitekeystorePassword, および対応する を指定する必要があります。
以下の図はデバッグフローチャートを示しています:

以下の問題が頻繁に発生し、2035エラーの原因となる可能性があります:
チャネルセキュリティは無効化されていますが、「root」権限を持つユーザーは報告されていません。
通常、
CHLAUTHパラメータが無効化され、CONNAUTHかつパラメータが設定されていない場合、 MQ チャネルのセキュリティは無効化されます。 どのユーザーが認証に使用されるかを決定する必要があります。 セキュリティ機能の優先順位は以下の通りです。を構成しない場合、アプリケーションが
CLNTUSERアサートしたユーザー(リモート接続Security exitにおけるchannel record USERSRC(MAP)オペレーティングシステムのユーザー)MCAUSERが使用されます。 このシナリオでは、 Instana エージェントがrootとして実行されているため、「root」がアプリケーションが主張するユーザーとして使用されます。 権限rootがない場合、 IBM MQ エラーログに「root」で権限を取得できません。 ユーザー権限の優先順位の詳細については、 IBM MQ Documents を参照してください。解決策: チャネルレコードを設定し、そのチャネルに対してCLNTUSERまたはMCAUSERを定義できます。 MCAUSER を、サーバー接続チャネルに対する MQ アクセス権限を持つユーザーとして定義し、このユーザーを使用してキューマネージャに接続します。
例:
alter channel(SVRCONN) chltype(SVRCONN) MCAUSER(‘mqmtest‘)SYSTEMサーバー接続チャネルへの接続権限は付与されていません。
一部のシステムサーバー接続チャネル(例: SYSTEM.AUTO.SVRCONN )はデフォルトでブロックされています。以下は MQ の BLOCKUSERS ルールです:CHLAUTH 処理には3つのデフォルトルールがあります:
- MQ -admin* の全ユーザーによる全チャネルへのアクセス不可
- すべてのシステムへのアクセス不可 全ユーザーによるチャンネル
- SYSTEM.ADMIN.SVRCONN チャンネルへのアクセスを許可する( MQ -admin 以外のユーザー)
最初の2つのルールは、すべてのチャネルへのアクセスをブロックします。 第三のルールはより具体的であり、他の二つに優先する。すなわち、CHLAUTHは SYSTEM.ADMIN.SVRCONN チャネルへのアクセスのみを許可する。 詳細については、 「CHLAUTH アクセス問題の解決」 を参照してください。
解決策:ユーザーを使用する前に、システムサーバー接続チャネルのユーザーブロックを解除するか、独自のサーバー接続チャネルを定義して接続することで、このユーザーブロック問題を回避できます。
セキュリティが有効化されているか、 TLS が有効化されている
チャネルセキュリティが有効化されている場合(CHLAUTH(ENABLED) または TLS が有効化されているが、対応するユーザー名とパスワード、またはキーストアパラメータ(keystore、 keystorePassword,、 cipherSuite )が提供されていない場合)、認証情報を提供してください。 MQ のセキュリティ関連設定を変更した後、変更を有効にするにはコマンドプロンプトから
runmqsc`refresh security type(CONNAUTH)gpedit.exe`を実行する必要があります。解決策: エージェント設定ファイルに、対応するユーザー名とパスワード、またはキーストアのパラメータを指定してください。
CHLAUTHとCONNAUTHの両方にセキュリティが有効化されていますが、ユーザーはキューマネージャへの接続権限の問題を抱えています。
解決策:キューマネージャにおけるCHLAUTHおよびCONNAUTHの設定を行い、その後CHLAUTHとCONNAUTHの相互作用フローを確認して優先順位を検証し、どのセキュリティレコードが機能するかを確認した上で問題を修正する。 詳細については、 CHLAUTH と CONNAUTH の相互作用を参照してください。
MQ 接続に問題はないが、オブジェクトのセキュリティではユーザーが他の監視データを取得するには不十分である。
解決策: MQ のエラーログを確認し、権限の問題が発生しているオブジェクトとユーザーを特定します。その後、該当オブジェクトに適切な権限を付与することで問題を解決します。 詳細については、 「 IBM MQ の権限の設定」 を参照してください。
SYSTEM.AUTH.DATA.QUEUE にアクセスする権限が不足しています
IBM MQ がキューリセット統計データを取得する権限が不足している場合、次のエラーが発生します。 キューリセット統計データを取得するには、アクセス権限の変更権限 SYSTEM.AUTH.DATA.QUEUEが必要です。 しかし SYSTEM.AUTH.DATA.QUEUE 、これは権限変更の許可を提供できない特別なキューです。
AMQ8077W: Entity 'user' has insufficient authority to access object
'SYSTEM.AUTH.DATA.QUEUE'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: chg
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
解決策: IBM MQ のログにこのようなエラーメッセージが表示されないようにするには SYSTEM.AUTH.DATA.QUEUE、 Instana エージェントのユーザーを特権ユーザーに設定してください。
IBM MQ トレースのトラブルシューティング
IBM MQ トレースでは、以下の問題が発生する可能性があります:
IBM MQ キュー管理者が起動に失敗しました
トラブルシューティングを行うには、次の手順を完了してください:
( Linux / AIX ) または
tracelibrary.dll( Windows ) がtracelibrary.so、 IBM MQ サービスを起動するすべてのユーザー( Linux または AIX 上のMQ_USERmqmユーザーや、 Windows 上のユーザーを含む)のすべての依存関係を解決できることを確認してください。 確認するには、次のコマンドを使用してください:- Linux: ldd
- AIX :
dump -Hまたはldd - Windows:dumpbin /dependents
- 必要なファイルがすべて期待される場所に存在することを確認してください:
- Linux:
.so - AIX :
.aまたは.so - Windows:
.dll
- Linux:
- システムに必要な OpenSSL のバージョンがインストールされていること、および実行時に または
tracelibrary.soがtracelibrary.dllそれを解決できることを確認してください。
メッセージ処理エラー
トレース相関情報を伝播するため、 IBM MQ トレースユーザー・エグジットは、メッセージに既に MQRFH2 ヘッダーが含まれている場合、またはメッセージ宛先の監視レベルがに設定されている場合に debug、トレース対象メッセージに追加の MQRFH2 ヘッダー(X_INSTANA_T, X_INSTANA_S, X_INSTANA_L, traceparent, および tracestate)を追加します。 ただし、メッセージに追加のヘッダーデータが含まれていると、一部の IBM MQ コンシューマーアプリケーションにおいてメッセージ処理エラーやメッセージ拒否を引き起こす可能性があります。 追加の MQRFH2 ヘッダーが IBM MQ クライアントアプリケーションでエラーを引き起こす場合、次のいずれかの操作を実行してください:
- IBM MQ クライアントアプリケーションを修正し、 Instana が追加したトレース相関情報を含む追加の MQRFH2 ヘッダーを無視するようにする。
- IBM MQIBMMQ_DEST_MONITOR_LEVEL_QUIETトレースのユーザー・エグジット構成パラメータに、メッセージング・チェーン内のキューを追加することで、トレース相関の伝播を無効化します。
- IBM MQ クライアントアプリケーションによって接続されたキューの`
PROPCTLproperty`プロパティの値を`value`に変更しますNONE。
IBM MQ メッセージにおけるトレース相関の欠落
デフォルトでは、トレース相関情報は、 MQRFH2 ヘッダーまたはメッセージプロパティを含む IBM MQ メッセージに自動的に追加されます。 IBM MQ クライアントアプリケーションの動作を妨げないため、 IBM MQ ユーザー・エグジットのトレースでは、プレーンテキスト・メッセージにトレース相関情報は追加されません。 メッセージにトレース相関情報を付加したい場合は、 IBM MQIBMMQ_DEST_MONITOR_LEVEL_DEBUGトレースのユーザー・エグジット設定パラメータにメッセージ宛先を追加できます。 ただし、 IBM MQ クライアントアプリケーションが追加の MQRFH2 ヘッダーを含むメッセージを解析できることを確認する必要があります。
インフラストラクチャリンクは通話詳細に表示されません
IBM MQ トレースユーザーエクジットによって生成された呼び出しを、監視対象のインフラストラクチャエンティティである IBM MQ キューマネージャにリンクできます。このエンティティは、 Instana UI内の Instana IBM MQ センサーによって収集されます。 IBM MQ の高可用性シナリオでは、インフラストラクチャリンクが利用できない場合があります。これは、 Instana センサー( IBM MQ )によって収集されるキューマネージャのエンティティIDに、アクティブおよびスタンバイの IBM MQ ノードの両方のホストが含まれるためです。 これは、 IBM MQ トレースユーザー・エグジットによって生成されるエンティティIDとは対照的であり、後者はアクティブな IBM MQ ノードのホストのみを含みます。 不一致により、通話詳細とキューエンティティの関連付けが妨げられます。 この問題を解決するには、次の手順を実行してください:
- Go Instana UIのインフラストラクチャビュー内にある高可用性キューマネージャダッシュボードへ。
- キューマネージャダッシュボードのサイドバーで 「Name 」属性を見つけ、キューマネージャのホスト情報を抽出します。 高可用性キューマネージャのホストは、``記号
@の後に続く``文字Name列の一部です。 たとえば、キューマネージャ名が のように表示されるhaqm1@ibmmqnode1.ibm.com-ibmmqnode2.ibm.com-ibmmqnode3.ibm.com場合、そのキューマネージャのホストは となりますibmmqnode1.ibm.com-ibmmqnode2.ibm.com-ibmmqnode3.ibm.com。 - IBM MQ サーバーにアクセスし、 IBM MQ
mqtracingexit.confのユーザー・エグジットのトレース設定ファイルを開きます。 - ステップ2で取得したキューマネージャのホスト名をHOST_ALIASフィールドに設定します。
- 構成ファイルを保存します。
- 変更を適用するには、高可用性キューマネージャを再起動してください。