Support for specifying sub/server type in resource discovery

Proposal

I implemented the MySQL resource type a while ago, and while not a huge issue it is a bit annoying to see: The metric 'cpu_credits_remaining' was not found.

The reason for these errors is that metrics available differs from MySQL Single and Flexible servers. The same is true for PostgreSQL as well.

Currently there is no way, as far as I know, to filter resource discovery group on a server type / sub type of a resource type. This would be nice to have for these use cases, and probably others.

I might have time to implement this myself, but would like some implementation direction in that case.

Possible declerations, depending on implementation.

Filter in resource discovery:

version: v1
azureLandscape:
  tenantId: 00000000-0000-0000-0000-000000000000
  subscriptions:
    - 00000000-0000-0000-0000-000000000000
  cloud: Global
resourceDiscoveryGroups:
  - name: azure_mysql_single
    type: MySql
    subType: Single
  - name: azure_mysql_flexible
    type: MySql
    subType: Flexible

Filter in metric decleration:

  - name: azure_mysql_cpu_credits_remaining
    description: "CPU credits remaining"
    resourceType: MySql
    azureMetricConfiguration:
      metricName: cpu_credits_remaining
      aggregation:
        type: Average
        interval: 00:15:00
    resourceDiscoveryGroups:
      - name: azure_mysql
         subType: Flexible

Component

Resource Discovery

Contact Details

No response

[MattiasAng]

I should be able to contribute this, C# skills are not the best but we’ll see.

Which of the alternative would you say is the best way to go? The second alternative (filtering in metric deceleration) would be quite nice otherwise there will be a lot of duplication in metric decelerations for these resources.

[tomkerkhove]

How do we handle it on the Resource Discovery API side if we want to have the “sub type” to be specific for each resource?

The API should be good, it’s how it is being configured and serialized/deserialized. You can learn more in the scraper on how it gets the metrics.

And secondly, I am trying to find where it would be best to filter the result of the query. My thought that we would still query resource graph for all resources regardless of specified “sub type” in resourceDiscoveryGroups and then filter afterwards.

We should filter this in the resource graph though. We already have query builders per type so have to plug in the new properties and use them there as well. Otherwise we’ll be pulling too much data and make too many calls.