The English version of quarkus.io is the official project site. Translated sites are community supported on a best-effort basis.
一覧に戻る

Micrometerメトリクス

micrometerは、メトリクス収集のための抽象化レイヤーを提供します。 カウンタ、ゲージ、タイマ、ディストリビューション・サマリなどの基本的なメータ・タイプの API と、さまざまなバックエンド監視システムのメトリクスの収集と伝達を一般化する MeterRegistry API を定義します。

Micrometerは、Quarkusのメトリクスとして推奨されるアプローチです。
デフォルトでは、メトリクスはメインの HTTP サーバで公開されます。 別の管理ポートからメトリッ クを表示したい場合は、 管理インターフェイス のセクションを参照してください。

マイクロメーターとモニタリングシステムのエクステンション

Quarkus Micrometerエクステンションは、Micrometerプロジェクトと同じ構造になっています。 quarkus-micrometer エクステンションは、Micrometerのコアサポートとランタイムの統合を提供します。 他のQuarkusやQuarkiverseのエクステンションは、Quarkus Micrometerエクステンションを使用して、他のモニタリングシステムのサポートを提供します。

Quarkus エクステンション:

  • micrometer

  • micrometer-registry-prometheus

Quarkiverse extensions (may be incomplete):

  • micrometer-registry-azure-monitor

  • micrometer-registry-datadog

  • micrometer-registry-graphite

  • micrometer-registry-influx

  • micrometer-registry-jmx

  • micrometer-registry-newrelic-telemetry

  • micrometer-registry-otlp

  • micrometer-registry-signalfx

  • micrometer-registry-stackdriver

  • micrometer-registry-statsd

例えば、アプリケーションに Prometheus メトリクスのサポートを追加するには、 micrometer-registry-prometheus エクステンションを使用します。 これにより、Quarkus MicrometerエクステンションとMicrometerコアライブラリが依存ライブラリとして追加されます。

（プロジェクトディレクトリで）以下のコマンドを使用して、エクステンションをプロジェクトに追加します：

コマンドラインインタフェース
quarkus extension add micrometer-registry-prometheus
Maven
./mvnw quarkus:add-extension -Dextensions='micrometer-registry-prometheus'
Gradle
./gradlew addExtension --extensions='micrometer-registry-prometheus'

これにより、 pom.xml に以下が追加されます:

pom.xml
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-micrometer-registry-prometheus</artifactId>
</dependency>
build.gradle
implementation("io.quarkus:quarkus-micrometer-registry-prometheus")

And you’re all set!

A similar process applies for other meter registry extensions. To use the Micrometer StackDriver MeterRegistry, for example, you would use the quarkus-micrometer-registry-stackdriver extension from the Quarkiverse:

コマンドラインインタフェース
quarkus extension add io.quarkiverse.micrometer.registry:quarkus-micrometer-registry-stackdriver
Maven
./mvnw quarkus:add-extension -Dextensions='io.quarkiverse.micrometer.registry:quarkus-micrometer-registry-stackdriver'
Gradle
./gradlew addExtension --extensions='io.quarkiverse.micrometer.registry:quarkus-micrometer-registry-stackdriver'
pom.xml
<dependency>
    <groupId>io.quarkiverse.micrometer.registry</groupId>
    <artifactId>quarkus-micrometer-registry-stackdriver</artifactId>
</dependency>
build.gradle
implementation("io.quarkiverse.micrometer.registry:quarkus-micrometer-registry-stackdriver")

その他のレジストリ実装

使用する Micrometer レジストリに関連エクステンションがない場合は、 quarkus-micrometer エクステンションを使用し、Micrometer メーターレジストリの依存関係を直接取り込んでください：

pom.xml
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-micrometer</artifactId>
</dependency>
<dependency>
    <groupId>com.acme</groupId>
    <artifactId>custom-micrometer-registry</artifactId>
    <version>...</version>
</dependency>
build.gradle
implementation("io.quarkus:quarkus-micrometer")
implementation("com.acme:custom-micrometer-registry")

次に、次のセクションで説明するように、MeterRegistry を設定して初期化するために、独自のプロバイダを指定する必要があります。

カスタマイズされたMeterRegistryの作成

Use a custom @Produces method to create and configure a your own MeterRegistry if you need to.

以下の例では、StatsDで使用される行フォーマットをカスタマイズしています。

@Produces
@Singleton (1)
public StatsdMeterRegistry createStatsdMeterRegistry(StatsdConfig statsdConfig, Clock clock) { (2)
    // define what to do with lines
    Consumer<String> lineLogger = line -> logger.info(line);

    // inject a configuration object, and then customize the line builder
    return StatsdMeterRegistry.builder(statsdConfig)
          .clock(clock)
          .lineSink(lineLogger)
          .build();
}
1 The method returns a @Singleton.
2 The method returns the specific type of MeterRegistry

This example corresponds to the following instructions in the Micrometer documentation: Micrometer StatsD: Customizing the Metrics Sink

Use MicroProfile Config to inject any configuration attributes you need to configure the registry. Most Micrometer registry extensions, like quarkus-micrometer-registry-statsd, provide registry-specific configuration objects that are integrated with the Quarkus configuration model. The Quarkiverse GitHub Repository can be a useful implementation reference.

独自のメトリクスの作成

Metrics data is used in the aggregate to observe how data changes over time. This data is used for trend analysis, anomaly detection, and alerting. Data is stored by backend monitoring systems in time series databases, with new values appended to the end of the series.

Metrics are constructed lazily. You may not see any data for the metric you’re looking for until you’ve performed an action that will create it, like visiting an endpoint.

命名規則

Meter names should use dots to separate segments, a.name.like.this. Micrometer applies naming conventions to convert registered meter names to match the expectations of backend monitoring systems.

Given the following declaration of a timer: registry.timer("http.server.requests"), applied naming conventions will emit the following metrics for different monitoring systems:

  • Prometheus: http_server_requests_duration_seconds

  • Atlas: httpServerRequests

  • Graphite: http.server.requests

  • InfluxDB: http_server_requests

Define dimensions for aggregation

Metrics, single numerical measurements, often have additional data captured with them. This ancillary data is used to group or aggregate metrics for analysis. The Micrometer API refers to this dimensional data as tags, but you may it referred to as "labels" or "attributes" in other documentation sources.

Micrometer is built primariliy for backend monitoring systems that support dimensional data (metric names that are enchriched with key/value pairs). For heirarchical systems that only support a flat metric name, Micrometer will flatten the set of key/value pairs (sorted by key) and add them to the name.

Tags can be specified when a meter is registered with a MeterRegistry or using a Meter Filter.

See the Micrometer documentation for additional advice on tag naming.

Each unique combination of metric name and dimension produces a unique time series. Using an unbounded set of dimensional data can lead to a "cardinality explosion", an exponential increase in the creation of new time series.

Obtain a reference to a MeterRegistry

To register meters, you need a reference to a MeterRegistry, which is configured and maintained by the Micrometer extension.

Use one of the following methods to obtain a reference to a MeterRegistry:

  1. CDIコンストラクタ注入の使用：

    package org.acme.micrometer;

import io.micrometer.core.instrument.MeterRegistry;

import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;

@Path("/example")
@Produces("text/plain")
public class ExampleResource {

    private final MeterRegistry registry;

    ExampleResource(MeterRegistry registry) {
        this.registry = registry;
    }
}

  2. Use a MeterRegistry member variable and use @Inject:

        @Inject
    MeterRegistry registry;

  3. Use the global MeterRegistry:

        MeterRegistry registry = Metrics.globalRegistry;

ゲージ

Gauges measure a value that can increase or decrease over time, like the speedometer on a car. Gauges can be useful when monitoring the statistics for a cache or collection.

Gauge values are sampled rather than set; there is no record of how the value associated with a gauge may have changed between measurements.

Micrometer provides a few mechanisms for creating gauges:

  1. Wrap construction of a collection to monitor its size:

    List<String> list = registry.gaugeCollectionSize("fantastic.list", (1)
        Tags.of("key", "value") // optional (2)
        new ArrayList<>());  (3)
    1 Create a new gauge, list.size, using the dot-separated convention.
    2 Associate tags with the gauge. Gauge tag values are constant, and must be assigned at construction time.
    3 Construct the array list whose size should be observed.

  2. Use a builder to create a Gauge that will call a function:

    Gauge.builder("jvm.threads.peak", threadBean, ThreadMXBean::getPeakThreadCount) (1)
    .baseUnit(BaseUnits.THREADS) // optional (2)
    .description("The peak live thread count...") // optional (3)
    .tags("key", "value") // optional (4)
    .register(registry); (5)
    1 Create a new gauge called jvm.threads.peak that will call getPeakThreadCount on threadBean, an instance of ThreadMXBean
    2 Define the base unit, see BaseUnits.java for predefined values.
    3 Provide a description of the Gauge
    4 Associate tags with the gauge
    5 Register the Gauge with the MeterRegistry

See Gauges in the Micrometer documentation for more information and examples. Of note are two special cases: TimeGauge for measuring time, and a MultiGauge for reporting several criteria together.

Micrometer does not create strong references to the objects it observes by default. Depending on the registry, Micrometer either omits gauges that observe objects that have been garbage-collected entirely or uses NaN (not a number) as the observed value.

When should you use a gauge? Only use a gauge when you can’t use something else. Gauges can be less straight-forward to use than other meters. If what you are measuring can be counted (because the value always increments), use a counter instead.

カウンター

Counters measure values that only increase. Use one of the methods below to create a counter.

  1. Use a convenience method on the MeterRegistry:

    registry.counter("example.prime.number", "type", "prime"); (1) (2)
    1 example.prime.number is the counter name.
    2 type is a dimensional tag with value prime.

  2. Use Counter.builder to provide a description and units:

    Counter.builder("count.me") (1)
    .baseUnit("beans")            // optional (2)
    .description("a description") // optional (3)
    .tags("region", "test")       // optional (4)
    .register(registry);
    1 Create a new counter called count.me
    2 Define a custom base unit. See BaseUnits.java for predefined values.
    3 Provide a description for the counter
    4 Associate tags with the counter

  3. Annotate a method

    @Counted(value = "counted.method", extraTags = { "extra", "annotated" }) (1) (2)
void countThisMethod(){
    ...
}
    1 A CDI interceptor will create and register a counter called counted.method
    2 The interceptor-created counter will have the "extra" dimension tag with value "annotated"

See Counters in the Micrometer documentation for more information and examples, including the less common FunctionCounter that can be used to measure the result returned by an always increasing function.

When should you use a counter? Use a counter if you are doing something that can not be either timed or summarized. If you want to understand more about how a value is changing, a timer (when the base unit of measurement is time) or a distribution summary might be more appropriate.

サマリーとタイマー

Timers and distribution summaries in Micrometer are very similar. Both meters record data, and can capture additional histogram or percentile data. While distribution summaries can be use for arbitrary types of data, timers are optimized for measuring time and durations.

Timers and distribution summaries store at least three values internally:

  • the aggregation of all recorded values as a sum

  • the number of values that have been recorded (a counter)

  • the highest value seen within a decaying time window (a gauge).

Create a distribution summary

Use a distribution summary to record a value, not time. Use one of the following methods to create a distribution summary.

  1. Use a convenience method on the MeterRegistry:

    registry.summary("bytes.written", "protocol", "http"); (1) (2)
    1 bytes.written is the summary name
    2 protocol is a dimensional tag with value http.

  2. Use DistributionSummary.builder to provide a description and units:

    DistributionSummary.builder("response.size") (1)
    .baseUnit("bytes")            // optional (2)
    .description("a description") // optional (3)
    .tags("protocol", "http")     // optional (4)
    .register(registry);
    1 Create a new distribution summary called response.size
    2 Use bytes as a base unit. See BaseUnits.java for predefined values.
    3 Provide a description for the distribution summary
    4 Associate tags with the distribution summary

タイマーの作成

Timers measure short-duration latencies and how often they occur. Negative values are not supported, and longer durations could cause an overflow of the total time (Long.MAX_VALUE nanoseconds (292.3 years)).

Use one of the following methods to construct a timer.

  1. Use a convenience method on the MeterRegistry:

    registry.timer("fabric.selection", "primary", "blue"); (1) (2)
    1 fabric.selection is the summary name
    2 primary is a dimensional tag with value blue.

  2. Use Timer.builder to provide a description and units:

    Timer.builder("my.timer")        (1) (2)
    .description("description ") // optional (3)
    .tags("region", "test")      // optional (4)
    .register(registry);
    1 Create a new timer called my.timer
    2 Timers measure time, and will convert it into the units required by the monitoring backend
    3 Provide a description for the distribution summary
    4 Associate tags with the timer

  3. Annotate a method

    @Timed(value = "call", extraTags = {"region", "test"}) (1) (2)
    1 A CDI interceptor will create and register a timer called call
    2 The interceptor-created timer will have the "region" dimension tag with value "test"

Measure durations with Timers

Micrometer provides the following convenience mechanisms for recording durations.

  1. Wrap the invocation of a Runnable:

    timer.record(() -> noReturnValue());

  2. Wrap the invocation of a Callable:

    timer.recordCallable(() -> returnValue());

  3. Create a wrapped Runnable for repeated invocation:

    Runnable r = timer.wrap(() -> noReturnValue());

  4. Create a wrapped Callable for repeated invocation:

    Callable c = timer.wrap(() -> returnValue());

  5. Use a Sample for more complex code paths:

    Sample sample = Timer.start(registry); (1)

doStuff; (2)

sample.stop(registry.timer("my.timer", "response", response.status())); (3)
    1 We create a sample, which records the start of the timer.
    2 The sample can be passed along as context
    3 We can choose the timer when the sample is stopped. This example uses a response status as a tag identifying the timer, which won’t be known until processing is complete.

Histograms and percentiles

Both timers and distribution summaries can be configured to emit additional statistics, like histogram data, precomputed percentiles, or service level objective (SLO) boundaries. See Timers and Distribution Summaries in the Micrometer documentation for more information and examples, including memory footprint estimation for both types.

The count, sum, and histogram data associated with timers and distribution summaries can be re-aggregated across dimensions (or across a series of instances).

Precomputed percentile values can not. Percentiles are unique to each dataset (the 90th percentile of this collection of measurements).

Automatically generated metrics

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 など)、そしてより一般的な結果フィールドのための次元ラベルが追加されました。

エンドポイントの無視

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 へのリクエストは、 http_server_requests_seconds_* メトリクスの属性として、 uri=/example/prime/{number} という値で表示されます。

正しい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} の値が使用されます。

エクスポートされるメトリクスフォーマット

デフォルトでは、メトリクスはPrometheusのフォーマット application/openmetrics-text を使用してエクスポートされます。 Accept リクエストヘッダを plain/text ( curl -H "Accept: plain/text" localhost:8080/q/metrics/ ) に指定することで、以前のフォーマットに戻すことも可能です。

Customizing Micrometer

Quarkus provides a variety of way to customize Micrometer.

Use MeterFilter to customize emitted tags and metrics

Micrometerは MeterFilter インスタンスを使って、 MeterRegistry インスタンスが出力するメトリクスをカスタマイズします。 Micrometer エクステンションは、 MeterFilter のCDI Beanを検出して、 MeterRegistry インスタンスを初期化するときにそれを使います。

@Singleton
public class CustomConfiguration {

    @ConfigProperty(name = "deployment.env")
    String deploymentEnv;

    /** Define common tags that apply only to a Prometheus Registry */
    @Produces
    @Singleton
    @MeterFilterConstraint(applyTo = PrometheusMeterRegistry.class)
    public MeterFilter configurePrometheusRegistries() {
        return MeterFilter.commonTags(Arrays.asList(
                Tag.of("registry", "prometheus")));
    }

    /** Define common tags that apply globally */
    @Produces
    @Singleton
    public MeterFilter configureAllRegistries() {
        return MeterFilter.commonTags(Arrays.asList(
                Tag.of("env", deploymentEnv)));
    }

    /** Enable histogram buckets for a specific timer */
    @Produces
    @Singleton
    public MeterFilter enableHistogram() {
        return new MeterFilter() {
            @Override
            public DistributionStatisticConfig configure(Meter.Id id, DistributionStatisticConfig config) {
                if(id.getName().startsWith("myservice")) {
                    return DistributionStatisticConfig.builder()
                        .percentiles(0.5, 0.95)     // median and 95th percentile, not aggregable
                        .percentilesHistogram(true) // histogram buckets (e.g. prometheus histogram_quantile)
                        .build()
                        .merge(config);
                }
                return config;
            }
        };
    }
}

この例では、シングルトン CDI Beanは、2 つの異なる MeterFilter Beanを生成します。1 つは Prometheus MeterRegistry インスタンスのみに適用され ( @MeterFilterConstraint 修飾子を使用)、もう 1 つはすべての MeterRegistry インスタンスに適用されます。アプリケーション設定プロパティーも注入され、タグ値として使用されます。MeterFiltersのその他の例は、次のリンクにあります：公式ドキュメント 。

Use HttpServerMetricsTagsContributor for server HTTP requests

By providing CDI beans that implement io.quarkus.micrometer.runtime.HttpServerMetricsTagsContributor, user code can contribute arbitrary tags based on the details of HTTP request

Use MeterRegistryCustomizer for arbitrary customizations to meter registries

By providing CDI beans that implement io.quarkus.micrometer.runtime.MeterRegistryCustomizer user code has the change to change the configuration of any MeterRegistry that has been activated. Unless an implementation is annotated with @io.quarkus.micrometer.runtime.MeterRegistryCustomizerConstraint, the customization applies to all MeterRegistry instances.

Micrometerはアノテーションをサポートしていますか？

Micrometerでは、メソッドに追加できる2つのアノテーション、 @Counted と @Timed が定義されています。 @Timed アノテーションは、メソッドの実行をラップし、アノテーション自体に定義されているタグに加えて、次のタグを出力します：class、method、exception（"none "または検出された例外のシンプルなクラス名）。

Parameters to @Counted and @Timed can be annotated with @MeterTag to dynamically assign meaningful tag values.

MeterTag.resolver can be used to extract a tag from a method parameter, by creating a bean implementing io.micrometer.common.annotation.ValueResolver and referring to this class: `@MeterTag(resolver=CustomResolver.class)

MeterTag.expression is also supported, but you have to implement the evaluation of the expression by creating a bean implementing io.micrometer.common.annotation.ValueExpressionResolver that can evaluate expressions.

enum Currency { USD, EUR }

@Singleton
class EnumOrdinalResolver implements ValueResolver {
    @Override
    public String resolve(Object parameter) {
        if(parameter instanceof Enum) {
            return String.valueOf(((Enum<?>) parameter).ordinal());
        }
        return null;
    }
}

@Singleton
public class MyExpressionResolver implements ValueExpressionResolver {
    @Override
    public String resolve(String expression, Object parameter) {
        return someParser.parse(expression).evaluate(parameter);
    }
}

// tags = type=with_enum, currency=${currency.toString()}
@Timed(value="time_something", extraTags = {"type", "with_enum"})
public Something calculateSomething(@MeterTag Currency currency) { ... }

// tags = type=with_enum, the_currency=${currency.toString()}
@Timed(value="time_something", extraTags = {"type", "with_enum"})
public Something calculateSomething(@MeterTag(key="the_currency") Currency currency) { ... }

// tags = type=with_enum, currency=${currency.ordinal()}
@Timed(value="time_something", extraTags = {"type", "with_enum"})
public Something calculateSomething(@MeterTag(resolver=EnumOrdinalResolver.class) Currency currency) { ... }

// tags = type=with_enum, currency=${currency.ordinal()}
@Timed(value="time_something", extraTags = {"type", "with_enum"})
public Something calculateSomething(@MeterTag(expression="currency.ordinal()") Currency currency) { ... }
Provided tag values MUST BE of LOW-CARDINALITY. High-cardinality values can lead to performance and storage issues in your metrics backend (a "cardinality explosion"). Tag values should not use end-user data, since those could be high-cardinality.

Many methods, like REST endpoint methods or Vert.x Routes, are counted and timed by the micrometer extension out of the box.

MicroProfile Metrics API のサポート

If you use the MicroProfile Metrics API in your application, the Micrometer extension will create an adaptive layer to map those metrics into the Micrometer registry. Note that naming conventions between the two systems is different, so the metrics that are emitted when using MP Metrics with Micrometer will change.

Use a MeterFilter to remap names or tags according to your conventions.

@Produces
@Singleton
public MeterFilter renameApplicationMeters() {
    final String targetMetric = MPResourceClass.class.getName() + ".mpAnnotatedMethodName";

    return MeterFilter() {
        @Override
        public Meter.Id map(Meter.Id id) {
            if (id.getName().equals(targetMetric)) {
                // Drop the scope tag (MP Registry type: application, vendor, base)
                List<Tag> tags = id.getTags().stream().filter(x -> !"scope".equals(x.getKey()))
                        .collect(Collectors.toList());
                // rename the metric
                return id.withName("my.metric.name").replaceTags(tags);
            }
            return id;
        }
    };
}

Ensure the following dependency is present if you require the MicroProfile Metrics API:

pom.xml
<dependency>
    <groupId>org.eclipse.microprofile.metrics</groupId>
    <artifactId>microprofile-metrics-api</artifactId>
</dependency>
build.gradle
implementation("org.eclipse.microprofile.metrics:microprofile-metrics-api")
The MP Metrics API compatibility layer may be moved to a different extension in the future.

マネジメントインターフェース

By default, the metrics are exposed on the main HTTP server.

You can expose them on a separate network interface and port by setting quarkus.management.enabled=true in your application configuration. Note that this property is a build-time property. The value cannot be overridden at runtime.

If you enable the management interface without customizing the management network interface and port, the metrics are exposed under: http://0.0.0.0:9000/q/metrics.

You can configure the path of each exposed format using:

quarkus.micrometer.export.json.enabled=true # Enable json metrics
quarkus.micrometer.export.json.path=metrics/json
quarkus.micrometer.export.prometheus.path=metrics/prometheus

このような設定にすることで、json メトリクスが http://0.0.0.0:9000/q/metrics/json で利用可能になります。prometheus メトリクスは、 http://0.0.0.0:9000/q/metrics/prometheus で利用可能になります。

詳しくは、 マネジメントインターフェイスのリファレンス を参照してください。

Micrometerで計測されたQuarkusのコアエクステンション

設定リファレンス

ビルド時に固定される構成プロパティ - 他のすべての構成プロパティは実行時にオーバーライド可能

Configuration property

型

デフォルト

quarkus.micrometer.enabled

Micrometer metrics support.

Micrometer metrics support is enabled by default.

Environment variable: QUARKUS_MICROMETER_ENABLED

Show more

boolean

true

quarkus.micrometer.registry-enabled-default

Micrometer MeterRegistry discovery.

Micrometer MeterRegistry implementations discovered on the classpath will be enabled automatically by default.

Environment variable: QUARKUS_MICROMETER_REGISTRY_ENABLED_DEFAULT

Show more

boolean

true

quarkus.micrometer.binder-enabled-default

Micrometer MeterBinder discovery.

Micrometer MeterBinder implementations discovered on the classpath will be enabled automatically by default.

Environment variable: QUARKUS_MICROMETER_BINDER_ENABLED_DEFAULT

Show more

boolean

true

quarkus.micrometer.binder.http-client.enabled

Outbound HTTP request metrics support.

Support for HTTP client metrics will be enabled if Micrometer support is enabled, the REST client feature is enabled, and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_HTTP_CLIENT_ENABLED

Show more

boolean

quarkus.micrometer.binder.http-server.enabled

Inbound HTTP metrics support.

Support for HTTP server metrics will be enabled if Micrometer support is enabled, an extension serving HTTP traffic is enabled, and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_HTTP_SERVER_ENABLED

Show more

boolean

quarkus.micrometer.binder.jvm

Micrometer JVM metrics support.

Support for JVM metrics will be enabled if Micrometer support is enabled, and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_JVM

Show more

boolean

quarkus.micrometer.binder.kafka.enabled

Kafka metrics support.

Support for Kafka metrics will be enabled if Micrometer support is enabled, the Kafka Consumer or Producer interface is on the classpath and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_KAFKA_ENABLED

Show more

boolean

quarkus.micrometer.binder.redis.enabled

Redis client metrics support.

Support for Redis metrics will be enabled if Micrometer support is enabled, the Quarkus Redis client extension is on the classpath and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_REDIS_ENABLED

Show more

boolean

quarkus.micrometer.binder.stork.enabled

Stork metrics support.

Support for Stork metrics will be enabled if Micrometer support is enabled, the Quarkus Stork extension is on the classpath and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_STORK_ENABLED

Show more

boolean

quarkus.micrometer.binder.grpc-server.enabled

gRPC Server metrics support.

Support for gRPC server metrics will be enabled if Micrometer support is enabled, the gRPC server interfaces are on the classpath and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_GRPC_SERVER_ENABLED

Show more

boolean

quarkus.micrometer.binder.grpc-client.enabled

gRPC Client metrics support.

Support for gRPC client metrics will be enabled if Micrometer support is enabled, the gRPC client interfaces are on the classpath and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_GRPC_CLIENT_ENABLED

Show more

boolean

quarkus.micrometer.binder.messaging.enabled

Kafka metrics support.

Support for Reactive Messaging metrics will be enabled if Micrometer support is enabled, MessageObservationCollector interface is on the classpath and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_MESSAGING_ENABLED

Show more

boolean

quarkus.micrometer.binder.mp-metrics.enabled

Eclipse MicroProfile Metrics support.

Support for MicroProfile Metrics will be enabled if Micrometer support is enabled and the MicroProfile Metrics dependency is present:

<dependency>
  <groupId>org.eclipse.microprofile.metrics</groupId>
  <artifactId>microprofile-metrics-api</artifactId>
</dependency>

The Micrometer extension currently provides a compatibility layer that supports the MP Metrics API, but metric names and recorded values will be different. Note that the MP Metrics compatibility layer will move to a different extension in the future.

Environment variable: QUARKUS_MICROMETER_BINDER_MP_METRICS_ENABLED

Show more

boolean

quarkus.micrometer.binder.system

Micrometer System metrics support.

Support for System metrics will be enabled if Micrometer support is enabled, and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_SYSTEM

Show more

boolean

quarkus.micrometer.binder.vertx.enabled

Vert.x metrics support.

Support for Vert.x metrics will be enabled if Micrometer support is enabled, Vert.x MetricsOptions is on the classpath and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_VERTX_ENABLED

Show more

boolean

quarkus.micrometer.binder.netty.enabled

Netty metrics support.

Support for Netty metrics will be enabled if Micrometer support is enabled, the Netty allocator classes are on the classpath and either this value is true, or this value is unset and quarkus.micrometer.binder-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_BINDER_NETTY_ENABLED

Show more

boolean

quarkus.micrometer.export.json.enabled

Support for export to JSON format. Off by default.

Environment variable: QUARKUS_MICROMETER_EXPORT_JSON_ENABLED

Show more

boolean

false

quarkus.micrometer.export.json.path

The path for the JSON metrics endpoint. The default value is metrics. By default, this value will be resolved as a path relative to ${quarkus.http.non-application-root-path}. If the management interface is enabled, the value will be resolved as a path relative to ${quarkus.management.root-path}.

Environment variable: QUARKUS_MICROMETER_EXPORT_JSON_PATH

Show more

string

metrics

quarkus.micrometer.export.json.buffer-length

Statistics like max, percentiles, and histogram counts decay over time to give greater weight to recent samples. Samples are accumulated to such statistics in ring buffers which rotate after the expiry, with this buffer length.

Environment variable: QUARKUS_MICROMETER_EXPORT_JSON_BUFFER_LENGTH

Show more

int

3

quarkus.micrometer.export.json.expiry

Statistics like max, percentiles, and histogram counts decay over time to give greater weight to recent samples. Samples are accumulated to such statistics in ring buffers which rotate after this expiry, with a particular buffer length.

Environment variable: QUARKUS_MICROMETER_EXPORT_JSON_EXPIRY

Show more

Duration

P3D

quarkus.micrometer.export.prometheus.enabled

Support for export to Prometheus.

Support for Prometheus will be enabled if Micrometer support is enabled, the PrometheusMeterRegistry is on the classpath and either this value is true, or this value is unset and quarkus.micrometer.registry-enabled-default is true.

Environment variable: QUARKUS_MICROMETER_EXPORT_PROMETHEUS_ENABLED

Show more

boolean

quarkus.micrometer.export.prometheus.path

The path for the prometheus metrics endpoint (produces text/plain). The default value is metrics and is resolved relative to the non-application endpoint (q), e.g. ${quarkus.http.root-path}/${quarkus.http.non-application-root-path}/metrics. If an absolute path is specified (/metrics), the prometheus endpoint will be served from the configured path.

If the management interface is enabled, the value will be resolved as a path relative to ${quarkus.management.root-path} (q by default), e.g. http://${quarkus.management.host}:${quarkus.management.port}/${quarkus.management.root-path}/metrics. If an absolute path is specified (/metrics), the prometheus endpoint will be served from the configured path, e.g. http://${quarkus.management.host}:${quarkus.management.port}/metrics.

Environment variable: QUARKUS_MICROMETER_EXPORT_PROMETHEUS_PATH

Show more

string

metrics

quarkus.micrometer.export.prometheus.default-registry

By default, this extension will create a Prometheus MeterRegistry instance.

Use this attribute to veto the creation of the default Prometheus MeterRegistry.

Environment variable: QUARKUS_MICROMETER_EXPORT_PROMETHEUS_DEFAULT_REGISTRY

Show more

boolean

true

quarkus.micrometer.binder.http-client.match-patterns

Comma-separated list of regular expressions used to specify uri labels in http metrics.

Outbount HTTP client instrumentation will attempt to transform parameterized resource paths, /item/123, into a generic form, /item/{id}, to reduce the cardinality of uri label values.

Patterns specified here will take precedence over those computed values.

For example, if /item/\\\\d+=/item/custom or /item/[0-9]+=/item/custom is specified in this list, a request to a matching path (/item/123) will use the specified replacement value (/item/custom) as the value for the uri label. Note that backslashes must be double escaped as \\\\.

Environment variable: QUARKUS_MICROMETER_BINDER_HTTP_CLIENT_MATCH_PATTERNS

Show more

list of string

quarkus.micrometer.binder.http-client.ignore-patterns

Comma-separated list of regular expressions defining uri paths that should be ignored (not measured).

Environment variable: QUARKUS_MICROMETER_BINDER_HTTP_CLIENT_IGNORE_PATTERNS

Show more

list of string

quarkus.micrometer.binder.http-client.max-uri-tags

Maximum number of unique URI tag values allowed. After the max number of tag values is reached, metrics with additional tag values are denied by filter.

Environment variable: QUARKUS_MICROMETER_BINDER_HTTP_CLIENT_MAX_URI_TAGS

Show more

int

100

quarkus.micrometer.binder.http-server.match-patterns

Comma-separated list of regular expressions used to specify uri labels in http metrics.

Vertx instrumentation will attempt to transform parameterized resource paths, /item/123, into a generic form, /item/{id}, to reduce the cardinality of uri label values.

Patterns specified here will take precedence over those computed values.

For example, if /item/\\\\d+=/item/custom or /item/[0-9]+=/item/custom is specified in this list, a request to a matching path (/item/123) will use the specified replacement value (/item/custom) as the value for the uri label. Note that backslashes must be double escaped as \\\\.

Environment variable: QUARKUS_MICROMETER_BINDER_HTTP_SERVER_MATCH_PATTERNS

Show more

list of string

quarkus.micrometer.binder.http-server.ignore-patterns

Comma-separated list of regular expressions defining uri paths that should be ignored (not measured).

Environment variable: QUARKUS_MICROMETER_BINDER_HTTP_SERVER_IGNORE_PATTERNS

Show more

list of string

quarkus.micrometer.binder.http-server.suppress-non-application-uris

Suppress non-application uris from metrics collection. This will suppress all metrics for non-application endpoints using ${quarkus.http.root-path}/${quarkus.http.non-application-root-path}.

Suppressing non-application uris is enabled by default.

Environment variable: QUARKUS_MICROMETER_BINDER_HTTP_SERVER_SUPPRESS_NON_APPLICATION_URIS

Show more

boolean

true

quarkus.micrometer.binder.http-server.max-uri-tags

Maximum number of unique URI tag values allowed. After the max number of tag values is reached, metrics with additional tag values are denied by filter.

Environment variable: QUARKUS_MICROMETER_BINDER_HTTP_SERVER_MAX_URI_TAGS

Show more

int

100

quarkus.micrometer.export.prometheus

Prometheus registry configuration properties.

A property source for configuration of the Prometheus MeterRegistry, see https://micrometer.io/docs/registry/prometheus.

Environment variable: QUARKUS_MICROMETER_EXPORT_PROMETHEUS

Show more

Map<String,String>
期間フォーマットについて

To write duration values, use the standard java.time.Duration format. See the Duration#parse() Java API documentation for more information.

数字で始まる簡略化した書式を使うこともできます:

  • 数値のみの場合は、秒単位の時間を表します。

  • 数値の後に ms が続く場合は、ミリ秒単位の時間を表します。

その他の場合は、簡略化されたフォーマットが解析のために java.time.Duration フォーマットに変換されます：

  • 数値の後に h 、 m 、 s が続く場合は、その前に PT が付けられます。

  • 数値の後に d が続く場合は、その前に P が付けられます。

関連コンテンツ

同一エクステンション

同一トピック

Quarkusはオープンです。このプロジェクトのすべての依存関係は、Apache Software License 2.0 または互換性のあるライセンスのもとで利用可能です。

このウェブサイトはJekyll で構築され、GitHub Pages にホストされ、完全にオープンソースです。改善したい場合は、ウェブサイトをフォークし、修正してみせてください。

ナビゲーション
フォローする
ヘルプ
言語
Quarkusはコミュニティプロジェクトで構成されています
CC by 3.0 | Privacy Policy Sponsored by