IBM MQキューマネージャーがKubernetesでポッドとして実行されている場合、クラスタの拡張に合わせて自動的に検出して追跡できる監視ソリューションが必要です。このガイドでは、手動で設定を変更することなく、キューマネージャーを自動的に検出してそのメトリクスをNew Relicに送信するコレクターをデプロイする方法を説明します。
New RelicのDistribution of OpenTelemetry（NRDOT）またはOpenTelemetry Collector Contribのいずれかを使用できます — どちらも同じ設定と自動検出アプローチを使用します。コレクターはアノテーションによってキューマネージャーのポッドを検出し、そのメトリクスを収集して、整理されたデータをNew Relicに送信します。New Relicでは、すぐに使用できるダッシュボードを備えたIBMMQ_MANAGERおよびIBMMQ_QUEUEエンティティとして表示されます。新しいキューマネージャーを追加すると、コレクターが自動的にそれらを検出します — 設定の更新は必要ありません。
ヒント
代わりにキューマネージャーが従来のホストで実行されている場合は、セルフホスト型IBM MQのモニターを参照してください。
あなたが始める前に
コレクターを設定する前に、以下のコンポーネントが必要です：
- 有効なライセンスキーを持つNew Relicアカウント
- ご使用のリージョンのNew Relic OTLPエンドポイント
kubectlアクセスがあり、HelmがインストールされているKubernetesクラスタ- ポートでメトリクスを公開するmq-metric-samplesエクスポーターのサイドカーを使用して実行されているIBM MQキューマネージャーのポッド
9157 - 必要なPrometheusアノテーションが付与されたキューマネージャーのポッド
ヒント
より優れたスループットメトリクスのために、ALTER QMGR STATMQI(ON) STATQ(ON)を使用してキューマネージャーでMQI統計を有効にすることをお勧めします。
IBM MQの監視のセットアップ
以下の手順に従ってコレクターをデプロイし、IBM MQのメトリクスをNew Relicに送信し始めます：
New Relic 認証情報シークレットを作成する
New Relicの認証情報を安全に保存するために、Kubernetesシークレットを作成します。コレクターは実行時にこれらの値を読み取るため、設定ファイルに機密情報が含まれないようにします。
ibmmqネームスペースが存在することを確認します：bash$kubectl get namespace ibmmq >/dev/null 2>&1 || kubectl create namespace ibmmq<YOUR_LICENSE_KEY>を実際のライセンスキーに置き換えて、認証情報のシークレットを作成します：bash$kubectl create secret generic newrelic-otlp-secret \>--namespace ibmmq \>--from-literal=NEW_RELIC_LICENSE_KEY="<YOUR_LICENSE_KEY>" \>--from-literal=NEW_RELIC_OTLP_ENDPOINT="https://otlp.nr-data.net:4318" \>--dry-run=client -o yaml | kubectl apply -f -EUアカウントの場合は、エンドポイント値として
https://otlp.eu01.nr-data.net:4318を使用します。
コレクターのHelm値を設定する
コレクターの設定を含むローカルのvalues.yamlファイルを作成します。このファイルには、OpenTelemetry Helmチャートを介してコレクターをデプロイするために必要なすべての設定が含まれています。
注意
初回のデプロイメント後にTARGET_NAMEを変更しないでください。この値は、すべてのIBMMQ_MANAGERおよびIBMMQ_QUEUEエンティティGUIDの1番目のセグメントを形成します。これを変更すると、新しいエンティティが作成され、既存のエンティティが孤立して、ダッシュボードとアラートが破損します。
この設定で行うこと
この設定は、IBM MQキューマネージャーのポッドを検出し、そのメトリクスをNew Relicに送信する自動検出パイプラインを作成します。処理パイプラインはホストのセットアップと同じですが、静的なターゲットの代わりにポッドの自動検出を使用します：
| セクション | ロール |
|---|---|
prometheus/ibmmq レシーバー | 必要なアノテーションを持つibmmqネームスペース内のキューマネージャーのポッドを自動的に検出します。各ポッドのメトリクスのエンドポイントに接続し、60秒ごとにIBM MQデータを収集します。 |
filter/ibmmq-overhead | IBM MQデータを含まないエクスポーターの内部セルフメトリクス（go_*やprocess_*など）を削除し、データ取り込みコストを最適化します。 |
filter/ibmmq-queues | 内部のIBM MQシステムキュー（SYSTEM.*およびAMQ.*）を除外し、アプリケーションキューのみがNew Relicのエンティティになるようにします。 |
transform/ibmmq-cleanup | New Relicの適切なIBM MQエンティティにメトリクスをマッピングする重要なコンポーネント。これがないと、データはダッシュボードやアラートを備えたIBMMQ_MANAGERおよびIBMMQ_QUEUEエンティティではなく、一般的なコレクターメトリクスとして表示されます。 |
memory_limiter/ibmmq | Kubernetesによってコレクターのポッドが強制終了されるのを防ぐため、メモリ使用量を400MB（512Miのコンテナ制限未満）に制限します。 |
batch/ibmmq | 送信前にメトリクスをグループ化し、リクエストごとに最大1000個のデータポイントをバンドルすることでネットワークのオーバーヘッドを削減します。 |
otlphttp/ibmmq エクスポーター | 認証用のライセンスキーと設定されたリージョナルエンドポイントを使用して、処理されたメトリクスをNew Relicにエクスポートします。 |
重要なKubernetesの設定：
| 設定 | 必要な理由 |
|---|---|
replicaCount: 1 | kubernetes_sdを使用し、TargetAllocatorを使用しない場合、すべてのレプリカがすべてのターゲットをスクレイピングするため、複数のレプリカがメトリクスを二重にカウント（および二重に課金）します。HAの場合は、OpenTelemetry TargetAllocatorを使用してターゲットをシャードします。 |
mode: deployment （daemonsetではありません） | DaemonSetはすべてのノードでkubernetes_sdを実行し、NノードのクラスタのすべてのメトリクスのN個のコピーを生成します。 |
clusterRole.create: true | kubernetes_sd ポッドにget/list/watchが必要です；これがないと、APIは403 Forbiddenを返し、レシーバーは0個のターゲットを検出します（コレクターは起動しますが、何も出力しません）。 |
service.enabled: false | このコレクターにはインバウンドレシーバーがないため、そうしないとチャートはゼロポートのServiceを作成しようとして、インストール時に失敗します。:8888のセルフテレメトリーには、引き続きkubectl port-forward経由で到達可能です。 |
replacement: $$1:$$2 （リラベルルール4） | $$はOTel設定ローダーの${...}環境変数展開をエスケープするため、Prometheusエンジンはリテラルの$1:$2キャプチャグループ構文を受け取ります。単一の$1:$2は空の環境変数として消費され、アドレス構築を失敗させます。 |
image.tag: "latest" | テストには適しています；本番環境では特定のバージョンを使用してください。 |
Helmを使用してコレクターをインストールする
OpenTelemetry Helmリポジトリを追加し、前の手順で作成したvalues.yamlを使用してibmmqネームスペースにコレクターをインストールします：
$helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts$helm repo update$
$helm upgrade --install ibmmq-collector open-telemetry/opentelemetry-collector \> --namespace ibmmq \> --create-namespace \> --values values.yamlコレクターのポッドが1/1 Runningに到達しない場合は、以下の「トラブルシューティング」を参照してください。
デプロイメントを確認する
コレクターのポッドが実行されていることを確認します：
$kubectl -n ibmmq rollout status deploy/ibmmq-collector-opentelemetry-collector --timeout=180s$kubectl -n ibmmq get podsコレクターのポッドには1/1 Runningが表示されるはずです。実際にポッドを検出してスクレイピングしていることを確認するには、その自己テレメトリーのエンドポイント（インバウンドのServiceが無効になっているため、:8888で公開され、port-forward経由でのみ到達可能）をポートフォワードし、accepted/exportedカウンターを確認します：
$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'$kill %1 2>/dev/nullotelcol_receiver_accepted_metric_points 0より大きい値は、コレクターがアノテーション付きの実行中のポッドを少なくとも1つ見つけてスクレイピングしたことを確認するものです；otelcol_exporter_send_failed_metric_pointsは0のままである必要があります（ゼロ以外の値はOTLP接続または認証情報に関する問題を示します）。
次に、データの検索とクエリの検証クエリを使用して、New RelicでIBM MQのメトリクスとエンティティを確認します。ステータス値の意味については、MQステータスコードリファレンスを参照してください。
New Relic でデータを表示する
コレクターのポッドが実行され、メトリクスが流れるようになると、New RelicでキューマネージャーがIBMMQ_MANAGERエンティティとして表示され、そのキューが子IBMMQ_QUEUEエンティティとして表示されます。データの検索、クエリの実行、ダッシュボードやアラートの設定の詳細については、データの表示とクエリを参照してください。