DockerでQuarkusライブコーディング（ライブリロード）を使用する方法

Quarkus Live Codingを使用すると、ソースコードを編集し、Quarkusが影響を受けるコードを自動的に再コンパイルして再ロードした後、手動での再構築や再デプロイを行うことなく、実行中のアプリケーションに変更を確認できます。 

ローカル環境では、開発モードではこれは自動的に行われます。Dockerコンテナ内では、コンテナはデフォルトで本番モードになっており、ライブコーディングが意図的に無効になっているため、いくつかの追加設定手順が必要になります。

このQuarkus Dockerガイドでは、Quarkusアプリの作成方法、ライブコーディングを使用してローカルで実行する方法、そして同じライブコーディングワークフローをDockerコンテナ内で実行する方法について説明します。

前提条件

開始する前に、以下をインストールしてください。

• Quarkusのバージョンとプロジェクトの要件に応じて、JDK 17、21、または25を使用します。
• DockerまたはPodman
• GradleまたはMavenを使用。できればプロジェクトに付属のMavenまたはGradleラッパーを使用する。

設定をapplication-dev.propertiesに記述する場合は、ビルドコマンドとremote-devコマンドの両方に-Dquarkus.profile=devを追加してください。このガイドの残りの部分では、各手順が必要な理由と、いずれかの手順がうまくいかない場合の対処法について説明します。  

Quarkusにおけるライブコーディングとは何ですか？

Quarkusのライブコーディング（開発モードまたはdevモードとも呼ばれる）は、ソースファイルを継続的に監視し、変更を加えるとアプリケーションを自動的に再構築および再読み込みするため、手動での再起動が不要になります。

これは開発モードでのみ機能し、本番ビルドでは機能しません。コードの記述とテストのサイクルを高速化するためのものであり、アプリのデプロイ方法の一部ではありません。それ以外の場所では、従来どおり変更されないビルドを使用します。

ワークフローは次のとおりです。アプリが開発モードで実行されている場合、リクエストが届くたびにソースコードの変更がチェックされます。変更があった場合、Quarkusはその部分のコードのみをコンパイルし、リクエストに応答する前に実行中のアプリを更新します。 

変更後の最初のリクエストはコンパイル処理のため少し時間がかかりますが、その後は次の編集を行うまで通常の速度で処理が進みます。

アプリがローカルマシン上で直接実行されている場合でも、Dockerコンテナ内で実行されている場合でも、動作は同じです。コンテナを使用する場合の唯一の違いは、開発モードで実行するように指示し、ローカルのQuarkus CLIからアクセスできるようにする必要があることです。

Quarkusアプリを初めて作成する方法

Quarkusプロジェクトを作成する最も直接的な方法は、Quarkus CLIを使用することです。インストールおよびJavaまたはビルドツールの要件は、選択した設定によって異なるため、最新のQuarkusドキュメントで確認してください。 

あるいは、code.quarkus.io はブラウザベースのフォームを通して同じプロジェクト構造を生成します。

CLIをインストールしたら、Gradleベースの新しいプロジェクトを作成します。

quarkus create app --gradle org.acme:docker-live-coding

Mavenの場合は、 --gradle flagMavenはデフォルトのビルドツールです。quarkus create appを実行してください。 --help プロジェクト作成オプションを表示するには、または quarkus -h を実行して CLI のその他の一般的なヘルプコマンドを表示します。

これにより、動作するRESTエンドポイント、その単体テスト、および既に設定済みのDockerfileセットを含むdocker-live-codingディレクトリが作成されます。

生成されたプロジェクトには何が含まれていますか？

エンドポイントは src/main/java/org/acme/GreetingResource.java:

@Path("/hello")
public class GreetingResource {
    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        return "Hello from Quarkus REST";
    }
}

マッチングテストは src/test/java/org/acme/GreetingResourceTest.java:

@QuarkusTest
public class GreetingResourceTest {

    @Test
public void testHelloEndpoint() {
        given()
          .when().get("/hello")
          .then()
            .statusCode(200)
            .body(is("Hello from Quarkus REST"));
    }

}

CLI は、Dockerfile も生成します。 src/main/docker/:

Quarkusアプリをローカルで開発モードで実行するにはどうすればよいですか？

プロジェクトディレクトリから実行できます。

CLI

quarkus dev

受け台

./gradlew quarkusDev

達人

./mvnw quarkus:dev

開始すると、開発モードとライブコーディングがアクティブになっていることを示すログ行が表示され、アプリには次のURLからアクセスできます。 http://localhost:80802つ目のターミナルを開いてリクエストを送信します。 http://localhost:8080/hello受け取るべきもの： Hello from Quarkus REST.

Quarkus開発モードでは、ライブリロードはどのように機能しますか？

アプリがまだ実行されている状態で、GreetingResource.java を編集します。

public String hello() {

    return "Hello from Quarkus REST. How are you?";

}

ファイルを保存してから、同じcurlコマンドを再度実行してください。Quarkusが変更を検知し、影響を受けるソースコードを再コンパイルして、アプリケーションを開発モードで再デプロイすると、次のリクエストで新しいテキストが反映されるはずです。

Quarkus は次の受信リクエストで変更を検知し、変更された部分のみを再コンパイルしてから処理を実行します。メソッド本体のみを変更するこのような単純な編集は、通常 Quarkus の状態保持リロードによって適用されるため、アプリケーションはメモリ上の状態を失うことはありません。 

フィールドの追加やメソッドシグネチャの変更といった構造的な変更は、代わりにアプリケーション全体の再起動を引き起こし、状態をリセットします。 

QuarkusのライブコーディングでDockerfileを使用するにはどうすればよいですか？

まず、JARファイルを作成します。 

Quarkus CLI を使用する:

quarkus build

Gradleを使用する:

./gradlew build

Mavenを使用する: 

./mvnw package

前のステップで hello() の変更をそのままにしておくと、変更を元に戻すかテストを更新しないと、テストがエンドポイントと一致しない場合にビルドが失敗します。

Dockerfile.jvmを使用してイメージをビルドします。

docker build -f src/main/docker/Dockerfile.jvm -t quarkus/docker-live-coding .

実行します:

docker run -i --rm -p 8080:8080 quarkus/docker-live-coding

エンドポイントに再度curlコマンドを実行すると、元の挨拶メッセージが返されます。コンテナには、ローカルでコミットされていない変更は、それらをイメージに組み込んで再構築しない限り反映されません。このコンテナの実行中にソースファイルを編集しても、アプリケーションは変更されません。 

起動ログに理由が示されています。「Profile prod が有効になっています」。Dockerfile.jvm から構築されたコンテナは本番モードで実行され、本番モードではライブコーディングを有効にすることはできません。

Docker環境でライブコーディングがデフォルトで動作しないのはなぜですか？

ライブコーディングは開発モード専用の機能であり、Quarkusが生成するデフォルトのDockerfileは本番モード向けに構築されています。 

コンテナ内でライブコーディングを動作させるには、そのコンテナを開発モードで実行するように指示し、ローカルマシンからコンテナに接続してソースコードの変更をプッシュできるようにする必要があります。 

Docker はコンテナのファイルシステムをホストから分離するため、コンテナは Quarkus dev と同じようにローカルのソース ファイルを監視することができません。

一般的なリモート開発ワークフローには以下が必要です。

• Quarkus開発モードが有効になっています。 QUARKUS_LAUNCH_DEVMODE=true
• 可変JARファイルとデプロイメントリソースへの書き込みアクセス
• アクセス可能なリモート開発エンドポイントと、必要な認証パスワード。

次の３つのセクションでは、それぞれについて詳しく説明します。

quarkusRemoteDev 用の Docker の設定方法

次の手順に従います。 

ステップ1：コンテナを開発モードに切り替える

Dockerfileに以下の環境変数を追加してください。

ENV QUARKUS_LAUNCH_DEVMODE=true

Dockerfile.jvm を直接編集するのではなく、新しい Dockerfile.dev にコピーして、クリーンな本番環境の参照を維持してください。この Dockerfile はコンテナ内でコンパイルするのではなく、既にビルド済みの JAR をコピーするため、完全なビルダー イメージではなく、ベース イメージのランタイム バリアント (openjdk-25-runtime) を使用してください。

FROM registry.access.redhat.com/ubi9/openjdk-25-runtime:1.24-3.1786536503
ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en'

COPY --chown=185 build/quarkus-app/lib/ /deployments/lib/
COPY --chown=185 build/quarkus-app/*.jar /deployments/
COPY --chown=185 build/quarkus-app/app/ /deployments/app/
COPY --chown=185 build/quarkus-app/quarkus/ /deployments/quarkus/
RUN chmod o+rw -R /deployments

EXPOSE 8080
USER 185
ENV JAVA_OPTS="-Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
ENV JAVA_APP_JAR="/deployments/quarkus-run.jar"

ENV QUARKUS_LAUNCH_DEVMODE=true

registry.access.redhat.com/ubi9/openjdk-25-runtime これは、Red Hat の公式 UBI9 OpenJDK 25 ランタイム イメージです。タグをピン留めする前に、Red Hat エコシステム カタログの最新リストを確認してください。これは最近追加されたものなので (2025 年 12 月に一般提供開始予定)、このガイドからそのままコピーするのではなく、タグが最新であることを確認してください。

Quarkus CLI がバージョンに合わせてわずかに異なる Dockerfile.jvm を生成する場合、それは想定内のことです。Quarkus はこれらのテンプレートを随時更新します。 QUARKUS_LAUNCH_DEVMODE=true この行が存在する場合、このチュートリアルの残りの部分が適用されます。

RUN chmod o+rw -R /deployments の行は必須ですが、見落としやすいので注意が必要です。この行がないと、コンテナは自身のデプロイメント ファイルを更新するための書き込み権限を持たないため、次に設定する remote-dev 接続でコードの変更を実行中のアプリに反映させることができません。 

ステップ2：ビルドを可変かつ到達可能にする

application.properties（src/main/resources内）を開き、以下を追加します。

quarkus.package.type=mutable-jar
quarkus.live-reload.password=changeit
quarkus.live-reload.url=https://localhost:8080

mutable-jar Quarkusにビルドをパッケージ化して、実行中のアプリケーションをその場で更新できるようにするよう指示します。 fast-jar 構築はできません。 

交換する changeit 実際のパスワードを使用してください。ローカルでのみ使用する場合でも、正しく設定する価値があります。なぜなら、Quarkusはローカル以外のマシンに対するリモートライブコーディングもサポートしており、その場合のデフォルトパスワードはネットワークに公開される実際の認証情報となるからです。

quarkus.live-reload.url これは厳密にはオプションです。コマンドラインフラグとして渡すこともできますが、ここで設定しておけば後で覚えておく必要がなくなります。

ステップ3：開発モードコンテナをビルドして実行する

次のコマンドを実行します。

quarkus build
docker build -f src/main/docker/Dockerfile.dev -t quarkus/docker-live-coding .
docker run -i --rm -p 8080:8080 quarkus/docker-live-coding

最初のコマンドに相当するMavenコマンド： ./mvnw package.

ステップ4：ローカルマシンをコンテナに接続する

新しいターミナルで、プロジェクトディレクトリから以下を実行します。

./gradlew quarkusRemoteDev

Mavenの場合： 

./mvnw quarkus:remote-dev.

application.propertiesで`quarkus.live-reload.url`を設定していない場合は、明示的に渡してください。

./gradlew quarkusRemoteDev -Dquarkus.live-reload.url=https://localhost:8080

接続が成功すると、「リモートサーバーに接続しました」というログが出力されます。ここから、ソースファイルを編集し、ローカルで行ったのと同じようにエンドポイントにcurlコマンドを実行してください。コンテナは、リモート開発接続を介して変更を反映させます。

ライブコーディングを開発者プロファイルのみに限定する方法

前のセクションの設定は、誤って本番環境にデプロイしてしまう可能性のあるビルドも含め、すべてのビルドに適用されます。ライブリロードが有効になっている可変JARは開発環境以外では使用すべきではないため、解決策は、これらの3つのプロパティを共有のapplication.propertiesファイルではなく、プロファイル固有のファイルに移動することです。

創造する application-dev.properties 既存の application.propertiesそして、3つのライブコーディングプロパティをその中に移動します。 

クォーカスは application.properties プロファイル固有のファイルが選択されるためには、たとえ空であっても、そのファイルが同じ場所に存在し続けなければなりません。そのため、プロパティを移動した後は、そのファイルを削除しないでください。

quarkus.package.jar.type=mutable-jar

quarkus.live-reload.password=changeit

quarkus.live-reload.url=https://localhost:8080

これらの設定は、開発者プロファイルを使用して明示的にビルドした場合にのみ適用されます。

quarkus build -Dquarkus.profile=dev

./gradlew quarkusRemoteDev -Dquarkus.profile=dev

Mavenの場合： 

./mvnw package -Dquarkus.profile=dev and ./mvnw quarkus:remote-dev -Dquarkus.profile=dev.

プロファイルフラグを指定せずにビルドすると、Quarkus は開発者専用のプロパティを完全に無視するため、標準の製品版ビルドは標準の製品版ビルドのままになります。

これらのライブコーディング設定を本番環境で使用しても安全ですか？

いいえ、走らないで mutable-jar パッケージまたはアクティブ quarkus.live-reload 本番環境での接続。どちらの場合も、リモートクライアントがコード変更を本番プロセスにプッシュできてしまうため、開発環境以外では絶対に避けたい状況です。 

これらの設定の範囲を application-dev.properties前のセクションで説明したように、プロファイルフラグのない通常の Quarkus ビルドではそれらが検出されないため、それが誤って発生するのを防ぐことができます。 

ライブコーディングが利用可能な環境（共有開発環境やステージング環境など）はすべて、本番環境のシークレットに使用するのと同じアクセス制御を適用してください。 

Quarkusコンテナイメージを作成するための選択肢は何ですか？

手動で`docker build`や`docker run`を実行する必要はありません。Quarkusには、通常は手書きのDockerfileを使わずにイメージをビルドしてくれる拡張機能があります。どの拡張機能を使うかは、環境によって異なります。

ビルドごとに1つのQuarkusコンテナイメージ拡張機能を使用してください。複数のビルダー拡張機能が存在する場合は、`quarkus.container-image.builder`で明示的に1つを選択するか、他の拡張機能を削除してください。 

ビルド環境に応じて、Docker、Podman、Jib、Buildpacks、またはOpenShiftを選択してください。選択が明示的に制御されている場合を除き、同じビルドに対して複数のプロバイダーを有効にしないでください。

デッカー

Dockerfilesに慣れている場合は、これを使用してください。これは、Quarkusが既に生成したDockerバイナリとDockerfilesを使用します。 src/main/docker.

それを使用する方法は次のとおりです。

CLI：

quarkus extension add quarkus-container-image-docker

メイヴン:

./mvnw quarkus:add-extension -Dextensions='quarkus-container-image-docker'

Gradle：

./gradlew addExtension --extensions='quarkus-container-image-docker'

この拡張機能は、docker buildx を使用してマルチプラットフォームイメージを構築することもできます。ただし、docker buildx build では、結果を単一プラットフォームの Docker イメージにのみロードします。 

設定した場合 quarkus.docker.buildx.platform 複数のプラットフォーム (例えば、linux/amd64、linux/arm64) にイメージをプッシュすると、イメージはローカルに表示されません。 quarkus.container-image.push=true 代わりに、同じビルドの一部として実行してください。Docker buildx はマルチプラットフォームの結果をローカルの Docker イメージ ストアにロードできないため、ビルドの一部としてレジストリにプッシュしてください。

ポッドマン

PodmanでDockerにはない機能（例えば、ネイティブなマルチプラットフォームビルドなど）が必要な場合は、これを使用してください。それ以外の場合は、PodmanがDocker互換のAPIを公開しているため、上記のDocker拡張機能は既にPodmanで動作します。

以下の拡張機能を追加する方法は次のとおりです。

CLI：

quarkus extension add quarkus-container-image-podman

メイヴン:

./mvnw quarkus:add-extension -Dextensions='quarkus-container-image-podman'

Gradle：

./gradlew addExtension --extensions='quarkus-container-image-podman'

ジブ

Dockerデーモンを使用しないCI環境では、この方法を使用してください。JibはDockerビルドステップを経ずに、イメージを直接ビルドしてプッシュします。

以下の拡張機能を追加する方法は次のとおりです。

CLI：

quarkus extension add quarkus-container-image-jib

メイヴン:

./mvnw quarkus:add-extension -Dextensions='quarkus-container-image-jib'

Gradle：

./gradlew addExtension --extensions='quarkus-container-image-jib'

ビルドパック

Dockerfileの作成やメンテナンスを省略したい場合は、こちらを使用してください。Buildpacksは、標準的なプロセスを使用して、ビルド出力からイメージを構築します。

以下の拡張機能を追加する方法は次のとおりです。

CLI：

quarkus extension add quarkus-container-image-buildpack

メイヴン:

./mvnw quarkus:add-extension -Dextensions='quarkus-container-image-buildpack'

Gradle：

./gradlew addExtension --extensions='quarkus-container-image-buildpack'

Buildpacks は、実際のビルドのためにバックグラウンドで Docker デーモンを必要とします。他の拡張機能とは異なり、デフォルトのビルダーイメージは付属していないため、設定する必要があります。 quarkus.buildpack.jvm-builder-image （と quarkus.buildpack.native-builder-image （ネイティブビルドの場合）ご自身で行ってください。

OpenShiftバイナリビルド

これを使用すると、OpenShift クラスター内で直接ビルドを実行できます。ビルド成果物をアップロードすると、OpenShift がビルドの一部としてそれらをビルダーイメージにマージします。

以下の拡張機能を追加する方法は次のとおりです。

CLI：

quarkus extension add quarkus-container-image-openshift

メイヴン:

./mvnw quarkus:add-extension -Dextensions='quarkus-container-image-openshift'

Gradle：

./gradlew addExtension --extensions='quarkus-container-image-openshift'

拡張機能が追加されたら、構築とプッシュを行います。

コンテナイメージをビルドするには、 quarkus.container-image.build=true お使いの環境に合ったものを以下のいずれか使用してください。

CLI：

quarkus build

メイヴン:

./mvnw install -Dquarkus.container-image.build=true

Gradle：

./gradlew build -Dquarkus.container-image.build=true

既にネイティブイメージが構築済みで、そのイメージを中心にコンテナを再構築したい場合は、以下を追加してください。 -Dquarkus.native.reuse-existing=true そしてQuarkusはネイティブビルドの再実行をスキップします。

画像をプッシュするには、設定します。 quarkus.container-image.push=trueレジストリを設定しない場合は quarkus.container-image.registryQuarkusはデフォルトでdocker.ioにプッシュします。

ビルドパックの場合、アプリケーションプロパティで quarkus.container-image.build=true を永続的に設定することは避けてください。ネストされたビルド（ビルドの中にビルド）がトリガーされる可能性があるためです。代わりに、ビルドコマンドにプロパティを渡してください。または、ビルドコマンドに -D フラグとして渡してください。 -Dquarkus.container-image.build=true コマンドライン上で直接指定します。

コンテナ内でQuarkusアプリケーションをデバッグする方法

コンテナデバッグはライブコーディングとは別個のものです。JVMビルドの場合、Javaデバッグエージェントを有効にしてアプリケーションを起動し、コンテナからデバッグポートを公開し、そのポートをホストにマッピングして、IDEまたはデバッガーが接続できるようにします。 

ポートは開発環境内でのみ使用し、共有インターフェースや公開インターフェースを通じて公開しないようにしてください。

ネイティブ実行ファイルには、異なるワークフローが必要です。デバッグシンボル付きで実行ファイルをビルドし、gdbまたは同等のネイティブデバッガを使用してください。製品版から削除されたバイナリには、ソースレベルのデバッグに必要な情報が不足しています。

JVM 専用のテストは、ネイティブまたは HTTP 専用の統合実行から除外する必要がある場合もあります。テストが JVM 固有の動作に依存する場合は、@DisabledOnIntegrationTest などの Quarkus テスト アノテーションを使用してください。

Docker Composeを使用してライブコーディングコンテナを実行する方法

データベースやメッセージブローカーなど、他のサービスをローカルで既に実行している場合は、Compose は、長いコマンドよりもクリーンな方法で開発モードコンテナをそれらのサービスと並行して起動できます。 ドッカーラン コマンド。最小限のコードを以下に示します。 docker-compose.yml 上記の設定の場合：

services:
  docker-live-coding:
    build:
      context: .
      dockerfile: src/main/docker/Dockerfile.dev
    ports:
      - "8080:8080"
    environment:
      QUARKUS_LAUNCH_DEVMODE: "true"

まず、JAR をビルドします。 クォーカスビルド （またはGradleやMavenの同等のもの）は以前と同じです。次に、スタックを開始します。 docker compose up –build、および接続します ./gradlew quarkusRemoteDev （またはMavenの同等のもの）Composeを使用しない場合と同じように。リモート開発接続は引き続きターゲットを localhost：8080コンテナがDockerまたはComposeのどちらによって起動されたかに関わらず。

DockerでネイティブQuarkus実行可能ファイルを構築および実行する方法

ネイティブ実行ファイルとは、QuarkusアプリをGraalVMで事前にコンパイルしてスタンドアロンのバイナリにしたもので、JVMを完全にスキップするため、イメージサイズが大幅に小さくなり、ほぼ瞬時に起動できます。 

デメリットとしては、ビルドに時間がかかることと、その過程でライブコーディングが使えなくなることが挙げられます。そのため、これは日常的に使うものではなく、本番環境のイメージに近づいてから利用する別のワークフローとして考えてください。

コンテナ内でビルドする場合は、マシンにGraalVMをインストールする必要はありません。 

ラン quarkus build --native --no-tests -Dquarkus.native.container-build=true （またはMavenやGradleの同等のもの）を使用し、生成されたDockerfile.nativeを、このガイドの前半で既にDockerfile.jvmをビルドして実行したのと同じ方法でビルドして実行します。 

試す前に知っておくべき2つのこと：

• 生成される実行ファイルは64ビットLinuxバイナリなので、macOSまたはWindowsを使用している場合、コンテナビルドをスキップすると、Linuxコンテナ内では実行されません。 
• Quarkus 3.19以降、コンテナのビルドにはUBI9ベースのビルダーイメージが使用されるため、DockerfileでUBI8ベースイメージと組み合わせないでください。正しく動作しません。

どのベースイメージを使用すべきですか？

適切なベースイメージは、デプロイする対象によって異なります。

Dockerでのライブコーディングのトラブルシューティング

ライブコーディングが機能しない場合は、まず以下を確認してください。

• 開発者モードが有効になりません: コンテナの起動ログで「Profile dev activated. Live Coding activated.」を確認してください。ログに「Profile prod activated」と表示されている場合、 QUARKUS_LAUNCH_DEVMODE=true 環境変数がコンテナに届いていません。実際にビルドに使用したDockerfileに環境変数が含まれていることを確認してください。未使用のDockerfileに環境変数が残っていないか確認してください。
• メインアプリは再読み込みされますが、同じプロジェクト内のライブラリモジュールに変更されます。 プロジェクトがマルチモジュール（メインアプリとは別のライブラリ）である場合、 quarkusRemoteDev ローカルの quarkus dev が同じ変更を問題なく使用しているにもかかわらず、ライブラリの再読み込みをサイレントにスキップできます。Quarkus は、次のプロジェクト成果物に対してライブ リロードが無効になっています: … のような警告をログに出力します。上記の成果物は、再読み込みできないアプリケーションの依存関係または Quarkus 拡張機能のいずれかであるようです。 
• コードの変更は反映されません quarkusRemoteDev 接続: 確認します quarkus.package.type=mutable-jar ビルド時に設定されました。そのプロパティを追加する前にJARファイルをビルドした場合は、再ビルドしてください。また、実際に接続したプロジェクト内のファイルを編集していることを確認してください。quarkusRemoteDevはコンテナ内ではなく、ローカルのプロジェクトディレクトリから同期します。

開発段階を超えてサービスを検証する

Docker開発ワークフローが正常に動作するようになったら、開発環境を超えて実際に運用されるサービスとして検証してください。開発プロファイル、変更可能なJARファイル、およびリモートライブコーディング接続は本番環境のビルドから除外し、本番環境と同様のトラフィックと依存関係を持つイメージをテストしてください。

ライブコーディングは、開発中にソースコードの変更を迅速に適用できることを実証します。しかし、デプロイされたコンテナが正常な状態を維持するかどうか、依存関係によって遅延が発生していないか、リソースの負荷がユーザーに影響を与えるかどうかは示しません。

LogicMonitor コンテナの健全性と再起動、JVMメモリとガベージコレクション、アプリケーションの応答時間とエラー、ホストまたはクラスタの負荷、依存関係の遅延、ネットワークパスのパフォーマンス、デプロイメントの変更など、これらの本番環境のシグナルを1つの運用ビューに統合することで際立っています。 

こうしたクロスレイヤーのコンテキストは、クラウド、コンテナ、ハイブリッド環境を問わず、チームがアプリケーションの症状から、その症状を引き起こしたインフラストラクチャや依存関係へと焦点を移すのに役立ちます。

よくあるご質問