Weave Code
Symfony Metrics Laravel Package
quiet-metrics/symfony-metrics
Symfony bundle that integrates Quiet Metrics into Symfony applications, providing service wiring and configuration for collecting and exposing application metrics to support monitoring, reporting, and observability.
Bundle Symfony du SDK Quiet Metrics (QuietSystems) : pageviews serveur automatiques via kernel.terminate et configuration sémantique.
Frequently asked questions about Symfony Metrics
- How do I install quiet-metrics/symfony-metrics?
- Install it with Composer via composer require quiet-metrics/symfony-metrics, then make sure the bundle is registered in config/bundles.php, which Symfony Flex usually handles automatically. Because the bundle depends on quiet-metrics/php-metrics ^0.6, Composer will pull that library in as well, so watch for conflicts if another package pins an older version. After registration, add the bundle configuration for your collectors and reporters and clear the cache.
- Does quiet-metrics/symfony-metrics work with Laravel?
- No. This is a Symfony bundle: its v0.6.0 SEO endpoint is implemented as a kernel.request listener at priority 200, and wiring happens through the Symfony service container, tagging, and autowiring. A Laravel application would need a separate adapter, such as a global middleware registered with equivalent early ordering and configuration read from config/*.php rather than a runtime env() call. Confirm which runtime you are actually targeting before adding it to a Laravel project.
- Which PHP and Symfony versions does this bundle support, and how tight is the constraint?
- The package overview does not list supported Symfony or PHP versions, so check composer.json before planning an upgrade. The one hard floor stated is quiet-metrics/php-metrics ^0.6; on a 0.x caret constraint that pins the dependency to 0.6.x, which is reasonably tight. Because the library is pre-1.0, minor releases can still carry behavioral changes, and any other package pinning php-metrics below 0.6 will conflict.
- How do I register custom collectors and reporters with the bundle?
- Collectors and reporters are ordinary Symfony services configured through the bundle, so you can define them in services.yaml and rely on tagging and autowiring instead of manual instantiation. The bundle handles the container wiring so the metrics pipeline is built once and injected where it is needed. Check the bundle configuration reference for the exact keys that enable each collector and reporter.
- What is the /.well-known/quietmetrics.json endpoint added in v0.6.0?
- It is an opt-in HTTP endpoint served by SiteVerificationListener on kernel.request at priority 200 that returns the site-ownership proof consumed by the Quiet Metrics SEO tab. It is gated twice: nothing is served unless seo_crawl is true (the default is false) and secret_key is set. It is a listener rather than a routed controller so it can answer before the firewall and session stack, which also means it lives outside your normal middleware and authorization layers.
- Is the well-known SEO verification endpoint a security risk?
- The endpoint must be reachable without authentication, so no auth, rate limiting, or CSRF protection applies to it and it deliberately runs ahead of the session and firewall. The single most important question to close before enabling it is what the body contains: a derived or hashed proof is acceptable, but if it returns the raw secret_key you are publishing a credential on a public path and should escalate to a security review. Also confirm the handler does no I/O beyond returning a static value and that the proof can be rotated independently of your other secrets.
- Why must seo_crawl use the bool: env processor?
- In Symfony, a plain env placeholder for QUIET_METRICS_SEO_CRAWL resolves to the string 'false', which is truthy in PHP, so a hand-written placeholder without the processor can silently enable a public endpoint. Always use the bool: processor form, env(bool:QUIET_METRICS_SEO_CRAWL), and keep that form in documentation and example configs. Configuration drift here is the easiest way to turn the feature on by accident.
- What console commands does quiet-metrics/symfony-metrics add?
- The bundle registers console commands for inspecting the configured collectors and reporters and for exporting collected metrics, which is handy for smoke-testing a configuration before wiring it into a dashboard. Run bin/console list and look for the Quiet Metrics namespace to see exactly what is available in your installed version. Command names and options can change between 0.x releases, so pin the version your tooling depends on.
- How do I test the metrics integration and the well-known endpoint?
- Use Symfony KernelTestCase or WebTestCase with a test environment that enables the bundle, then assert that your collectors are present in the container and that the listener behaves as expected. Verify the pass-through case first: with seo_crawl false, or true with an empty secret_key, requests should reach your normal routing. Then check GET and HEAD requests, query strings, trailing slashes, and Accept headers other than application/json, and confirm the Cache-Control, Pragma, and nosniff headers you expect.
- What should I check before enabling this in production?
- Keep seo_crawl at its false default until you have confirmed the response body, the rotation story for secret_key, and the exact behavior when seo_crawl is true but secret_key is empty. Remember the listener runs at priority 200 ahead of the firewall and session with no rate limiting, and the path is fixed at /.well-known/quietmetrics.json, so it will shadow any application route or reverse-proxy rule at the same path. On multi-tenant or multi-domain installs sharing one config, the same proof answers on every host bound to that app. If you need richer metric reporting, compare it against dedicated observability exporters before committing.
Weaver
How can I help you explore Laravel packages today?