OpenTelemetryコレクターを使用してIBM MQを監視する場合、コレクターの起動、データフロー、またはエンティティの合成に関する問題が発生する可能性があります。このガイドは、LinuxホストとKubernetesデプロイメントの両方における一般的な問題を診断して修正するのに役立ちます。
Collectorが起動しない、または実行状態を維持できない 自己ホスト型環境の場合 コレクターのステータスを検証し、ログを確認して問題を特定します：
$ sudo systemctl status nrdot-collector.service --no-pager
$ sudo journalctl -u nrdot-collector.service -n 200 --no-pager
設定の問題：
YAML構文エラー：コレクター設定ファイルのインデントと構文を確認します 環境ファイルがありません：/etc/nrdot-collector/ibmmq-envが存在することを確認してください 無効なライセンスキー：401または403のエラーが表示されます。New Relicライセンスキーを確認してください。 Kubernetes環境の場合 コレクターのステータスを検証し、ログを確認して問題を特定します：
$ kubectl -n ibmmq logs deploy/ibmmq-collector-opentelemetry-collector
一般的な原因と解決策 ログで次のエラーパターンを確認します：
設定の問題：
YAML構文エラー：コレクター設定ファイルのインデントと構文を確認します 環境ファイルがありません：ibmmqネームスペースにnewrelic-otlp-secretシークレットが存在することを確認してください。 無効なライセンスキー：401または403のエラーが表示されます。New Relicライセンスキーを確認してください。 Kubernetes固有の問題：
CreateContainerConfigError：newrelic-otlp-secretシークレットがありません。New Relic認証情報シークレットの作成 ステップを再実行しますspec.ports: Required value：service.enabled: falseが次から欠落しています values.yamlcannot list resource "pods" … forbidden：RBACの欠落。HelmのvaluesにclusterRole.create: trueが設定されていることを確認してください。New RelicにIBM MQメトリクスが表示されない コレクターが実行されているにもかかわらず、IBM MQのメトリクスがNew Relicに到達しない場合は、体系的にトラブルシューティングを行ってください：
自己ホスト型環境の場合 IBM MQエクスポーターが機能していることを確認します：
$ curl -s http:// < exporter-host > :9157/metrics | grep '^ibmmq_qmgr_status'
キューマネージャーごとに1行表示されます。出力が表示されない場合、エクスポーターは正常に機能していません。
コレクターが正常であり、ターゲットを検出していることを確認します。
$ curl http://127.0.0.1:13133
otelcol_receiver_accepted_metric_points 0より大きい場合、コレクターがターゲットを見つけたことが確認できます。otelcol_exporter_send_failed_metric_pointsは0のままである必要があります。
ターゲット検出の問題を確認してください。
IBMMQ_QMN_ENDPOINT変数が機能しているエクスポーターを指していることを確認してください。コレクターが各エクスポーターのエンドポイントに到達できることを確認してください 静的ターゲット設定が正しいことを確認します メトリクスが収集されているにもかかわらず、New Relicに表示されないかどうかを確認します： OTLPエンドポイントのリージョン ：エンドポイントがNew Relicアカウントのリージョン（USまたはEU）と一致していることを確認してください。
ライセンスキー ：ライセンスキーが有効であり、正しい権限を持っていることを確認してください。
ネットワーク接続 ：コレクターがNew Relic OTLPエンドポイントに到達できることを確認してください。
リージョンが間違っていると、コレクター側のエラーなしにデータがサイレントにドロップされます。
Kubernetes環境の場合 IBM MQエクスポーターが機能していることを確認します：
$ curl -s http:// < exporter-host > :9157/metrics | grep '^ibmmq_qmgr_status'
キューマネージャーごとに1行表示されます。出力が表示されない場合、エクスポーターは正常に機能していません。
コレクターが正常であり、ターゲットを検出していることを確認します。
$ kubectl -n ibmmq port-forward deploy/ibmmq-collector-opentelemetry-collector 8888 :8888 &
$ curl -s http://localhost:8888/metrics | \
> grep -E 'otelcol_(receiver_accepted|exporter_sent|exporter_send_failed)_metric_points'
otelcol_receiver_accepted_metric_points 0より大きい場合、コレクターがターゲットを見つけたことが確認できます。otelcol_exporter_send_failed_metric_pointsは0のままである必要があります。
otelcol_receiver_accepted_metric_pointsが0のままであるかどうかを確認してください：
キューマネージャーのポッドは、 を正確に設定した状態で、 ポッドテンプレート に 必須のアノテーション を保持する必要があります。 prometheus.io/scrape "true" ポッドはibmmqネームスペースで実行する必要があります clusterRole.create: trueが適用されていることを確認してください — これがないと、kubernetes_sdが返されます。 403 Forbiddenメトリクスが収集されているにもかかわらず、New Relicに表示されないかどうかを確認します： OTLPエンドポイントのリージョン ：エンドポイントがNew Relicアカウントのリージョン（USまたはEU）と一致していることを確認してください。
ライセンスキー ：ライセンスキーが有効であり、正しい権限を持っていることを確認してください。
ネットワーク接続 ：コレクターがNew Relic OTLPエンドポイントに到達できることを確認してください。
リージョンが間違っていると、コレクター側のエラーなしにデータがサイレントにドロップされます。
New RelicにIBM MQエンティティが表示されません。 New RelicにIBM MQのメトリクスは表示されるが、IBMMQ_MANAGERまたはIBMMQ_QUEUEエンティティが表示されない場合：
プロセッサの順序を確認してください：transform/ibmmq-cleanupプロセッサはresourcedetectionの後に実行する必要があります 。この順序が逆の場合、メトリクスはIBM MQエンティティではなくコレクター自身のエンティティに到達し、ダッシュボードが空白になります。
必須ラベルを確認してください：メトリクスには以下のラベルを含める必要があります：
qmgrラベルqmgr="QM1"）とともに発行する必要がありますqueueラベルtarget.name属性TARGET_NAME環境変数から取得され、エンティティGUIDを形成しますTARGET_NAMEの一貫性を確認してください：初期デプロイメント後にTARGET_NAMEの値を変更しないでください。この値はすべてのエンティティGUID（target.name:qmgr）の一部になり、これを変更すると新しいエンティティが作成され、既存のエンティティが孤立して、ダッシュボードとアラートが機能しなくなります。データの可視性 メトリクスはNRDBに表示されますが、IBMMQ_MANAGERエンティティは表示されません これはほぼ常に、エンティティに不可欠なメトリクスの形状を変更したことが原因です。エンティティの合成は、生のアンダースコアメトリクス（ibmmq_*）、生のqmgrラベル、およびtarget.name属性をキーとします。以下を確認してください：
メトリクス名がドット区切りではありません。ibmmq.queue.depthではなく、ibmmq_queue_depthが表示されるはずです。
qmgrラベルが存在し、名前が変更されていません。ibmmq.queue_manager.nameとして表示されていないことを確認しました。
メトリクスにtarget.nameが設定されていること、およびキャメルケースのtargetNameとして表示されていないことを確認してください。targetNameがまだ存在し、transform/ibmmq-cleanupが実行されていないか順序が間違っている場合：
FROM Metric SELECT uniques ( target . name ) , uniques ( qmgr ) WHERE metricName LIKE 'ibmmq_%' SINCE 30 minutes ago
コレクター設定におけるプロセッサーの順序は重要です — resourcedetection → transform/ibmmq-cleanup。transform/ibmmq-cleanupを並べ替えたり削除したりした場合、IBM MQメトリクスはIBMMQ_MANAGERエンティティではなくコレクター自身のエンティティにルーティングされます。ドキュメントに記載されているパイプラインの順序を復元してください。
カウンターメトリクスが平坦な線として表示されます New Relicはカウンターに対してデルタテンポラリティを想定しています；Prometheusは累積値を出力します。cumulativetodelta/ibmmqプロセッサーはそれらをインプレースで変換します。カウンターがフラットに見える場合は、各メトリクスパイプラインにプロセッサーが存在することを確認してください。
再デプロイ後に古いエンティティが古くなった target.nameの値（LinuxではTARGET_NAME環境変数、KubernetesではtargetNameリラベルを介して設定されます）は、すべてのIBMMQ_MANAGERおよびIBMMQ_QUEUEのGUIDの最初のセグメントです。デプロイメント後にこれを変更すると、まったく新しいエンティティが作成されて古いエンティティは古くなり、古いGUIDを指すダッシュボードやアラートが機能しなくなります。安定した値を一度選択したら、決して変更しないでください。
すでに変更している場合は、元のTARGET_NAME値を復元し、コレクターを再起動します。正しい名前のエンティティは報告を再開します；間違った名前で作成された重複はデータの受信を停止し、New Relicのエンティティ報告ウィンドウの後にUIからエージアウトします。