This is what we're using to send to loggly. I'm not honestly 100% sure it
works as intended but it gets the job done. It would be great if we could
conditionally log to console when running in a local dev environment.
LOGGING = {
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'simple': {
'format': '%(asctime)s %(levelname)s %(message)s',
},
'request': {
'format': '%(asctime)s %(levelname)s %(status_code)d
%(message)s -> %(request)s',
},
'sql': {
'format': '%(asctime)s %(levelname)s duration: %(duration)d
SQL: %(sql)s',
},
},
'handlers': {
'simple.SysLogHandler': {
'level': 'DEBUG',
'class': 'logging.handlers.SysLogHandler',
'facility': 'local5',
'formatter': 'simple',
},
'request.SysLogHandler': {
'level': 'DEBUG',
'class': 'logging.handlers.SysLogHandler',
'facility': 'local5',
'formatter': 'request',
},
'db.SysLogHandler': {
'level': 'DEBUG',
'class': 'logging.handlers.SysLogHandler',
'facility': 'local5',
'formatter': 'sql',
},
},
'loggers': {
'django.request': {
'handlers': ['request.SysLogHandler'],
'level': 'DEBUG',
'propagate': True,
},
'django.db.backends': {
'handlers': ['db.SysLogHandler'],
'level': 'DEBUG',
'propagate': True,
},
'django.db.backends.schema': {
'handlers': ['simple.SysLogHandler'],
'level': 'DEBUG',
'propagate': False,
},
'loggly_logs': {
'handlers': ['simple.SysLogHandler'],
'propagate': True,
'format': 'django: %(message)s',
'level': 'DEBUG',
},
},
}
On Monday, March 23, 2015 at 12:48:26 PM UTC-5, Tim Graham wrote:
>
> The alternative to a new setting would be to revert the "merging" behavior
> of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING entirely. This
> original design was proposed by Claude in
> https://code.djangoproject.com/ticket/18993#comment:7, but now we realize
> disable_existing_loggers=True doesn't work as expected in that proposal.
> I also find that writing a nice configuration that uses
> disable_existing_loggers=False and that merges nicely with Django's
> defaults to be difficult (for example, in trying to output all log entries
> to the console, some as simple as the config below [1] won't work because
> Django's DEFAULT_LOGGING has handlers for 'django.request' and
> 'django.security' which don't propagate their entries (I couldn't tell the
> reason for this from
> https://github.com/django/django/commit/f0f327bbfe1caae6d11fbe20a3b5b96eed1704cf#diff-246800ac266982b8ad12f505352a662eR63
> )
>
> I would like to ask if anyone who is using settings.LOGGING could share
> their config so we can get a sense of different use cases?
>
> [1] An attempt to write a LOGGING config that outputs all entires to
> stdout, but doesn't entirely work as stated above.
>
> LOGGING = {
> 'version': 1,
> 'handlers': {
> 'console': {
> 'level': 'DEBUG',
> 'class': 'logging.StreamHandler',
> },
> },
> # A catch-all root logger.
> 'root': {
> 'handlers': ['console'],
> 'level': 'DEBUG',
> },
> }
>
> On Monday, March 23, 2015 at 12:31:06 PM UTC-4, Carl Meyer wrote:
>>
>> On 03/22/2015 08:23 PM, Carl Meyer wrote:
>> > The first, more complex and more important question is: how do we fix
>> > Django's logging config process to be less broken, so that the best
>> > advice for getting it to do what you what isn't "disable Django's
>> > interference entirely and do it yourself."? I don't have a
>> > fully-packaged solution ready to propose here; someone will need to dig
>> > into it. Probably the biggest sticking point to get around will be
>> > backwards compatibility.
>> >
>> > I'm pretty sure that a good solution will include an optional way to
>> > prevent Django from ever installing its default logging config in the
>> > first place, since it seems there's no way to tell logging to "clear
>> out
>> > everything and start fresh" once some configuration has been set.
>> >
>> > And I think it will also mean that we stop ever recommending the use of
>> > "disable_existing_loggers" (and probably even include a callout in our
>> > docs warning users against it). It seems that
>> "disable_existing_loggers"
>> > is a bad feature with surprising behavior, and our current docs were
>> > written based on a misunderstanding of what it does.
>>
>> After giving this a bit more thought, I think at least the first step of
>> a better solution may not be too hard, and could be integrated
>> immediately along with the doc changes.
>>
>> The problem is that the current system always installs the default
>> logging config, and expects that you can use `disable_existing_loggers:
>> True` to undo that if you want, but `disable_existing_loggers: True`
>> doesn't do the right thing at all. So really we just need a way to skip
>> installing Django's default logging config, if you don't want it. I
>> think the simplest solution is to just add a `LOGGING_SKIP_DEFAULTS`
>> setting which can be set to `True` to prevent Django from ever
>> installing its default logging config. Aside from that, the rest of the
>> `LOGGING_CONFIG/LOGGING` system is functional and fine as is, I think.
>>
>> The harder problem is figuring out how to have new projects default to
>> good in-development console logging in DEBUG mode, without breaking
>> back-compat for older projects. But I don't think we should hold up
>> incremental improvement while waiting for a solution to that -- having a
>> proper way to bypass Django's default logging, and fixing our
>> documentation to be accurate, would be a big step forward.
>>
>> Carl
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/b9367ef8-1d4c-45c7-84f9-1294985f5be9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
