Skip to content

Increase log verbosity of development app, add log-level config for production#128

Merged
dwilding merged 10 commits intocanonical:mainfrom
dwilding:logging
Mar 4, 2026
Merged

Increase log verbosity of development app, add log-level config for production#128
dwilding merged 10 commits intocanonical:mainfrom
dwilding:logging

Conversation

@dwilding
Copy link
Collaborator

@dwilding dwilding commented Mar 3, 2026

This PR makes several logging-related improvements:

  • Defines a handler for the "root" logger, which lets us log from the app code. I've added a logging call to achieved_level() in dashboard/projects/models.py to demonstrate the capability, and to support troubleshooting I'm doing elsewhere. Sample output:

    DEBUG (projects.models) - Calculating level for <ProjectObjective: Blue bicycles > Agreeableness>
    
  • For the development app (run using runserver), increased the log verbosity to DEBUG. I've excluded SQL queries and file reloads, otherwise the logs get very noisy, but have included comments about how to output those logs too. See dashboard/dashboard/settings.py.

    Setting DEBUG level enabled me to catch the error fixed by #126.

  • For the production charm, made the log level configurable at the Juju level. The new config option log-level controls the Django app logs. For example: juju config dashboard log-level=debug. The default level is info.

    If an invalid log level is configured, the charm goes into blocked status with the message "Webserver configuration check failed, please review your charm configuration or database relation", which is defined by the PaaS charm. Running juju debug-log shows a more specific message:

    unit-dashboard-0: 12:57:09 ERROR unit.dashboard/0.juju-log webserver configuration check failed, stdout: , stderr: Invalid log level 'foo'. Valid levels: debug, info, warning, error, critical

    log-level doesn't control the gunicorn logs (the web request logs). I think that's OK, as the main purpose of log-level is to make it easier to troubleshoot internal app issues - especially in our testing deployment.


Unrelated changes: I ran ruff format on the Python code that I touched, for more consistent formatting.


Manual checks

  • If you changed the Dashboard application or the rock, have you increased the version number in rockcraft.yaml? Remember to use the same version number in README.md. @dwilding TODO before merging

This comment was marked as resolved.

@dwilding dwilding marked this pull request as ready for review March 4, 2026 05:04
Copy link
Contributor

@alithethird alithethird left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀

@dwilding dwilding merged commit 95d14ce into canonical:main Mar 4, 2026
6 of 7 checks passed
@dwilding dwilding deleted the logging branch March 4, 2026 23:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants