Disabling trace logs

[maaudet-ca]

These logs are polluting my logs and taking about 90% of the available logs space. Every times that I analyze logs I actually remove them manually using a regex expression because I don't see the use for them.

Is there any easy ways to disable these logs?

[johnsca]

It seems there was a thought to add a layer.yaml option to control it but there wasn't enough of a push to do so, probably because Juju changed the default unit log level to INFO rather than DEBUG. It should be easy enough to do in your charm, though. At the start of your reactive/my_charm.py file, add:

from charms.reactive import trace
from charmhelpers.core import hookenv

hookenv.atstart(tracer.install_tracer, tracer.NullTracer())

That should run after the default one and should override it to turn off trace logging.

[johnsca]

For charms that aren't under your control, though, there's not going to be an easy solution; even the originally-proposed layer.yaml option would require the charm itself to opt out. Maybe adding a flag that can be set to override it would work, which could then be done on any charm using juju run --unit charm/0 -- charms.reactive set_flag charms.reactive.tracer.disable. That would require an update to the charms.reactive library and for charms to be rebuilt with that new library version.

[maaudet-ca]

I think that my main issue is that I have a lot of flags, so it might be realistic to keep those logs in certain cases. ex: in one my my charms it can get up to 55 flags and it becomes easier to just follow my own info level logs than the actual flags that are set to know what's going on.

The flag idea could be a nice one, otherwise I don't know if a config would be feasible? That way we could disable/enable them using juju config my-app reactive-tracer-disable=false or something similar. It's less flexible on the units though.

[maaudet-ca]

By the way, the fix worked ! Noticed that I had some charms with over 150 flags, so the trace messages would fill everything up quite quickly 🙃

Edit: I'm still getting the tracer: set flag [insert-flag-here] logs though, but I don't have the ones that says which flags are currently set. Is this normal?

[johnsca]

Hrm, no, that shouldn't be happening. It sounds like something else is reinstalling the LogTracer after your code removes it. Try grepping your built charm for install_tracer and see if one of the other layers you're including is explicitly installing the LogTracer.

[maaudet-ca]

Mmm, the only tracers that I see are the config.* flags that are set at the beginning. The only other layer that I really use are the leadership, coordinator and basic layers.

Could be it possible that the LogTracer is installed at the beginning, then some startup code setting the config flags happen and I remove the LogTracer after this is done?

[johnsca]

Ah, yeah. The atstart handlers are executed in the order that they're registered, and it looks like this one will always be first, which is what would be emitting those.

[maaudet-ca]

Ah, well. That explains it. For now I'll go on without further adjustments since it's really not as bad, but I'll keep it in note on my side to see for a solution when I'll have some time.