Logging
:::info Status Implemented. :::
Application logs
fastapi-backend/main.py configures Python's standard logging module to
stdout (%(asctime)s | %(levelname)s | %(message)s), so container logs are
the primary log surface:
docker compose logs --tail=50 fastapi-backend
docker compose logs -f fastapi-backend # follow
FFmpeg subprocess stderr is tailed into the same application log by a
dedicated logger task per broadcast (see
Azaan Broadcast) — an FFmpeg spawn/encode failure
shows up in fastapi-backend logs, not in a separate file.
Structured audit trails (not plain logs, but the durable record)
Two Postgres tables function as this system's structured, queryable audit log — prefer them over grepping container logs when the question is "what happened to broadcast/device X":
| Table | What it records | Read via |
|---|---|---|
broadcast_audit_logs | Every broadcast (live/offline azan, announcements): delivery stats, MQTT timing, errors | Broadcast Audit API |
device_audit_log | Device lifecycle events, authorization denials (e.g. stream_denied, rate-limited to one row per subject/reason/minute) | SQL, or the device registry's GET /devices/{id}/audit |
Broker-side visibility
EMQX's own metrics (connection counts, authn/authz failure rates) are
scraped into /health/detail — see Monitoring.
The EMQX dashboard itself is never published in production (see
Device Deployment); log-level detail from
the broker is only reachable through an SSH tunnel to it.
Deployment logs
GitHub Actions logs cover the deploy workflow itself (SSH, tag checkout,
docker compose up); see
Environments & Release Process.