Symfony Open System Monitor Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — so treat it as a library of system-monitoring services you wire up yourself rather than something that auto-discovers. Release 0.1.1 is a patch that only widens the Symfony constraint to include Symfony 8; the API surface is unchanged from 0.1.0.

composer require michallkanak/symfony-open-system-monitor

Where to look first, in order:

1. composer.json — check the symfony/* constraint floor/ceiling. With 0.1.1 you can install against Symfony 7.x or 8.x; on Laravel you'll be resolving against whatever symfony/* components your framework version pins, so run composer why symfony/http-foundation before assuming the install is clean.
2. The bundle class and its DI extension (DependencyInjection/*Extension.php) — this is the authoritative list of what services you actually get and how they're configured.
3. The README's quick-start snippet — it will show Symfony YAML config that does not apply to Laravel.

First use case: a /health or /status endpoint that reports machine-level state (load, memory, disk, uptime) for ops dashboards and uptime probes. Start by resolving one metric service out of the container and dumping it in php artisan tinker before building anything around it.

Implementation Patterns

Resolve services directly from the container. Because there's no Laravel service provider, register the pieces you need in a small SystemMonitorServiceProvider of your own, binding the concrete service classes and any interfaces they satisfy. Keep the bindings lazy — most of these services are cheap to construct but not free to invoke.

Wrap in a controller with a cached payload. The idiomatic Laravel use is:

Route::get('/health', fn () => Cache::remember('sys.health', 30, fn () => [
    'load'  => $monitor->getLoadAverage(),
    'mem'   => $monitor->getMemoryUsage(),
    'disk'  => $monitor->getDiskUsage(),
]));

A 15–60 second TTL turns a per-request cost into a rounding error and keeps your health endpoint honest enough for alerting.

Schedule sampling instead of on-demand reads. If you want history rather than a point-in-time snapshot, run an artisan command on Schedule::everyMinute() that writes samples to a table or a Redis sorted set. This decouples metric collection from request latency and gives you a series to graph.

Wrap the Symfony console command. If the bundle ships a console command, don't try to shoehorn it into Laravel's command registry. Instead write a thin php artisan monitor:report that instantiates the Symfony command, sets the input/output, and runs it — or just call the underlying services directly and skip the command entirely.

Reuse in a shared-codebase setup. If you run Symfony and Laravel apps side by side, put the health-payload assembly in a shared package that consumes this bundle in the Symfony app and consumes the same underlying services in Laravel. That keeps the output schema identical across both.

Gate the endpoint. A health endpoint that lists disk usage and uptime is mild reconnaissance. Put it behind auth/IP allowlist, or emit only a boolean ok publicly and the detail behind authentication.

Gotchas and Tips

• Version pinning. You're on 0.1.x. Composer treats ^0.1 as >=0.1.0 <0.2.0, so patch upgrades are safe, but any 0.2.0 may break you. Pin explicitly if this feeds an alerting pipeline.
• Symfony 8 requires PHP 8.4. Symfony 8 dropped support for older PHP runtime versions. If your Laravel app is on PHP 8.2/8.3, 0.1.1's new constraint is inert for you — you'll resolve against Symfony 7.x and nothing changes. Verify with composer update --dry-run rather than assuming the release unblocks you.
• No config publishing. php artisan vendor:publish will find nothing. Symfony bundle config is a Configuration tree consumed at container compile time; in Laravel you must create your own config/system-monitor.php and feed those values into the constructors yourself.
• bundles.php is irrelevant. Don't copy Symfony installation instructions verbatim — there is no kernel to register the bundle with.
• Container/cgroup reality. Memory and CPU readings on Linux typically come from /proc or sysinfo. Inside Docker or Kubernetes those numbers describe the host, not your container limit, unless the implementation reads cgroup v2 files. Sanity-check a memory reading against memory_limit from php.ini and your pod spec before trusting it in a dashboard.
• Non-Linux and restricted open_basedir. These calls can return false or throw on macOS/Windows or hardened PHP builds. Wrap every metric read in a try/catch and degrade to null — a health endpoint that 500s is worse than one that reports partial data.
• Debugging tip. If a binding fails to resolve, php artisan tinker → app()->make(YourService::class) and inspect the constructor signature. Symfony bundles often type-hint against interfaces that only exist when the bundle's extension has run, so you may need to alias them manually.
• Extension point to watch. If the package exposes a metric-collector interface or an event, that's your cleanest hook for adding app-specific signals (queue depth, failed jobs) to the same payload. Prefer that over subclassing concrete services, which are far more likely to change pre-1.0.
• Evaluate before betting on it. At 0.1.x with a one-line changelog entry as the entire release, the project has thin maintenance signal. If you only need load/memory/disk, a 30-line class reading /proc yourself has fewer moving parts and no upgrade treadmill. Adopt this when you specifically want its formatting or its Symfony-side integration.