はじめに
アプリケーション開発においてオブザーバビリティを実現するためにOpenTelemetryを使用するケースが増えているように感じます。
OpenTelemetry自体はテレメトリーデータの生成、収集、管理、出力にフォーカスしており、そのデータを処理しUIを提供するバックエンドのシステムはJaegerやPrometheusのようなOSS製品からDynatraceをはじめとした商用ベンダーまでさまざま利用が可能です。
本記事では、バックエンドとしてDynatraceを用いる方法について紹介します。
環境
Kubernetes環境にOpenTelemetry DemoアプリとOpenTelemetry CollectorをデプロイしてCollector経由でDynatraceへデータを送る方法について試していきます。
demoアプリ、CollectorともにHelmを使ってインストールしていきます。
デフォルトで用意されているHelm Chartを利用すると全てAll-in-oneでインストールすることができますが、今回はdemoアプリとCollectorで異なるNamespaceにインストールしていきたいと思います。
絵にするとこんな感じです。Ingress等も使って良い感じに外からアクセスできるようにしていきます。
ちなみにKubernetes環境はUbuntu上にMicrok8sで構築しています。
Dynatraceへのテレメトリーデータの送信はActiveGateを経由させていますが、Dynatraceへ直接送信する方法もサポートしています。
DynatraceといえばOneAgentを使ったデータの収集が代表的ですが、今回はCollector経由のみでどのようなデータが収集できるか確認したいためOneAgentは導入しません。
Dynatrace環境の準備
ActiveGateの構築(オプション)
この辺の記事を参考にActiveGateを構築します。
OTLPのエンドポイントは以下のアドレスになります。
https://{your-activegate-domain}:9999/e/{your-environment-id}/api/v2/otlp
アクセストークンの発行
Dynatraceへデータを取り込むにあたって必要なアクセストークンは以下の3つになります。
シグナル | アクセススコープ |
---|---|
トレース | openTelemetryTrace.ingest |
メトリクス | metrics.ingest |
ログ | logs.ingest |
DynatraceのUIからアクセストークンの発行画面に行き、トークン名を入力して、スコープの検索にopentelemetry
と入力すると必要なトークンの一覧が出てきますので3つ全てにチェックを入れてトークンの生成をクリックします。
生成されたトークンは一度しか表示されないため、必要に応じて安全に保存してください。
OpenTelemetry Collectorのデプロイ
この辺を参考にCollector用のvalues.yaml
を作成します。
mode: deployment
config:
exporters:
otlphttp/dynatrace:
endpoint: https://{your-activegate-domain}:9999/e/{your-environment-id}/api/v2/otlp
tls:
insecure_skip_verify: true
headers:
Authorization: "Api-Token dt0c01.XXXXX"
service:
pipelines:
traces:
exporters: [otlphttp/dynatrace]
metrics:
exporters: [otlphttp/dynatrace]
logs:
exporters: [otlphttp/dynatrace]
resources:
limits:
cpu: 250m
memory: 512Mi
DynatraceはOpenTelemetry ProtocolのHTTPを利用したバイナリーエンコーディング方式にネイティブ対応していますので、otlphttp
を指定することが可能です。
helm install
コマンドでCollectorのインストールを実行します。
OpenTelemetry Demoのデプロイ
この辺を参考にCollectorやバックエンドがいないDemoアプリ用のvalues.yaml
を作成します。
default:
envOverrides:
- name: OTEL_COLLECTOR_NAME
value: my-otel-collector-opentelemetry-collector.otel-col
components:
frontendProxy:
ingress:
enabled: true
annotations:
cert-manager.io/cluster-issuer: letsencrypt
kubernetes.io/ingress.class: public
hosts:
- host: otel-demo.example.com
paths:
- path: /
pathType: Prefix
port: 8080
tls:
- hosts:
- otel-demo.example.com
secretName: otel-demo-tls
opentelemetry-collector:
enabled: false
jaeger:
enabled: false
prometheus:
enabled: false
grafana:
enabled: false
本筋とは関係ないですが、cert-managerを使ってTLSでデモアプリにアクセスできるように設定してあります。
デプロイに成功したらアクセスできるか確認をしておきましょう。
Dynatraceでのデータの確認
サービスと分散トレースの確認
DynatraceのUIからサービスを開いてみます。無事にデータが届いていることが確認できます。
checkoutserviceが応答時間の中央値、90パーセンタイルともにかなり時間がかかっているようなのでもう少し深堀して分散トレースを確認してみたいと思います。
トポロジー情報もちゃんと取れていますね。デモアーキテクチャの図によれば、Checkout Serviceはいろんなサービスの起点になっているのがわかりますが、Dynatraceの画面上でもそれが確認できますね。
分散トレースの画面では、orders publish
の処理にかなり時間がかかっていることがわかりました。
メタデータやAttribute情報もしっかり取れていそうです。
右上にあるこのトレースのログを表示
ボタンをクリックしてみましょう。
自動的でクエリを書いてくれてトレースIDと紐づいたログを表示してくれるので便利ですね。
疑似障害の発生
デモアプリケーションはFeature Flagsを変更することで疑似的にエラーを発生させることが可能なようです。せっかくなので、試してみます。
adServiceFailureという障害を発生させてみたいと思います。Enabledを1に設定することで常に発生(10回に1回の割合でエラーが起きる)します。
しばらくするとDynatrace側でもFailed requestsの値が上昇していることが確認できました。
該当のスパンのイベント情報ではexception.message RESOURCE_EXHAUSTED
が確認できます。
また、スパンに紐づいて出力されているログ情報も確認できます。
Failure rate increaseのプロブレムが上がっていることも確認できました。アラート通知の設定をしていればメールやSlackなどに通知することが可能ですので、障害にすぐに気づけそうですね。
まとめ
今回はOpenTelemetry Demoアプリを使って、オブザーバビリティバックエンドにDynatraceを利用することでどのようにデータが確認できるのか試してみました。
Collector経由でも普通に使うことはできそうですし、障害の検知も問題なくできました。