Are metric APIs expected to validate instrument names?

[MrAlias]

The current metric API specification declares the following for instrument names:

Instrument naming rule

Instrument names MUST conform to the following syntax (described using the Augmented Backus-Naur Form):

instrument-name = ALPHA 0*62 ("_" / "." / "-" / ALPHA / DIGIT)

ALPHA = %x41-5A / %x61-7A; A-Z / a-z
DIGIT = %x30-39 ; 0-9

• They are not null or empty strings.
• They are case-insensitive, ASCII strings.
• The first character must be an alphabetic character.
• Subsequent characters must belong to the alphanumeric characters, '_', '.',
  and '-'.
• They can have a maximum length of 63 characters.

It does not however define how the API should treat the instrument name. As a contrast both the instrument unit and description are define such that they "MUST be treated as an opaque string from the API and SDK."

Should the instrument names not be validated by the API? Should the naming rule section be updated to include the following statement?

The API MUST treat instrument names as opaque strings.

Or, are APIs expected to be structured such that instrument names are validated by the API?

[jack-berg]

For what its worth, the java implementation validates metric name and unit. Our APIs are just a set of interfaces, so the way we do this by having the validation embedded in both the default noop implementation and the SDK implementation:

• When implementation is noop we log warnings if name or unit is invalid.
• When implementation is the SDK:
  • If name is invalid we log a warning and return a noop instrument.
  • If unit is invalid we log a warning, ignore the invalid unit, and return a functional instrument.

[MrAlias]

For what its worth, the java implementation validates metric name and unit. Our APIs are just a set of interfaces, so the way we do this by having the validation embedded in both the default noop implementation and the SDK implementation:

• When implementation is noop we log warnings if name or unit is invalid.

• When implementation is the SDK:

  • If name is invalid we log a warning and return a noop instrument.
  • If unit is invalid we log a warning, ignore the invalid unit, and return a functional instrument.

Gotcha, thanks for the data point. 👍

Go also validates names as the SDK level as well, not the API currently. I don't think we do it in our no-op implementation, and that might be a mistake on our part. I think this further points out the need for the specification to be updated and clarify where the validation needs to happen.

[jmacd]

My opinion is that the SDK should have this responsibility, not the API. In particular, I would not like to see a no-op implementation perform validation.