Skip to content
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

Metricbeat: MongoDB TLS connection support #7401

Merged
merged 5 commits into from
Jun 28, 2018
Merged

Conversation

jsoriano
Copy link
Member

Add support for TLS in MongoDB metricbeat module. A common builder is also added for MongoDB metricsets.

Fixes #6619

@jsoriano jsoriano requested review from ruflin and acchen97 and removed request for acchen97 June 22, 2018 18:13
# Username to use when connecting to MongoDB. Empty by default.
#username: user

# Password to use when connecting to MongoDB. Empty by default.
#password: pass
----

This module supports TLS connection when using `ssl` config field, as described in <<configuration-ssl>>. It also supports the options described in <<module-http-config-options>>.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This message is autogenerated after adding the ssl settings to fields.yml. I think it shouldn't mention by default the http options, as for example this module uses TLS but doesn't use HTTP. To be fixed in a future PR.

}

dialInfo.DialServer = func(addr *mgo.ServerAddr) (net.Conn, error) {
return tls.Dial("tcp", addr.String(), tlsConfig.BuildModuleConfig(""))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we pass addr.String() to tlsConfig.BuildModuleConfig instead of ""? Maybe it doesn't matter but reading through https://golang.org/pkg/crypto/tls/#Config it appears this value is used for hostname verification.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other uses of this function we are passing the empty string but yes, it'd make sense to pass the hostname in the address, I'll try this.

@@ -47,24 +46,18 @@ func init() {
// additional entries. These variables can be used to persist data or configuration between
// multiple fetch calls.
type MetricSet struct {
mb.BaseMetricSet
dialInfo *mgo.DialInfo
*mongodb.MetricSet
Copy link
Contributor

@ycombinator ycombinator Jun 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be an invalid/stupid question because I'm still new to beats + golang but why do we need to embed the *mongodb.MetricSet type inside this MetricSet struct? Couldn't we get rid of the outer/wrapper struct now and in the New function below do this instead:

func New(base mb.BaseMetricSet) (mb.MetricSet, error) {
    return mongodb.NewMetricSet(base)
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no stupid questions, this is a good one :)

Here all the metricsets share the same fields, so I use the same builder, but they need different implementations for the Fetch() method, so I embed the common data in structs implementing these specializations.

@jsoriano
Copy link
Member Author

@ycombinator thanks for your review!

I have added the server name to the TLS config, but after some tests I couldn't see any change in how it behaves. It seems that the dialer method already tries to infer the server name from the address if it is not set. In any case I'm fine with leaving it explicit.

# Mode of verification of server certificate ('none' or 'full')
#ssl.verification_mode: 'full'

# List of root certificates for HTTPS server verifications
Copy link
Contributor

@ycombinator ycombinator Jun 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably should say TLS or SSL instead of HTTPS (since there's no HTTP connection here)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, fixed.

Copy link
Contributor

@ycombinator ycombinator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a minor doc comment otherwise LGTM.

Copy link
Member

@ruflin ruflin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WFG

@ruflin ruflin merged commit 153b695 into elastic:master Jun 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants