-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Add Google Pubsub exporter for OTLP messages - PR1 #3551
Add Google Pubsub exporter for OTLP messages - PR1 #3551
Conversation
9a3779a
to
3e62e58
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.
Add CODEOWNERS entry, re-run make gendependabot
3e62e58
to
bda55f2
Compare
I'm confused, do I need to add myself to the CODEOWNERS? or add @punya @dashpole as codeowners... I'm happy to set myself, but it feels weird to set myself for the initial reviews. If it's created up, I'll add the remarks to the CONTRIBUTING files (as it's not clear to me) |
bda55f2
to
a9a9638
Compare
Rebased, squached and added me to code owners, and added ependabot |
We're using this within our company (Collibra) for about half a year now, and it's been battle-tested. Bumping almost every release. The plan is to keep it up-to-date. (as well as: #3552 ). This would also be a testing ground from : open-telemetry/oteps#157 |
@alexvanboxel, thank you for building, testing and contributing this! We (GCP) would prefer if this exporter continues to be maintained by @alexvanboxel and the OTel community. I'll add a comment to the README suggesting a notice that clarifies ownership and support expectations. |
Comments about community module added, note that following the guidelines the implementation and the switch are upcoming |
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.
@punya please still review :)
// Override of the Pubsub endpoint | ||
Endpoint string `mapstructure:"endpoint"` | ||
// Only has effect if Endpoint is not "" | ||
UseInsecure bool `mapstructure:"use_insecure"` |
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.
Be consistent with other places where we use insecure
https://github.com/open-telemetry/opentelemetry-collector/blob/1f7c6618070197a7818371e747de4e0d61cbc9d9/config/configtls/configtls.go#L54
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.
Tried to be consistent with the Google exporter:
UseInsecure bool `mapstructure:"use_insecure"` |
But switch to insecure
func (ex *pubsubExporter) ConsumeTraces(ctx context.Context, td pdata.Traces) error { | ||
return nil | ||
} | ||
|
||
func (ex *pubsubExporter) ConsumeMetrics(ctx context.Context, td pdata.Metrics) error { | ||
return nil | ||
} | ||
|
||
func (ex *pubsubExporter) ConsumeLogs(ctx context.Context, td pdata.Logs) error { | ||
return nil | ||
} |
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.
They don't need to be "exported" since you use only reference can be called pushTraces
.
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.
Changed, as well as shutdown/start
|
||
const name = "googlecloudpubsub" | ||
|
||
// pubsubExporter is a wrapper struct of OT cloud trace exporter |
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.
Is this comment accurate? I don't see any dependencies on the OT cloud trace exporter, will they be introduced in a future PR?
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.
Oeps, removed comment. Old comment, from the start of the implementation
exporterhelper.WithLogs(createLogsExporter)) | ||
} | ||
|
||
var exporters = map[config.Exporter]*pubsubExporter{} |
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.
Could you add some comments explaining why this global mutable state is necessary? Based on a spot check, I didn't see such a pattern used in other exporters.
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.
A lot of exporter/receivers have other endpoints to send data to/from. Here everything is piped over a single pubsub topic/subscription so there is a need to reuse the same connection.
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.
var exporters = map[config.Exporter]*pubsubExporter{} | |
// This map allows multiple exporter instances to be multiplexed over the same PubSub connection. | |
// It is initialized at process startup and read-only afterwards, so we don't need to guard it for concurrent access. | |
var exporters = map[*Config]*pubsubExporter{} |
I also suggest changing the map key type to the concrete type that we care about rather than an interface, because that documents the intent better.
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 don't have this for exporters, only problem is for components that need to share the same port/endpoint across traces/logs/metrics, so don't think you need 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.
- It originally was the concrete type but making it the interface removed the need to cast at that point
- Yes, the exporter joins the same topic, so the same gRPC connection to Pubsub
Note: this rule of splitting a PR into different phases makes it really annoying to contribute a new module. I have the full implementation working for more than half a year, but now have to retrofit all the comments back in that implementation hoping I don't do mistakes, and then merge that back for PR2 (the implementation). Having the implementation already available at the initial commit would make reviewing also easier. Just my 2 cents.
a58f06e
to
14a459b
Compare
81ab5c4
to
3099356
Compare
Rebased to the latest main and squashed everything as a lot of changes were required. I think all concerns in the comments are addressed. |
3099356
to
631a67d
Compare
Signed-off-by: Bogdan Drutu <[email protected]>
Description:
Add the skeleton for Google Pubsub exporter for OTLP messages. The export is able to send OTEP messages to a Google Pubsub topic.
This exporter is the 2nd rewrite following feedback from the community on the original PR ( #1892 ), and also implements feedback given in the OTLP/Messaging otep:
open-telemetry/oteps#157
PR1 as described in the CONTRIBUTING guide only the README, config, and factory.
Link to tracking Issue:
#1802
Testing:
Tests for config and factory
Documentation:
Up-to-date README