Logger Laravel Package

Getting Started

Before anything else, treat this as a research task, not an install task. The package advertises Elasticsearch-backed logging, but with zero stars, zero dependents, and a last release in December 2017, you are effectively adopting an unmaintained beta. Confirm the following in order:

1. Verify the package is installable. The repo is modpreneur/trinity-logger but the package name is trinity/logger. Check composer.json inside the repo for the real name, type, and require block before running composer require trinity/logger. If it isn't on Packagist, you'll need a VCS repository entry:

   "repositories": [{ "type": "vcs", "url": "https://github.com/modpreneur/trinity-logger" }]
   

   Then composer require trinity/logger:dev-master — and expect Composer to complain about PHP/Laravel version constraints, because a 2017 bundle almost certainly caps at Laravel 5.x and PHP 7.0/7.1.

2. Read the service provider and config first. Open the bundle's *ServiceProvider.php, its config/ directory, and the README (if one exists). The three things you need to extract immediately are: which Elasticsearch client version it wraps (likely elasticsearch/elasticsearch 2.x or 5.x — the ES 7/8 clients are wire-incompatible), what config keys it expects (host, port, index, type), and whether it registers a Monolog handler or a custom Log channel.

3. Configure a single target index and host. Copy the package config into config/trinity-logger.php (or whatever the provider publishes via php artisan vendor:publish), then point it at a local Elasticsearch container:

   // config/trinity-logger.php (shape will vary — match the package's keys)
   return [
       'hosts' => [env('ELASTIC_HOST', '127.0.0.1:9200')],
       'index' => env('ELASTIC_LOG_INDEX', 'laravel-logs'),
   ];
   

4. First use case: a smoke test, not production. Wire the package's handler into a single non-critical channel and write one structured entry:

   Log::channel('elastic')->info('trinity smoke test', [
       'user_id' => 1,
       'route'   => 'GET /health',
   ]);
   

   Then hit GET /<index>/_search on the cluster directly with curl to confirm the document landed. Do not trust the package's own "it worked" path — verify at the index level.

If steps 1–3 fail (missing composer constraints, no ES 6+ compatibility, no PHP 8 support), stop and pivot to the alternatives in the Gotchas section. That is a legitimate outcome of this assessment.

Implementation Patterns

If the package does install, these are the patterns that make it tolerable in day-to-day work.

Isolate it behind a logging channel, never call it directly. The package is a transport detail. Keep your application code on Log::info() / Log::error() and let a dedicated channel route to Elasticsearch. That way swapping the package out later is a config change, not a find-and-replace:

// config/logging.php
'channels' => [
    'elastic' => [
        'driver'  => 'monolog',
        'handler' => Trinity\Logger\Handlers\ElasticHandler::class,
        'handler_with' => [
            'client' => app(Trinity\Logger\Client::class),
        ],
        'level' => 'info',
    ],
],

(Class names above are illustrative — substitute whatever the provider actually binds. The pattern is what matters: one channel, one handler, app code stays on the Log facade.)

Always log arrays, never interpolated strings. Elasticsearch's value is structured search. Log::info("user $id did $thing") gives you an unsearchable blob. Use the context argument so each key becomes a queryable field:

Log::channel('elastic')->warning('payment retry', [
    'order_id'   => $order->id,
    'attempt'    => $attempt,
    'gateway'    => 'stripe',
    'latency_ms' => $latency,
]);

Use per-environment and per-day indices. Sharing an index between local, staging, and prod is the fastest way to make the cluster useless. Drive the index name from APP_ENV and, if the package supports suffixing, append a date (laravel-logs-2024.01.15) so retention is a curator/ILM job rather than a manual delete.

Route only the channels that benefit. Elasticsearch is a poor fit for high-volume debug chatter and an excellent fit for audit trails, security events, and error/exception records. Typical split:

Wrap the logging call site, not the package. Even in the happy path, a network call to ES on every log line is a latency and availability risk. Either push through a queue (Log::channel('elastic') inside a queued listener) or accept the package's synchronous behaviour knowingly. Never let a failed log write throw into a request that was otherwise succeeding — a try/catch around the context-building helper is cheap insurance.

Gotchas and Tips

This package is abandoned. Last release 2017-12-13, zero dependents, zero stars. There is no maintenance path for Laravel 9/10/11, PHP 8.x, or Elasticsearch 7/8 (which removed mapping types — the _type concept the 2017-era client relies on is gone). Before investing an hour, run composer require in a throwaway branch and read the dependency resolution errors. They will tell you more than the README will.

Version-skew is the #1 failure mode, and it fails silently. An old elasticsearch/elasticsearch client talking to an ES 7+ node typically gets a 400 with a type is illegal or mapping type is missing error — but if the handler swallows exceptions, you get no logs at all and no error either. Always verify by querying the index directly after your first write.

Silent drop on cluster unavailability. Logging libraries are usually written to never break the app, which means a down ES cluster produces zero logs and zero alerts. Add an out-of-band check (a /health probe that queries _cluster/health and a metric on your log volume) so "we lost logging" is detectable.

Mapping and field explosion. Elasticsearch creates a mapping from the first document it sees. Log a context array with dynamic keys (["user_{$id}" => ...]) and you'll blow past the default 1000-field limit and get a hard rejection. Keep context keys a fixed, documented vocabulary; pre-create the index template with explicit mappings for the fields you query on.

Don't log secrets into an index that many people can read. ES has weak per-document access control by default. If request bodies or headers are in your context, you're one _search away from leaking tokens. Add a context scrubber (Laravel's Log::withContext plus a redaction helper) before handing data to the handler.

Namespace and autoload surprises. With a 2017 bundle, check whether it's PSR-4 or PSR-0, and whether the provider is auto-discovered. On Laravel 5.5+ it may register itself; on older or heavily customized setups you'll need to add it to config/app.php providers manually — but on modern Laravel, manual registration isn't the issue, package incompatibility is.

When to walk away. If you're on Laravel 8+ and need ES logging today, the maintained route is a modern client (elastic/elasticsearch 8.x) plus a small custom Monolog handler (~80 lines: extends AbstractProcessingHandler, write() → $client->index([...])), or a maintained alternative like elasticsearch/elasticsearch wrappers, laravel-elasticsearch, or shipping logs to ES via Filebeat/Fluent Bit and keeping the app on plain daily files. That last option is usually the better architecture anyway: it decouples log shipping from request latency, survives ES outages, and doesn't require touching composer.json.

Bottom line: treat trinity/logger as a reference implementation to read for the ES-indexing pattern, not a dependency to adopt. The day-to-day leverage you'd get from it is real — structured, searchable logs — but you can get the same thing from ~80 lines of Monolog handler code that you control and that runs on ES 8.