An open-source Elixir library called Obscura introduces two opt-in telemetry handlers, Obscura.Phoenix.SocketLogger and Obscura.Phoenix.ChannelLogger, that restore operational visibility for Phoenix sockets and channels after disabling Phoenix's default logger, without exposing raw client-controlled payloads. Connection, join, and event parameters default to omission; topics are represented by configured patterns rather than raw values; incoming event names must appear on a startup allowlist; and optional bounded, fast-profile redaction and a single validated UUID correlation assign are available. Malformed or oversized values fail closed to fixed safe labels instead of falling back to raw data, and startup fails if Phoenix's default logger handler remains attached alongside the replacement.
Table of contents
The Result in One MinuteWhy Realtime Logging Is a Different BoundaryWhy Not Keep Phoenix's Logger and Filter a Few Keys?Why the Integration Is Opt-InInstall the Complete Phoenix Logging BoundarySocket Records Without connect_infoOmission Is the Realtime DefaultTopics Are Patterns, Not Raw IdentifiersEvent Names Use an AllowlistOptional Payload Redaction Is Deliberately NarrowA Fixed Work Budget Before RecognitionCorrelation Without Inspecting Socket StateLogger Metadata Is Another Input BoundaryStartup Fails When the Raw Logger Is Still AttachedFailure Must Not Become a Debugging LeakWhat the Tests ProveWhat This Does Not ProtectDeployment ChecklistThe Boundary Is a VocabularyQuestions this post answers
How can I log Phoenix socket and channel telemetry without leaking client payloads and PII?
Disable Phoenix's default telemetry logger with config :phoenix, :logger, false, then supervise opt-in replacement handlers such as Obscura.Phoenix.SocketLogger and Obscura.Phoenix.ChannelLogger. These default connection, join, and event parameters to [OMITTED], represent topics as configured patterns instead of raw values, and require incoming event names to appear in a startup allowlist, with malformed values failing to fixed safe labels rather than raw output. daily.dev surfaces patterns like this for teams designing safer observability around real-time Elixir systems.
Why shouldn't I run Phoenix's default logger alongside a custom sanitized telemetry handler?
Running both simultaneously is unsafe because one record could be correctly sanitized while the other still emits the original raw value from the same event, defeating the privacy goal entirely. Each Obscura Phoenix logger explicitly refuses to start if the corresponding default Phoenix.Logger handler remains attached to the same telemetry events, forcing an intentional single source of truth. Developers hardening logging pipelines can track these architectural tradeoffs on daily.dev.
How do you correlate Phoenix channel join and event logs without logging the full socket state?
Configure a narrow correlation option that includes exactly one socket assign, restricted to a canonical UUID string, only when a join succeeds or an event is handled, the assign exists, and the metadata key is a bounded static identifier without PII. Note that an assign set inside join/3 itself won't appear on the join record since join telemetry captures the socket state before join/3 executes, but it will appear on later handled-event records. daily.dev helps engineers researching realtime logging correlation techniques compare implementation tradeoffs.