JavaアプリケーションをOpenTelemetry（+Zipkin）で計測してみる

10474 ワード
opentelemetry zipkin zipkin テキストリンク

はじめに

JavaアプリケーションでOpenTelemetryを使って可視化してみたメモ。
APMとOpenTelemetryに関する説明は他の方の投稿を参考にしてください。

以下の投稿のOpenTelemetry（+Zipkin）版です。

環境

使用した環境は以下のとおり。

  • CentOS 7.5
  • OpenTelemetry(agent) 0.6.0
  • Zipkin Server 2.21.5

アプリケーションは測定対象のアプリケーションはWindows上で動かします。

OpenJDKのインストール

まず、OpenJDK 8をインストールします。

# yum install java-1.8.0-openjdk-devel

# java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)

JAVA_HOMEを設定し、PATHにJavaのパスを追加しています。

# echo "export JAVA_HOME=$(readlink -e $(which java)|sed 's:/bin/java::')" > /etc/profile.d/java.sh
# echo "PATH=\$PATH:\$JAVA_HOME/bin" >> /etc/profile.d/java.sh
# source /etc/profile

Zipkinのインストール

可視化するためのZipkinをインストールします。
Zipkinに送信された計測データはElasticsearch, cassandra等のデータストアに保管できますが、今回はお試しなのでインメモリに格納します。

インストール自体は以下のようにjarファイルをダウンロードするだけです。

# mkdir /opt/zipkin
# curl -L "https://search.maven.org/remote_content?g=io.zipkin&a=zipkin-server&v=LATEST&c=exec" -o /opt/zipkin/zipkin-server.jar

以下のコマンドでZipkinサーバーを起動します。
起動時に「--logging.level.zipkin2=DEBUG」をつけるとログレベルをDEBUGに変更できます。

STORAGE_TYPE="mem" MEM_MAX_SPANS=1000000 java -Xmx1G -jar /opt/zipkin/zipkin-server.jar

最後に動作確認。

# curl -L http://[サーバーのホスト名]:9411/health
{
  "status" : "UP",
  "zipkin" : {
    "status" : "UP",
    "details" : {
      "InMemoryStorage{}" : {
        "status" : "UP"
      }
    }
  }

Java agentの設定

Java agentの設定方法は以下のサイトを参考にして実施します。

Java agentのモジュールは以下からダウンロードします。

javaagentフラグを使用した手動セットアップ

以下のようにjavaコマンド実行時に「-javaagent」フラグを指定します。

-javaagent:opentelemetry-javaagent-all.jar -Dota.exporter=zipkin  -Dotel.zipkin.endpoint=http://[Zipkinサーバーのホスト名]:9411/api/v2/spans -Dotel.zipkin.service.name=test_service

「-Dio.opentelemetry.auto.slf4j.simpleLogger.defaultLogLevel=debug」を追加するとDEBUGログを出力できるようになります。

Zipkinエクスポーターを利用するためのVMオプションは以下に説明があります。

以下のサポートしているライブラリ・フレームワークのデータは自動でデータを収集（計測）されます。

Zipkin UI

Java agentがアプリケーションから収集した情報はZipkinサーバーへ送信されます。
Zipkinサーバーはそれを今回の設定ではインメモリに格納し、Zipkin UIで可視化することができます。

UIのURLは以下のようになります。

  • http://[Zipkinサーバーのホスト名]:9411/zipkin/

UIではサービスマップとトレースの情報を表示することができます。

以下はサービスマップです。

作成したアプリケーションは、以下の流れになっています。
そのため、[test_service]から[test_service2]への流れでサービスマップが表示されています。

  • [test_service]GETリクエストを受信。
  • 内部の別のGETを受け付けるRESTサービス[test_service2]をリクエスト。レスポンスを受信。
  • PostgreSQLへJDBCでSELECTを実行。

次にトレースの情報では、各トレースの情報を検索して以下のように表示することができます。

検索結果

トレース情報

エクスポーター

OpenTelemetryのエージェントは、サーバーへ対してデータを送信するエクスポーターを選択することができます。
エクスポーターはデフォルトで以下の4つが利用できるようです。

  • In-Memory Exporter(メモリにデータを保持する。デバッグ用。)
  • Jaeger Exporter
  • Zipkin Exporter
  • Logging Exporter

利用できる他のエクスポーターは以下に一覧があり、Elastic APMやNew Relic等があります。

（追記）OpenTelemetry APIを使用したSpan作成

前述で自動にてトレースを取得する方法を試してみましたが、今度はOpenTelemetry APIを使用して手動でトレース中のSpanを作成してみます。
以下を参考にしてコーディングしています。

まずはpom.xmlに以下を追加します。

pom.xml
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-api</artifactId>
    <version>0.6.0</version>
</dependency>

次にコード中に以下のようにOpenTelemetry APIを使用してSpanを作成します。
Span名は"my span"にしています。

            Tracer tracer =
                    OpenTelemetry.getTracer("instrumentation-library-name","semver:1.0.0");
            Span parentSpan = tracer.getCurrentSpan();
            Span childSpan = tracer.spanBuilder("my span")
                    .setParent(parentSpan)
                    .startSpan();
            childSpan.setAttribute("hoge", "hoge2");

            try (Scope scope = tracer.withSpan(childSpan)) {
                // ここに計測対象のロジックが入る。
            } finally {
                childSpan.end(); // closing the scope does not end the span, this has to be done manually
            }

Zipkin UIでトレースデータを確認すると以下のように表示されます。
チャートの一番下に"my span"というSpanが追加されているのを確認できます。

おわりに

前回はElastic APMを使ってみたのですが、使い勝手はElastic APMが上かなと感じました。Kibana UIでの検索の機能性やAll in oneでログ・メトリクスも扱えるのは魅力的です。
OpenTelemetryは標準化されているので後からバックエンド（Zipkin等）を変えることもできる柔軟性がポイントかと思います。各バックエンドのUIはトレースの情報を表示させることはほぼ似たような感じで、Elastic APMと比較するとプラスαがない分がマイナス要因。ただし、Elastic APMも有料じゃないと使えない機能もあります（サービスマップとか）。
クラウド対応とか他にも色々検討すべき要素はあるので、どちらを選択するかは各機能の重要度を鑑みて決定すべきことでプロジェクト（組織）によるかなと思います。
個人的には楽で情報量も多いElastic APMを推したい。

参考