Add support for Azure Storage Queue

[developerxnz]

Add support to access Storage Queue Message Count using the azure go sdk.

[tomkerkhove]

This is actually already supported - https://github.com/Azure/azure-k8s-metrics-adapter#external-metrics.

Every metric that is available in Azure Monitor, is waiting for you to use!

[jsturtevant]

I thought the same initially but I have found that there are edge cases on how each metric is reported to Azure Monitor. In this case, Azure Storage only reports the queue Capacity Metrics every 24 hours. I tested this to confirm it and found that for the first day I did not get any Queue message counts, The second day I had the counts.

This makes the Azure Monitor metric not very useful in this use case. In addition, the metric reported to Azure Monitor by Azure Storage Queue's is total messages across all queues and doesn't currently support dimensions for per queue metrics.

To enable this will need to create a way to use a different api endpoint via the go SDK. It does look like we can get the QueueMessage Count through the SDK.

I am currently thinking we modify the ExternalMetric CRD to have a type that can override the type of api endpoint we want to query. This way we could have an ExternalMetric that uses Azure Monitor, Storage Queue, or any other one that comes up with a limitation like this.

[tomkerkhove]

Too bad but makes sense to me! Will the schema be different based on that type? Otherwise, would it make sense to create a new CRD instead? Tom Kerkhove Azure Architect at Codit, Microsoft Azure MVP

…

________________________________ From: James Sturtevant <notifications@github.com> Sent: Thursday, October 11, 2018 7:31:47 PM To: Azure/azure-k8s-metrics-adapter Cc: Tom Kerkhove; Comment Subject: Re: [Azure/azure-k8s-metrics-adapter] Add support for Azure Storage Queue (#39) I thought the same initially but I have found that there are edge cases on how each metric is reported to Azure Monitor. In this case, Azure Storage only reports the queue Capacity Metrics every 24 hours<https://docs.microsoft.com/en-us/azure/storage/common/storage-metrics-in-azure-monitor?toc=%2fazure%2fstorage%2fqueues%2ftoc.json#capacity-metrics>. I tested this to confirm it and found that for the first day I did not get any Queue message counts, The second day I had the counts. This makes the Azure Monitor metric not very useful in this use case. In addition, the metric reported to Azure Monitor by Azure Storage Queue's is total messages across all queues and doesn't currently support dimensions for per queue metrics<https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-supported-metrics#microsoftstoragestorageaccountsqueueservices>. To enable this will need to create a way to use a different api endpoint via the go SDK. It does look like we can get the QueueMessage Count through the SDK<https://godoc.org/github.com/Azure/azure-sdk-for-go/storage#Queue>. I am currently thinking we modify the ExternalMetric CRD<https://github.com/Azure/azure-k8s-metrics-adapter/blob/master/samples/resources/externalmetric-example.yaml> to have a type that can override the type of api endpoint we want to query. This way we could have an ExternalMetric that uses Azure Monitor, Storage Queue, or any other one that comes up with a limitation like this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#39 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEJPP7CVGvjgPiUoZtmWQ4gZE6O1aFglks5uj4CDgaJpZM4XW4FA>.

[jsturtevant]

I am planning on re-using the same ExternalMetric CRD with a property that will tell us the type and use a different schema based on each type. I think having too many CRD types will get confusing and is harder to maintain in the code. It would look something like:

apiVersion: azure.com/v1alpha2
kind: ExternalMetric
metadata:
  name: example-external-metric-sb
spec:
  type: azuremonitor
  config:
    azure:
      resourceGroup: sb-external-example
      resourceName: sb-external-ns
      resourceProviderNamespace: Microsoft.ServiceBus
      resourceType: namespaces
    metric:
      metricName: Messages
      aggregation: Total
      filter: EntityName eq 'externalq'

or

apiVersion: azure.com/v1alpha2
kind: ExternalMetric
metadata:
  name: example-external-metric-sb
spec:
  type: storagequeue
  config:
    queuename: test1
    resourcegroup: storage-rg

I am not sure what config is nessary for the storage queue example currently but that give you a sense of what I am thinking.

[tomkerkhove]

Would it make sense to rename azuremonitor to generic?

This feels similar to Promitor's Service Bus Queue scraping & generic scraping where there are more convenient and simple configs but also more advanced in case there is a need.

[developerxnz]

The example code I was using to access the storage queue only requires the storage account name, the queue name and the connection string.

e.g.
`u, _ := url.Parse(fmt.Sprintf("https://%s.queue.core.windows.net/%s", c.storageaccountname, c.queueName))'

`queueURL := azqueue.NewQueueURL(*u, azqueue.NewPipeline(azqueue.NewSharedKeyCredential(c.storageaccountname, c.accountKey), azqueue.PipelineOptions{}))`

[brobichaud]

Has any progress been made on this issue? I am in need of horizontal pod scaling based on azure storage queue depth.

[jsturtevant]

@brobichaud You should now check out the KEDA project for future work. Specifically storage queues are supported.

[brobichaud]

@jsturtevant yeah I have taken a look at KEDA and it does go a bit further but is truly event driven. Meaning it would create a new pod for every message that appears in the queue, I need a more chunky approach, to which I've given them feedback.

That said, are you indicating that this component is likely end-of-life? And thus I should not expect any movement?