dotnet-cloud-native-build-2023
opentelemetry-dotnet
dotnet-cloud-native-build-2023 | opentelemetry-dotnet | |
---|---|---|
1 | 7 | |
162 | 2,982 | |
- | 1.7% | |
8.3 | 9.7 | |
3 months ago | 1 day ago | |
C# | C# | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dotnet-cloud-native-build-2023
-
ASP.NET Core: Monitoreo con OpenTelemetry y Grafana
bradygaster/dotnet-cloud-native-build-2023 (github.com)
opentelemetry-dotnet
-
ASP.NET Core: Monitoreo con OpenTelemetry y Grafana
open-telemetry/opentelemetry-dotnet: The OpenTelemetry .NET Client (github.com)
-
Guide to Distributed Tracing with OpenTelemetry Dotnet
💡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.
-
Observability with Grafana Cloud and OpenTelemetry in .net microservices
We're going to use OpenTelemetry .NET SDK. Add following nuget dependencies to the project:
-
OpenTelemetry in Action: Identifying Database Dependencies
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:
-
State for each API Request
It should be handled automatically by OpenTelemetry middlewares. Just look through documentation and samples https://github.com/open-telemetry/opentelemetry-dotnet
-
[c#] Using W3C Trace Context standard in distributed tracing
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:
-
Tracing End-to-End Data from Power Apps to Azure Cosmos DB
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.
What are some alternatives?
serilog-sinks-seq - A Serilog sink that writes events to the Seq structured log server
ApplicationInsights-dotnet - ApplicationInsights-dotnet
DevToPosts
RabbitMQ - Open source RabbitMQ: core server and tier 1 (built-in) plugins
grafana-otel-dotnet - Sample setup showing ASP.NET Core observability with Prometheus, Loki, Grafana, Opentelemetry Collector
zipkin - Zipkin is a distributed tracing system
jaeger - CNCF Jaeger, a Distributed Tracing Platform
C# StatsD Client
open-meteo - Free Weather Forecast API for non-commercial use
ASP.NET Core - ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
trace-context-w3c - W3C Trace Context purpose of and what kind of problem it came to solve.
opentelemetry-specification - Specifications for OpenTelemetry