Weave Code
Collector Laravel Package
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.
Jmonitor is a monitoring service for PHP web stacks. It collects server and application metrics and turns them into readable, premade dashboards and alerts.
Frequently asked questions about Collector
- How do I install jmonitor/collector in a Laravel application?
- Install it with Composer using composer require jmonitor/collector. The package ships a Laravel service provider, so framework package discovery registers it automatically without manual provider edits. Publish the configuration file if you want to change which collectors run or how data is exposed, then add any JMonitor credentials your setup requires.
- Which Laravel versions does jmonitor/collector support?
- The package is Laravel-native and relies on the service container and configuration system, but the supported version range is defined in its composer.json. Check that file and the release notes before committing, since the assessment here is based on the v2.3.1 notes rather than a full dependency audit. If you are pinned to an older Laravel release, verify constraints in a staging branch first.
- How do I configure which collectors are enabled?
- Collection is configured through the package's published config file, where collectors are individually enabled or disabled. That per-collector switch keeps the blast radius small, so you can turn on request, query, job, exception, or performance collectors only where you need them. Exposure settings are controlled in the same layer, so review the config before rolling out to production.
- Can I write a custom collector for my own metrics?
- Yes. The architecture is built around pluggable collectors: discrete, named units that each inspect one dependency or data source and emit structured data into a central collection pipeline. To add app-specific data, implement a collector following the same pattern and register it in configuration. Because collectors are additive, custom ones do not require patching the package core.
- Does jmonitor/collector slow down my Laravel application?
- The package is designed to be lightweight, and its collectors sit outside the request hot path and are expected to degrade gracefully when a dependency is unavailable. Some collectors shell out to binaries such as FrankenPHP, Caddy, or Redis, so cost is tied to how often collection runs rather than to every request. Confirm whether your setup schedules collection or runs it per request, since that determines the process-spawn and latency profile.
- How do I test jmonitor/collector without sending data to JMonitor?
- Disable the collectors you do not need in your testing environment config, or point the package at a non-production endpoint. Because some collectors depend on exec-family functions and binaries being on PATH, they will not produce data in slim CI images, so assert on the notice path or mock the collector rather than expecting real version strings. Keep an integration test in staging where the binaries and managed services actually exist.
- How is jmonitor/collector different from Laravel Telescope or Pulse?
- Telescope and Pulse are primarily local debugging and first-party metrics tools, while jmonitor/collector focuses on forwarding captured runtime data to JMonitor for centralized visibility, alerting, and debugging. It is intentionally minimal with few dependencies and an extensible collector layer, so it complements rather than replaces local inspection tooling. If you need an in-app debug UI, keep Telescope; if you need centralized monitoring, this package covers that path.
- Is jmonitor/collector safe to run in production?
- The 2.3.1 changes are low risk and improve robustness: a Redis CONFIG GET failure no longer throws when no logger was supplied, and unparseable version output becomes a diagnostic notice instead of a silent gap. Before rollout, confirm that exec or proc_open is enabled and that the FrankenPHP and Caddy binaries are present on PATH inside your production image. Also check that your managed Redis permits CONFIG GET, since many providers disable it and you will get a permanent unknown with a notice.
- What changed in jmonitor/collector 2.3.1?
- Version 2.3.1 is a patch release with three refinements and no stated removals, signature changes, or migrations. It adds a diagnostic notice, truncated to 500 characters, when FrankenPHP or Caddy version output cannot be parsed, fixes a null-logger crash when Redis CONFIG GET fails, and correctly parses doubled v prefixes such as FrankenPHP vv1.12.7 on Clever Cloud builds. The parsing fix is the clearest signal that version detection is environment-dependent and will need periodic upstream maintenance.
- Should I upgrade from 2.2.x and what should I review first?
- Check your pinned version before deciding, because moving from 2.2.x to 2.3.1 also pulls in the 2.3.0 minor, which introduces the FrankenPHP, Caddy, and Redis collector surface. That turns a patch upgrade into feature adoption and warrants a fuller review of the changelog and composer constraints. Audit any dashboards, alerts, or inventory reports keyed on the version field, since hosts that previously reported blank values will now populate them.
Weaver
How can I help you explore Laravel packages today?