Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenTelemetry Support in Arcus #579

Open
gverstraete opened this issue Oct 24, 2024 · 2 comments
Open

OpenTelemetry Support in Arcus #579

gverstraete opened this issue Oct 24, 2024 · 2 comments
Labels
dependencies All issues related to dependencies

Comments

@gverstraete
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Many things are moving towards OpenTelemetry, so I would encourage to also embrace this in Arcus.

Describe the solution you'd like
I would be good to be able to log to OpenTelemetry with .Log{whatwewanttodo}

Additional context
Please also concern simplification & justification.

Also apply this to the default web api template.

@stijnmoreels stijnmoreels added the dependencies All issues related to dependencies label Oct 29, 2024
@github-project-automation github-project-automation bot moved this to To do in Roadmap Oct 29, 2024
@stijnmoreels
Copy link
Member

Some info related to this and migration from App Insights client SDK to OpenTelemetry using service-to-service correlation/distributed tracing.

Minimalistic setup:

var builder = new HostBuilder();

builder.ConfigureServices(services =>
{
    services.ConfigureOpenTelemetryTracerProvider((provider, traces) =>
    {
        traces.AddSource("<name-of-subscribed-activity>");
        traces.ConfigureResource(resource =>
        {
            resource.AddService("<my-cloud-name>", serviceInstanceId: "<my-cloud-instance>");
        });
    });
    
    services.AddOpenTelemetry()
            .UseAzureMonitor(options =>
            {
                options.ConnectionString = "InstrumentationKey=<key>";
            });
});

Logging dependencies/requests:

internal static class ILoggerExtensions
{
    public static void LogDependency(this ILogger _, string dependencyName, ActivitySource source, bool isSuccessful, DateTimeOffset startTime, TimeSpan duration, Dictionary<string, object> contextProperties)
    {
        using Activity? activity = source.StartActivity(name: dependencyName, kind: ActivityKind.Client, startTime: startTime);
        if (activity is null)
        {
            return;
        }

        activity.SetEndTime(activity.StartTimeUtc.Add(duration));
        activity.SetStatus(isSuccessful ? ActivityStatusCode.Ok : ActivityStatusCode.Error);

        foreach (KeyValuePair<string, object> property in contextProperties)
        {
            activity.SetTag(property.Key, property.Value);
        }
    }

    public static void LogRequest(this ILogger _, string requestName, ActivitySource source, bool isSuccessful, DateTimeOffset startTime, TimeSpan duration, Dictionary<string, object> contextProperties)
    {
        using Activity? activity = source.StartActivity(name: requestName, kind: ActivityKind.Server, startTime: startTime);
        if (activity is null)
        {
            return;
        }

        activity.SetEndTime(activity.StartTimeUtc.Add(duration));
        activity.SetStatus(isSuccessful ? ActivityStatusCode.Ok : ActivityStatusCode.Error);

        foreach (KeyValuePair<string, object> property in contextProperties)
        {
            activity.SetTag(property.Key, property.Value);
        }
    }
}

Thing is, that you don't need a ILogger; we could inject our own logging provider, but that would make it more complex and we don't have the budget (anymore) to provide entire custom-SDK implementations.

@fgheysels
Copy link
Member

fgheysels commented Jan 3, 2025

These are some interesting resources:
https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-dotnet-migrate?tabs=aspnetcore
https://learn.microsoft.com/en-us/dotnet/core/diagnostics/observability-with-otel#net-implementation-of-opentelemetry

When providing support for OTel, we'll have to keep on supporting our current approach for a certain period of time.

I believe the current extension methods that Arcus offers (LogCustomEvent, LogCustomMetric, ... ) can still be leveraged here. The behavior / implementation of those methods will depend based whether we're using OTel or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies All issues related to dependencies
Projects
Status: To do
Development

No branches or pull requests

3 participants