-
Notifications
You must be signed in to change notification settings - Fork 71
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
Clean up configuration generation for otel configs. #145
Clean up configuration generation for otel configs. #145
Conversation
d23609a
to
12bf723
Compare
…l's Stackdriver into the otel.Exporter interface. Use the otel.Processor and otel.Exporter interfaces instead of the processor/exporter name maps.
d2ffcfd
to
903c862
Compare
I rebased this on |
I finished the work from Friday to make otel config generation completely modular. The diff is now Please review, @davidbtucker |
c910356
to
b24888f
Compare
b24888f
to
1880902
Compare
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.
First round of comments.
Version string | ||
} | ||
|
||
func (r MetricsReceiverAgent) Pipeline() otel.Pipeline { |
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.
Possibly *otel.Pipeline
.
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.
No, I don't think there's any reason to pass by reference (and if we do, that brings up the possibility of accidentally changing the struct)
aac139d
to
9d963e1
Compare
I just pushed a couple commits to make the golden file diffs smaller. Here's a command you can use to diff them:
|
type Metrics struct { | ||
Receivers metricsReceiverMap `yaml:"receivers" validate:"dive,keys,startsnotwith=lib:"` | ||
Processors metricsProcessorMap `yaml:"processors" validate:"dive,keys,startsnotwith=lib:"` | ||
// Exporters are deprecated and ignored, so do not have any validation. | ||
Exporters metricsExporterMap `yaml:"exporters,omitempty"` | ||
Service *MetricsService `yaml:"service"` | ||
Exporters map[string]interface{} `yaml:"exporters,omitempty"` |
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.
We will now allow arbitrary YAML in the exporters
field, and it's completely unvalidated. Is this where we want to be with respect to customer configs? Or do we want to restrict what they put in there before we ignore it?
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.
We already dropped validation on this field, both partially before and now even more. It's a lot of work to maintain validation on a field that's already ignored and deprecated. Anyone who is specifying this field has been doing it since pre-2.0, so they already had a chance to get the field validated. I don't think it's worth the effort to maintain unused validation.
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
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. Integration tests passed: http://b/195762251#comment4
stackdriverList = append(stackdriverList, &stackdriver) | ||
exportNameMap[eID] = "googlecloud/" + eID | ||
for i, receiverPipeline := range receiver.Pipelines() { | ||
prefix := fmt.Sprintf("%s_%s", strings.ReplaceAll(pID, "_", "__"), strings.ReplaceAll(rID, "_", "__")) |
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 curious: what is the reason behind replacing _
with __
? The resulting prefix looks like:
agentmetrics/default__pipeline_hostmetrics_0
If the purpose is to make them look grouped, shouldn't it be
agentmetrics/default_pipeline__hostmetrics__0
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.
Replacing _
with __
prevents collisions between different pipelines. If we went the other direction, there would be no way to distinguish between (pipeline default__pipeline
receiver hostmetrics
) and (pipeline default
receiver pipeline__hostmetrics
).
We could certainly introduce smarter anti-collision logic though (e.g. default to the bare pipeline name and add suffixes only when there would be a collision). But I'd like to save that for later PRs.
@@ -44,7 +44,7 @@ func (c Component) name(suffix string) string { | |||
return c.Type | |||
} | |||
|
|||
// configToYaml converts a tree of structss into a YAML file. | |||
// configToYaml converts a tree of structs into a YAML file. |
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.
LOL
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.
My MBP keyboard introduces spurious s
keypresses all over the place :(
Extracted from #141.