Instana セルフホスト型クラシックエディションのリリースノート。
注: セルフホスト型クラシックエディション( Docker )では、 提供される機能や性能が限定されています。 さらなる機能や性能を活用するには、 Standard Edition をインストールするか、 へ移行してください。 Instana を初めて導入する場合は、Classic Editionではなく Standard Edition をインストールしてください。
以下の表には、リリースビルド番号、リリース日、アップグレードの互換性、および主な機能が記載されています。
表 1. クラシック・エディションのリリース
| ビルド |
リリース日 |
アップグレード元 |
新機能、改善点、および修正点 |
| 319-1 |
2026年6月26日 |
|
修正:
Nginx イメージのセキュリティ脆弱性(CVE)が修正されました。
|
| 319および318 |
2026年5月26日 |
315 |
フィーチャー:
- ウェブサイトのコンバージョン目標は、新しい指標と機能によってさらに充実しました:
- コンバージョンまでの平均時間 :セッションが最初のインタラクションからコンバージョン目標を達成するまでに要する平均時間を示す新しい指標です。
- 主要なコンバージョン目標 :各ウェブサイトについて、1つのコンバージョン目標を主要な目標として指定できるようになりました。
詳細については、 「ウェブサイトのコンバージョン目標」 をご覧ください。
- 「サービス」および「エンドポイント」ダッシュボードに、新しい「内部コール」KPIカードが追加されました。 このカードには、サービス内部で発生する呼び出しを示す「内部呼び出し」メトリクスが表示されます。
- トリガーを生成するエンティティがすでにチームに割り当てられている場合、課題およびインシデントの詳細ページにチームとの関連情報が表示されるようになりました。 この機能強化により、チームは調査の過程で責任の所在を迅速に特定し、適切な関係者に協力を求めることが可能になります。
改善点:
- クラスターおよびネームスペースのダッシュボードから、 Kubernetes のスマートアラートを設定できるようになりました。 この機能により、 Kubernetes の監視ワークフローにおけるアラートの設定が効率化されます。 詳細については、 「 Kubernetes のスマートアラート」 を参照してください。
- 「 アナリティクス 」ページでは、ウェブサイトIDまたはモバイルアプリIDを使用して、ウェブサイトやモバイルアプリからの通話をフィルタリングできるようになりました。 このフィルターが機能するようにするには、高速トリアージを有効にしてください。
- Instana リモート監視対象の Microsoft SQL Server データベースへの呼び出しについて、インフラストラクチャの相関分析に対応しました。 関連付けを成功させるには、呼び出しにおいて、データベースインフラストラクチャエンティティから報告された名前と一意に一致するホスト名またはクラスタ名を使用する必要があります。
修正:
- 以前は、ウェルカムページの「インフラストラクチャ」ウィジェットにおいて、一部の言語のメトリクスが表示されていませんでした。 This issue is now fixed.
- 以前は、 インフラストラクチャ ・ダッシュボードの「 比較表 」のページサイズを変更しても、更新に失敗し、ページサイズは変更されませんでした。 This issue is
now resolved.
|
| 317-2 |
2026年6月26日 |
|
修正:
Nginx イメージのセキュリティ脆弱性(CVE)が修正されました。
|
| 317および316 |
2026年4月26日 |
313 |
フィーチャー:
{unit}-{tenant}.instana.io/api/host-agent/{hostId}/configurationユーザーは、バックアップ、監査、またはトラブルシューティングの目的で、エージェント管理ダッシュボードから、あるいは API エンドポイントを使用して、エージェントの設定をダウンロードできるようになりました。
新しいRBAC権限「エージェント設定をダウンロードできる」により、この機能へのアクセスが制御されます。 管理者は、この機能が必要なロールにこの権限を割り当てることができます。
{unit}-{tenant}.instana.io/api/host-agent/modeAPI のエンドポイント {unit}-{tenant}.instana.io/api/host-agent/{hostId}/mode および を使用することで、個々のエージェントまたはエージェントのグループのエージェントモードを変更できるようになりました。
APMこの機能により、チームは運用対応、トラブルシューティング、またはホストの障害を未然に防ぐために、エージェントを、 INFRA / INFRASTRUCTURE、 または OFF に素早く切り替えることができます。
この機能へのアクセスは、既存のRBAC権限 Configuration of agent mode によって制御されています。
改善点:
- 「Analytics Applications」の「Calls」ダッシュボードで、IDフィールドを使用して通話のフィルタリングやグループ化ができるようになりました。 これまで内部タグとしてのみ利用可能だった「コールID」および「親コールID」を用いたフィルタリングがサポートされ、また「トレースID」および「親コールID」を用いたグループ化もサポートされています。
- Instana のUIにおいて、 インフラストラクチャマップに、 Azure リソース(Key Vault、Managed HSM、Service Busエンティティ(キューおよびトピック)など)のサブスクリプションIDが表示されるようになりました。
AWS Metric Streamsとの連携において、以下の AWS サービスが新たにサポートされるようになりました:
- Amazon Bedrock :[
ModelId dimension] を使用する基盤モデルのメトリクスを確認する
- Amazon CloudFront : 「
DistributionId 」ディメンションを使用する CDN メトリクスを監視する
- Amazon DocumentDB :および
DBInstanceIdentifier ディメンションを使用 DBClusterIdentifier するクラスターまたはインスタンスのメトリクスを追跡する
- Amazon MQ :[
Broker dimension] を使用するメッセージブローカーを監視する
実行中のコンポーネントは、インフラストラクチャ・エンティティのサイドバーに表示されます。 これらは、現在のエンティティ内の構成要素について、最も詳細なレベルで表示しています。 以下の囲み要素は、その子要素とともに表示されるよう固定されています:
- AceIntegrationServer
- IbmIOs
- IbmMqQueueManager
- 以前のリリースでは、エンティティがオフラインとマークされるまでの時間は、そのポーリングレートに正比例していました。 たとえば、ポーリング間隔が60秒の場合、そのエンティティは、実際にオフラインになってから20分後にオフラインとみなされていました。 現在のリリースでは、有効期限までの遅延時間は次のように計算されます:
- ポーリング間隔が15秒未満の場合、遅延時間はポーリング間隔の20倍となります。
- ポーリング間隔が15秒以上の場合、遅延時間はポーリング間隔の5倍となります。
その結果、ポーリング間隔が60秒の場合、 Instana では5分経過後にそのエンティティをオフラインとみなすようになりました。
- アラートチャネルを追加する際の詳細設定で、メール、 Office 365、およびMicrosoft Teamsのアラートチャネルについて、タイムゾーンを設定できるようになりました。 タイムゾーンを設定することで、アラートチャネルを通じてアラート通知を受け取る受信者は、デフォルトのUTC時間ではなく、設定されたタイムゾーンでメッセージを確認できるようになります。
- 「Analyze Infrastructure」のエージェントタグは、エージェントカテゴリにまとめられるようになりました。 この機能強化により、Unbounded Analytics との整合性が確保されます。
セルフホスト型インストールでは、アプリケーションのデータ保持期間やエンドユーザーの監視に関する設定オプションがさらに充実しました:
- デフォルトの7日間から保持期間を延長できるほか、短期の全データ保持期間を最短2日間に短縮することも可能になりました。
- 長期サンプリングデータの保存期間を設定できるようになり、デフォルトの396日から短縮することが可能です。
これらの設定オプションは、分析に必要な期間が短い場合に、アプリケーションのデータベースが使用するディスク容量を削減するのに役立ちます。
- Instana Java 向け AWS SDKのサポートが追加されました。 2.x。 将来的には、 Java 向けの AWS SDK( 1.x )に取って代わる予定です。 タイムラインの詳細については、 「非推奨機能」 を参照してください。
修正:
- Webサイトのコンバージョン目標に関する「 目標を分析」 ボタンでは、[分析] ビューでユーザー定義のフィルターが正しく適用されるようになりました。
JVM のGCメトリクスに関する5秒ごとの集計結果が、正しく報告されるようになりました。 以前は、GCの呼び出し回数および所要時間に関する5秒ごとの集計では、サンプルの平均値が使用されていました。 彼らは現在、サンプルの合計値を使用している。 Beeinstana を使用する場合、5 秒を超えるロールアップでは、ユーザー定義の集計が使用されます。
アラートに関しては、5秒ごとの集計は標準イベントでのみ使用されます。 スマートアラートでは、ユーザー定義の集計が使用されます。
- 誤検知を防ぐため、スマートアラートの信頼性を向上させました。 以前は、フィラー部品のメンテナンス作業後に、スマートアラートをミュートにすることができました。 この修正は、スマートアラートの耐障害性を向上させ、誤検知を防ぐことを目的としています。
- 特定の条件下では、アプリケーション監視機能において、デフォルト以外のポートを使用した HTTP への呼び出しが、監視対象のインフラストラクチャと関連付けられませんでした。 This issue is now fixed.
- Instana のUIから、 Kubernetes または Red Hat OpenShift にある静的な YAML ファイルを使用してエージェントをインストールするオプションが削除されました。 これらのオプションは2025年3月に非推奨となりました。
|
| 315-1 |
2026年6月26日 |
|
修正:
Nginx イメージのセキュリティ脆弱性(CVE)が修正されました。
|
| 315および314 |
2026年3月17日 |
ビルド 311 |
フィーチャー:
- Linux (パブリックプレビュー)で、 Instana エージェントを非rootユーザーとして実行する: Linux プラットフォーム上で、 Instana エージェントを非rootユーザーとして実行し、完全な監視機能を維持できるようになりました。 この機能はパブリックプレビューとして提供されています。 インストールおよび設定の詳細については、 エージェントの非rootユーザーによるインストール手順を参照してください。
- インフラストラクチャ用グラフエクスプローラー: インフラストラクチャダッシュボードに新しいグラフエクスプローラー ビューが追加されました。このビューでは、ノードとエッジによるグラフレイアウトを用いて、インフラストラクチャエンティティとその関係を視覚的に表示します。
- Microsoft SQL Server のAlways On可用性グループ(AG)の監視: Microsoft SQL Server センサーは、Always On可用性グループ(AG)の監視に対応するようになり、インスタンスレベルと可用性グループエンティティレベルの両方でメトリクスを収集できるようになりました。 詳細については、 「 Microsoft SQL Server の監視」 を参照してください。
改善点:
- インフラストラクチャの分析: Instana UI の 「インフラストラクチャの分析」 ダッシュボードにある 「メトリクス 」セクションから、メトリクスを追加できるようになりました。 「メトリクスの選択」リストは利用できなくなりました。
- カスタムダッシュボード:不要なウィジェットの再読み込みを最小限に抑えるよう最適化されたウィジェット。 この機能強化により、カスタムダッシュボードの編集および設定時のパフォーマンスが向上します。
- データ粒度テーブルにおけるおおよその取り込み量:データ粒度テーブルが拡張され、サービスやエンドポイント、EUMのWebサイトやアプリケーション、および合成テストを含むすべてのデータタイプについて、おおよその取り込み量が提供されるようになりました。
修正:
名前にピリオドが含まれる「 HTTP 」ヘッダーに対するフィルタリングおよびグループ化:バックエンドのトレース処理において、ヘッダー名にピリオドが含まれる「 HTTP 」ヘッダーが正しく処理されていませんでした。 そのため、こうしたヘッダーに基づいてフィルタリングやグループ化を行うと、誤った結果が返されてしまいました。 This issue is now fixed.
|
| 313-2 |
2026年3月17日 |
|
修正:
- エージェントのダウンロードに関連する複数の問題が解決されました。
- 監視対象エンティティが「オフライン」状態に移行するまでの時間は、そのエンティティに設定されたポーリング頻度の整数倍として算出された。 その結果、 60‑second のポーリングレートを持つエンティティは、データの報告を停止してから約20分後まで、オフラインとしてマークされませんでした。 これで問題は解決しました。 ポーリング間隔が15秒以上のエンティティに対しては、より短く、かつ一貫性のあるタイムアウトが適用されます。 たとえば、 60‑second のポーリングレートの場合、5分間操作がないと、エンティティは「オフライン」状態に移行します。
|