That's a different use case than that's served by ASP.NET's health checks. ASP.NET Health checks can be used at an application-level monitoring than infrastructure. If your infrastructure is down, you will know when you hit it. In which case, you can do an HTTP monitoring (which pings your server and returns a result - much like you hitting a remote endpoint and seeing that server is down etc.).
The solution really depends on your infrastructure setup. Some options I could think of off the top of my head.
In local env, check IIS logs in inetmgr to figure out what's going on. Or you can take out the Monitor project and host in Kerstel rather than running IIS. That way, if your services are unreachable, you'll know that IIS is also down.
If in a hosted env, like Azure
If using a load balancer, you could set up health checks to probe if it can ping
If using VMs, you can do the health checks with VMSS
Using Azure Monitor and Log Analytics
As I mentioned in the article, I would prefer to use ASP.NET Health Checks in the local development environment to get an idea of how the services are running quickly.
I am a Full stack .NET Developer, I like to work with C#, Asp.Net Core, SQL, Mongo DB, Azure, JavaScript...
Always eager to learn new technologies. I am here to share, ask & eventually learn.
Thanks for detailed explanation. So what is the use case of health checks in Asp.Net Core ? Just to check status between services hosted in a single IIS server ?
You can use to check if your app can connect to a database as well. Plus you can write custom checks for other things such as external apis for example. I think it's a very easy way to check critical things in your app are working OK.
@shaijut
It doesn't necessarily have to be on IIS. They can be distributed across many hosting servers, PaaS offerings like App Service etc. Better to think of it in the context of running many applications rather than infrastructure. As @gustavobmichel
already mentioned you can monitor the status of many different services depending on your use case.
Check out this full list of health checks available:
Thanks for your comment :)
That's a different use case than that's served by ASP.NET's health checks. ASP.NET Health checks can be used at an application-level monitoring than infrastructure. If your infrastructure is down, you will know when you hit it. In which case, you can do an HTTP monitoring (which pings your server and returns a result - much like you hitting a remote endpoint and seeing that server is down etc.).
The solution really depends on your infrastructure setup. Some options I could think of off the top of my head.
In local env, check IIS logs in
inetmgr
to figure out what's going on. Or you can take out the Monitor project and host in Kerstel rather than running IIS. That way, if your services are unreachable, you'll know that IIS is also down.If in a hosted env, like Azure
As I mentioned in the article, I would prefer to use ASP.NET Health Checks in the local development environment to get an idea of how the services are running quickly.
Thanks for detailed explanation. So what is the use case of health checks in
Asp.Net Core
? Just to check status between services hosted in a singleIIS
server ?You can use to check if your app can connect to a database as well. Plus you can write custom checks for other things such as external apis for example. I think it's a very easy way to check critical things in your app are working OK.
@shaijut It doesn't necessarily have to be on IIS. They can be distributed across many hosting servers, PaaS offerings like App Service etc. Better to think of it in the context of running many applications rather than infrastructure. As @gustavobmichel already mentioned you can monitor the status of many different services depending on your use case.
Check out this full list of health checks available:
github.com/Xabaril/AspNetCore.Diag...
Hope this helps to clarify it.