-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
feat(outputs.nats): Introduce NATS Jetstream option #14236
Conversation
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 PR! I have added some initial high-level questions.
Additionally, please resolve the test issues:
plugins/outputs/nats/nats.go:124:29 revive unused-parameter: parameter 'stream' seems to be unused, consider removing or renaming it as _
plugins/outputs/nats/nats.go:124:29 unparam `(*NATS).createStream` - `stream` is unused
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.
Thank you for the updates! I think if we can get the config cleaned up, we are nearly there.
Thanks again!
plugins/outputs/nats/sample.conf
Outdated
## Jetstream specific configuration. If specified, telegraf will use Jetstream to publish messages | ||
# [outputs.nats.jetstream] | ||
## Specifies whether telegraf should create the stream at the startup or not. It will only create if it doesn't exist. | ||
# auto_create_stream = true |
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.
This default value is missing from the init
or Init
methods, so default currently is false
instead of true
.
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.
reworked the logic. can you go through it again?
631cedb
to
7b876c6
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.
Thanks for the large update! I have a couple suggestions to clean up the config and I want to chat with the other maintainer about the use of the TOML parser in the plugin. Otherwise, this looks great.
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.
looks good, still have a look at the linters as they still fail.
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 driving this!
I rebased on master and cleaned up the one lint issue.
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.
@neelayu thanks for the nice contribution. I do have some comments...
plugins/outputs/nats/nats.go
Outdated
if err != nil { | ||
return fmt.Errorf("failed to create or update stream: %w", err) | ||
} | ||
n.Log.Infof("stream (%s) successfully created or updated", n.Jetstream.Name) |
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.
Shouldn't this be a debug message? In any case it should start with an uppercase letter...
plugins/outputs/nats/nats.go
Outdated
func (n *NATS) convertToJetstreamConfig(streamConfig *jetstream.StreamConfig) { | ||
telegrafStreamConfig := reflect.ValueOf(n.Jetstream).Elem() | ||
natsStreamConfig := reflect.ValueOf(streamConfig).Elem() | ||
for i := 0; i < telegrafStreamConfig.NumField(); i++ { | ||
destField := natsStreamConfig.FieldByName(telegrafStreamConfig.Type().Field(i).Name) | ||
if destField.IsValid() && destField.CanSet() { | ||
destField.Set(telegrafStreamConfig.Field(i)) | ||
} | ||
} | ||
} |
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.
This has footgun potential as you circumvent Golangs type-checking. If for example one field is removed upstream (or the type is changed) you silently will ignore the Telegraf setting and nobody will notice until some unexpected behavior happens. I really would feel better if we explicitly set the config-fields here (even though this bloats the code) or if we use the jetstream.StreamConfig
directly in the Telegraf configuration.
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.
Using jetstream.StreamConfig
directly was done before, but rejected since it didn't have toml conversion, but only json.
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.
Well it is not absolutely necessary to have toml
tags, but I agree and would prefer the explicit setting of options. The question is, do we really need to expose all those options or can we live with the defaults?
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.
Yes it is not necessary to have toml tags. but there are some fields which did not support toml unmarshalling such as retention, limits. This is the reason why in the configuration, users are expected to pass integer values for such fields because it we can resuse the Stringer interface defined on those types.
There are use cases when we definitely need full set of options.
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.
@neelayu ok, so we can go with the full set of options, but I really think we should not hamper the user experience with the integers just because it's more convenient to use the String() interface. So please use speaking-strings where possible and do the explicit transformation. @powersj what do you think?
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.
Sounds good to me
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.
Will make the changes.
Co-authored-by: Joshua Powers <powersj@fastmail.com> Co-authored-by: Thomas Casteleyn <thomas.casteleyn@me.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.
@neelayu thanks for the update, just a few more minor comments. I added suggestions so it is quick for you to change those. I do have one more question about subject appending (in the code) and would love to hear your opinion there.
Co-authored-by: Sven Rebhan <36194019+srebhan@users.noreply.github.com>
@srebhan Thanks for your code suggestions. One important thing I learnt in this PR is, even if the code becomes verbose, its okay to do it. Its nice to see that telegraf doesn't compromise on code quality 😄 |
Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip. 📦 Click here to get additional PR build artifactsArtifact URLs |
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.
@neelayu thank you for all the effort you put into this PR!
Co-authored-by: Joshua Powers <powersj@fastmail.com> Co-authored-by: Thomas Casteleyn <thomas.casteleyn@me.com>
Required for all PRs
resolves #14235