Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（@chiroito）です。

この記事は、Red Hat Developerのブログ記事、A faster way to access JDK Flight Recorder data | Red Hat Developer の翻訳記事です。

この記事では、Cryostat 2.0の特別なルール定義について紹介します。これにより、アプリケーションの通常スケジュールされたアーカイブプロセスを待たずに、JDK Flight Recorder (JFR) データにその場でアクセスできます。Cryostat の新しい POST ルール定義を紹介し、それを使って Kubernetes や Red Hat OpenShift 上で動作するコンテナ化アプリケーションのパフォーマンス問題を迅速に診断する方法を紹介します。

シリーズを読む：

Kubernetes のための JDK Flight Recorder (JFR) であるCryostat 2.0を使用するためのハンズオンガイドをシリーズで公開しています。このシリーズの全記事をご覧ください。

注意：Cryostat 2.0 の Red Hat ビルドは、現在、技術プレビューで広く利用可能です。Red Hat ビルドには、OpenShift 上での Cryostat のデプロイを簡素化および自動化するための Cryostat Operator が含まれています。

サービスの中断を継続的に監視

クラスタ管理者がプロジェクトの名前空間に Cryostat をデプロイし、Cryostat の自動化ルールを使って継続的なアプリケーション監視を可能にしたシナリオを考えてみましょう。

このようなルール定義は、次のようになります。

{
  "name": "continuousMonitoring",
  "description": "Enable the Continuous template on all parts of our service",
  "matchExpression": "target.labels.platform[‘app’]==’myService’",
  "eventSpecifier": "template=Continuous,type=TARGET",
  "archivalPeriodSeconds": 3600,
  "preservedArchives": 4
}

continuousMonitoringと呼ばれるこのルールは、app=myServiceラベルを持つすべてのターゲットでContinuousイベントテンプレートを使用して記録を作成します。そして、1時間に1回、レコーディングデータをアーカイブにコピーし、このアーカイブされたコピーを4つ維持します。

このシナリオでは、プロジェクトに多くのマイクロサービスのインスタンスが含まれ、それらが一緒になって顧客に大きな外部サービスを提供します。マイクロサービスは、顧客のトラフィックを処理する一方で、お互いに内部リクエストをします。時折、クラスタ管理者がまだ理解していない理由で不具合が発生し、顧客のリクエストに対応する時間が突然急増することがあります。

OpenJDKのフライトデータのPOSTルールを利用

管理者がスパイクが発生したという通知を受け取ったとします。しかし、continuousMonitoringルールは、JDK Flight Recorderのデータをアーカイブにコピーするために、さらに40分設定されていません。明らかに、管理者はそんなに長く待ちたくはありません。サービスの遅延が急増した原因を突き止め、すぐに修正する必要があります。そのためには、JDK Flight Recorderのデータを即座に取得する方法が必要です。

Cryostat 2.0では、クラスタ管理者が以下のような形式のルール定義をPOSTすることで、OpenJDKのフライトデータを即座に取得できます。

{
  "matchExpression": "target.annotations.platform[‘app’]==’myService’",
  "eventSpecifier": "archive"
}

eventSpecifier: archive プロパティに注目してください。これは、一致するすべてのターゲットに新しい記録を作成するのではなく、一致するすべてのターゲットからCryostatアーカイブに直ちに記録データをコピーすることをCryostatに指示する特殊なケースです。元のルール定義と同じmatchExpressionを使用することで、アーカイブアクションが同じターゲットに適用されることが保証されます。

たとえば、管理者がマイクロサービスのターゲットの特定のグループに問題があると疑った場合、それに合わせて matchExpression を細かく調整できます。たとえば、ログインサービスに検索を集中させることもできます。

{
    "matchExpression": "target.annotations.platform[‘app’]==’myService’ && /^my-app-login-service-/.test(target.alias)",
    "eventSpecifier": "archive"
}

新しいルール定義をCryostatにPOSTした後、管理者はすぐにCryostatアーカイブ内の各マイクロサービスレプリカの記録データのコピーにアクセスできるようになります。見てみましょう。

$ CRYOSTAT=https://cryostat.example.com
$ curl -F name="continuousMonitoring" -F description=”Enable the Continuous template on all parts of our service” -F matchExpression=”target.annotations.platform[‘app’]==’myService’” -F eventSpecifier=”template=Continuous,type=TARGET” -F archivalPeriodSeconds=3600 -F preservedArchives=4 $CRYOSTAT/api/v2/rules
$ # some time passes
$ curl -F matchExpression=”target.annotations.platform[‘app’]==’myService’ && /^my-app-login-service-/.test(target.alias)” -F eventSpecifier=archive $CRYOSTAT/api/v2/rules
$ curl $CRYOSTAT/api/v1/recordings

ここから、JSONレスポンスを処理し、様々なアクションを起こせます。レスポンスは、アーカイブ内の各レコーディングに関する情報を含むオブジェクトの配列です。レコーディング名は、アーカイブルールによって生成されたものを分離するために、フィルタリングできます。管理者は、JSONオブジェクトのreportUrlまたはdownloadUrlプロパティを使用して、自動分析またはJDK Flight Recorderデータダンプのいずれかを含むHTMLドキュメントを取得することができます。

まとめ

JDK Flight Recorderのレコーディングデータは、定期的にアーカイブされるため、ほとんどの場合、診断の目的には十分です。しかし、時にはデータへのより迅速なアクセスが必要な場合があります。この記事では、Cryostatの新しいPOSTルール形式を使用して、JDK Flight Recorderのデータに即座にアクセスする方法を学びました。クラスタ管理者として、特別に策定したルールをPOSTすることでシステムの中断に対応し、その後、コンテナ化されたアプリケーションのパフォーマンスの中断を診断するためにデータをバッチで取得できます。Cryostat 2.0のこの他の新機能の詳細については、Cryostat.ioをご覧ください。

赤帽エンジニアブログ

JDK Flight Recorderデータへの高速アクセス方法

サービスの中断を継続的に監視

OpenJDKのフライトデータのPOSTルールを利用

まとめ