Azure Queue Storage
This health check verifies the ability to communicate with Azure Queue Storage. It uses the provided QueueServiceClient to get first queue or configured queues properties.
Installation
Defaults
By default, the QueueServiceClient
instance is resolved from service provider. AzureQueueStorageHealthCheckOptions
does not provide any specific queue name, so the health check fetches just first queue.
Customization
You can additionally add the following parameters:
clientFactory
: A factory method to provideQueueServiceClient
instance.optionsFactory
: A factory method to provideAzureQueueStorageHealthCheckOptions
instance. It allows to specify the queue name.name
: The health check name. The default isazure_queue_storage
.failureStatus
: TheHealthStatus
that should be reported when the health check fails. Default isHealthStatus.Unhealthy
.tags
: A list of tags that can be used to filter sets of health checks.timeout
: ASystem.TimeSpan
representing the timeout of the check.
Breaking changes
In the prior releases, AzureQueueStorageHealthCheck
was a part of Pulse.AzureStorage
package. It had a dependency on not just Azure.Storage.Queues
, but also Azure.Storage.Files.Shares
and Azure.Storage.Blobs
. The packages have been split to avoid bringing unnecessary dependencies. Moreover, AzureQueueStorageHealthCheck
was letting the users specify how QueueServiceClient
should be created (from raw connection string or an endpoint with managed identity credentials), at a cost of maintaining an internal, static client instances cache. Now the type does not create client instances nor maintain an internal cache and it’s the caller responsibility to provide the instance of ShareServiceClient
(please see #2040 for more details). Since Azure SDK recommends treating clients as singletons
Was this page helpful?