[ops][nova]Logging in nova and other openstack projects
On 07.05.2019 23:31, Jean-Philippe MÃ©thot wrote:
> Indeed, this is what was written in your original response as well as in
> the documentation. As a result, it was fairly difficult to miss and I
> did comment it out before restarting the service. Additionally, as per
There is also a deprecated (but still working) log_config . So please
double-check you don't have that configuration leftover. Another caveat
might be that SIGHUP does not propagate to all of the child
processes/threads/whatever to update its logging configs with the new
default_log_levels and removed log_config(_append) ones... But you said
you are restarting not reloading, so prolly can't be a problem here.
> the configuration I had set up, had the log-config-append option be set,
> I wouldnâ??t have any INFO level log in my logs. Hence why I believe it is
> strange that I have info level logs, when Iâ??ve set default_log_levels
> like this:
> =Â amqp=WARN,amqplib=WARN,boto=WARN,qpid=WARN,sqlalchemy=WARN,suds=WARN,oslo.messaging=WARN,iso8601=WARN,requests.packages.urllib3.connectionpool=WARN,urllib3.connectionpool=WARN,websocket=WARN,requests.packages.urllib3.util.retry=WARN,urllib3.util.retry=WARN,keystonemiddleware=WARN,routes.middleware=WARN,stevedore=WARN,taskflow=WARN,keystoneauth=WARN,oslo.cache=WARN
> Please understand that I am not doubting that your previous answer
> normally works. I have seen your presentations at past Openstack summit
> and know that you are a brilliant individual. However, I can only answer
> here that, from my observations, this is not working as intended.
> Iâ??ll also add that this is on Pike, but we are slated to upgrade to
> Queens in the coming weeks.
> Best regards,
> Jean-Philippe MÃ©thot
> Openstack system administrator
> Administrateur systÃ¨me Openstack
> PlanetHoster inc.
>> Le 7 mai 2019 Ã 11:39, Jay Pipes <jaypipes at gmail.com
>> <mailto:jaypipes at gmail.com>> a Ã©crit :
>> As mentioned in my original response, if you have
>> CONF.log_config_append set to anything, then the other conf options
>> related to logging will be ignored.
>> On Tue, May 7, 2019, 11:15 AM Jean-Philippe MÃ©thot
>> <jp.methot at planethoster.info <mailto:jp.methot at planethoster.info>> wrote:
>> Iâ??ve just tried setting everything to warn through the nova.conf
>> option default_log_levels, as suggested. However, Iâ??m still
>> getting info level logs from the resource tracker like this :
>> INFO nova.compute.resource_tracker
>> Could the compute resource tracker logs be managed by another
>> parameter than whatâ??s in the default list for that configuration
>> Best regards,
>> Jean-Philippe MÃ©thot
>> Openstack system administrator
>> Administrateur systÃ¨me Openstack
>> PlanetHoster inc.
>>> Le 7 mai 2019 Ã 09:02, Jay Pipes <jaypipes at gmail.com
>>> <mailto:jaypipes at gmail.com>> a Ã©crit :
>>> On 05/06/2019 05:56 PM, Jean-Philippe MÃ©thot wrote:
>>>> Weâ??ve been modifying our login habits for Nova on our Openstack
>>>> setup to try to send only warning level and up logs to our log
>>>> servers. To do so, Iâ??ve created a logging.conf and configured
>>>> logging according to the logging module documentation. While
>>>> what Iâ??ve done works, it seems to be a very convoluted process
>>>> for something as simple as changing the logging level to
>>>> warning. We worry that if we upgrade and the syntax for this
>>>> configuration file changes, we may have to push more changes
>>>> through ansible than we would like to.
>>> It's unlikely that the syntax for the logging configuration file
>>> will change since it's upstream Python, not OpenStack or Nova
>>> that is the source of this syntax.
>>> That said, if all you want to do is change some or all package
>>> default logging levels, you can change the value of the
>>> CONF.default_log_levels option.
>>> The default_log_levels CONF option is actually derived from the
>>> oslo_log package that is used by all OpenStack service projects.
>>> It's default value is here:
>>> So, if you don't want to mess with the standard Python logging
>>> conf, you can just change that CONF.default_log_levels option.
>>> Note that if you do specify a logging config file using a
>>> non-None CONF.log_config_append value, then all other logging
>>> configuration options (like default_log_levels) are ignored).