Getting Started

Install with composer require tourze/server-stats-bundle. Check composer.json for PHP/Symfony version constraints before adding it to a Laravel app.
First place to look: composer.json, src/, DependencyInjection/, and any Command/ or Controller/ directories. This is a Symfony bundle, so Laravel auto-discovery will not register it automatically.
Minimal Laravel wiring: create a small service provider that binds the bundle’s collector/stat service(s) into the container, or instantiate them directly if the package has no framework coupling.
First use case: register a scheduled command or route that returns basic server stats as JSON — CPU load, memory usage, disk space, uptime — for a status page or uptime monitor.

Implementation Patterns

Health endpoint pattern: wrap the stats collector in a Laravel controller and return a small JSON payload. Keep the response stable and cache it briefly so monitoring probes do not hammer /proc or shell commands.
Scheduled snapshot pattern: run a Laravel scheduled command every minute, collect stats, and write them to cache, Redis, or a server_stats table for later charting.
Threshold alerting pattern: compare collected values against config thresholds and dispatch a Laravel event/notification when memory or disk crosses a limit.
Service-provider bridge: if the bundle exposes Symfony services, bind interfaces to implementations in a Laravel provider and resolve them via the container; avoid using the Symfony kernel directly inside Laravel.
Testing pattern: fake the underlying collector in tests so feature tests do not depend on the host machine’s real CPU/memory values. Assert only the response shape and threshold logic.
Dashboard integration: expose stats through a small internal API and let a frontend poll it; avoid coupling the package directly to Blade views.

Symfony bundle in Laravel: do not assume package discovery works. Manually register services or use a bridge. This is the most likely source of “class not found” or “target not instantiable” errors.
Release 1.0.1 has no detailed changelog — only a compare link. Treat it as a patch release, pin 1.0.1, and review the diff between 1.0.0...1.0.1 before upgrading production. No documented breaking changes, but verify.
Host vs container stats: collectors that read /proc or call system tools may report host-level or misleading values inside Docker/Kubernetes. Test in the same environment you deploy to.
Permissions and binaries: commands such as df, free, or uptime may be missing or restricted in minimal containers. Prefer pure-PHP /proc reads where possible and fail gracefully.
Units and freshness: confirm whether values are bytes vs megabytes, seconds vs milliseconds, and whether results are cached. Normalize units at the boundary of your own API.
Debugging: run the bundle’s console command with -vvv if one exists; otherwise inspect the collector output directly via php artisan tinker. Check /proc/loadavg, /proc/meminfo, and df -h on the host to compare expected values.
Extension points: look for collector interfaces or configurable stat providers. If none exist, wrap the package behind your own ServerStatsService contract so you can swap implementations later without touching controllers or commands.