Reputation: 6450
So when developing an app utilizing Azure Storage Queues and a Web Job, I feel like I need some sort of health check (via API) to ensure my Azure Storage Queue is properly configured for each environment up to prod. I don't have access (directly) to view the Dashboard or Kudu.
My thought thus far was to just create an API route that returns a bool that tells me if I was able to create the queue if it doesn't exist, and peek at a message (even if one doesn't exist), like :
public async Task<bool> StorageQueueHealthCheck()
{
return await _queueManager.HealthCheck();
}
And the implementation:
public async Task<bool> HealthCheck()
{
try
{
CloudQueue queue = _queueClient.GetQueueReference(QueueNames.reportingQueue);
queue.CreateIfNotExists();
CloudQueueMessage peek = await queue.PeekMessageAsync();
return true; // as long as we were able to peek at messages
}
catch (Exception ex)
{
return false;
}
}
Is this a bad approach? Is there another way to "health check" certain Azure functionality when the dashboard is abstracted away? If I absolutely needed I would be able to view the Kudu but would rather just use an API and hit it via Swagger.
Upvotes: 0
Views: 2395
Reputation: 1263
This is a good approach, please just make sure you do have a retry mechanism so that your healthcheck does not just return false for intermittent failures.
Second Approach, Instead of api which will perform the job only is trigger there should be a console app (webjob) which does this task on regular interval (1min) and based on some logic lets say all 'creates' in last 10mins threw error sends an email. This can be used in all environments.
Upvotes: 1
Reputation: 6467
Looks good. You can also try CloudQueue.FetchAttributeAsync() since the payload would be smaller when the message size is large.
Upvotes: 1