- Is ias/newrelic-logger-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. It ships a Bundle subclass, a DependencyInjection extension with a config tree, and a compiler pass that registers a Monolog handler through Symfony's monolog service definitions. Composer-installing it into a Laravel app leaves you with an inert package plus symfony/http-kernel and symfony/dependency-injection added to your dependency graph. Only its handler class is framework-agnostic and worth extracting.
- How do I install and configure the New Relic Monolog handler in a Symfony app?
- Install it with Composer, enable the bundle in config/bundles.php, then configure the handler under the bundle's config key in config/packages/ with your New Relic ingest license key, the minimum log level, and your preferred formatter. The service container handles handler registration, so you do not wire it manually into monolog.yaml. Exact config keys are not covered in the package description, so confirm them against the repository README before deploying.
- Can I use ias/newrelic-logger-bundle in a Laravel application?
- Not out of the box. Laravel has no bundle, DI extension, or compiler-pass concept, so the package will not auto-register a channel or add anything to config/logging.php. You would have to copy the handler out and expose it through a Laravel custom channel driver. For most Laravel apps, agent-based forwarding or the official enricher is the better route.
- How does the handler send log records to New Relic, and what about US versus EU regions?
- It is an AbstractProcessingHandler subclass that formats each record and POSTs it to the New Relic Logs API at log-api.newrelic.com/log/v1, with the EU variant at log-api.eu.newrelic.com, authenticating with an ingest license key. Because delivery is a plain HTTP call per record, the endpoint is just configuration, which makes a region mismatch easy to introduce and hard to notice. Validate the endpoint against your New Relic account region and monitor for rejected or dropped payloads.
- Which Monolog, PHP, and Symfony versions does it support?
- The package description does not pin Monolog, PHP, or Symfony versions, so check its composer.json before committing to it. Any port to a modern stack must match Monolog 3's AbstractProcessingHandler::write() signature and LogRecord value object, because code written against Monolog 1 or 2 will not load. Pin the versions you actually test against in your fork's composer.json.
- How is this different from newrelic/monolog-enricher or New Relic agent log forwarding?
- New Relic's supported PHP path is agent-based forwarding: emit structured JSON to stdout or a file and let the New Relic PHP agent or infrastructure agent tail and ship it, with batching and backpressure handled for you. newrelic/monolog-enricher adds trace and span correlation to records but does not ship them itself. A hand-rolled HTTP handler is only defensible when agent installation is impossible, such as locked-down containers, shared hosting, or some serverless setups.
- Does adding the New Relic handler replace or break my existing local logging?
- No. The design keeps local logging intact while adding remote delivery, so your existing file, stderr, and rotating channels keep working. The New Relic handler is simply an additional Monolog handler, and it honors the configured minimum log level so you can control what leaves the host.
- How do I set the minimum log level and attach service name, environment, and host metadata?
- Set the minimum log level through the bundle's config tree so only records at or above that threshold are forwarded to New Relic. The handler attaches contextual metadata such as service name, environment, and host, which is how New Relic correlates log lines with traces, metrics, and alerts. Keep the service name stable and identical across services, otherwise correlation and entity grouping break.
- Is this package safe for production, and is it still maintained?
- The repository is archived and has zero stars and zero dependents, so no one is stress-testing it, there is no issue history to mine, and nobody will fix a Monolog 3 signature break or a New Relic API change. Runtime concerns include synchronous per-record HTTP calls on the request path, license keys stored as plain config rather than secrets, silent log loss on a regional endpoint mismatch, PII leaving your perimeter to a third-party SaaS, and unbounded ingest cost without sampling or level filtering. Treat it as a code sample to fork, not a dependency to adopt.
- How do I port the New Relic Monolog handler into a Laravel custom log channel?
- Copy the handler class into app/Logging/, wrap it in a custom channel driver registered via Log::extend(), and reference that driver from config/logging.php. Treat the result as first-party code from that moment: pin PHP and Monolog versions, move the license key into env or a secrets manager, and add a contract test asserting a record reaches a mocked New Relic endpoint with the expected payload. That test also protects you when Monolog changes its handler API.