銀の光と碧い空

クラウドなインフラとC#なアプリ開発の狭間にいるエンジニアの日々

OpenTelemetry .NETを理解する (6) コード修正不要な自動計装ライブラリを利用する

前回の投稿から時間が空きましたが、今回は今までとは違う方法での計装を試してみます。

今までの方法は、ソースコードの修正を前提とするものでした。トレース、ログ、メトリクスの1つ1つを詳細に計測するコードは必要なく、例えばASP.NET Coreに対応した計装ライブラリを利用できました。が、それでも、数行程度とはソースコードへの修正が必要でした。 今回試す方法は、ソースコードへの修正を必要としない方法での計装です。これは例えば、従来のNew Relic Agentと同じように、.NETのProfiler APIを利用した方法です。

さて、この方法については数ヶ月前にLTで発表しました。

その時は最初のバージョンでしたが、現在では次の0.2.0-beta1が出ています。今回はこれを試してみました。

github.com

おおまかには同じなのですが、10ページ目で言っていた課題がどうなっているかを確認してみました。

環境変数については相変わらず多いです。Macで動作しないのも同じでした。おそらく、MacOSでの.NET プロセスの権限まわりが問題だと思うのですが、詳しくはわからず... 今回は、Mac上のDockerで動作確認しました。 OTLPでの認証ヘッダーなしでのデータ転送についても変わらずですが、otel/opentelemetry-collectorを経由してデータ転送できます。

動作確認したデモアプリをここに公開しています。docker composeでアプリのコンテナとotel/opentelemetry-collectorを同時に立ち上げています。

github.com

そして、Collectorで適当なOTLPバックエンド(ここではNew Relic)を指定すると実際のデータを確認できます。

また、OpenTelemetry .NET では.NET標準のSystem.Diagnostics.Activityを利用することで手動での計装が可能です。

tech.tanaka733.net

Activityクラスは、今回ためしている自動計装ライブラリでも動作しており、例えば次のようなコードを記述すると

app.MapGet("/ExternalError", async (ILogger<Program> logger) => 
{
    var activity = Activity.Current;
    var client = new HttpClient();
    try
    {
        await client.GetStringAsync("https://httpstat.us/502");
        return "Hello World!";
    }
    catch (System.Exception e)
    {
        activity?.SetStatus(ActivityStatusCode.Error, "外部呼び出しエラー");
        logger.LogError(e, "外部呼び出しエラー");
        return "error";
    }
    
});

このように、HTTPの呼び出しスパンだけではなく、その親スパンもエラー状態と記録することができます。

また、Metricsの収集と送信にも対応しており、次のようなメトリクスを.NET Runtimeメトリクスとして収集しています。

Logsについては未対応なようです。また、更新があればまとめようと思います。

公開スライドをSlideshareからドクセルに移しています

今まで登壇資料などはSlideShareに公開していたのですが、徐々にドクセルに移しています。

www.docswell.com

一時期、docs.com を利用したこともあったのですが、サービス終了したこともありSlideShareを使い続けていました。が、買収により所有企業がころころ変わり、最近では一部の機能が有償化しているようです。一番懸念しているのが、どの機能が有償なのか、資料を公開する側が払うのか、資料を閲覧する側が払うのか明確でないということです。 基本的にはSlideShareで使っていた機能が使えることが条件だったのですが、例えばこんな機能です。

  • はてなブログなどへの埋め込みができる。できるだけ手順が簡単なのが望ましい。 => はてなブログではURLをコピぺしてページ埋め込みモードで下のように埋め込めます。
  • PPTXもしくはPDFがアップロード可能
  • スライド内のハイパーリンクが動くこと
  • 資料のページでTwitterへのシェアが可能なこと

www.docswell.com

加えて、ドクセルでは同じリンクのまま資料を更新することが可能です*1。また、ページを指定したURLハッシュに対応しているので、指定したページに直接飛ばすこともできます。

https://www.docswell.com/s/tanaka_733/KE17N5-202202-open-telemetry-net-handson#p3

実際に移行するときに気になるのがSlideShareに公開済みの既存の資料の移行ですが、ドクセルでは手順が公開されています。

www.docswell.com

SlideShareのExport機能を使うわけですが、SlideShareでのダウンロードはExport機能で出力されたURLをクリックするとWebページ内で(クライアントブラウザ内で)リダイレクトされたうえで、ファイル保存ダイアログが開く仕様になっています。つまり、プログラミングでの自動化がやりづらくなっています。なおかつ、このときのデフォルトファイル名がタイトルなどとは関連しないわかりづらいものになることがあり、ファイル数が多いとこの後の作業が非常にわかりづらい状況でした。

ドクセルではこのページに書いている通り、登録の代行もしていただけるとのことで、私も(声をかけていただいたこともあり)お願いしました。無事にすべて登録できており、まずは非公開ですべて保存されています。今後、確認しながら新しいものから順次公開しています。昨年公開した資料はすでにドクセルで公開済みにしました。

SlideShareに公開した資料は、今後デフォルトで課金されるなどなければそのままにするつもりですが、今後公開する資料はドクセルで公開する予定です。

*1:読み手が混乱するほど異なる資料をアップロードした場合は非公開になることもあると記載されています。妥当な対応だと思います。

OpenTelemetry .NETを理解する (5) HttpClientによる外部通信処理を計測する

前回はスパンに情報を追加しました。

tech.tanaka733.net

次にトレースをさらにスパンで区切ってどの処理に時間がかかっているか計測することにします。スパンは作業の単位で区切ります。原理的には1メソッド1スパンで記録することもできますが、計測のオーバーヘッドや分析のノイズになることから、意味のある作業の単位でスパンを作成するのがおすすめです。そして、トレースで注目したいボトルネックになりうる作業の単位としては、HTTPでの外部呼び出しやデータベースへの呼び出しが典型的です。そのため、OpenTelemetry .NETでもそれらのライブラリに対して自動計装する機能が用意されています。今回は、HttpClientによる外部呼び出しを自動計装する機能を紹介します。

最初のコードはこのような状態です。

app.MapGet("/external", async () =>
{
    var client = new HttpClient();
    var req = await client.GetAsync("http://httpbin.org/get");
    var res = await req.Content.ReadAsStringAsync();
    Console.WriteLine(res);
    return res;
});

app.MapGet("/external/error", async () =>
{
    var client = new HttpClient();
    var req = await client.GetAsync("http://httpbin.org/status/502");
    try
    {
        var res = await req.EnsureSuccessStatusCode().Content.ReadAsStringAsync();
        Console.WriteLine(res);
    }
    catch (Exception e)
    {
        Console.WriteLine(e.Message);
    }
});

HttpClientの自動計装については、次のようにASP.NET Coreの最初の設定時にAddHttpClientInstrumentationメソッドを呼び出すことで行います。そのため、個別のHttpClientの呼び出し部分に処理を追加する必要はありません。

builder.Services.AddOpenTelemetryTracing((builder) => builder
        .AddAspNetCoreInstrumentation()
        .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("Hello-Otel").AddAttributes(tags))
        //以下1行を追加する
        .AddHttpClientInstrumentation()
        .AddOtlpExporter(options => 
        {
            options.Endpoint = new Uri("https://otlp.nr-data.net:4317/");
            options.Headers = $"api-key={Environment.GetEnvironmentVariable("OTEL_API_KEY")}";
        })
    );

すると、/externalのエンドポイントは次のようにトレースが記録されます。HttpClientによる通信処理が1つの子スパンとして記録されています。これにより、全体の処理(親スパン)のうち、外部通信でどれだけかかっているかがわかります。また、レスポンスのステータスコードなどの情報がhttp.ではじまる属性として記録されています。

一方、external/error のエンドポイントは次のようにトレースが記録されます。通信処理が子スパンとして記録された上で、スパンの状態をエラーとして記録しているため赤く表示されています。

さて、子スパンはエラーとして記録されていますが、親スパンの側はエラーとしては記録されていません。これは外部通信処理がエラーであっても、必ずしも親スパンの状態がエラーになるべきではないからです。通信処理でエラーが発生した場合に親スパンもエラーとして記録したい場合、前回の記事で紹介した方法で記録することになります。

app.MapGet("/external/error", async () =>
{
    var client = new HttpClient();
    var req = await client.GetAsync("http://httpbin.org/status/502");
    try
    {
        var res = await req.EnsureSuccessStatusCode().Content.ReadAsStringAsync();
        Console.WriteLine(res);
    }
    catch (Exception e)
    {
        var activity = Activity.Current;
        activity?.SetTag("otel.status_code", "ERROR");
        activity?.SetTag("otel.status_description", "required service is down.");
        activity?.RecordException(e);
    }
});

これで親スパンもエラーとして記録されるようになります。