jmonitor/collector
jmonitor/collector is a Laravel package for capturing application monitoring data such as requests, database queries, jobs, exceptions, and performance timings, then forwarding it to JMonitor for centralized visibility, alerting, and debugging with low overhead.
vv-prefixed version strings matters specifically for PaaS builds (e.g. Clever Cloud), so it de-risks "we can't see versions on our host" findings during a platform review.CONFIG GET no longer crashes collection when no logger is supplied — is a direct signal that the package is being hardened for managed Redis (ElastiCache, Upstash, Heroku, Scalingo) where CONFIG is commonly disabled. That turns "our managed Redis breaks the dashboard" from a blocker into a non-event.Consider adoption when:
CONFIG GET may be unavailable — v2.3.1 explicitly handles this without crashing.Look elsewhere when:
For executives: This is a low-cost reliability improvement with no migration effort. The latest patch hardens the package against real infrastructure quirks — locked-down managed Redis and PaaS builds that report versions in nonstandard formats — so our monitoring stops going blind exactly where we have the least control. No breaking changes, no config changes; it is a routine upgrade that reduces the chance of a monitoring gap during an incident.
For engineering: Adopt the collectors instead of maintaining custom version-scraping and Redis health checks. v2.3.1 makes three things true that were previously fragile: a disabled CONFIG GET no longer throws during collection, Clever Cloud-style vv1.12.7 version strings now parse correctly, and unparseable version output is logged (truncated to 500 chars) so a missing version is visible and debuggable rather than silent. Upgrade is patch-level and safe to fold into the next deploy; the only behavioral change is additional notice-level logging on failure paths.
How can I help you explore Laravel packages today?