第4章 修正された問題

Cryostat のリリースには、Cryostat の以前のリリースで特定された問題の修正が含まれている場合があります。問題の説明とその後の修正については、修正された各問題の注記を確認してください。

Cryostat 2.4 リリースで、以下の問題が修正されました。

遅延接続ターゲットでのルールアクティベーションの失敗

Cryostat 2.4 より前のバージョンでは、Cryostat は検出された JVM ターゲットで自動ルールをトリガーできない場合がありました。この問題は、コンテナー内の JVM が受信 JMX リクエストを受け入れる準備ができる前に、検出メカニズム (OpenShift エンドポイントのクエリーなど) により新しいターゲットコンテナーに関する通知を Cryostat に送信した場合に発生する可能性があります。

Cryostat 2.4 は、以前は接続できなかったターゲット JVM の再チェックを実行し、設定された期間、定期的に頻繁にルールのトリガーを再試行することで、この問題を解決します。今回の修正は、Cryostat と JVM の間の接続の問題をより迅速に解決するのに役立ちます。この修正は、ルールの有効化と無効化を切り替えるときに、ルールがトリガーされる一貫性のない動作や予測不可能な動作を回避するのにも役立ちます。

検出プラグインの登録の失敗

Cryostat 2.4 より前では、Cryostat エージェントのインスタンスが Cryostat サーバーに登録できない場合がありました。登録プロトコルには、このような問題を特定して登録をリセットできるように、定義された動作がありますが、このような定義済み動作は、他の状況でも失敗する可能性があります。これらの問題が両方発生した場合、Cryostat サーバーには、サーバーが有効であるとみなした無効なエージェント登録レコードが存在します。この状況では、エージェントは、以前の登録が失敗したという想定に基づいて、さらに登録を試行する可能性があります。ただし、サーバーはその後、エージェントがすでに登録されているという想定に基づいて、エージェントの再登録の試みを拒否します。これにより、エージェントとサーバーは相互に認識したり、登録ステータスをリセットしたりすることはできません。

Cryostat 2.4 はこの問題を解決し、より信頼性の高いエージェント検出登録を提供します。

エージェントインスタンスが利用できないため、サーバーの起動に失敗する

Cryostat 2.4 より前では、Cryostat サーバーをシャットダウンして再起動すると、サーバーが正常に再起動できない場合がありました。この問題は、有効なエージェント登録レコードが含まれるサーバーをシャットダウンし、エージェントを再起動せずにこれらのエージェントインスタンスをシャットダウンした場合に発生していました。このような場合、サーバーの起動時に、サーバーは既存のエージェント登録レコードを確認して、これらのエージェントインスタンスがまだ存在すると想定します。しかし、エージェントが利用できなくなったため、サーバーは起動に失敗しました。

Cryostat 2.4 ではこの問題が解決されています。このリリースでは、サーバーの起動時に、利用できなくなったエージェントインスタンスにエージェントの登録レコードがまだ存在する場合、サーバーはこれらの登録レコードを削除し、サーバーの起動が通常どおり続行されます。

cryostat-reports および jfr-datasource によるコンテナー調整プロパティーがオーバライドされてしまう

cryostat-reports および jfr-datasource コンテナーはどちらも OpenJDK UBI ランタイムイメージを使用します。Cryostat 2.4 より前では、これらのコンテナーは、基本イメージのエントリーポイントスクリプトが実行するさまざまなコンテナー調整プロパティーをオーバーライドするように誤って設定されていました。

Cryostat 2.4 では、cryostat-reports と jfr-datasource コンテナーがコンテナー調整プロパティーをオーバーライドしなくなり、これらのパラメーターが有効になりました。

自動ルールを使用してフライトレコーディングを再開するときに JFR データが切り捨てられる

Cryostat 2.4 より前のバージョンでは、クライアントが自動化ルールを使用して JFR レコーディングを作成する要求を送信すると、既存のレコーディングの JFR データが予期せず切り捨てられる可能性がありました。これは、クライアント要求に restart=true 設定が含まれているが、同じ名前の既存のレコーディングがまだ STOPPED 状態ではなかった場合に発生する可能性があります。この状況では、サーバーがレコーディングを自動的に停止、削除、再作成したため、アーカイブされていない録画データが失われました。

Cryostat 2.4 では、以前のリリースで使用できた restart パラメーターに代わる replace パラメーターを導入することで、この問題を解決しています。JFR レコーディングを作成する自動ルールを定義するときに、クライアント要求に replace=stopped 設定を含めることができるようになりました。この設定は、既存のレコーディングが STOPPED 状態にある場合にのみ、JFR レコーディングを再開するようにサーバーに指示します。既存のレコーディングが RUNNING などの別の状態にある場合、サーバーはリクエストを拒否します。

CPU 制限が小さいためにコンテナーの起動が失敗する

Cryostat 2.4 より前は、CPU の制限が小さく、Cryostat がデプロイされている場合、コンテナーが起動に失敗する可能性がありました。

Cryostat 2.4 では、Cryostat が CPU 制限が小さい状態でデプロイされている場合でもコンテナーを起動できるようにすることで、この問題を解決しています。