opentelemetry-dotnet VS opentelemetry-go

open-telemetry/opentelemetry-dotnet: The OpenTelemetry .NET Client (github.com)

💡Good to know -- If you wish to export traces to Jaeger, you should use the AddJaegerExporter instead of the AddOtlpExporter. Visit the opentelemetry-dotnet repository to see how it's done.

We're going to use OpenTelemetry .NET SDK. Add following nuget dependencies to the project:

We instrument the application with the OpenTelemetry SDK and SqlClient instrumentation library for .NET. First, we add the following NuGet package references to the API’s project file:

Besides that, the propagation fields (traceparent and tracestate) were added in the message header. In the last article, I said that the standard (in the Working Draft (WD) step of the w3c process) recommends to add the propagation fields in the application-properties section by the message publisher. For the current example, I chose to propagate that context in the message header even for AMQP calls as was done in the dotnet OpenTelemetry example. It's important to reinforce that Trace Context: AMQP protocol is not a W3C Recommendation yet. Take a look at the place where the propagation fields were added:

As long as the Azure Functions app knows the instrumentation key from an Application Insights instance, it traces almost everything. OpenTelemetry.NET is one of the Open Telemetry implementations, has recently released v1.0 for tracing. Both metrics and logging are close to GA. However, it doesn't work well with Azure Functions. Therefore, in this post, let's manually implement the tracing at the log level, which is sent to Application Insights.

https://opentelemetry.io/ with Grafana?

I'm working towards a Deno-first implementation of OpenTelemetry and had to start with creating an implementation of a protocol buffer Reader and Writer:

OpenTelemetry - A collection of open-source tools for collecting and exporting telemetry data (metrics, logs, and traces) for analyzing software performance and behavior.

from here https://github.com/open-telemetry/opentelemetry-go

The Pokeshop API with Otel Instrumentation, ADOT, X-Ray, and Tracetest. Using Tracetest's own distributed Node.js Pokemon demo API, instrumented using official OpenTelemetry packages, the AWS Distro for OpenTelemetry as middleware to send tracing data to AWS, and Tracetest for trace-based testing.

Telemachus is a DCS-gRPC client that records DCS server and mission metrics such as server FPS, take-offs, landings etc. and converts them to OpenTelemetry metrics which can then be stored and visualised using a wide variety of OpenTelemetry supporting programs and services. OpenTelemetry is becoming a software industry standard way of processing metrics, logs and traces.

Enter OpenTelemetry. Don't worry if you're not familiar with it (although it's the 2nd largest CNCF project!) - it's just a standard protocol for reporting traces, logs and metrics from production services. We realized it's a great way to observe all the side effects as they happen within the system. We can send a request to the system and then validate side-effects using the OpenTelemetry data coming out of the system.