Getting Started with OpenTelemetry in .NET
Use code KUBE20 and get 20% off the brand new "From Zero to Hero: Kubernetes for Developers" course on Dometrain: dometrain.com/course/from-zer...
Get the source code: mailchi.mp/dometrain/nfu-hchyl2s
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video, I will show you how you can get started with OpenTelemetry in .NET using Prometheus and Grafana.
.NET Aspire video: • What Is .NET Aspire? T...
IMeterFactory video: • Creating Dashboards wi...
Aspirate video: • How to Deploy .NET App...
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
I liked the video, but it felt a bit cluttered. This appears to be an ideal continuation for the 'How to Deploy .NET Apps to Kubernetes' series, with a focus on integrating Open Telemetry. But as usual, awesome content 👍
Amazing, aspire is getting better and more support from community.
Awesome video! Thank you for showing foss software and not choosing azure. This is really helpful!
Awesome content! Awesome Nick! 👌
Hi Nick, I've been following you for a few years now and I appreciate all the content you put out over the years, I learned a lot from the videos. However, last couple of videos felt over-filled, and it felt like you rushed through the content just to get through all of it, instead of explaining everything like you used to. If one does not have personal experience with any of the stuff you present, it is very easy to feel left behind and not understand anything. Please slow down, and explain everything like you used to, because this video specifically feels more like a sales pitch intended to make the listener feel dumb in order to buy the course instead of being a quality piece of content.
Accurate
Thanks!
Your course about docker explains how to debug inside a container? Thank you Nick!
Hey Nick. Out of interest, I threw up a version of the Aspire Dashboard as an Azure Web App (I modified it to use a single port for the inbound telemetry and the Blazor UI instead of needing 2 ports). I also added Microsoft Identity authentication and a OTLP API Key to the Dashboard App, although it looks like the core team are adding OTLP API Key support in preview 4 anyway.... But I am enjoying just using that Aspire Dashboard app directly for some of my cloud dev environments.
great, feel like my organisation will get there in about 10 years time, lot invested already in kubernetes and terraform
How does sampling work in non development environments?
I am wondering, how different (in the case of Azure, for instance) is it from using Azure Monitor and AppInsights in terms of what you get out of it? What advantages does it give besides the open standards and open source and data portability in the case of OT?
You don't have to choose - OpenTelemetry has an Azure Monitor exporter. I guess that's part of the advantage - YOU want to run Azure Monitor, but a different deployment of same app may want to run Prometheus/Grafana - and this gives you the option of using any of them without changing your code (except for config).
That is what is good about Azure Monitor by itself. I do not have to do anything in the code. Azure, as the hosting platform provides the telemetry and does all the plumbing. Other cloud providers have similar things as well. If you run something on-prem, I can see the need for that. There might be other scenarios. However, when cloud providers are in use, I think that features like telemetry are built in, without the need to change anything in the code.
Managed Prometheus and Grafana have been fused with Azure Monitor. AppInsights is now a component of Azure Monitor. When it comes to monitoring, you are spoiled for choice. It boils down to your preferred tools and the breadth and depth of coverage. The advantage of Azure Monitor is that you can ingest signals from your "entire infrastructure" and other tools and services. This allows you to correlate the information and carry out advanced diagnostics on the logs, metrics, and traces.
Cool, a good topic finally!
Does it have metrics for kafka and dapper for a AspNetCore web api? So I can check if queries/messaging are slow. Love the content! : )
2:12 As far as I know, Aspire is for local development, not for production use. That's at leas what David Fowler answered to my question.
Hi, Nick can you do video where Prometheus is used as data source only and .net application is using it and exposing the data from it on the application itself and not in grafana?
When deploying different releases of say Api project via Aspire. Then will K8s or docker compose re-deploy all the containers again ?
Great :)
how to integrate with cgp (trace and metric explorer) instead of grafana
That was a lot of content. Maybe the most packed one yet. In the real world out in the wild, is one person ever doing all of this? Or is this done by a team of people?
Depends on the size and circumstances of the team. For a new team getting started and bootstrapping, the initial team members will do all this ground work themselves. Sometimes, they will just be 1 to 3 people. So they need to know how to code, deploy, handle kubernetes, monitor and deal with database and security issues. Sprinkle on some PKI issues, email setup, etc, etc... Tools like this are meant for such individuals (and also more advanced teams with greater delineation of duties). It reduces the cognitive load while allowing them stay in control of everything going on. They are able to rev quickly, experiment and adapt till they find the sweet spot that works for them that will allow frequent, repeatable deployments and features are added and the project grows... My thoughts (also speaking from personal experience).
If you're a one-person shop trying to get off the ground, unless you have unlimited runway and bandwidth, this is probably more of a v2.0 / do-it-when-you're-profitable kind of thing. This stuff is cool and immensely useful for finding hot-spots, bottlenecks, and overall project health, but you will bog yourself down if you focus on these kinds of things instead of the core product. Gotta keep minimal viable product in mind. If you run out of funding the project will never see the light of day. No amount of telemetry, metrics, or logging will fix that.
Very good and interesting topic! One question though. Where is all that data stored? Prometheus scraps it but where is it saved? How does grafana know where to find the data to visualise?
Prometheus stores it. You can query prometheus directly or via a visualization tool like Grafana
@@dauchande but where does Prometheus store it? Disc? Can it be configured other storage media like Azure storage table or blob?
@@andrewiecisa2907 Prometheus itself is a time-series database, so you don't store its data in other Azure databases. There is a Managed Prometheus offering in Azure, or you can use a compatible database called Grafana Mimir that can store data in cloud blob storage such as Azure blob storage. Then use something like Grafana Agent to remote-write the prometheus data to Mimir
With the amount of data exported on every single call, I would worry about storage, bandwidth and performance in general. No wonder why the cloud cost so much...
Worked parallel to a team of about a dozen devs on a brand new greenfield project w/ a couple dozen or so micro apps and services (the tail was wagging the dog for sure, w/ the devs calling all the shots). They were generating on the order of gigabytes of logging data every night, and they weren't even live. Our DBA was furious with them. They ran themselves right into the ground -- the project was poop-canned about 5 years into it. Millions of dollars wasted, other than padding their resumes, and the sad part was they were just fine with that and moved on to make the same mistakes in future projects w/ other organizations. Your point is well taken, esp. for the people in charge funding these development projects. Buyer beware.
More a Aspire video than Open Telemetry
I come here to learn about open telemetry and found a bad tutorial which base everything on aspire, then aspire dont even work...
The Prometheus is totally unnecessary, otel alone is enough. Also be aware that the cost of aspnetcore metrics if exporting to grafana web is extreme.
First!
Adam and Eve were first, not you!!