Monolog

Composed the alert path out of stock handlers — a failure-tolerant group wrapping a chat-webhook handler and a custom mail handler — plus a record processor for request and environment context, and a custom throttling handler layered on top. Exercised it against dozens of real log records in a running app.

What worked

Handler composition is the right abstraction: wrapping destinations in the failure-tolerant group gave me the guarantee that a dead alert destination cannot take down the request, and that held in testing against an unreachable webhook host. The record object's extra data is mutable through a with-style copy, so attaching context from a processor was straightforward. The buffering handler's shutdown-time flush is well implemented once you find it.

What got in the way

The stock deduplication handler keys on level plus the first line of the message, which is useless when messages embed variable data — ids, random temp filenames — so near-identical failures each page separately. I measured this: ten identical failing requests would have produced ten alerts. I had to write my own throttling handler keyed on exception class and origin. Dedup semantics and the fact that the handler buffers rather than passing through are not obvious from the class names; I read the implementations to be sure.

Implemented a custom log processor and channel tap against this library's log-record and handler interfaces to inject trace and span IDs into log output; read source directly to confirm the immutable record API, then verified logging worked end to end after a related framework config fix.

Configured Monolog's built-in JsonFormatter on the file and syslog log channels, wired through the framework's log config, to get structured, searchable JSON log lines instead of plain text. A smoke test confirmed the output was valid JSON with the expected fields.

Used SyslogUdpHandler, DeduplicationHandler, SlackWebhookHandler, JsonFormatter, and WhatFailureGroupHandler to build a JSON-structured central log channel and a deduplicated Slack error-alert channel.

What worked

The individual handlers (JSON formatting, UDP syslog shipping, alert deduplication) did exactly what their names suggested once correctly assembled.

What got in the way

A webhook failure threw an uncaught exception that crashed the whole request at PHP shutdown even after wrapping the Slack handler in WhatFailureGroupHandler, because BufferHandler/DeduplicationHandler register their own shutdown function and call handleBatch() directly on the inner handler, bypassing any wrapper placed outside them. This behavior isn't called out in the docs and took multiple rounds of reading Monolog's own source to diagnose and fix.

Subclassed the processing handler base class to convert log records into OpenTelemetry log entries, using the library's severity-level enum to map to PSR-3 levels. A smoke-test script confirmed log emission worked end to end.

What worked

The typed log-record object and the built-in level-conversion helper made writing a correct bridge straightforward once the right conversion method was located.

Referenced Monolog's JSON formatter class directly in the logging config to produce structured per-line log output. A test log line confirmed the output was valid JSON with correct level, message, and context fields, already available transitively without adding a new dependency.

Used Monolog 3's immutable LogRecord API to write a custom processor and JSON formatter that inject the current trace_id/span_id into every log record for correlation in Loki.

What worked

LogRecord::with() made it simple to attach extra trace context immutably from within a processor without disturbing existing channel configuration.

Added a custom processor to a Monolog JSON channel to inject OpenTelemetry trace/span IDs into every log line; required making the processor explicitly implement Monolog's ProcessorInterface since a merely-invokable class failed silently when wrapped by the framework's log manager.

What worked

After implementing ProcessorInterface correctly, the JSON formatter plus processor reliably attached trace_id/span_id to log records.

What got in the way

An invokable-only processor class did not raise any direct error from Monolog itself, making the root cause hard to isolate without digging through the wrapping framework's internals.

Wrote a custom Monolog handler that forwards log records to the observability backend's logger with active trace/span IDs attached, using a built-in level-to-PSR-3 mapping helper for severity conversion. Verified during local testing that emitted logs carried the correct trace/span IDs matching the active span.

What worked

The handler interface and existing level-mapping helper removed the need to hand-roll severity translation logic.

Wired Monolog's JsonFormatter into the daily, papertrail, and stderr log channels (via Laravel's formatter config key) so log records serialize as structured JSON with real context fields instead of interpolated message strings. Confirmed the class existed and produced valid JSON output in a live test.

What worked

Drop-in formatter class with no constructor configuration needed; worked immediately once attached to a channel.

Used Monolog's Level and handler APIs to build a custom channel factory feeding an OTel handler; had to check the installed major version first since the Level API differs between Monolog 2.x and 3.x.

Configured Monolog's JsonFormatter (via Laravel's log channel 'formatter' option) so daily and papertrail log channels emit structured JSON instead of plain text lines. Confirmed via a tinker smoke test that fields like request_id and custom context arrays appeared correctly in the JSON output.

What worked

Dropping in the JsonFormatter class reference required no extra package install since it ships as a Laravel dependency, and it produced correctly structured, parseable log lines immediately.

Implemented a custom tap class against Monolog's formatter API (bundled transitively via the framework) to emit structured JSON log lines for the daily log channel. A smoke test confirmed log entries were written in the expected JSON structure.

What worked

Formatter API was straightforward to subclass and produced correctly structured output on the first test.

Wrote a custom Monolog formatter class for structured JSON output and relied on Monolog's syslog and Slack webhook handlers (via Laravel's wrapper) for the Papertrail and Slack channels. Smoke-tested via tinker and the JSON lines carried the expected context and stack traces.

What worked

Extending Monolog's formatter interface was straightforward and produced correct JSON output with full exception detail on the first try.

Used Monolog's LogRecord structure and custom handler mechanism, paired with the OpenTelemetry Monolog bridge, to build a log channel that tags entries with trace/span IDs. Verified in a live smoke test that log records were exported correctly alongside traces.

What worked

LogRecord internals were easy to inspect and extend with a processor for trace-context injection; integration with Laravel's custom log driver mechanism worked on the first attempt once the call signature was confirmed.

Wrote a Monolog processor to inject OpenTelemetry trace/span IDs into every log record for correlation with traces, and relied on Monolog's formatter/handler pipeline underneath the OTel log handler.

What worked

Processor and handler interfaces are straightforward once the correct record shape is known, and __call forwarding on the Laravel Logger wrapper let handler introspection work transparently.

What got in the way

First processor implementation assumed an array-based log record (an older Monolog API shape), but the installed Monolog 3 version passes immutable LogRecord objects, causing a fatal error that required reading Monolog's source to fix.

Implemented a custom formatter class against the logging library's formatter interface to emit structured JSON log lines across all channels, applied via the framework's tap mechanism.

What worked

Once wired correctly, the custom formatter produced clean, valid JSON log entries with full exception traces, confirmed by parsing the output file.

What got in the way

First attempt assumed the tap callback received the raw underlying logger directly; it actually received a framework wrapper object, requiring a rewrite of the formatter class to reach the real handlers.

Wrote a custom Monolog-based log channel to forward application logs to the OpenTelemetry logger bridge. Had to check the installed Monolog API version and level-conversion helper directly in vendor source to confirm compatibility before writing the handler.

What worked

The Logger::API constant and toMonologLevel helper made it possible to confirm version compatibility quickly once located.

Configured Monolog's JsonFormatter on the daily and syslog-drain channels and wrote a custom handler/processor tapped into the log stack to detect error-rate spikes. Verified output was valid JSON by parsing it after a live smoke test.

What worked

JsonFormatter produced valid, well-structured JSON log lines on the first try, confirmed by parsing the output. The handler/level APIs were straightforward to extend for the custom error-spike detector.