- How do I install ytake/laravel-fluent-logger in a Laravel app?
- Run composer require ytake/laravel-fluent-logger, then publish the package config so you have the fluent channel settings available. Add a fluent channel entry to config/logging.php and reference it from a stack or as your chosen channel. For Lumen you must register the service provider manually in bootstrap/app.php. Most of the real work happens on the Fluentd side with tag routing and output configuration, not in the PHP package.
- How do I configure the Fluentd channel in config/logging.php?
- The package registers a custom log driver that wraps a Monolog handler built on the official fluent/logger client, so you add a channel entry with that driver name plus host, port and tag options. Point host at your td-agent or Fluentd instance and use the default forward protocol port 24224, or a Unix socket path if you prefer. Then attach the channel to a stack alongside your existing daily or stderr channel rather than replacing the default. This keeps a rollback path: drop the channel from the stack and you are back to the previous behavior.
- Does ytake/laravel-fluent-logger support Monolog 3 and Laravel 10 or 11?
- Do not assume it does; check the illuminate/*, monolog/monolog and php constraints in the package composer.json before committing. Monolog 3 changed handler contracts and removed legacy behavior, so a handler written against Monolog 1 or 2 can install cleanly and still break at runtime. Verify the handler extends AbstractProcessingHandler in a Monolog-3-compatible way and run a real write to Fluentd in a staging environment. If the constraint blocks installation, forking and vendoring the small handler is the cheapest fix.
- What happens when Fluentd is unreachable or the network is slow?
- The forward protocol is synchronous, so a failed connection typically surfaces as an exception or a block until the configured timeout expires. The package is a thin adapter with no meaningful buffering, so a slow or dead Fluentd endpoint can affect request latency. Ask whether your configured handler throws, swallows or retries, and set explicit connect and write timeouts. Attaching the fluent channel to a stack with a local file or stderr channel gives you a fallback if the network hop fails.
- Is this package safe with Laravel Octane, RoadRunner or Swoole?
- Long-lived workers are the risk area: a naively cached client or open connection can go stale after a fork or after idling, producing silent loss or exceptions inside the worker. Check whether the client is created per record, per request or as a singleton, and whether it reconnects after failure. Under Octane you may need to reset the handler or connection in a worker lifecycle hook. Test an idle-then-write cycle explicitly, because it is the case most likely to fail in production.
- Does this package block the request and hurt performance?
- Yes, logging becomes a network operation on the critical path because the fluent-logger client sends each record over TCP or a Unix socket using the synchronous forward protocol. The cost is usually small on a co-located td-agent but noticeable across a network hop or when Fluentd is under pressure. There is no batching or bounded buffer in the package itself, so throughput and backpressure are Fluentd's problem. Keep timeouts short and consider a local agent socket rather than a remote host.
- Should I use this package in Docker or Kubernetes deployments?
- Usually not as the primary path. The container convention is to write logs to stdout or stderr and let a node-level Fluent Bit or Fluentd DaemonSet collect them, which this package bypasses by making the PHP process a network client. It fits naturally on VMs or bare metal where a td-agent runs alongside the application. If you already operate Fluentd centrally and want tag-based routing to Elasticsearch, BigQuery, S3 or Kafka without writing a handler, it is a reasonable additional channel even in containers.
- Is ytake/laravel-fluent-logger actively maintained?
- Treat it as a small, low-traffic package: modest star count, effectively one maintainer and few dependents, so the bus factor is the dominant risk. The code is MIT licensed and only a few hundred lines, which makes forking and vendoring cheap if the maintainer goes quiet. Check release cadence and issue-response history, and confirm whether recent tags are substantive or metadata bumps. Adopt the pattern more than the vendor, and pin the version you have tested.
- What are the alternatives to ytake/laravel-fluent-logger?
- You can write a small custom Monolog handler around the official fluent/logger client yourself, which gives you full control over connection lifecycle and timeouts. The other common pattern is stdout logging plus a Fluent Bit or Fluentd DaemonSet, which avoids a network hop in the PHP process entirely. If your platform team already standardizes on a specific collector, follow that rather than adding a second pipeline. For simple needs, Fluentd's own HTTP input with a standard Laravel HTTP-based log channel can also work.
- How do I add Fluentd logging without breaking existing logs?
- Do not swap your default channel. Add fluent as an additional channel and attach it to a stack next to your existing daily or stderr channel for a defined overlap period. Verify records arrive in Fluentd using the configured tag before you rely on it, then remove the old channel only after the overlap proves stable. Because the fluent handler can throw on connection failure, keeping a second channel in the stack preserves local visibility during the transition. This gives you a zero-downtime rollback: drop the fluent channel and behavior returns to the previous state.