第5章 修正された問題

Cryostat リリースには、以前のバージョンで特定された問題に対する修正が含まれる場合があります。以下の注記には、各問題とその解決策の詳細が記載されています。

Cryostat 4.0.2 で修正された問題

Cryostat 4.0.2 リリースには、依存関係の 1 つに対する重要なセキュリティー更新に加えて、中程度の Cryostat セキュリティー更新が含まれています。これらのセキュリティー更新の詳細は、RHSA-2025:14919 を参照してください。

Cryostat 4.0.1 で修正された問題

Cryostat 4.0.1 リリースでは、次の問題が解決されました。

Cryostat ではカスタムではないターゲットの削除が可能

Cryostat 4.0.1 より前のリリースでは、カスタムターゲット削除エンドポイント (DELETE/api/v4/targets/{id}) によって、検出されたターゲットの削除が誤って許可されていました。

Cryostat 4.0.1 では、カスタムターゲット削除エンドポイントで、対応する POST/api/v4/targets エンドポイントによって作成されたカスタムターゲットの削除のみが許可されるようにすることで、この問題を解決しました。Cryostat に組み込まれている検出メカニズムでは、他のターゲットは削除できません。これらの他のターゲットは、それらを見つけた検出メカニズムによってのみ削除できます。この状況では、削除されるターゲットが Custom Targets レルムのメンバーではない場合、Cryostat は HTTP 400 Bad Request エラーで応答します。

新しく検出されたターゲットに対して自動ルールがアクティブ化されない可能性がある

Cryostat 4.0.1 より前のリリースでは、影響を受ける別のターゲットが接続に失敗した場合、エラー処理の問題により、自動化ルールがターゲットに対してアクティブ化されない可能性がありました。

Cryostat 4.0.1 では、ルールエグゼキューターによって出力されたエラーがルールサービスに返され、エラーが正しく処理されるようになり、この問題は解決しました。

Kubernetes API ターゲット検出が default namespace のエンドポイントの同期に失敗する

Cryostat 4.0.1 より前のリリースでは、ターゲット namespace に targetRef フィールドを持たない Service オブジェクト (default namespace の kubernetes サービスなど) が含まれている場合、Kubernetes API ターゲット検出は正しく機能しませんでした。この状況では、Cryostat は Failed to synchronize Endpoints in namespace default のエラーを返しました。

Cryostat 4.0.1 では、Kubernetes API ターゲット検出が targetRef フィールドを持たない Kubernetes エンドポイントを正しく処理するようにすることで、この問題を解決しました。

Cryostat ストレージコンテナーの起動時に発生する可能性のある障害

cryostat-storage コンテナーでは、少しカスタマイズされた SeaweedFS ストレージソリューションが提供されており、S3 互換のストレージプロバイダーとして機能します。SeaweedFS では、個々のボリュームごとに最大 30 GB のサイズ制限があります。

Cryostat 4.0.1 より前のリリースでは、割り当てられた永続ボリューム要求 (PVC) に使用可能なストレージ容量が 1.4 TB を超えると、cryostat-storage コンテナーの起動に失敗しました。

Cryostat 4.0.1 では、最大許容ボリュームサイズを 30 GB に設定することでこの問題が解決されました。

Liveness および Readiness プローブが原因で Cryostat エージェントが Cryostat に登録されない

Cryostat エージェントの自動設定の一部として、コンポーネントと候補ホスト名のリストから独自のコールバック URL を動的に決定するようにエージェントを設定できます。エージェントが Cryostat サーバーに提供するコールバック URL 内のホスト名を使用する前に、エージェントは組み合わせごとにドメイン名検索 (DNS) 解決を試行してその有効性を確認します。

Cryostat 4.0.1 より前のリリースでは、エージェントがアタッチされているアプリケーションに Liveness プローブまたは Readiness プローブがある場合、OpenShift はプローブが合格するまでコンテナーの DNS を設定しませんでした。この状況では、エージェントの DNS 解決の 1 回の試行が早期に失敗します。これは、Liveness プローブまたは Readiness プローブが設定されたアプリケーションにアタッチされたときに、エージェントが Cryostat に自身を登録できなかったことを意味します。

Cryostat 4.0.1 では、コールバック URI 解決をエージェント起動時の 1 回限りの操作から登録ループ開始時の繰り返し可能な操作に変更することで、この問題を解決しました。現在は、DNS 解決が失敗すると、登録ループは失敗してスケジュールどおりに繰り返されます。この動作の変更は、エージェント (またはそのホスト JVM やコンテナー) が起動シーケンスの早い段階で独自の DNS アドレスを解決できない場合に、登録の失敗を回避するために役立ちます。

HTTP 経由のエージェントクエリーでは、JMX クエリー結果に表示される JFR レコーディングは表示されません。

Cryostat 4.0.1 より前のリリースでは、Cryostat エージェントのシャットダウン時に Null Pointer Exception エラーが発生することがありました。このエラーが原因で、JFR レコーディングスナップショットを Cryostat サーバーにプッシュするために使用されるエージェントハーベスターシステムでアップロードエラーが発生した可能性があります。この問題により、エージェントによって報告される JFR レコーディングのリストと、同じ Cryostat インスタンスの JMX クエリーによって返される JFR レコーディングのリストとの間に不整合が生じる可能性があります。

Cryostat 4.0.1 では、エージェントが開始する JFR レコーディングを、利用可能なレコーディングのクエリー結果のリストに含めることで、この問題を解決しました。現在は、Cryostat Web コンソールで Cryostat エージェントに関連付けられたターゲット JVM を表示すると、エージェントがハーベスターシステムを通じて開始したレコーディングが Active Recordings テーブルに正しく表示されます。

エージェントログは、デフォルトで stdout ではなく stderr に出力されます。

Cryostat 4.0.1 より前のリリースでは、Cryostat エージェントはデフォルトでログメッセージを標準エラー (stderr) に出力していました。このような状況では、エージェントのログメッセージによって、stderr 上のメッセージを監視してアラートをトリガーする外部の監視および可観測性ツールもトリガーされていることがありました。

Cryostat 4.0.1 では、Cryostat エージェントがデフォルトでログメッセージを標準出力 (stdout) に出力するようにすることで、この問題を解決しました。

Cryostat がレポート生成をサイドカーコンテナーに正しく委譲しない

Cryostat 4.0.1 より前のリリースでは、自動レポート分析用に 1 つ以上のサイドカーコンテナーをデプロイするようにカスタムリソース (CR) を設定した場合、Cryostat はレポート生成をこれらのサイドカーコンテナーに委譲しませんでした。代わりに、メインの Cryostat コンテナーがレポート生成自体を処理しましたが、これは予期しない動作であり、パフォーマンスの問題を引き起こす可能性がありました。

Cryostat 4.0.1 では、Cryostat Operator が正しい環境変数を設定して、レプリカサイドカーコンテナーのサービス URL を Cryostat に通知するようにすることで、この問題を解決しました。

エージェントのロギングレベルが原因でアプリケーションログに潜在的な問題が発生する

Cryostat 4.0.1 より前のリリースでは、Cryostat エージェントのデフォルトのログレベルにより、エージェントログがホストアプリケーションのログメッセージと混同される可能性がありました。これらのエージェントログはその後、警告またはエラーレベルのメッセージをチェックする他のアラートシステムをトリガーする可能性があります。

Cryostat 4.0.1 では、Cryostat エージェントロギングをデフォルトで無効にすることで、この問題を解決しました。Cryostat には、エージェントの適切なろリングレベルを設定するために使用できる log-level ラベルも含まれるようになりました。これは、エージェント設定のトラブルシューティングやデバッグに役立つ可能性があります。Cryostat Operator によるエージェントの自動設定を有効にする場合、アプリケーションのデプロイメントに log-level ラベルを追加して、Operator にエージェントログの指定されたレベルを設定するように指示することができます。

cert-manager が TLS 証明書を更新すると、Cryostat デプロイメントは機能しなくなります。

TLS 証明書の有効期限が近づくと、cert-manager はそれを自動的に更新します。

Cryostat 4.0.1 より前のリリースでは、Cryostat Operator は証明書の有効期限切れを検出せず、Operator は壊れた証明書チェーンでのデプロイメント実行の継続を許可していました。

Cryostat 4.0.1 では、証明書の更新を Cryostat Operator が検出することで、この問題を解決しました。このような状況では、Operator は TLS 証明書を更新し、コンポーネントを再デプロイします。

MBean メトリクスダッシュボードカードが正しく更新されないことがある

Cryostat 4.0.1 より前のリリースでは、Cryostat Web コンソールのダッシュボードビューで、MBean メトリクスチャートのダッシュボードカードが正しく更新されないことがありました。さらに、Cryostat Web コンソールプラグインインターフェイスと特定の Cryostat インスタンスの Web コンソールインターフェイス間で、同じターゲット JVM の MBean メトリクスチャートデータが一致しないことがありました。

Cryostat 4.0.1 では、MBean メトリクスチャートデータが常に正しく更新されるようにすることで、この問題を解決しました。

Cryostat 接続障害により Cryostat Web コンソールプラグインがシャットダウンする

TLS 証明書の有効期限が近づくと、cert-manager はそれを自動的に更新します。

Cryostat 4.0.1 より前のリリースでは、Cryostat Web コンソールプラグインが Cryostat に正常に接続できない場合、Web コンソールプラグインがシャットダウンし、OpenShift によって再起動する必要がありました。この問題は、たとえば、接続を受け入れる準備ができていない Cryostat インスタンスで Cryostat Web コンソールプラグインを使用しようとした場合に発生する可能性がありました。

Cryostat 4.0.1 では、Cryostat Web コンソールプラグインがアクティブ状態を保ち、Cryostat に接続できない場合でも失敗しないようにすることで、この問題を解決しました。