Weave Code
App Metrics Laravel Laravel Package
avto-dev/app-metrics-laravel
Laravel package for collecting and exposing application metrics, with built-in integrations for Prometheus and other backends. Adds middleware and service providers to track requests, responses, and custom counters, helping you monitor performance and health with minimal setup.
avto-dev/app-metrics-laravel is a Laravel integration for collecting and exposing application metrics. It wires the underlying metrics library into Laravel’s container, providing a service provider, publishable configuration, and a convenient Facade for instrumenting application code.
- Auto-discovered service provider and config
- Middleware for HTTP request metrics
- Simple Facade/helper API for custom counters, gauges, and timings
- Configurable metrics endpoint for scraping/export
- Laravel-friendly setup for local and production environments
Frequently asked questions about App Metrics Laravel
- Does avto-dev/app-metrics-laravel support Laravel 11, 12, and 13?
- Yes. Release 2.10.0 declares support for Laravel ^11.0 through 13.x, so it fits a modern Laravel estate. Note that Laravel 13 support is a constraint addition at this stage, so confirm it is GA and covered by CI before relying on it in production. Laravel 10 and earlier are not supported by this release.
- How do I install avto-dev/app-metrics-laravel in a Laravel application?
- Install it as a standard Composer dependency with composer require avto-dev/app-metrics-laravel. Laravel package auto-discovery registers the service provider, and you publish the configuration file to adjust metric settings. Then add counters, gauges, and timing metrics in your application code and expose them to your monitoring stack.
- Can I use this package on Laravel 10 or older?
- No. v2.10.0 requires Laravel ^11.0 or newer, so Laravel 10 applications cannot consume it. Pin the package to the last release that supports Laravel 10, complete the framework upgrade, then lift the pin. Treat the package bump as part of the upgrade programme rather than a standalone change.
- What PHP runtime version does this package require?
- The published release notes do not state the runtime PHP constraint, so check the require section of the package's composer.json. The Docker image used for development now runs PHP 8.5, but that is contributor tooling rather than a guaranteed runtime requirement. Confirm your application's PHP version meets or exceeds the declared constraint before upgrading.
- What kinds of metrics can I collect with this package?
- The package provides counters, gauges, and timing metrics, covering both runtime and business data. You add them with minimal setup and Laravel-friendly configuration, then expose them for monitoring and observability. That makes it suitable for request counts, latency measurements, and domain-specific values.
- Is Laravel 13 support in v2.10.0 production-ready?
- Treat it as a candidate rather than a guarantee. Laravel 13 support appears to be a declarative constraint addition, so wait until Laravel 13 is GA and the package has real CI coverage against it. Validate against the exact Laravel 13 minor version you plan to run before adopting.
- Why did the Laravel 10 support drop ship as a minor release (2.10.0)?
- That is a semver concern. Raising the minimum from Laravel 10 to ^11.0 in a minor release means teams with permissive constraints like ^2.0 could pull v2.10.0 and hit a Composer resolution failure or a runtime incompatibility. Pin the package version explicitly and check whether a 3.0.0 major is planned.
- How do I stop Composer from pulling v2.10.0 into a Laravel 10 application?
- Pin the package to a known-good version in composer.json and commit composer.lock. Avoid permissive constraints such as ^2.0 until the framework upgrade is complete, and enforce the lock file in CI. This prevents an unintended pull of v2.10.0 during a routine composer update.
- How should I test and roll out the package upgrade in production?
- Upgrade Laravel on one representative service first and run the full test suite. Then bump the package constraint in a branch, re-run tests, and exercise integration points in staging before rolling out per service. Watch error rates and logs during rollout, and validate against the exact Laravel minor version in use.
- How does this package fit into an existing Laravel upgrade programme?
- It slots into an existing upgrade programme rather than driving one, because the release is dependency-matrix work rather than feature work. Check that the full transitive dependency graph resolves, especially packages lagging on Laravel 13 or capping PHP below 8.2 or 8.3. Also confirm no first-party code depends on behaviour that changed between Laravel 10 and 11 or 12.
Weaver
How can I help you explore Laravel packages today?