I like this, but I'm not clear on how it works for a production deployment. Where are the metrics stored, how does the data get there, how can I monitor multiple installations (like if my suite of apps is installed at 100 different unrelated clients how do I centralize monitoring so I can see performance for all of my customers, etc.), is this chained to cloud deployments (most of my clients host my app suite on-prem with VMs), etc. Essentially, Aspire looks interesting, but it's not yet clear to me how to approach it.
I would be interested in a video explaining how to visualize a histogram in Kibana or grafana using opentelemetry data, this feels to be quite a challenge.
I'm not yet using this API, but I've been using the AppMetrics NuGet packages which are very similar. I'm using it to measure the performance of some background processes and then using those numbers in the application's health checks to have some alarm bells go off in case of degraded performance.
Great video! You are creating a new IDisposable object for the histogram. When will it be a memory performance issue and how can it be handled? Comparing this to your videos of logging and incorrect using of string interpolation
I think this ie really neat. But if you restart the application it will be kinda "faulty" data. I release 5-20 times a day on my microservices and want to know over a longer time period. Guess this is nothing for me then =/
Quick question, is there ever a chance that (even if not now, but maybe by the time we have .Net 9), the running code will try optimizing itself. If it is waiting for the request, and it knows the discarded var is never used below, it might want to GC or Dispose is early. Is there a way to know the lifetime of the disposed method will always be the full runtime of the method?
That behaviour is guaranteed to stay how it is. The point of IDisposable is to provide a deterministic point when your resources, whatever they may be, get disposed of. Introducing any "optimizationa" like that would defeat the point of Dispose since it'd no longer be deterministic. Not to mention it'd be a giant breaking change, which Microsoft generally avoids.
This new feature is very interesting! But, maybe it's me who doesn't understand well, is it weird to write code to have metrics that will be deployed in production?
You need metrics more in production than dev. In dev you can just debug. But in a production environment you'd send these metrics, together with logs, to a single aggregate (most use Grafana) for storage. And then use (again most use Prometheus) to explore and visualize that data, for all your apps, in a single web interface.
Hello, can we calculate requests by user IP, header etc. Instead of total requests? So we can see how many requests per api user and by method based?Also , use it for distributed rate limiter. İnstead of using redis? Because current rate limiter does not allow distributed limitting.
Distributed rate limiting is a different beast to tame. You gotta track the requests overall (over many servers) which is a different concern and has other requirements then collecting and visualizing metrics.
Nick, you already owe us a video on building visualisation dashboards with grafana.
I guess this is the call to action you need 😂
I could absolutely use a few good pointers.
I like this, but I'm not clear on how it works for a production deployment. Where are the metrics stored, how does the data get there, how can I monitor multiple installations (like if my suite of apps is installed at 100 different unrelated clients how do I centralize monitoring so I can see performance for all of my customers, etc.), is this chained to cloud deployments (most of my clients host my app suite on-prem with VMs), etc.
Essentially, Aspire looks interesting, but it's not yet clear to me how to approach it.
I would be interested in a video explaining how to visualize a histogram in Kibana or grafana using opentelemetry data, this feels to be quite a challenge.
It's very easy from this video to export the metrics to Prometheus and visualise them in Grafana. It's a video asking to be made
You could use the same disposable pattern in counter (increase in dispose function). And now your code will be clearer without try-finally.
For Azure users it might be nice to show Application Insite Intergration
Probably not going to happen as Nick is sponsored by Amazon afaik.
Would love to see alternatives to aspire for this
I'm not yet using this API, but I've been using the AppMetrics NuGet packages which are very similar. I'm using it to measure the performance of some background processes and then using those numbers in the application's health checks to have some alarm bells go off in case of degraded performance.
Waiting for empty builder benchmark 😄 , Good Luck ❤
Please make a video on opentelemetry & grafana.
I would be interested in a video about transactions, concurrency and locks
Great video!
You are creating a new IDisposable object for the histogram. When will it be a memory performance issue and how can it be handled?
Comparing this to your videos of logging and incorrect using of string interpolation
Loving your videos Nick! This is great!
Does open telemtry allows store the values in certain services?
My man just explained in a few minutes what I was struggling to get out of coworkers with otel experience for yonks 😅
You're corret. But that's so nice.
Merry Christmas! 🎄⛄❄️
Can you make more videos about opentelemetry and grafana
Thanks for your great videos. Can you perhaps also make one with Keyvault and database in connection with Aspire?
I think this ie really neat. But if you restart the application it will be kinda "faulty" data. I release 5-20 times a day on my microservices and want to know over a longer time period. Guess this is nothing for me then =/
Would it be possible to implement the request duration as a middleware and group them by route?
Where is that metric data stored exactly?
Why try/finally instead of doing it as first line? You will have on-the-fly requests in metric, but no try{} block inserted...
The link isn’t in the description
I cannot unhear the intro as “Hello everybody, I’m naked…”
can't be sure if this built-in metric factory can replace prometheus-net's in-memory metric exporter or can be used together
Quick question, is there ever a chance that (even if not now, but maybe by the time we have .Net 9), the running code will try optimizing itself.
If it is waiting for the request, and it knows the discarded var is never used below, it might want to GC or Dispose is early.
Is there a way to know the lifetime of the disposed method will always be the full runtime of the method?
That behaviour is guaranteed to stay how it is. The point of IDisposable is to provide a deterministic point when your resources, whatever they may be, get disposed of.
Introducing any "optimizationa" like that would defeat the point of Dispose since it'd no longer be deterministic. Not to mention it'd be a giant breaking change, which Microsoft generally avoids.
The typo in the thumbnail 😭
I want to think, that it is intentional. :)
It’s 100% intentional (it’s not 🥲)
Just pretend it's for engagement baiting Nick
@@IIARROWS he fixed it
what about using appMetrices nuget package
is this code available in git ?
Check spelling in your thumbnail, though: "Corretly." :)
Can we do sth like this counter for all endpoints we have in the API? (Without adding code to each)
Yes you can do that with middleware
This new feature is very interesting! But, maybe it's me who doesn't understand well, is it weird to write code to have metrics that will be deployed in production?
You need metrics more in production than dev. In dev you can just debug.
But in a production environment you'd send these metrics, together with logs, to a single aggregate (most use Grafana) for storage. And then use (again most use Prometheus) to explore and visualize that data, for all your apps, in a single web interface.
Cab you pls share the source Code link.
Hello, can we calculate requests by user IP, header etc. Instead of total requests? So we can see how many requests per api user and by method based?Also , use it for distributed rate limiter. İnstead of using redis? Because current rate limiter does not allow distributed limitting.
Distributed rate limiting is a different beast to tame. You gotta track the requests overall (over many servers) which is a different concern and has other requirements then collecting and visualizing metrics.
@@EdubSi I mean asyncronus rate limiting with that endpoint consumpiton data.
Hello everybody, I’m naked and today I’m going to show you….😂 cracked me up had to replay it to see if you actually said it this time 😅
I've been waiting for something like for this a long time, can't wait to try it! Also, Merry Christmas!
I need help Nick. I'm working on this large project and the build times are debilitating. How can I debug/reduce build times?
Aspire will change the game for .NET
First!
Great!