.NET 6 と Daprを使った分散サービス開発その5 Observability (観測可能性)

Last updated at 2022-03-05Posted at 2022-03-04

Observability (観測可能性)によるマイクロサービスの状態観測とログ、分散トレーシング

今まで、以下の流れで作業を行ってきました。今回はDaprに備わっているObservability (観測可能性)を使って、各サービスの状態観測やモニタリングについて触れていきたいと思います。

今までの前提の上で観測可能性機能を追加しますので、このページから読まれている方は、前提として以下を読んできてください。

Observability (観測可能性)の大事さ

Kubernetesなどの環境では、もちろんPersistentVolumeを用意して永続化ストアを持つことができなくもないですが、ログの為に永続化ストアを使うことは正直言ってあまりお勧めできる事では無いと思っています。また、各サービスがお互いに連携して動作するマイクロサービスのような設計の場合、どのサービスで例外が起こっているかなどをわかりやすく把握できる仕組みが大事ですし、できる事であれば運用に入る前の開発時から導入して効率よく開発を進めたいものです。

いわゆる分散トレーシングと呼ばれているものです、AzureですとApplication Insights, AWSだとX Ray, GoogleだとStackdriver 、New Relicなども良く知られたサービスです。

以下は、Azure Application Insightsという分散トレーシングのサービスの一画面です。エンドポイントのPath単位で、500エラーが何回発生しているかを集計してくれており、そしてログをドリルダウンする事ができます。

これらのログをドリルダウンすると、ログの中から重複したエラーを整理してくれ、どの点で例外が発生したかコールスタックを表示してくれます。

何かが起こって ログを見る前に、何が起こっているのかを常にモニタして、可視化しましょう。

DaprでのObservability (観測可能性)

Daprでは、オープンソースプロジェクトであるOpenTelemetry での、W3C Tracing contextフォーマットでのログ収集の仕組みを実装しています。
各サービスから収集したトレース、メトリック、ログのデータは、Azure AppInsights, AWS X-Ray, StackDriver, Azure Monitor,Prometheus,Grafana,New Relic,FluentD,New Relic,Zipkin,Jaegerなどに連携する事ができます。

DaprでObservability (観測可能性)コンポーネントを設定する

ここでは、あらかじめdapr initでコンテナとしてロードされており、既にローカルに設定されているZipkinを使う設定をDaprに仕込みます。

注意として、今まで設定していたコンポーネントとしてのプロジェクト単位の設定では無く、Daprの全体設定となります。よって、以下に記載してください。同じようにKubernetes にもconfigmapとして設定できますが、それについては後のトピックとしたいと思います。

%USERPROFILE%.dapr\config.yaml (Windowsの場合)
$HOME/.dapr/config.yaml (Linux/Macの場合)

config.yaml

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: daprConfig
spec:
  tracing:
    samplingRate: "1"
    zipkin:
      endpointAddress: http://localhost:9411/api/v2/spans

あれ？既に書かれているよ？となっていた方は正解です。dapr initでローカル展開した際に自動的に設定してくれていたのでした。
そして、dapr initで展開されたdockerイメージの中でOpen Zipkinが既に稼働しています。

$ docker ps
CONTAINER ID   IMAGE               COMMAND                  CREATED      STATUS                       PORTS                              NAMES
ba8a9bdb62ab   daprio/dapr:1.6.0   "./placement"            2 days ago   Up About an hour             0.0.0.0:6050->50005/tcp            dapr_placement
808b6358b4e7   openzipkin/zipkin   "start-zipkin"           7 days ago   Up About an hour (healthy)   9410/tcp, 0.0.0.0:9411->9411/tcp   dapr_zipkin
bed085e54a77   redis               "docker-entrypoint.s…"   7 days ago   Up About an hour             0.0.0.0:6379->6379/tcp             dapr_redis

Open Zipkinで確認しよう

Open Zipkinで分散トレーシングログを確認してみようと思います。まぁ、ログといえるほどのログやアクセスが無いので、とても質素で貧相ですが・・・

URL http://localhost:9411/ にアクセスしてみてください、以下のような画面が表示されると思います。

とりあえず、何も考えずにRUN QUERYをクリックします。各サービスが一覧となって、Durationなども表示されています。

ギアマークから、過去何日間のログを出すかなどフィルタに関しての設定もできます。

Dependenciesからは、ログから得られるサービス間の依存関係なども表示されています。

プロジェクトが吐き出すログ設定を変更する

何故、動いていたのにログがほとんどなかったのか？というのは、実は各プロジェクトからログの出力設定を行っていなかったからです。
各プロジェクトに Program.cs の先頭に以下のログのフォーマット設定2行を追加します。

using System.Diagnostics;
Activity.DefaultIdFormat = ActivityIdFormat.W3C;

Program.cs

using System.Diagnostics;
Activity.DefaultIdFormat = ActivityIdFormat.W3C;

var builder = WebApplication.CreateBuilder(args);
// Add services to the container.

builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

// Add Dapr Client
builder.Services.AddDaprClient();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

Open Zipkinで再度確認

設定を終えたら、 tye run でプロジェクトと起動しましょう。
Tye dashboardから、http://localhost:8000/　にアクセスして、エンドポイントを確認します。
ここでは、AppのSwaggerにアクセスしたいので　https://localhost:49689/swagger にアクセスしましょう。