logging debug client vs debugging cookbook

Description

This applies to running chef-client --log-level=debug or setting provisioner: log_level: debug in the .kitchen.yml file.

A while back in issue #13936 we discussed excessive noise in the chef client logs when the log verbosity was set to debug level, around connections to HTTP endpoints. These messages

[2026-03-19T12:04:27-04:00] DEBUG: opening connection to app.ddog-gov.com:443...
[2026-03-19T12:04:27-04:00] DEBUG: opened
[2026-03-19T12:04:27-04:00] DEBUG: starting SSL for app.ddog-gov.com:443...
[2026-03-19T12:04:27-04:00] DEBUG: SSL established, protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256

are still present. Over time and successive chef client versions the client debug output has gotten worse and worse and noisy. I ran a kitchen converge ... with an empty runlist (to measure how noisy the client-only output was) on a RHEL 9 system and got 9316 lines of output . That's too much.

To be clear, 9316 lines are just output about the operation of the chef client, and not anything about any cookbooks. There's so much, it's impossible for me to list all of the different things that are generating debug logs, but a few of them that seem to be bigger problems (in addition to the 'opening connection' messages):

• DEBUG: Plugin Network: Parsing ethtool output: Features for eth0: lists all of the NIC settings(?) sometimes more than once in a chef-client run.

• DEBUG: POST /organizations/chef/clients (this seems to be a huge amount of it and is a relatively recent addition in my memory) dumps the raw http request/response data

• under some conditions (usually cookbook fails/errors) that I haven't been able to nail down, chef-client writes all of the attributes/ohai data to stdout/stderr, usually a couple of times. Often the relevant error message is buried somewhere between copies of the attributes in the output.

• As above dozens of DEBUG: opening connection to app.yoursite.com:443... type messages

My problem here is that I can't figure out a way to debug the cookbook without being subject to huge amounts of noise from the chef client itself. With a runlist, the noise gets so much worse because you end up getting all of the additional HTTP traffic in the output. In my cookbooks I'm using Chef::Log.debug("..."), which I believe is the correct way to write logs. There's so much debug noise from the client that it's nearly impossible to debug cookbooks. (Windows is even worse partly because a bunch of the output is powershell scripts/results. I try to avoid debug logging on windows as much as possible.)

I have my terminal output buffer set to 8192 lines, which should be more than reasonable. It's not enough.

I don't know if the answer is better log/output separation, or if the client debugging needs to be much less verbose.

Chef Version

client 19.1.164

Platform Version

ec2, Rocky (RHEL) 9.7

Replication Case

use kitchen with provisioner: log_level: debug or chef-client --log-level=debug

Client Output

Sorry, not ideal but there's almost certainly proprietary client/corporate specific data in this massive output that I'm never going to be able to find and redact all of it so I'm not creating a gist.