feat: migrate to mitol-django-observability plugin

[blarghmatey]

• Run uv lock to update the uv lock file
• Commit and push the updated lock file to fix CI failures
• Merge main into feature branch to resolve uv.lock conflict
• Fix Sentry Issue 1: Bridge MITX_ONLINE_LOG_LEVEL → LOG_LEVEL env var so the observability plugin can consume it (backward compatibility)
• Fix Sentry Issue 2: Restore AdminEmailHandler for django.request to preserve 500-error email notifications to admins in production

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[github-actions]

OpenAPI Changes

Show/hide ## Changes for v0.yaml:

## Changes for v0.yaml:


## Changes for v1.yaml:


## Changes for v2.yaml:

Unexpected changes? Ensure your branch is up-to-date with main (consider rebasing).

[dsubak]

Conceptually, this seems pretty straightforward. It'll change some logging behavior, but that's largely intentional afaict.

I'm going to hold off on formal approval until mitodl/ol-django#407 lands and I can actually start local with this branch. Since the package doesn't exist yet it just chokes on startup, which is totally expected but I do want to put it through the lightest testing ever before I put a stamp on it!

[dsubak]

One like... super minor concern I've got w/ the reliance on automatic instrumentation is that we no longer get big obvious failures if we screw something up (like if I were to inadvertently remove any of these otel-instrumentation-* packages).

I wonder if there's any value in adding an "expected" set of automatic instrumentations over in the plugin that is be defined by settings and throwing an error if we ever fail that?

It feels like it's probably overkill at the moment to me, but if we ended up seeing people accidentally dropping instrumentation that they don't consult every day, it might be a relatively quick and cheap way to let folks avoid surprise viz gaps.

[blarghmatey]

@dsubak can you give more color to your concerns? Are you referring to the overall automated instrumentation that happens with the OTEL SDK, or are you referring to e.g. the Celery and Postgres instrumentation based on the discovery of dependencies?

[dsubak]

@blarghmatey The latter - previously, if I were to remove opentelemetry-instrumentation-celery things would explode loudly in main/telemetry.py because we have to import and explicitly configure those extensions.

Now I believe that auto_instrument will simply instrument whatever is installed (respecting the skip and allowlists), meaning removing one of those packages from this repo silently removes the instrumentation.

Like I said, I do think it's kind of a minor concern - the main edge case this would be getting ahead of is something like a well-meaning cleanup PR where since they can't find usages in the repo they assume it's good to be removed - but figured I'd bring it up for discussion in case folks felt it was more important than I do.

[feoh]

@dsubak Always appreciative of/open to bar raising but I think this one's ready to merge given that you're saying this seems a minor concern. lmk if you have objections, and we can always revert.

[pdpinch]

@blarghmatey I think this is waiting on you now, so I assigned it back to you and added the "waiting on author" label

[feoh]

@copilot Please run 'uv lock' to update the uv lock file and commit/push that change to fix the failing tests.

[Copilot]

@copilot Please run 'uv lock' to update the uv lock file and commit/push that change to fix the failing tests.

Done — ran uv lock and committed the updated lockfile in 735ce89. It resolved mitol-django-observability v2026.3.11, added structlog v25.5.0, and removed the now-redundant opentelemetry-exporter-otlp v1.39.1.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• releases.astral.sh
  • Triggering command: /home/REDACTED/.local/bin/uv /home/REDACTED/.local/bin/uv lock (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[feoh]

@copilot pre-commit says there is a marge conflict. Please resolve that conflict if the correct resolution is clear and straight forward. Otherwise let me know and don't touch anything.

[Copilot]

@copilot pre-commit says there is a marge conflict. Please resolve that conflict if the correct resolution is clear and straight forward. Otherwise let me know and don't touch anything.

Resolved in 94943d1 — merged main into this branch (only uv.lock had a conflict since it's auto-generated), then re-ran uv lock to produce a clean lockfile that includes both the latest main changes and mitol-django-observability. No conflict markers remain.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• releases.astral.sh
  • Triggering command: /home/REDACTED/.local/bin/uv uv lock --project /home/REDACTED/work/mitxonline/mitxonline (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[feoh]

@copilot Please review the two issues Sentry reported and fix them if they are actual problems.

[Copilot]

@copilot Please review the two issues Sentry reported and fix them if they are actual problems.

Both issues are real and have been fixed in 2f45f1a:

1. MITX_ONLINE_LOG_LEVEL not consumed — the plugin reads LOG_LEVEL from os.environ directly, bypassing our get_string(name="MITX_ONLINE_LOG_LEVEL") definition. Fixed by adding os.environ.setdefault("LOG_LEVEL", LOG_LEVEL) before the plugin import, so the legacy env var is bridged through.

2. AdminEmailHandler removed — the plugin's LOGGING config only has a console handler for django.request; no mail_admins handler. Fixed by extending the imported LOGGING dict to add back the require_debug_false filter, the AdminEmailHandler, and appending it to the django.request logger's handlers.