416a
commented
2 years ago Hi gupps8117! You probably resolved this by now but in case you or other's haven't, yes there's a way to use the DataDog's cookbook attributes to override this port.
See https://github.com/DataDog/chef-datadog#extra-configuration
For the go_expvar port conflict (I also ran into the same Docker+go_expvar issue), you would use the following:
# File: some_cookbook/attributes/default.rb
override['datadog']['extra_config']['expvar_port'] = 5555All the best and stay safe!
Describe what happened:
After installing the agent on our GitLab server, we encountered issues with GitLab Container Registry. The issue didn't appear immediately after the agent was installed but after the scheduled server update followed by the restart.
Suddenly, all attempts to push to the container registry started to fail with a 404 error. It significantly disturbed the work of our development team, because it was working and out of the blue stopped working.
After checking GitLab omnibus logs, I found out that the Docker registry keeps restarting, reporting that 127.0.0.1:5000 is already in use. Then I found out that the agent is listening on that port.
I had to change the agent settings so it doesn't use port 5000 and I don't really know what consequences it would have on the agent itself.
Describe what you expected:
Since GitLab integration is one of the standard integrations of Datadog, I was not expecting that it will come in direct conflict with the widely used GitLab component, such as the container registry.
Steps to reproduce the issue:
Install GitLab using Omnibus and enable the container registry. Check if everything works as expected. Install the Datadog agent on the same machine, reboot the machine and observe that the GitLab container registry keeps restarting because port 5000 is already in use.
Additional environment details (Operating System, Cloud provider, etc):
Ubuntu 18.04
Is there any way I can update the port used by go_expvar using CHEF Cookbook or Atrributes.