Would it be helpful to make the metric name optional?

[salehabbas]

Hello Team,

I would appreciate your feedback about a little suggestion, please. While trying Promitor (with Prometheus), I can see that the Metric Name is a required field. Would it helpful to make it optional and automatically construct the metric name for Prometheus sink as follow:

<azure>_<short_resource_name>_<azureMetricConfiguration.metricName>_<azureMetricConfiguration.aggregation.type> 

An example for clarification:
The metric name will be optional and is: azure_agw_backend_response_status_total

And the metric definition is:

  - description: "Count of HTTP response status codes returned by the backends. This does not include any response codes generated by the Application Gateway"
    resourceType: ApplicationGateway
    azureMetricConfiguration:
      metricName: BackendResponseStatus
      aggregation:
        type: Total
    resourceDiscoveryGroups:
      - name: application-gateway-landscape

Just wanted to see if it's worth it and maybe I can work on a PR.

[tomkerkhove]

That's an interesting idea. If we support this, I think the pattern should be configurable where tokens can be used to define what goes where. For example, I don't think everyone wants to have azure_ as a prefix.

In terms of the short name, that is something you'd expect that we define then or not?

If would not limit it to Prometheus though, but support StatsD as well since it is applicable there, but we would need to have validation and enforce the metric name if an unsupported sink is being used.

[salehabbas]

Thanks for your prompt answer, @tomkerkhove. Please find my thoughts below.

That's an interesting idea

I got the idea from the Prometheus CloudWatch exporter as I am using it and I like how the metrics are named automatically as I had explained.

If we support this, I think the pattern should be configurable where tokens can be used to define what goes where. For example, I don't think everyone wants to have azure_ as a prefix

That makes sense! I believe it will be fine to have azure_ as a prefix but totally makes sense to make it configurable in case users wants to drop that prefix.

In terms of the short name, that is something you'd expect that we define then or not?

Exactly! Those values will be defined only by us. For every resource that promitor supports.

If would not limit it to Prometheus though, but support StatsD as well since it is applicable there, but we would need to have validation and enforce the metric name if an unsupported sink is being used.

Totally makes sense! I just mentioned Prometheus as I think this naming convention I am suggestion is kind of matching the best practices for the Prometheus Metric names too but not sure about StatsD (I will have a look)

[tomkerkhove]

Sounds good, I will open an issue to track this and will see how fast this lands.

[tomkerkhove]

Feature request is open on #1614, marking as answered for now.

[salehabbas]

Thanks @tomkerkhove!