Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate naming #310

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

PericlesTheo
Copy link

馃憢 everyone,

Related to #292 I've opened an MR that validates the naming expectations of Prometheus before sending the event.

I'm returning false for now but I am open to ideas as to the best way to handle this.

@@ -128,6 +130,8 @@ def find_registered_metric(name, type: nil, help: nil)
end

def send_json(obj)
return false unless valid_naming?(obj)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we raise instead? Otherwise the error would be pretty silent.

Also I am wondering if could be done somewhere else to avoid extra check on every send_json. For example when the metric is setup?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My initial thought was to add it in RemoteMetric as such

class RemoteMetric
  def valid?
     # ...
   end
end

But that doesn't cover the custom labels passed to the instance methods of RemoteMetric nor the global custom_labels.

Where were you thinking it would be a nice place?

About the error, I'm not sure 馃 My initial thoughts were:

  • Let's say you are using something like Sentry. You can flood your account with error events quite easily.
  • Is it better to have an app crashing in the middle because of metrics?

But I'm up for discussing this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And lastly, one can call send_json directly I think so the MR was safeguarding against that as well.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct. I think your change is the way to go.

@SamSaffron
Copy link
Member

this is a massive behavior change that is breaking, maybe we make this optional default off?

@PericlesTheo
Copy link
Author

PericlesTheo commented May 4, 2024

Hey @SamSaffron, how/where do you suggest we do this?

Would an optional argument in lib/prometheus_exporter/client.rb work?

module PrometheusExporter
  class Client
    def initialize(..., validate_metric_naming: false)
    end
  end
end

If we go with an approach like that, should we raise an error when the naming is invalid instead of returning false as the PR currently suggests since it's now an explicit decision from the developer?

An alternative, that might be an okay middle-ground, is to have a custom metric such as "invalid_naming" or something similar, with the label value of the failed naming. This can remove the decision making from the gem on how to proceed in the cases of errors. Developers can then have an alert on the "invalid_naming" metric and act upon.

Personally, it also satisfies the two concerns I raised here about raising an error (also returning false has the inverse concerns)

About the error, I'm not sure 馃 My initial thoughts were:

  • Let's say you are using something like Sentry. You can flood your account with error events quite easily.
  • Is it better to have an app crashing in the middle because of metrics?

The first one is obvious as no errors will be raised. As for the second, I doubt the cardinality of the label value (invalid name) is going to be an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants