How to export data from asp.net core t telemetry to Grafana without installing the Grafana agent

According to the following article, it seems it needs to deploy a local Grafana agent along with my asp.net core application in order to export trace data to the Grafana cloud server. Is it possible to use API configuration to push data to the Granfan server without the need to install any agent? Do you have step guide on that?

1 Like

No, that “Grafana cloud server” is Tempo instance. Tempo supports standard OTLP protocol, so your solution will be to use standard openetelemetry lib (.NET | OpenTelemetry) and OTLP GRPC exporter with proper authentication (basic auth).

Jangaraj, Thanks for your help. I am following the steps in the same doc you refer me to .Net | OpenTelemetry. The code below has a placeholder (“your-endpoint-here”). I thought that would be the endpoint to my storage (Grafana) in the Grafana server. Do you know if there is any doc that guides the setup of the exporter to the endpoint with proper authentication and API key?

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenTelemetryTracing(b =>
{
    b
    .AddOtlpExporter(opt =>
    {
        opt.Endpoint = new Uri("your-endpoint-here");
        opt.Protocol = OtlpExportProtocol.HttpProtobuf;
    })
    // The rest of your setup code goes here too
});

No, that’s not endpoint to your Grafana. “Grafana cloud” is package of the services: Grafana, Loki, Tempo, Mimir, … One of that service is Tempo (tracing backend) . You will find your Tempo endpoint in your Grafana cloud admin console (again that’s not your Grafana, your Grafana has only datasource which is connecting to Tempo). In the admin console you can also generate an user with right write permissions for Tempo. Authentication is implemented via basic auth, not an API key, so define right basic auth headers, not API key headers.

services.AddOpenTelemetryTracing(
(builder) => builder
.SetResourceBuilder(ResourceBuilder.CreateDefault().AddService(“InsightDataService”))
.AddAspNetCoreInstrumentation()
.AddConsoleExporter()
.AddOtlpExporter(opt =>
{
opt.Endpoint = new Uri(“https://tempo-us-central1.grafana.net/tempo”);
opt.Protocol = OtlpExportProtocol.HttpProtobuf;

                   }));

I updated the code with the trace endpoint to the tempo url. However, I don’t know where to add the user name and password for basic authentication. In grafana tempo, I had already add a permission to allow a user with edit permission. How to add a basic authentication credentials to the opentelemetry tracing to tempo?

Again, it seems the only way to get the trace data to the tempo in the cloud is through a local agent according to this doc from Grafana. Could you please confirm that or give an example of how to do that without?

Again, Tempo is based on Opentelemetry standard, so any OTLP lib can export traces to Tempo.

1.) otlp .net add header - Google Search

2.) first result https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/README.md#configure-httpclient will give you a glue how to add custom headers (for Tempo authentication)

Please don’t expect copy paste solution (if so, then hire someone). You are developer, so you have to find right config for used lib in used language. Read the doc first, pls. (BTW I never used .Net for OTLP)

Before you ask again - see how to construct basic auth header create basic auth header - Google Search

“Please don’t expect copy paste solution”. Of course, because we are already in version 7 of .NET and until today, grafana doesn’t have a decent documentation, not even for version 5. I feel like Sherlock Holmes, trying to unravel the mystery of deploying grafana in my application.

Why Grafana? Don’t focus on Grafana, but on OpenTelemetry standard, which can be used with any tracing backend (Grafana Mimir, Lighstep, X-Ray, Jaeger, Zipkin, Elastiscsearch, Splunk, …). Implement GitHub - open-telemetry/opentelemetry-dotnet: The OpenTelemetry .NET Client and you don’t have any vendor lock-in + you can anytime switch easily to any OTLP compatible backend. That’s a current trend - vendors add OTLP support, instead of own legacy vendor implementations.