はじめに

Happy May day

みなさま、ゴールデンウィークいかがお過ごしでしょうか。３年ぶりに「ゴールデンウィーク」という雰囲気を味わっている方も多いのではないでしょうか。私も雰囲気を堪能しています。ゴールデンウィーク後半なにしようかなと考えながらこのブログを書いています。

あらためまして、「AKSでDaprを使ってみる」の第２回目。前回はAKSにDaprをインストールし、ingress controllerを使ってWebアプリケーションを実行するところまで行いました。

techblog.ap-com.co.jp

今回はDaprのMonitoringとDistributed TracingをAzure Monitor/Application Insightsと連携してみたいと思います。前回ほどではありませんが、今回もちょっとしたトラップが待ち受けています。

DaprのMonitoring

DaprのMetricsをAzure Monitorで収集する方法はDapr公式ドキュメントで紹介されています。

docs.dapr.io

こちらの内容に沿って登録をしてみましょう。

ConfigMapの登録

まずはじめに azm-config-map.yaml というファイルをダウンロードします。

もしDaprインストール時にインストール先 namespace を変更している場合はドキュメントに従い内容を編集しましょう。今回は変更なく dapr-system というnamespaceのままインストールしていますのでそのまま利用します。

kubectl apply -f azm-config-map.yaml

Jsonフォーマットでログ出力するよう設定変更

次に daprの設定を変更する・・・。と、ここでさっそくちょっとしたトラップ発生です。第１回のところでインストールに使ったのは dapr CLI。ところがインストール後の設定変更はできない模様。 Helmで設定するようにドキュメントで紹介されています。（一瞬「まさかインストールし直し？」と思いましたが、helmでupgradeできそうなのでそのまま実行。）

dapr-config.yaml

global:
  logAsJson: true

上記のコンフィグレーションを作成し、helmでupgradeしてみます。

helm repo add dapr https://dapr.github.io/helm-charts/
helm repo update
helm upgrade --install dapr dapr/dapr --namespace dapr-system --values dapr-config.yaml --wait

annotatonsの変更

Metricsはprometheusのannotationをつけることで収集されます。このため、Deploymentのannotationに修正を加えます。対象は aggregatorとtimefeedの２つのアプリケーションです。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aggregator
  namespace: web
  labels:
    app: aggregator
spec:
  selector:
    matchLabels:
      app: aggregator
  template:
    metadata:
      labels:
        app: aggregator
      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "aggregator"
        dapr.io/app-port: "8080"
        dapr.io/log-as-json: "true"       # 追加
        prometheus.io/scrape: "true"      # 追加
        prometheus.io/port: "9090"        # 追加
        prometheus.io/path: "/"           # 追加
    spec:
      containers:
〜以下省略〜

Ingress Controllerの設定もわすれずに変更しておきましょう。

controller:
  podAnnotations:
    dapr.io/enabled: "true"
    dapr.io/app-id: "nginx-ingress"
    dapr.io/app-port: "80"
    dapr.io/log-as-json: "true"              # 追加
    prometheus.io/scrape: "true"             # 追加
    prometheus.io/port: "9090"               # 追加
    prometheus.io/path: "/"                  # 追加
    dapr.io/sidecar-listen-addresses: "0.0.0.0"

これらを反映して作業は完了。

動作確認

あとは公式ドキュメントで紹介されてる方法で確認すれば動作確認できます。

Metrics収集は問題なく実行できるようになりました。

DaprのTracing

DaprはDistributed Tracingもサポートしています。これをApplication Insightsと連携してみましょう。

docs.dapr.io

こちらもドキュメントに沿ってすすめてみましょう。なお、あらかじめAzure Application Insightsは作成済みの想定です。

Open Telemetry Collectorの設定

Daprのプロジェクトで Application Insights用の OpenTelemetry Collectorを公開しています。まずこの設定ファイルをダウンロードします。

open-telemetry-collector-appinsights.yaml中に <INSTRUMENTATION-KEY> と記載されている部分があります（こちらです）のでここにご自身のApplication InsightsのInstrumentation Keyを記載してください。

また、open-telemetry-collector-appinsightsは特にnamespaceを指定していませんが、実はdefault namespaceにデプロイすることを期待しています。これで問題なければそのまま、もしnamespaceを変更したい場合は namespaceを指定しましょう。私は dapr-system namespace にデプロイするようにしてみました。

続いて collector-config.yaml です。先程のopen-telemetry-collector-appinsightsのdeploy先namespaceが endpointAddress に関わってきます。（こちらの部分） default にデプロイした場合は変更なし、もし異なるnamespaceにデプロイするならば URLの default の部分を変更してください。私の場合は dapr-system にデプロしますので
http://otel-collector.dapr-system.svc.cluster.local:9411/api/v2/spans
となります。（あわせてcollector-config.yaml のnamespaceもご注意ください）

これらを、kubectl apply します。

Annotation追加

Tracingを有効にするには Deploymentにannotationを追加しなければなりません。

ふたたび aggregator/timefeed/nginx ingress controller の設定の変更です。

controller:
  podAnnotations:
    dapr.io/enabled: "true"
    dapr.io/app-id: "nginx-ingress"
    dapr.io/app-port: "80"
    dapr.io/config: "appconfig"          # 追加
    dapr.io/log-as-json: "true"
    prometheus.io/scrape: "true" 
    prometheus.io/port: "9090" 
    prometheus.io/path: "/" 
    dapr.io/sidecar-listen-addresses: "0.0.0.0"

参考として ingress controllerの設定を掲載していますが、aggregator/timefeedも同様に修正します。 appconfig という名称は先程デプロイした collector-config.yaml に指定した名前です。

これらを kubectl applyやhelm upgrade したら完了。

ここでトラップ

これで設定は完了・・・。デプロイしたら問題ないはず・・・。だったのですが、どうもsidecarの中でエラーが出ているようです。

前回体験したトラップを踏まえ、今回もnamespace を疑います。 namespaceは以下のような状態になっています。

ingress controllerは ingress-system
aggregator/timefeedは web
appconfigのConfigurationは dapr-system

ingress-systemやweb namespaceのアプリケーションのannotationでdapr-systemにあるappconfigという設定が参照できていない。これが問題と推測しました。

最初、Service Invocation同様にdapr.io/config で <名称>. とすればいいかと考えました。しかしエラー。ということで、ConfigMapでよく行われる方法、Configurationをそれぞれのnamespaceに同名でデプロイすることで解決を試みました。

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: appconfig
  namespace: dapr-system
spec:
  tracing:
    samplingRate: "1"
    zipkin:
      endpointAddress: "http://otel-collector.dapr-system.svc.cluster.local:9411/api/v2/spans"
---
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: appconfig
  namespace: web
spec:
  tracing:
    samplingRate: "1"
    zipkin:
      endpointAddress: "http://otel-collector.dapr-system.svc.cluster.local:9411/api/v2/spans"
---
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: appconfig
  namespace: ingress-system
spec:
  tracing:
    samplingRate: "1"
    zipkin:
      endpointAddress: "http://otel-collector.dapr-system.svc.cluster.local:9411/api/v2/spans"

こちらで再度デプロイし直し、念の為 ingress-controller/aggregator/timefeed もrestartしました。今度は問題なく正常起動します。

動作確認

Application Insightsのアプリケーションマップで確認すると次のように表示されます。

アプリケーション自体にはTracingなどの設定は加えていません。それでもこのマップは作成できました。平均呼び出し時間といった最低限の情報も取得できます。Daprのannotationを加えるだけでこうした情報が取得できるのは助かります。

おわりに

今回はもともとDaprの公式ドキュメントにも記載されているMetricsやTracingを有効にしてみました。これらを活用するといったところまでご紹介できていませんが、まずスタートラインに立つことが重要なのでご紹介させていただきました。

第１回の経験から、問題となりそうなところはnamespace周辺」とある程度わかっていますので時間をかけずに問題を解決できましたが、知らないとなかなか気づけずに解決に時間がかかってしまう部分でもあると思います。今回のご紹介が何かの参考になれば幸いです。

今回検証で使用したコードはGitHubで公開しています。

github.com

APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

AKSでDaprを使ってみる（２） MetricsとTracingを有効にする

はじめに

DaprのMonitoring

ConfigMapの登録

Jsonフォーマットでログ出力するよう設定変更

annotatonsの変更

動作確認

DaprのTracing

Open Telemetry Collectorの設定

Annotation追加

ここでトラップ

動作確認

おわりに