fix: normalize label name to follow prometheus spec

[srikanthccv]

Summary

See the metrics labels section of https://prometheus.io/docs/concepts/data_model/#metric-names-and-labels. The valid label name doesn't allow any special characters other than _. This PR normalizes the label name so that alertmanager doesn't reject the alert sending.

Maybe TODO: SigNoz/alertmanager#22

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[ankitnayan]

Correct me if I am missing anything. There are 3 ways to solve this issue

1. Reject labels which do not comply with the above regex in the UI itself. But I guess, users do not control the value of labels and hence we cannot use this method? And if so, this would be huge problem in prometheus as users will have to be very cautious about the values they put in.
2. Convert non-supported chars to _ as done in this PR
3. Fix alertmanager to support the other chars. But I guess, the maintainers at Prometheus must have placed that restriction due to same reason. We should find that out before fixing at alertmanager

[srikanthccv]

Reject labels which do not comply with the above regex in the UI itself. But I guess, users do not control the value of labels and hence we cannot use this method? And if so, this would be huge problem in prometheus as users will have to be very cautious about the values they put in.

Convert non-supported chars to _ as done in this PR

We are only concerned with the the label key not the value. The value can be whatever users set. We are only normalizing the label key string. We cannot reject in the UI itself because users want to set alerts on logs/traces which currently have attribute keys/names with dots in them.

https://prometheus.io/docs/concepts/data_model/#metric-names-and-labels: Label values may contain any Unicode characters.

Fix alertmanager to support the other chars. But I guess, the maintainers at Prometheus must have placed that restriction due to same reason. We should find that out before fixing at alertmanager

Yes, I have opened a separate issue for that. The delivery of the alert is more important now. Eventually, we need to find a way to solve this issue.

[ankitnayan]

@srikanthccv will the url to the alert work fine?

[srikanthccv]

Yes, we are not changing anything in the URL. The URL is prepared (as of today) based on the query range payload not the result.