Skip to content
This repository was archived by the owner on Aug 30, 2019. It is now read-only.

trace-agent is not using the configured log_level #516

Closed
renchap opened this issue Nov 6, 2018 · 6 comments
Closed

trace-agent is not using the configured log_level #516

renchap opened this issue Nov 6, 2018 · 6 comments

Comments

@renchap
Copy link

renchap commented Nov 6, 2018

In my /etc/datadog-agent/datadog.yml I am setting the log_level like this:
log_level: warning

This is correctly working for datadog-agent, but trace-agent is not using it and still outputs INFO level logs, even if reading the config file:

Nov 06 22:25:55 tg-staging2 trace-agent[21161]: 2018-11-06 22:25:55 INFO (main.go:89) - pid '21161' written to pid file '/opt/datadog-agent/run/trace-agent.pid'
Nov 06 22:25:55 tg-staging2 trace-agent[21161]: 2018-11-06 22:25:55 INFO (agent.go:225) - Loaded configuration: /etc/datadog-agent/datadog.yaml
Nov 06 22:25:55 tg-staging2 trace-agent[21161]: 2018-11-06 22:25:55 INFO (trace_writer.go:49) - Trace writer initializing with config: {MaxSpansPerPayload:1000 FlushPeriod:5s Upda
Nov 06 22:25:55 tg-staging2 trace-agent[21161]: 2018-11-06 22:25:55 INFO (stats_writer.go:42) - Stats writer initializing with config: {MaxEntriesPerPayload:12000 UpdateInfoPeriod
Nov 06 22:25:55 tg-staging2 trace-agent[21161]: 2018-11-06 22:25:55 INFO (service_writer.go:31) - Service writer initializing with config: {FlushPeriod:5s UpdateInfoPeriod:1m0s Se
Nov 06 22:25:55 tg-staging2 trace-agent[21161]: 2018-11-06 22:25:55 INFO (main.go:156) - trace-agent running on host tg-staging2.ovh.talegraph.net
Nov 06 22:25:55 tg-staging2 trace-agent[21161]: 2018-11-06 22:25:55 INFO (api.go:140) - listening for traces at http://localhost:8126
Nov 06 22:26:01 tg-staging2 trace-agent[21161]: 2018-11-06 22:26:01 INFO (service_writer.go:76) - flushed service payload to the API, time:483.180167ms, size:77 bytes
Nov 06 22:26:01 tg-staging2 trace-agent[21161]: 2018-11-06 22:26:01 INFO (trace_writer.go:97) - flushed trace payload to the API, time:484.055105ms, size:6557 bytes
Nov 06 22:26:05 tg-staging2 trace-agent[21161]: 2018-11-06 22:26:05 INFO (api.go:324) - [lang:ruby lang_version:2.5.1 interpreter:ruby-x86_64-linux tracer_version:0.16.1] -> trace
Nov 06 22:26:05 tg-staging2 trace-agent[21161]: 2018-11-06 22:26:05 INFO (trace_writer.go:97) - flushed trace payload to the API, time:358.4442ms, size:4855 bytes
Nov 06 22:26:10 tg-staging2 trace-agent[21161]: 2018-11-06 22:26:10 INFO (trace_writer.go:97) - flushed trace payload to the API, time:326.552803ms, size:4736 bytes

Environment

I am using the Chef cookbook to install Datadog on Debian.

# /opt/datadog-agent/embedded/bin/trace-agent --version
Version: 6.6.0
Git hash: 24d4c76
Git branch: HEAD
Build date: 2018-10-25 15:27:32.839833398 +0000 UTC m=+0.002630095
Go Version: 1.10.2
@gbbr
Copy link
Contributor

gbbr commented Nov 7, 2018

This works fine, but there is a small problem here, the correct logging level to set is warn, not warning. This works in the rest of the agent because there is a hook for this, but that's just luck. Can you please try the same with warn and see if that works for you?

@gbbr
Copy link
Contributor

gbbr commented Nov 7, 2018

Created #518 to fix this for 6.7.0

@renchap
Copy link
Author

renchap commented Nov 7, 2018

I confirm using warn is working correctly. Thanks!

@gbbr
Copy link
Contributor

gbbr commented Nov 7, 2018

Glad to hear! Thanks for confirming. I will close this issue once my PR gets merged then. In the next version (6.7.0) we should hopefully be consistent with the main agent and support both "warn" and "warning".

@renchap
Copy link
Author

renchap commented Nov 7, 2018

Might I suggest to have a way to override it for the trace agent, for example an optional apm_log_level? I can open a new issue for this if you want :)

@gbbr
Copy link
Contributor

gbbr commented Nov 7, 2018

I'm not sure if there is any value in adding that. I think it would just increase confusion. Besides the issue you've already opened (#517), which is a valid claim that we should fix, I think there is no need for a new option.

@gbbr gbbr closed this as completed in #518 Nov 7, 2018
gbbr added a commit that referenced this issue Nov 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants