-
Notifications
You must be signed in to change notification settings - Fork 466
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Truncate HELP metadata on ingest #2993
Conversation
Currently we drop the HELP metadata and return a 400 error even though we ingest the related series. This is confusing and not very productive. Truncate the HELP instead. Ref: support escalation 3976 Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
pkg/util/validation/validate.go
Outdated
if cfg.EnforceMetadataMetricName(userID) && metadata.GetMetricFamilyName() == "" { | ||
DiscardedMetadata.WithLabelValues(reasonMissingMetricName, userID).Inc() | ||
return newMetadataMetricNameMissingError() | ||
} | ||
|
||
maxMetadataValueLength := cfg.MaxMetadataLength(userID) | ||
|
||
if len(metadata.Help) > maxMetadataValueLength { | ||
metadata.Help = metadata.Help[:maxMetadataValueLength] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HELP
can be any UTF-8 bytes. I think we run the risk of corrupting it by using slice operations like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a fix that does a for loop but still uses slicing to avoid allocating memory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it's a good idea to have this loop, plus we don't check if the input it utf-8 (I don't think), so maybe it's ok to just slice the string after all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what the loops solves. A bit of searching makes me think that "runes" are the right way to deal with this. That also matches what Prometheus does when dealing with exemplar labels. I don't feel particularly strongly about this but it seems prone to be an issue since HELP
text is where users are most likely to put multi-byte characters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
range
on strings works on runes, not bytes, so this loop finds index of last rune that can still be added to be within the size limit. It seems fine to me. I would keep it as-is, so that users don't get corrupted texts.
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
2ff344a
to
a14c0b7
Compare
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
What this PR does
Currently we drop the HELP metadata and return a 400 error even though we ingest the related series. This is confusing and not very productive.
Truncate the HELP instead.
Which issue(s) this PR fixes or relates to
Ref: support escalation 3976
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]