-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[FEATURE] adding otlp endpoint #7996
base: main
Are you sure you want to change the base?
[FEATURE] adding otlp endpoint #7996
Conversation
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
|
||
tenant, err := tenancy.GetTenantFromHTTP(r, h.options.TenantHeader, h.options.DefaultTenantID, h.options.TenantField) | ||
if err != nil { | ||
level.Error(h.logger).Log("msg", "error getting tenant from HTTP", "err", err) |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information High
Sensitive data returned by HTTP request headers
|
||
defer writeGate.Done() | ||
if err != nil { | ||
level.Error(tLogger).Log("err", err, "msg", "internal server error") |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information High
Sensitive data returned by HTTP request headers
case errBadReplica: | ||
responseStatusCode = http.StatusBadRequest | ||
default: | ||
level.Error(tLogger).Log("err", err, "msg", "internal server error") |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information High
Sensitive data returned by HTTP request headers
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
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.
Thanks for the efforts here! Looks good already. 🙂
I did recommend copying the translator struct over to use thanos protos natively instead of doing a full conversion, but it could be a maintenance burden.
Let's wait for other maintainers to have a look as well.
Couple of comments
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.
Thanks for starting this work @nicolastakashi ❤️, I'm adding a couple more suggestions
// Copyright (c) The Thanos Authors. | ||
// Licensed under the Apache License 2.0. | ||
|
||
// Provenance-includes-location: https://github.com/prometheus/prometheus/blob/318d6bc4bfe2d81af88697940740a378b503335a/storage/remote/otlptranslator/prometheusremotewrite/context.go#L18 |
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.
Just for my understanding, where are these provenance directives from? What does it mean? That the code is copied from Prometheus repo?
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 copy the code from prometheus and prometheus copied from OTel 😅
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
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.
Thanks! ❤️
This already looks quite good. @nicolastakashi we can probably mark it ready for review, and get others to have a look as well?
Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
Co-authored-by: Saswata Mukherjee <[email protected]> Signed-off-by: Nicolas Takashi <[email protected]>
Signed-off-by: Nicolas Takashi <[email protected]>
@@ -275,6 +277,18 @@ func NewHandler(logger log.Logger, o *Options) *Handler { | |||
), | |||
) | |||
|
|||
h.router.Post( |
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.
@saswatamcode just FYI use this endpoint naming will require users to use the metrics_endpoint
instead of endpoint
property, maybe worth document it or writing a blog post later about Thanos and OTLP wdyt?
Signed-off-by: Nicolas Takashi <[email protected]>
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 for working on this, this makes the project much more relevant in the whole Observability space.
That said, I am not a huge fan of the whole copying files over, but I am okay with it in name of optimization. The code for the handler looks good, I just wanted to see more core reuse in general (but not a problem to solve on this PR). We already have duplication because of Capn Proto ingestion and now also because of OTLP.
Once again, amazing work Nicolas! 💪
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.
Thanks again @nicolastakashi 🙌 , this is looking better with every pass.
I'm adding couple more suggestions to improve the parameters, I hope that's OK and doesn't add to much effort.
Two more things:
-
I think it would be good to have a separate documentation section to explain the OTLP endpoint and mainly to explain the behavior of resource attributes and how the parameters affect the ingested metrics / labels.
-
With regards to the translator code, I'm personally also leaning towards just importing instead of copying and all of the code, and then seeing if we need to copy the code over for further optimization. But it's not a strong position, if people see value in including this optimization from the get-go, I'm not opposed.
@@ -1052,6 +1056,9 @@ func (rc *receiveConfig) registerFlag(cmd extkingpin.FlagClause) { | |||
cmd.Flag("receive.limits-config-reload-timer", "Minimum amount of time to pass for the limit configuration to be reloaded. Helps to avoid excessive reloads."). | |||
Default("1s").Hidden().DurationVar(&rc.limitsConfigReloadTimer) | |||
|
|||
cmd.Flag("receive.otlp-disable-target-info", "Disable target information OTLP metrics ingested by Receive.").Default("false").BoolVar(&rc.otlpDisableTargetInfo) |
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.
Two suggestions:
- Maybe it would feel a bit more natural to make it a positive setting, i.e. make
receive.otlp-enable-target-info
(since that is also the default) - Describe what exactly enabling / disabling this means, something like
If enabled, converts the resource to the target info metric.
@@ -1052,6 +1056,9 @@ func (rc *receiveConfig) registerFlag(cmd extkingpin.FlagClause) { | |||
cmd.Flag("receive.limits-config-reload-timer", "Minimum amount of time to pass for the limit configuration to be reloaded. Helps to avoid excessive reloads."). | |||
Default("1s").Hidden().DurationVar(&rc.limitsConfigReloadTimer) | |||
|
|||
cmd.Flag("receive.otlp-disable-target-info", "Disable target information OTLP metrics ingested by Receive.").Default("false").BoolVar(&rc.otlpDisableTargetInfo) | |||
cmd.Flag("receive.otlp-resource-attributes", "(Repeatable) Resource attributes to include in OTLP metrics ingested by Receive.").Default("").StringsVar(&rc.otlpResourceAttributes) |
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.
On second look, this might be a little confusing - this should indicate which resource attributes should be used as metric labels, correct? Maybe we could retain the original parameter name, something like receive.otlp-promote-resource-attributes
?
Changes
Verification