Quarkus アプリケーションでのメトリクスの収集
はじめに
アプリケーション開発者は、Micrometer を使用してメトリクスを収集し、Quarkus アプリケーションのパフォーマンスを向上できます。
前提条件
OpenJDK (JDK) 11 がインストールされ、
JAVA_HOME
環境変数が Java SDK の場所を指定している。- Red Hat ビルドの Open JDK は、Red Hat カスタマーポータルの Software Downloads ページからダウンロードできます (ログインが必要です)。
- Apache Maven 3.6.2 以降がインストールされている。Maven は Apache Maven Project の Web サイトから入手できます。
Red Hat ドキュメントへのフィードバック (英語のみ)
弊社の技術的な内容についてのフィードバックに感謝します。ご意見をお聞かせください。コメントの追加、Insights の提供、誤字の修正、および質問を行う必要がある場合は、ドキュメントで直接行うこともできます。
Red Hat アカウントがあり、カスタマーポータルにログインしている必要があります。
カスタマーポータルからドキュメントのフィードバックを送信するには、以下の手順を実施します。
- Multi-page HTML 形式を選択します。
- ドキュメントの右上にある Feedback ボタンをクリックします。
- フィードバックを提供するテキストのセクションを強調表示します。
- ハイライトされたテキストの横にある Add Feedback ダイアログをクリックします。
- ページの右側のテキストボックスにフィードバックを入力し、Submit をクリックします。
フィードバックを送信すると、自動的に問題の追跡が作成されます。Submit をクリックすると表示されるリンクを開き、問題の監視を開始するか、さらにコメントを追加します。
貴重なフィードバックにご協力いただきありがとうございます。
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 Quarkus アプリケーションのメトリクスコレクション
メトリクスとは、トレンドや動作の監視に使用されるアプリケーションの特定の側面を定量的に測定するものです。各測定は、文字列キーと追加のタグ (オプション) またはラベルで一意に識別されるそれぞれの監視値で一定間隔で収集されます。
その後、これらのキーと値のペアは時系列に追加されます。これは、時間の経過とともにインデックスが付けられた一連のデータポイントです。メトリクスを取得して分析することで、潜在的な問題や異常が深刻化して重大な問題を引き起こす前に、それらを特定することができます。
メトリクスは診断や問題の特定には使用できません。視覚化ツールは個別の測定を集計し、トレンドを視覚化します。確認された問題の原因を特定する必要があるインシデント固有のコンテキストは、集計されたメトリクスデータでは検出されません。問題の特定または根本原因の分析には、より詳細なトレースまたはログデータが必要になります。
Micrometer ライブラリーまたは SmallRye Metrics 仕様のいずれかを使用して、ランタイムおよびアプリケーションメトリクスを収集できます。
- Micrometer は、一般的なモニタリングシステムのインストルメンテーションクライアント上にシンプルなファサードを提供します。Quarkus は、Micrometer と Prometheus を組み合わせ、アプリケーションのモニタリングおよび管理を支援します。
- SmallRye Metrics は、Prometheus と互換性のあるメトリクスエンドポイントを提供する MicroProfile Metrics 仕様の実装です。
Micrometer エクステンションは、Quarkus でのアプリケーションおよびランタイムのメトリクスの収集における推奨される方法で、以下を提供します。
- ディメンションメトリクス: タイマー、ゲージ、カウンター、ディストリビューションサマリー、および長期タスクタイマー用のベンダーに依存しないインターフェースをディメンション分析とともに提供します。これは、ディメンションモニタリングシステムと組み合わせた場合に、ディメンション全体でドリルダウン機能を使用して、特定の名前のメトリクスへ効率的にアクセスすることができます。
-
事前設定されたバインディング: キャッシュ、クラスローダー、ガベージコレクション、プロセッサーの使用状況、スレッドプール、および HTTP トラフィックの追加設定なしのインストルメンテーション。
hibernate-orm
およびmongodb-client
などの他のエクステンションは、有効にすると追加のバインディングを自動的に提供します。
第2章 Quarkus アプリケーションでのメトリクスの公開
micrometer
エクステンションを使用して Quarkus 1.11 でメトリクスを有効にします。有効にすると、micrometer
エクステンションによって収集されるすべてのメトリクスのリアルタイム値は、/q/metrics
エンドポイントを使用して表示されます。デフォルトでは、このエンドポイントはプレーンテキストでのみ応答します。
手順
quarkus-micrometer-registry-prometheus
エクステンションを依存関係としてアプリケーションに追加します。./mvnw quarkus:add-extension -Dextensions="io.quarkus:quarkus-micrometer-registry-prometheus"
このコマンドにより、以下の依存関係が
pom.xml
に追加されます。pom.xml
<dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-micrometer-registry-prometheus</artifactId> </dependency>
以下のコマンドを入力して、ターミナルで収集したメトリクスを表示します。
curl http://localhost:8080/q/metrics
(オプション) Micrometer エクステンションを使用して JSON 形式でメトリクスのコレクションを有効にするには、以下の行を
src/main/resources/application.properties
ファイルに追加します。quarkus.micrometer.export.json.enabled=true
-
変更を
application.properties
ファイルに保存します。 以下のコマンドを使用して、JSON 形式でメトリクスを表示します。
curl -i -H "Accept: application/json" -H "Content-Type: application/json" http://localhost:8080/q/metrics
第3章 Quarkus アプリケーションのカスタムメトリクス
Micrometer は、独自のカスタムメトリクスを作成できる API を提供します。モニタリングシステムでサポートされる最も一般的なメータータイプは、ゲージ、カウンター、およびサマリーです。以下のセクションでは、サンプルエンドポイントをビルドし、これらの基本メータータイプを使用してエンドポイントの動作を監視します。
メーターを登録するには、Micrometer エクステンションで設定および維持される MeterRegistry
への参照が必要です。MeterRegistry
は、以下のようにアプリケーションに注入することができます。
package org.acme.micrometer; import io.micrometer.core.instrument.MeterRegistry; import javax.ws.rs.GET; import javax.ws.rs.Path; import javax.ws.rs.PathParam; import javax.ws.rs.Produces; @Path("/") @Produces("text/plain") public class ExampleResource { private final MeterRegistry registry; ExampleResource(MeterRegistry registry) { this.registry = registry; } }
Micrometer には規則があります。たとえば、a.name.like.this
のように、メーターの作成および名前付けではドットを使用してセグメントを分けなければなりません。続いて Micrometer は、その名前を選択したレジストリーが優先する形式に変換します。Prometheus はアンダースコアを使用するため、以前の名前は Prometheus 形式のメトリクス出力では a_name_like_this
と表示されます。
Micrometer は、一意のメトリクス識別子とタグの組み合わせと、特定のメーターインスタンスとの間の内部マッピングを維持します。register
、counter
、またはその他のメソッドを使用してカウンターやレコードの値をインクレメントしても、識別子とタグのその組み合わせまたはラベルの値が以前に確認されていない限り、メーターの新規インスタンスは作成されません。
ゲージ
ゲージは、車の速度計のように時間の経過と共に増減する値を測定します。ゲージは、キャッシュまたはコレクションの統計をモニタリングする際に便利です。リストのサイズを監視する以下の簡単な例を検討してください。
LinkedList<Long> list = new LinkedList<>(); // Update the constructor to create the gauge ExampleResource(MeterRegistry registry) { this.registry = registry; registry.gaugeCollectionSize("example.list.size", Tags.empty(), list); } @GET @Path("gauge/{number}") public Long checkListSize(@PathParam("number") long number) { if (number == 2 || number % 2 == 0) { // add even numbers to the list list.add(number); } else { // remove items from the list for odd numbers try { number = list.removeFirst(); } catch (NoSuchElementException nse) { number = 0; } } return number; }
Prometheus を使用する場合、作成されたゲージの値とリストのサイズは、Prometheus エンドポイントへのアクセスの際に監視されます。ゲージは設定ではなくサンプリングされることを重要な点として留意してください。ゲージと関連付けられる値が測定間でどのように変更された可能性があるかという記録はありません。
Micrometer は、ゲージを作成するための追加のメカニズムを提供します。Micrometer は、デフォルトで監視するオブジェクトへの強力な参照を作成しない点に留意してください。Micrometer はレジストリーに応じて、ガベージコレクションが設定されたオブジェクトを監視するゲージをすべて除外するか、または監視値として (数値以外の) NaN
を使用します。
カウントできるものは測定しないでください。ゲージの使用はカウンターよりも難しい場合があります。(値が常にインクリメントするため) 測定中のものがカウントできる場合は、代わりにカウンターを使用してください。
カウンター
カウンターは、増加する値だけを測定するために使用されます。以下の例では、素数かどうかを確認するために数値をテストする回数をカウントします。
@GET @Path("prime/{number}") public String checkIfPrime(@PathParam("number") long number) { if (number < 1) { return "Only natural numbers can be prime numbers."; } if (number == 1 || number == 2 || number % 2 == 0) { return number + " is not prime."; } if ( testPrimeNumber(number) ) { return number + " is prime."; } else { return number + " is not prime."; } } protected boolean testPrimeNumber(long number) { // Count the number of times we test for a prime number registry.counter("example.prime.number").increment(); for (int i = 3; i < Math.floor(Math.sqrt(number)) + 1; i = i + 2) { if (number % i == 0) { return false; } } return true; }
確認された値を示すカウンターにラベルまたはタグを追加したくなるかもしれません。メトリクス名 (testPrimeNumber
) とラベル値の一意の組み合わせはそれぞれ、一意の時系列を生成する点に留意してください。無制限のデータセットをラベル値として使用すると、新しい時系列が指数関数的に増加するカーディナリティーの爆発につながる可能性があります。
ただし、情報をもう少し伝えるラベルを追加することは可能です。以下の例では、カウンターを移動して一部のラベルを追加するように調整されました。
@GET @Path("prime/{number}") public String checkIfPrime(@PathParam("number") long number) { if (number < 1) { registry.counter("example.prime.number", "type", "not-natural").increment(); return "Only natural numbers can be prime numbers."; } if (number == 1 ) { registry.counter("example.prime.number", "type", "one").increment(); return number + " is not prime."; } if (number == 2 || number % 2 == 0) { registry.counter("example.prime.number", "type", "even").increment(); return number + " is not prime."; } if ( testPrimeNumber(number) ) { registry.counter("example.prime.number", "type", "prime").increment(); return number + " is prime."; } else { registry.counter("example.prime.number", "type", "not-prime").increment(); return number + " is not prime."; } } protected boolean testPrimeNumber(long number) { for (int i = 3; i < Math.floor(Math.sqrt(number)) + 1; i = i + 2) { if (number % i == 0) { return false; } } return true; }
このカウンターによって生成されたデータを確認すると、負数、数字の 1、または偶数などを確認した頻度がわかります。以下のシーケンスを試し、プレーンテキストの出力で example_prime_number_total
を探します。Micrometer が Prometheus 命名規則を _total
(最初に指定したカウンター名) に適用すると、example.prime.number
接尾辞が追加される点に留意してください。
# If you did not leave quarkus running in dev mode, start it again: ./mvnw compile quarkus:dev curl http://localhost:8080/example/prime/-1 curl http://localhost:8080/example/prime/0 curl http://localhost:8080/example/prime/1 curl http://localhost:8080/example/prime/2 curl http://localhost:8080/example/prime/3 curl http://localhost:8080/example/prime/15 curl http://localhost:8080/q/metrics
時間の計測またはサマライズが可能な場合は、カウントしないでください。カウンターはカウントしたものだけを記録します。これは、カウントしたものだけで十分な場合が多いからです。ただし、値が変更される方法を理解する必要がある場合は、タイマー (測定の基準単位が時間の場合)、またはディストリビューションサマリーの方が適している場合もあります。
サマリーとタイマー
Micrometer におけるタイマーとディストリビューションサマリーは非常に似ています。いずれの場合も、監視値を記録することができます。これは、他の記録値と共に集計され、合計として保存されます。また、Micrometer は記録された測定回数を示すカウンターをインクリメントし、指定された時間間隔内で監視された最大値を追跡します。
ディストリビューションサマリーは、監視値を記録するために record
メソッドを呼び出して設定されますが、タイマーは、時間および測定期間に固有の追加機能を提供します。たとえば、タイマーを使用し、Supplier 関数の呼び出しをラップする record
メソッドのいずれかを使用して素数を数える際にかかる時間を測定できます。
protected boolean testPrimeNumber(long number) { Timer timer = registry.timer("example.prime.number.test"); return timer.record(() -> { for (int i = 3; i < Math.floor(Math.sqrt(number)) + 1; i = i + 2) { if (number % i == 0) { return false; } } return true; }); }
Micrometer は、このタイマーのメトリクスを生成する際に Prometheus の規則を適用します。Prometheus は時間を秒単位で計測します。Micrometer は測定期間を秒単位に変換し、規則ごとにメトリクス名に単位を含めます。prime エンドポイントに数回移動した後、プレーンテキストの出力で、example_prime_number_test_seconds_count
、example_prime_number_test_seconds_sum
、および example_prime_number_test_seconds_max
の 3 つのエントリーを検索します。
# If you did not leave quarkus running in dev mode, start it again: ./mvnw compile quarkus:dev curl http://localhost:8080/example/prime/256 curl http://localhost:8080/q/metrics curl http://localhost:8080/example/prime/7919 curl http://localhost:8080/q/metrics
タイマーとディストリビューションサマリーはいずれも、ヒストグラムデータ、事前計算されたパーセンタイル、またはサービスレベル目標 (SLO) の境界など、追加の統計を生成するように設定することができます。カウント、合計、およびヒストグラムのデータは、ディメンション全体で (または一連のインスタンスをまたいで) 再集計できますが、事前計算されたパーセンタイル値は再集計できない点に留意してください。
第4章 HTTP メトリクス
Micrometer エクステンションは、HTTP サーバーのリクエストを自動的に計算します。タイマーの Prometheus 命名規則に従って、http_server_requests_seconds_count
、http_server_requests_seconds_sum
、および http_server_requests_seconds_max
を検索します。リクエストされた uri、HTTP メソッド (GET、POST など)、ステータスコード (200、302、404 など)、およびより一般的な結果フィールドにディメンションラベルが追加されました。
# HELP http_server_requests_seconds # TYPE http_server_requests_seconds summary http_server_requests_seconds_count{env="test",method="GET",outcome="SUCCESS",registry="prometheus",status="200",uri="/example/prime/{number}",} 6.0 http_server_requests_seconds_sum{env="test",method="GET",outcome="SUCCESS",registry="prometheus",status="200",uri="/example/prime/{number}",} 0.007355093 http_server_requests_seconds_count{env="test",method="GET",outcome="SUCCESS",registry="prometheus",status="200",uri="/example/gauge/{number}",} 4.0 http_server_requests_seconds_sum{env="test",method="GET",outcome="SUCCESS",registry="prometheus",status="200",uri="/example/gauge/{number}",} 0.005035393 # HELP http_server_requests_seconds_max # TYPE http_server_requests_seconds_max gauge http_server_requests_seconds_max{env="test",method="GET",outcome="SUCCESS",registry="prometheus",status="200",uri="/example/prime/{number}",} 0.002110405 http_server_requests_seconds_max{env="test",method="GET",outcome="SUCCESS",registry="prometheus",status="200",uri="/example/gauge/{number}",} 0.00239441
エンドポイントの無視
quarkus.micrometer.binder.http-server.ignore-patterns
プロパティーを使用すると、HTTP エンドポイントの測定を無効にできます。このプロパティーは、無視すべき URI パスを特定する単純な正規表現に一致するパターンのコンマ区切りリストを受け入れます。たとえば、quarkus.micrometer.binder.http-server.ignore-patterns=/example/prime/[0-9]+
を設定すると、http://localhost:8080/example/prime/7919
への要求は無視されます。http://localhost:8080/example/gauge/7919
への要求は引き続き測定されます。
URI テンプレート
Micrometer エクステンションは、テンプレート化された形式のパスパラメーターを含む URI を表すために最大限に対応します。上記の例を使用すると、http://localhost:8080/example/prime/7919
への要求は、uri=/example/prime/{number}
のラベルを持つ http_server_requests_seconds_*
メトリクスの属性として表示されるはずです。
正しい URL を判断できない場合は、quarkus.micrometer.binder.http-server.match-patterns
プロパティーを使用します。このプロパティーは、単純な正規表現一致パターンと代替文字列の関連付けを定義するコンマ区切りリストを受け入れます。たとえば、quarkus.micrometer.binder.http-server.match-patterns=/example/prime/[0-9]+=/example/{jellybeans}
を設定すると、要求された URI が /example/prime/[0-9]+
と一致するときはいつでも、uri 属性に値 /example/{jellybeans}
が使用されます。
第5章 信頼性のメトリクス
信頼性のメトリクスは、定量的測定を使用してソフトウェア製品の信頼性を示すために使用されます。使用するメトリクスは、信頼性のメトリクスを適用するシステムのタイプや、アプリケーションドメインの要件によって異なります。サイト信頼性エンジニアリング (SRE) の観点から、Java アプリケーションにフォーカスする主要なメトリクスがいくつかあります。
平均故障時間
平均故障時間 (MTTF: Mean Time to Failure) とは、2 つの連続する失敗間の間隔を指します。MTTF の測定に使用する時間の単位はシステムによって異なり、トランザクションの回数によって定義することもできます。大量のトランザクションがあるシステムの場合は、MTTF は通常一貫しています。
平均修復時間
平均修復時間 (MTTR: Mean Time to Repair) とは、故障の原因となったエラーの追跡と修復にかかる平均時間を指します。
平均故障間隔
MTTF と MTTR のメトリクスを組み合わせた場合、その結果は 平均故障間隔 (MTBF: Mean Time Between Failure) に相当します。時間の測定は、MTTF に含まれる実行時間ではなく、実際の時間になります。
故障発生率
故障発生率 (ROCOF: Rate of Occurrence of Failure) は、単位時間の間隔で発生する故障回数を指し、頻繁に発生する想定外のイベントの可能性に重点を置いています。
要求時故障率
要求時故障率 (POFOD: Probability of Failure on Demand) とは、サービスのリクエストが実行される際にシステムが故障する確率を指します。POFOD は、安全を最重視するシステムにおいて必要不可欠なもので、時としてサービスが要求される保護システムに適しています。
可用性
可用性は、システムがいつでも利用可能である確率を測定します。システムの修復時間と再起動する時間を考慮する必要があります。
第6章 OpenShift との統合
ランタイムおよびアプリケーションメトリクスに Micrometer メトリクスライブラリーを使用するように Quarkus アプリケーションを有効にすることができます。Micrometer は、OpenShift に組み込まれた Prometheus のようにアプリケーションとサードパーティー間のファサードのようなロールを持っています。Quarkus と OpenShift の統合により、自動的に有効にされた埋め込みメトリクスだけでなく、アプリケーションの一部として登録されたカスタムメトリクスも公開することができます。
各種メトリクスの設定に関する詳細は、Quarkus Micrometer metrics コミュニテイーガイド を参照してください。
前提条件
- OpenShift CLI の使用方法 (4.6 以降) にアクセスできる。
- OpenShift インスタンスがある。
手順
以下の手順を完了し、OpenShift に組み込まれた Prometheus を使用して Quarkus アプリケーションからメトリクスを公開します。
6.1. OpenShift でのユーザー定義プロジェクトのモニタリングの有効化
Red Hat OpenShift Container Platform 4.6 以降では、ユーザー定義プロジェクトのモニタリングおよびデフォルトのプラットフォームモニタリングを有効にすることができます。
前提条件
- OpenShift CLI の使用方法 (4.6 以降) にアクセスできる。
- OpenShift のインスタンスがある。
手順
-
ユーザー定義プロジェクトのモニタリングの有効化 のページへ移動し、ユーザー定義プロジェクトの監視を有効にする方法に関する具体的な手順に従います。これにより、namespace
openshift-monitoring
に ConfigMap が作成されます。
cluster-monitoring-config.yaml
:
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | enableUserWorkload: true
OpenShift 4.5 以前を使用している場合は、以下を使用します。
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | techPreviewUserWorkload: enabled: true
ユーザー定義プロジェクトのモニタリングを有効にする手順の完了後、OpenShift は、Quarkus アプリケーションの OpenShift へのデプロイ および OpenShift プロジェクトでのサービスモニターの作成 を開始する際にデプロイする namespace openshift-user-workload-monitoring
を自動的に作成します。
6.2. Quarkus アプリケーションの OpenShift へのデプロイ
必要なインフラストラクチャーの設定後、Prometheus で Micrometer を有効にする必要があります。
前提条件
- OpenShift CLI の使用方法 (4.6 以降) にアクセスできる。
- OpenShift インスタンスがある。
- 直前のセクションで ConfigMap を作成し、OpenShift でユーザー定義プロジェクトのモニタリングを有効化 している。
手順
REST API を実装します。
<dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-resteasy</artifactId> </dependency> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-micrometer-registry-prometheus</artifactId> </dependency>
micrometer レジストリーファサードを追加します。
import javax.inject.Inject; import javax.ws.rs.GET; import javax.ws.rs.Path; import io.micrometer.core.instrument.MeterRegistry; @Path("/hello") public class GreetingsResource { @Inject MeterRegistry registry; @GET public String sayHello() { registry.counter("greeting_counter").increment(); return "Hello!"; } }
この Micrometer ファサードは、サービスを呼び出すたびにインクリメントされるカウンターを作成します。レジストリーは、カスタムメトリクスの作成またはメトリクスの手動での使用に役立ちます。また、以下のようにメソッドにアノテーションを付けることもできます。
@GET @Counted(value = "greeting_counter") public String sayHello() { return "Hello!"; }
アプリケーションを実行します。
mvn compile quarkus:dev
サービスを呼び出します。
curl http://localhost:8080/hello
サービスは
Hello!
を返すはずです。http://localhost:8080/q/metrics
を参照します。(完了したばかりの) カウント 1.0 のgreeting_counter
が表示されるはずです。# HELP greeting_counter_total #TYPE greeting_counter_total counter greeting_counter_total 1.0
エクステンション
quarkus-openshift
をpom.xml
に入力して、Quarkus アプリケーションを OpenShift にデプロイします。<dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-openshift</artifactId> </dependency>
アプリケーションを OpenShift の
my-project
という名前の新規作成されたプロジェクトにデプロイします。oc new-project my-project mvn clean package -Dquarkus.kubernetes.deploy=true -Dquarkus.openshift.expose=true -Dquarkus.openshift.labels.app-with-metrics=quarkus-app
app-with-metrics
に関する説明は、OpenShift プロジェクトでのサービスモニターの作成 を参照してください。
非セキュアな SSL で OpenShift を使用している場合は、Maven コマンドに -Dquarkus.kubernetes-client.trust-certs=true
も追加する必要があります。
6.3. OpenShift プロジェクトでのサービスモニターの作成
Prometheus はプルモデルを使用してアプリケーションからメトリクスを取得します。つまり、エンドポイントをスクレープまたは監視してメトリクスをプルします。直前の手順は、OpenShift インスタンスでサービスを公開する上で役立ちましたが、サービスをスクレープする Prometheus の設定はまだ何も行われていません。このため、サービスモニターが必要になります。
サービスモニターは、実行中のサービスの同じプロジェクトまたは namespace で作成する必要のあるカスタムリソースです (my-project
)。
手順
service-monitor.yaml
を設定します。apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: k8s-app: prometheus-app-monitor name: prometheus-app-monitor namespace: my-project spec: endpoints: - interval: 30s targetPort: 8080 scheme: http selector: matchLabels: app-with-metrics: 'quarkus-app'
service-monitor.yaml を適用します。
oc apply -f service-monitor.yaml
このコマンドにより、
prometheus-app-monitor
という名前のサービスモニターが作成され、ラベルapp-with-metrics: quarkus-app
でアプリケーションを選択します。このラベルは、Quarkus アプリケーションの OpenShift へのデプロイ の手順の際に追加されました。OpenShift は、app-with-metrics: quarkus-app
でラベル付けされたすべてのサービスのエンドポイント/metrics
を呼び出します。サービスモニターを使用するには、以下を実行します。
-
greetings サービスを呼び出します (
curl http://quarkus-micrometer-my-project.ocp.host/hello
)。これにより、greeting_counter_total
カウンターが増加します。 - メトリクスを表示するには、OpenShift コンソールを参照し、Developer > Monitoring ビューを選択します。
- Metrics タブを選択します。
-
Custom Query フィールドに
greeting_counter_total
を入力します。
-
greetings サービスを呼び出します (
カスタムクエリーフィールドの下にある表にメトリクスが表示されます。
第7章 関連情報
改訂日時: 2023-05-16