Riemann Logger Laravel Package

Product Decisions This Supports

• Observability architecture: Riemann vs. the modern default. Adopting this package is effectively a bet on Riemann as the event/telemetry backbone for a PHP service. That is a real architectural fork in the road — most teams today standardize on OpenTelemetry plus Prometheus/Grafana or a managed vendor — and this decision should be made deliberately at the platform level, not quietly inside a feature team.
• Build vs. buy (or rather, build vs. wrap). The package is a thin convenience layer over trademachines/riemann-client-php. The build-vs-buy question is narrow: is a small adapter worth a dependency, or is ~100 lines of in-house glue (a Monolog handler or Laravel log channel) cheaper to own? For a layer this thin, in-house ownership is often the better economics.
• Feature-level: shipping business events as first-class telemetry. If the roadmap includes alerting on domain events (order failures, payment latency, queue backlog) rather than just infra metrics, a logger-to-event-stream bridge is the enabling capability. This package is one implementation of that capability, not the capability itself.
• Laravel standardization. If adopted, it becomes part of the standard service template — which means every new Laravel service inherits the Riemann dependency, the config surface, and the operational burden of running Riemann infrastructure.
• Legacy continuity. The most defensible use case is an organization that already operates Riemann and wants PHP/Laravel services to participate without bespoke integration work per service.
• Diligence flag for the roadmap: zero stars, zero dependents, and a score of 0 mean this is unproven in the wild. Any decision to depend on it should be gated on a maintenance and compatibility review (PHP/Laravel version constraints, test coverage, last commit, whether the parent riemann-client-php is actively maintained).

When to Consider This Package

Consider it when:

• You already run Riemann in production and have teams who know how to operate it — the marginal cost of this dependency is then genuinely low.
• Your stack is Laravel/PHP and you want events flowing into the existing Riemann streams with minimal per-service integration code.
• You need a short, reversible proof of concept: a thin adapter is easy to swap out later if you keep the emission points behind your own interface.
• The maintainer relationship is acceptable to you (internal fork, willingness to vendor or patch).

Look elsewhere when:

• You do not already operate Riemann. Standing up Riemann solely to justify this package is almost certainly the wrong trade against OpenTelemetry, Prometheus, or a managed observability vendor.
• You need distributed tracing, not just events — this is a logging/event bridge, not a tracing solution.
• Vendor neutrality matters. A thin, single-maintainer, zero-adoption package is a poor foundation for a cross-team standard.
• You require support contracts, security review evidence, or long-term maintenance guarantees. Score 0 and no dependents means you are the first real user; assume you will be maintaining it.
• Compatibility with your PHP and Laravel versions is unverified. Treat version constraints as unknown until proven in a spike.

Recommendation shape: treat this as a use-case-specific adapter, not a platform commitment. Prototype behind an internal TelemetryEmitter interface so the underlying choice stays reversible.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free open-source connector that lets our Laravel services send application events into Riemann, the monitoring system that turns raw signals into dashboards and alerts. It is not a new platform and it costs nothing to license. Its value depends entirely on whether we already run Riemann — if we do, it saves us writing and maintaining per-service integration code; if we don't, the real cost is standing up and operating Riemann itself, which is a much larger decision than this package. Given the package has no meaningful public adoption, I'd position it as a time-boxed pilot with a defined exit, not a standard.

To engineering (one paragraph): trademachines/riemann-logger is a convenience wrapper over trademachines/riemann-client-php that lets us emit Riemann events from Laravel without hand-rolling a client. Before we adopt: verify PHP/Laravel version support, check the last commit and issue activity on both this repo and the parent client, and read the source — it's thin enough to audit in an hour. If it holds up, integrate it behind an interface we own (emitter abstraction plus a Monolog handler or log channel) so we can swap to OpenTelemetry later without touching call sites. If it doesn't hold up, our fallback is the parent client directly or a small in-house adapter — the wrapper is not load-bearing.