search

percona / mongodb_exporter

A Prometheus exporter for MongoDB including sharding, replication and storage engines
Apache License 2.0
1.18k stars 423 forks source link

Cannot get mongodb-exporter to connect to my mongo pod in another namespace #751

Closed ermirry closed 10 months ago

ermirry commented 11 months ago

Describe the bug I have a deployment with a single mongodb-exporter pod that needs to connect to a mongodb pod living in the default namespace. The mongodb-exporter deployment lives in a namespace called mongo-exporter. I believe I have my mongodb.uri defined correctly, but the exporter pod logs complain of a server selection timeout/server selection error and cannot seem to communicate with my mongodb pod.

To Reproduce Steps to reproduce the behavior:

  1. `args:
    • --collect-all
    • --mongodb.uri=mongodb://$(MONGO-USER):$(MONGO-PASS)@xxxx.default.svc.cluster.local:27017`
  2. Create a deployment using the percona/mongodb_exporter:0.40.0 image with containerPort 9216 defined and use the above args for the container.

Expected behavior Since this is my first time using this software, i'm not entirely sure what the expected behaviour is but I can only assume I should see some log message about a successful connection made to my mongodb instance running in the cluster.

Logs level=info ts=2023-11-29T23:17:09.851Z caller=tls_config.go:274 msg="Listening on" address=[::]:9216 level=info ts=2023-11-29T23:17:09.851Z caller=tls_config.go:277 msg="TLS is disabled." http2=false address=[::]:9216 time="2023-11-29T23:17:14Z" level=error msg="Cannot connect to MongoDB: cannot connect to MongoDB: server selection error: server selection timeout, current topology: { Type: Single, Servers: [{ Addr: xxxx.default.svc.cluster.local:27017, Type: Unknown, Last error: connection(xxxx.default.svc.cluster.local:27017[-12]) socket was unexpectedly closed: EOF }, ] }"

Environment

Additional context I'm hoping what i'm missing is something small and someone here can point it out to me. Any help or any direction would be greatly appreciated. Thank you

ermirry commented 10 months ago

Alright I figured this out. Turns out, I was missing a little bit of extra fluff at the end of the connection string and additionally had rename the environment variables I was using to pass the username and password in the connection string.

Previously, I was using --mongodb.uri=mongodb://$(MONGO-USER):$(MONGO-PASS)@xxxx.default.svc.cluster.local:27017 but I had to add /admin?ssl=true&tlsInsecure=true to the end of that to get it to connect. For my environment variables, I was naming them mongo-user and mongo-pass but apparently the application is specifically looking for MONGODB_USER and MONGODB_PASSWORD as variable names.

I must say though, the application still does not output any sort of logging that confirms that a successful connection has been made. I was only able to confirm this by port forwarding to the pod and curling the metrics endpoint to see if it returned metrics or not. Some sort of messaging that a successful connection has been made in the logs would be very useful for troubleshooting going forward.