Weave Code
Jmonitor Bundle Laravel Package
jmonitor/jmonitor-bundle
JMonitor Bundle offers a packaged integration for bringing JMonitor monitoring into PHP applications. It provides bundle-style configuration to help connect your project to JMonitor services, centralize setup, and simplify adding monitoring to existing Composer-based projects.
Easy monitoring for PHP web server and Symfony
Frequently asked questions about Jmonitor Bundle
- Can I install jmonitor/jmonitor-bundle in a Laravel application?
- No. It is a Symfony bundle that is registered through config/bundles.php and the Symfony kernel, and Laravel has no equivalent bundle loader. Composer may resolve the dependency, but you will not get a working dashboard or health endpoint inside a Laravel app.
- Does jmonitor/jmonitor-bundle support Laravel 10 or 11?
- There is no Laravel support in any version of this package. Its collectors are coupled to Symfony component APIs such as Flex, Scheduler, and Messenger rather than to generic system primitives, so there is no service provider, config file, or facade to publish. Laravel version numbers make no difference to compatibility here.
- How do I install and configure jmonitor/jmonitor-bundle in a Symfony project?
- Require the package with Composer, enable the bundle in config/bundles.php, and configure which collectors and status endpoints are exposed. In a Symfony codebase this is typically under a day of work, and most of that time goes into deciding what data to expose rather than into wiring.
- Can I write custom collectors for jmonitor/jmonitor-bundle?
- Yes, the bundle advertises extensible collectors for custom metrics. In practice those collectors are written against Symfony component APIs, so the effort does not transfer to a Laravel application. Treat collector work as an investment in a Symfony estate, not a portable integration layer.
- Is the JMonitor metrics endpoint safe to expose in production?
- Review it carefully before exposing anything publicly. The endpoint reports hostnames, kernel versions, disk layout, PHP configuration, the full scheduled-job inventory, and message-queue topology, and as of v2.2.0 scheduled task arguments are exported as a first-class field. Command arguments routinely carry paths, environment names, and occasionally tokens, so plan argument redaction and network-level restriction rather than only host fingerprinting.
- How do I run JMonitor alongside a Laravel application?
- The workable pattern is a standalone Symfony worker instance per host, scraped centrally, because the valuable telemetry is Symfony-specific. That worker is a supervised long-running daemon with a boot lifecycle, not a stateless request handler or a one-line container. Scraping a plain PHP-FPM host on its own will not produce the framework-level data.
- Why does my JMonitor dashboard stay green when a component is failing?
- Since v2.2.0 a boot-time component error disables only that component until the worker restarts, instead of dropping the whole collector. That is deliberate fault isolation and better than the previous behaviour, but it means a component can report nothing while the endpoint still looks healthy. Add an explicit alert on degraded or disabled component state.
- Is jmonitor/jmonitor-bundle actively maintained?
- Adoption is effectively zero: one GitHub star, no dependents, no community tutorials, and a bus factor of one. Version 2.2.0 is a positive signal because it ships targeted edge-case fixes such as argument parsing, missing commands, and partial-failure isolation rather than feature sprawl. One release is a data point, not a trend, so keep it on your watchlist rather than assuming momentum.
- What should Laravel teams use instead of jmonitor/jmonitor-bundle?
- Purpose-built Laravel tooling is a better fit: Laravel Telescope or Pulse for request and performance insight, combined with an established metrics stack for host and infrastructure health. Keep JMonitor as a reference implementation if you like its collector design. Only adopt it directly if you already operate a Symfony estate and want the same view across both.
- How should I evaluate jmonitor/jmonitor-bundle before adding it to composer.lock?
- Verify release provenance first by reconciling the tag history and confirming commit signing, since the published release dates have looked anomalous. Check whether the maintainer responds to issues and read the changelog for collector behaviour changes such as boot-time component disabling. Given the low adoption, pin exact versions and review diffs before every upgrade.
Weaver
How can I help you explore Laravel packages today?