Rename azure storage metricset to storage_account

[narph]

There are some inconsistencies when it comes to the storage and the database_account metricset naming.
They both support database account and storage account resource types, so we should follow one notation when considering these 2 metricsets.
I suggest renaming storage to storage_account, this way we are more consistent to the rest of the metricsets as well, not only database_account.
@sorantis , @andresrc what do you think?

[elasticmachine]

Pinging @elastic/integrations-platforms (Team:Platforms)

[andresrc]

I agree, but I would leave the module as is and do it in the package.

[sorantis]

@narph agree with the change with a minor adjustment: storage_accounts to make it more consistent with the namespace name.
Also agree with @andresrc, let's not change the modules anymore and implement such naming changes in the packages.

In general, should we consider a broader scope for Azure metricset names? I'm considering the option to align the names with the original namespaces, e.g.

• Microsoft.Storage/storageAccounts -> storage_accounts
• Microsoft.Compute/virtualMachines -> virtual_machines
• Microsoft.Compute/virtualMachineScaleSets -> virtual_machine_scale_sets
• etc.

This way will remove the need to have a custom naming convention and make it also simpler for other to contribute with additional metricsets. Thoughts?

[narph]

@sorantis , I do not have a strong opinion regarding this, each monitor related metricset collects metrics from only one resource type atm.
Few things to think about:

• we might run into the situation of monitoring namespaces as Microsoft.EventHub/clusters , Microsoft.HDInsight/clusters, Microsoft.Kusto/Clusters for this we would have to chose a naming based on the resource type ex eventhub_cluster (many other cases apply here) so the namespace clusters will not be clear enough to name the metricset.

I do agree if the namespace is clear enough then we should use it as is, but we should also consider the type of the resource we are monitoring.

• regarding the plural form, I didn't find much consistency with the rest of the modules/metricsets besides maybe stats but the rest used the singular form.

[sorantis]

That's true, such cases will exist and will need custom naming. I see those as exceptions from the general rule.

The plural form with this specific case of storage_accounts stemmed from the namespace name itself, no other reason :)

[narph]

discussed