315
CHAPTER 7 | Implement resilient applications
var
hcBuilder = services.
AddHealthChecks
();
hcBuilder
.
AddSqlServer
(
configuration[
"ConnectionString"
],
name:
"CatalogDB-check"
,
tags:
new
string
[] {
"catalogdb"
});
if
(!
string
.
IsNullOrEmpty
(accountName) && !
string
.
IsNullOrEmpty
(accountKey))
{
hcBuilder
.
AddAzureBlobStorage
(
$
"DefaultEndpointsProtocol=https;AccountName={accountName};AccountKey={accountKey};Endpoint
Suffix=core.windows.net"
,
name:
"catalog-storage-check"
,
tags:
new
string
[] {
"catalogstorage"
});
}
if
(configuration.
GetValue
<
bool
>(
"AzureServiceBusEnabled"
))
{
hcBuilder
.
AddAzureServiceBusTopic
(
configuration[
"EventBusConnection"
],
topicName:
"eshop_event_bus"
,
name:
"catalog-servicebus-check"
,
tags:
new
string
[] {
"servicebus"
});
}
else
{
hcBuilder
.
AddRabbitMQ
(
$
"amqp://{configuration["
EventBusConnection
"]}"
,
name:
"catalog-rabbitmqbus-check"
,
tags:
new
string
[] {
"rabbitmqbus"
});
}
return
services;
}
Finally, add the HealthCheck middleware to listen to “/hc” endpoint:
// HealthCheck middleware
app.
UseHealthChecks
(
"/hc"
,
new
HealthCheckOptions
()
{
Predicate = _ =>
true
,
ResponseWriter = UIResponseWriter.
WriteHealthCheckUIResponse
});
Query your microservices to report about their health status
When you’ve configured
health checks as described in this article and you have the microservice
running in Docker, you can directly check from a browser if it’s healthy. You have to publish the
container port
in the Docker host, so you can access the container through the external Docker host IP
or through
host.docker.internal
, as shown in figure 8-8.
316
CHAPTER 7 | Implement resilient applications
Figure 8-8. Checking health status of a single service from a browser
In that test, you can see that the
Catalog.API
microservice (running on port 5101)
is healthy,
returning HTTP status 200 and status information in JSON. The service also checked the health of its
SQL Server database dependency and RabbitMQ, so the health check reported itself as healthy.
Use watchdogs
A watchdog is a separate service that can watch health and
load across services, and report health
about the microservices by querying with the
HealthChecks
library introduced earlier. This can help
prevent errors that would not be detected based on the view of a single service. Watchdogs also are a
good place to host code that can perform remediation actions for known conditions
without user
interaction.
The eShopOnContainers sample contains a web page that displays sample health check reports, as
shown in Figure 8-9. This is the simplest watchdog you could have since it only shows the state of the
microservices and web applications in eShopOnContainers. Usually a
watchdog also takes actions
when it detects unhealthy states.
Fortunately,
AspNetCore.Diagnostics.HealthChecks
also provides
AspNetCore.HealthChecks.UI
NuGet
package that can be used to display the health check results from the configured URIs.
317
CHAPTER 7 | Implement resilient applications
Figure 8-9. Sample health check report in eShopOnContainers
In summary, this watchdog service queries each microservice’s “/hc” end
point. This will execute all the
health checks defined within it and return an overall health state depending on all those checks. The
HealthChecksUI is easy to consume with a few configuration entries and two lines of code that needs
to be
added into the
Startup.cs
of the watchdog service.
Sample configuration file for health check UI:
Dostları ilə paylaş: