既知の問題と制約事項

IBM の可観測性に関する既知の問題と制限事項を確認してください。 Instana

既知の問題

CrowdStrike Falcon のサイドカーと Instana エージェントの非互換性

Instana エージェントコンテナは、 CrowdStrike Falcon サイドカーと互換性がありません。 Falconは DaemonSet としてのみ使用できます。

Windows Server 2016 における「 Instana 」エージェントのメモリ問題

Windows Server 2016 ホストにおいて、 Instana エージェントが使用するライブラリが、メモリを適切に解放せずに徐々に消費し続けるため、影響を受ける Windows システムでメモリ使用量が増加する可能性があります。 メモリ使用量を抑えるため、 Instana エージェントは自動的に再起動されます。 自動再始動機能は、メモリーの問題がエージェントの自動更新に影響しないようにするためのものです。 デフォルトでは、 Windows Server 2016 に展開されているすべての Instana エージェントは、7日ごとに午前5時から5時30分の間に再起動します。 この機能は、 Instana エージェントバンドル 1.1.702 以降で利用可能です。 エージェント・バンドルのバージョンは、 Instana のエージェント起動ログで確認できます。

デフォルトの再起動動作を変更するには、 Instana エージェントを起動する前に、以下の環境変数を設定してください。

環境変数名 Default
INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_ENABLED true 自動再始動を有効または無効にするフラグ。
INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME 5:15 Instana エージェントが再起動する時刻。
INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN 30 エージェントが再始動する時刻範囲を設定するためのジッター (分単位)。 このジッターは、 Instana エージェントが同時に再起動するのを防ぐためのものです。 再始動時間は、指定された範囲内でランダムに選択されます。 再始動時間のランダム化を変更するには、1 より大きい値を設定します。 再始動時間の時刻範囲は、式 INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME -(INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN/2) および INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME + (INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN/2) を使用して計算されます。 たとえば、再起動時刻を午前 5.15 に設定し、ジッターを30分に設定した場合、再起動は午前5:00から5:30の間に実行されます。
INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_MIN_INTERVAL_IN_DAYS 7 次の再始動が行われるまでの間隔。 ゼロより大きい値を設定してください。

MACアドレスが同一であるためにエージェントIDが競合する

複数のシステムが同じMACアドレスを共有すると、同一のエージェントIDが生成され、ホストIDの競合が発生します。 その結果、エージェント同士が互いのデータを上書きしてしまい、あるホストの処理が別のホストのものとして誤って認識される可能性があります。

この問題を解決するには、以下の設定オプションのいずれかを使用できます:

オプション 1: エージェント ID に FQDN を追加する

エージェントIDにFQDNを含めるように INSTANA_APPEND_FQDN_TO_AGENT_ID=true 環境変数を設定します。 この設定により、MACアドレスが同一であっても、各エージェントIDが一意であることが保証されます。

複数のホストが同じMACアドレスを共有しているが、FQDNまたはホスト名がそれぞれ異なる場合に、このオプションを使用してください。

オプション 2: ホスト固有 ID を保持する

環境変数を設定 INSTANA_PERSIST_HOST_UNIQUE_ID=true して、一意のハッシュベースのエージェントIDを生成し、保持します。 エージェントは初回起動時に一意のIDを生成し、それをディスクに保存することで、エージェントの再起動後も同一のIDが使用されるようにします。

エージェントは、IDを以下のプラットフォーム固有の場所に保存します。 プライマリの場所が利用できない場合、エージェントは自動的に代替の場所を試みます:

Linux または Unix:
  • プライマリ: /proc/1/root/var/lib/instana/instana-agent-id (コンテナ内およびホスト上で動作)
  • 代替案: /var/lib/instana/instana-agent-id
macOS:
  • プライマリ: ~/Library/Application Support/com.instana.agent/instana-agent-id (ユーザー固有)
  • フォールバック: /Library/Application Support/com.instana.agent/instana-agent-id (システム全体)
Windows:
  • 1 次: %LOCALAPPDATA%\Instana\agent\instana-agent-id
  • 代替案: %APPDATA%\Instana\agent\instana-agent-id または %PROGRAMDATA%\Instana\agent\instana-agent-id

環境変数を設定することで、これらの場所 INSTANA_AGENT_ID_FILE_PATH=/custom/path/to/instana-agent-idを上書きすることができます。

再起動後も維持される安定したエージェントIDが必要な場合、またはMACアドレスが一時的なコンテナ環境で実行する場合に、このオプションを使用してください。

オプション 3: 静的エージェント ID を設定する

エージェント設定ファイルに、次の <instanaAgentDir>/etc/instana/com.instana.agent.main.config.Agent.cfg 行を追加して、静的なエージェントIDを手動で指定します:
uniqueAgentId=SomeUniqueString
を、ご希望の一意の SomeUniqueString 識別子に置き換えてください。 例:
uniqueAgentId=prod-server-01-custom-id

エージェントIDを完全に制御する必要がある場合や、特定の命名規則を使用したい場合に、このオプションを使用してください。

注:

複数の設定オプションが指定されている場合、エージェントは以下の順序でそれらを使用します:

  1. 静的エージェントID (uniqueAgentId)
  2. 永続化された一意のID (INSTANA_PERSIST_HOST_UNIQUE_ID)
  3. FQDN を含む MAC ベースの ID (INSTANA_APPEND_FQDN_TO_AGENT_ID)
  4. デフォルトのMACアドレスに基づくID

古いバージョンの Kubernetes および containerd 環境におけるCRI- API 接続の失敗

古いバージョンまたはカスタマイズされたバージョンの RKE2 およびContainerdを実行している Kubernetes 環境では、モニタリングエージェントがContainer Runtime Interface(CRI) gRPC API を介してコンテナランタイムとの通信を確立できない場合があります。

バージョンの例:

  • コンテナランタイムのバージョン: containerd://1.4.12-k3s1
  • Kubelet のバージョン: v1.21.8+rke2r1

この不具合は、次のようなエラーとして現れます:

io.grpc.StatusRuntimeException: UNIMPLEMENTED: unknown service runtime.v1.RuntimeService
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:268) ~[?:?]
 

この問題は、 Kubernetes およびContainerdの古いバージョンが、エージェントが期待するCRI( gRPC API )を完全にサポートしていない可能性があるため発生し、コンテナランタイムとの通信中に接続エラーが発生します。

回避策として、エージェント上で INSTANA_USE_CONTAINERD_CRI_CLIENT=false 環境変数を設定し、CRIクライアントを介したコンテナランタイムとの通信を無効にしてください。 その後、エージェントは を使用してメトリクスを ctr 収集します。

既知の制限

Elasticsearch 8.18 + monitoring failure

Elasticsearch ( 8.18.0 )以降、 Instana エージェントは Elasticsearch のJVMに接続できなくなりました。 この障害は、 Elasticsearch ( 8.18.0 )が、 Java ( SecurityManager )からEntitlementsセキュリティフレームワークへ恒久的に移行したために発生します。 詳細については、 Elasticsearch 8.18.0 のリリースノートをご覧ください。

このセキュリティフレームワークは、動的に読み込まれたコードによって実行される機密性の高いJDK操作を検知し、制限します。 Instana エージェントが標準の JVM アタッチメント( API )を使用しようとすると、ターゲットの JVM にローダーコンポーネントを埋め込みます。 ローダーは、監視を確立するために、 ClassLoaders, インストルメンテーション API を使用したバイトコードの変更、エージェントへの送信 TCP 接続の確立、データ収集のためのバックグラウンドスレッドの開始など、いくつかの操作を実行する必要があります。

Elasticsearch のセキュリティフレームワークは、これらの操作を黙ってブロックします。 その結果、ローダーは初期化シーケンスを完了できず、必要なコールバック接続を確立できません。 エージェントは応答を90秒間待ちます。 応答がない場合、エージェントは JVM を監視対象外としてマークし、すべての監視試行を停止します。 この動作のため、 Instana エージェントは、 Elasticsearch、 8.18、および Java のプロセスを監視できません。

注:Elasticsearch のバージョン 8.18 以降については、変更タグ 2026.04.16.1110 でリリースされた Instana エージェントのバージョン 1.2.61 以降でサポートされています。 このアップデートでは、バイトコード変換を通じて Elasticsearch の権限管理システムとの互換性が追加されました。 これにより、 Instana エージェントは、 Elasticsearch のセキュリティ違反や権限違反を引き起こすことなく、正常に動作します。

Windows におけるプロセッサグループの認識

64コア以上を実行する2008~2019年版の Windows サーバーでは、 Instana エージェントは、自身に割り当てられたプロセッサグループ内のコアのみを監視できます。 この制限が生じるのは、現在のバージョンのエージェントがプロセスグループに対応していないためであり、つまり、プロセッサグループに属していないコアを認識できないからです。

トレースおよび呼び出しの分析

呼び出しが log.level または log.messageによってグループ化されている場合、特殊タグ・グループ Tag not present は、他のタグと同じようには表示されません。

この機能の詳細については、 「トレースと呼び出しの分析」 を参照してください。

ダイナミックフォーカスによるフィルタリング

この機能の詳細については、 「動的フォーカスによるフィルタリング」 を参照してください

構文の制約

  • ! と否定する照会の間に空白を入れることはできません。 代わりに !<query> または NOT <query> を使用してください。
  • ダイナミック・フォーカス・キーワードの entity.application.nameentity.service.nameentity.endpoint.name のうち、同じキーワードを同時に複数回使用する場合は、OR 演算子を使用して結合する必要があります。 E.g. 照会 entity.application.name:foo AND entity.application.name:bar, entity.application.name:foo entity.application.name:bar はサポートされていません。 照会 entity.application.name:foo OR entity.application.name:bar はサポートされます。
  • ダイナミック・フォーカスキーワードの entity.application.nameentity.service.nameentity.endpoint.name のうち、異なるキーワードを同時に使用する場合は、AND 演算子を使用して結合する必要があります。 E.g. 照会 entity.application.name:foo AND entity.service.name:bar はサポートされていますが、照会 entity.application.name:foo OR entity.service.name:bar はサポートされていません。
  • アプリケーション名、サービス名、またはエンドポイント名の否定を含む照会はサポートされません。 そのため、NOT entity.application.name:foo!entity.service.name:bar、および NOT entity.endpoint.name:foobar はいずれも無効です。 ただし、代わりに NOT event.entity.label:foo を使用することで、アプリケーション、サービス、またはエンドポイントのイベントを除外することはできます。
  • ダイナミック・フォーカス・クエリー entity.application.name:<term>entity.service.name:<term> および entity.endpoint.name:<term> は、ストリング contains ロジックを使用して評価されます。例えば、ダイナミック・フォーカス・クエリー entity.application.name:shopentity.application.name:shop-frontendと一致します。
  • ダイナミック・フォーカス照会キーワード entity.application.nameentity.service.name、および entity.endpoint.name は、ブール照会 (上記のブール論理の制約を参照)、用語照会、語句照会、および接頭語照会でのみサポートされます。

クエリーの制限

  • ハイフンが含まれる event.text に対するダイナミック・フォーカス・クエリーからは、予期しない結果が返される可能性があります。 例: また、 event.text:"foo-bar-random" は、Lucene アナライザーのトークン化のために、 foo または bar または random のみを含むイベントを返します。
  • Docker コンテナーに続くエンティティー ( 「ホスト」「アベイラビリティー・ゾーン」など) は、ほとんどの Kubernetes キーワードにスコープを設定するときに選択できません。 例えば、クエリー entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:host はホストを返しません。 一方、クエリー entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:docker は、デプロイメントに関連するすべての Docker コンテナーを返します。 ただし、 ホスト entites, nameley entity.kubernetes.cluster.* および entity.kubernetes.node.*を選択するために使用できる Kubernetes キーワードがいくつかあります。 例えば、照会 entity.kubernetes.cluster.label:my-K8s-cluster AND entity.selfType:host は、クラスターのすべての関連ホストを返します。

インフラストラクチャー・メトリック

  • パフォーマンス上の理由から、 Instana のUIでは、エンティティごとに最大3000個のメトリクスしか表示できません。 この制限を超える数のメトリックを持つダッシュボードには、欠落しているメトリックがあります。
  • 負のメトリック値は表示されません。

IBM App Connect Enterprise (ACE)の監視

  • REST API インターフェースで HTTPS が有効になっている場合は、 <agent_install_dir>/etc/instana/configuration.yamlでキーストアと keystorePassword のパラメーターを指定する必要があります。 鍵ストア・タイプには、JKS または P12 のみがサポートされます。
  • ACEのユーザー・エグジット・トレーシング方式は、シングルノード構成のみをサポートしています。 高可用性(HA)構成およびクラスタ環境はサポートされていません。 HA展開やクラスタ環境では、ユーザー・エグジット方式の代わりに、 OpenTelemetry のネイティブトレース機能を使用してください。

この機能の詳細については、 「 IBM App Connect Enterprise (ACE)の監視」 を参照してください

Jaeger トレース

  • Jaeger から収集されたトレース・データは、AutoTrace を介して収集されたトレース・データと相関されません。その結果、Jaeger と Instana AutoTrace によってそれぞれトレースされたシステムが、相互に直接対話する場合であっても、別々のトレースになります。

  • Jaeger トレース・データは、どのプロセスがそれらをホスト・エージェントに送信するかという概念を伝達しないため、Instana は、それらのトレースをホスト・エージェントを支えるホストに相関させます。 これにより、プロセスとの関連付けが回避されます。したがって、コンテナーとプラットフォームの階層 (Kubernetes ポッド、名前空間、クラスターなど) との関連付けも防止されます。

  • Jaeger には、ユーザー・モニターの概念がありません (ただし、 W3C TraceContext.md の採用によって最終的には変更される可能性があります)。そのため、Instana Web サイト・モニター で収集されたビーコンは、Jaeger から収集されたバックエンド・トレースと相関しません。

  • ホスト・エージェントは、HTTP のみを介した Jaeger トレースの収集をサポートします。 JAEGER_AGENT_HOST および JAEGER_AGENT_PORT 環境変数を構成する場合に使用されるプロトコルである UDP は、サポートされません。

この機能の詳細については、 Jaeger を参照してください

OpenTelemetry トレース

  • OpenTelemetrylinks はサポートされていません。
  • Instana のデフォルトのコンテキストプロパゲータを、それ以外のコンテキストプロパゲータ W3C Trace Context と組み合わせることはサポートされていません。 W3C Trace Context OpenTelemetry のデフォルトのコンテキストプロパゲーターです。

この機能の詳細については、 OpenTelemetry のトレースを参照してください

IBM MQ トレース

Windows プラットフォームには既知の問題があり、宛先キューのモニターレベル (IBMMQ_DEST_MONITOR_LEVEL_*) とグローバルモニターレベル (MONITOR_LEVEL) を同時に使用することができません。

AIX プラットフォームでは、 OTLP gRPC プロトコル(設定時に有効化 OTLP_EXPORTER_GRPC_ENDPOINTされる)は利用できないため、デフォルトでは HTTP が使用されます。

Zipkin トレース

  • Zipkin から収集されたトレース・データは、AutoTrace を介して収集されたトレース・データと相関されません。その結果、Zipkin と Instana AutoTrace によってそれぞれトレースされたシステムが、相互に直接対話する場合であっても、別々のトレースになります。

  • Zipkin にはユーザー・モニターの概念がありません (ただし、これは最終的に W3C TraceContext.md の採用によって変更される可能性があります)。そのため、Instana Web サイト・モニター で収集されたビーコンは、 Zipkinから収集されたバックエンド・トレースと相関しません。

  • ホスト・エージェントは、HTTP を介した Zipkin トレースの収集のみをサポートします。これは、Zipkin の COLLECTOR_HTTP_ENABLED設定に対応します。

この機能の詳細については、 Zipkin を参照してください

Containerd のモニタリング

CPU Total Normalized および Memory Working Set Usage % メトリックは、制御グループ v1 (cgroupv1) を使用しているシステムでのみ使用可能です。

Amazon MSK のモニター

Amazon MSK センサーは、プロビジョンされた MSK クラスター・タイプのモニターのみをサポートします。 サーバーレス・クラスター・タイプはサポートされていません。

ALPNのサポート

Instana エージェントおよびバックエンドは、以下の要件が満たされている場合、アプリケーション層プロトコルネゴシエーション(ALPN)接続をサポートします:

  • Netty 4.1.49.Final 以降
  • Java 開発キット(JDK) 1.8.0_251 以降

CPU使用率の高さへの対処

エージェント・コンテナー 1.263.3 以前のホット・スポット・ベースのエージェントでは、CPU 使用率が高くなります。 この問題を解決するには、エージェントを再インストールしてください。 予約済みコード・キャッシュ・サイズが、高い CPU 使用量をサポートするように増やされました。 ホスト環境で実行されるエージェントの場合は、エージェントを削除してから再インストールします。

Kubernetes (k8s) または OpenShift Container Platform (OCP) を使用している場合は、以下の手順を実行します。

  1. エージェントのアンインストール:

    kubectl delete agents.instana.io instana-agent -n instana-agent --wait; helm uninstall instana-agent -n instana-agent; kubectl delete crd agents.instana.io; kubectl delete namespace instana-agent
     
  2. エージェントのインストール:

    Instana エージェントをインストールするには、 Kubernetes または OpenShift Container Platform で「 Helm 」チャートをご利用ください。

合成テスト属性

Browser Simple、 API Script、および API のSimpleテスト(UIおよび API )では、 scriptType としてのJestはサポートされていません。 scriptType としての Jest は、ブラウザスクリプトテストでのみ使用できます。

一部の合成テスト属性は、 Instana のUIではサポートされていません。 これらの属性を設定するには、「 API 」を開くか、 synctl ツールを使用してください。 Instana のUIでサポートされていない属性は、次の表に示されています:

テスト属性 ブラウザー・スクリプト ブラウザー (シンプル) API シンプル API スクリプト
ブラウザー 該当なし 該当なし
expectExists 該当なし 該当なし 該当なし
expectNotEmpty 該当なし 該当なし 該当なし
ScriptType 該当なし 該当なし
HEAD (操作) 該当なし 該当なし 該当なし
DELETE (操作) 該当なし 該当なし 該当なし
OPTIONS (操作) 該当なし 該当なし 該当なし
PATCH (操作) 該当なし 該当なし 該当なし
POST (操作) 該当なし 該当なし 該当なし
PUT (操作) 該当なし 該当なし 該当なし

記号 ☒ は、その属性が Instana のUIではサポートされていないことを示しています。

N/A は、属性がテスト・タイプに適用されないことを示します。

ビジネス・プロセス

IBM 上で動作する特定のバージョンの Business Automation Workflow (BAW)には既知の制限事項があり( J9 JVM )、これがビジネスプロセスの機能に影響を及ぼす可能性があります。 この問題により、システム内の一部のプロセスまたはすべてのプロセスが表示されなくなったり、アクセスできなくなったりする可能性があります。

ビジネス・パースペクティブ

Instana が接続されたエージェントを検出しなかった場合、「ビジネス展望」タブは使用できなくなります。 ビジネスの見通しを確認するには、少なくとも1人のエージェントが接続されていることを確認してください。

キャンバスの描画

Safariを使用している場合、一部のキャンバスが Instana のUIで正しく表示されないことがあります。 これには、以下のものが含まれます。

  • ビジネスプロセスのフロー図
  • インフラストラクチャ図
  • 本事象の推定根本原因のトポロジー
  • OTel のコレクター設定エディタのグラフ

より適切に表示されるよう、Chromeや Firefox などの他のブラウザをご利用ください。