- How do I install ns3777k/prometheus-bundle in a Symfony application?
- Install it with Composer using composer require ns3777k/prometheus-bundle. It pulls in promphp/prometheus_client_php as the underlying metrics client and registers as a standard Symfony bundle, so with Symfony Flex it is usually enabled automatically; otherwise add it to config/bundles.php. After installation, create a bundle configuration file (for example config/packages/prometheus.yaml) to set the storage adapter, namespace, and endpoint options. This package is a Symfony bundle, not a Laravel package.
- Does this package work with Laravel?
- No. ns3777k/prometheus-bundle is built specifically for Symfony: it relies on the Symfony bundle system, dependency injection autowiring, and bundle configuration to expose its metric registry and collectors. Laravel applications should instead use promphp/prometheus_client_php directly or a Laravel-specific Prometheus wrapper. Trying to drop this bundle into Laravel will not give you the autowired registry or the configured exposition endpoint.
- How do I configure the /metrics exposition endpoint?
- The bundle exposes a configurable metrics route, typically served at /metrics, that renders all registered metrics in the Prometheus text exposition format. You control the path and related options through the bundle configuration in your Symfony config directory. Then add a scrape target in prometheus.yml pointing at that path on each application host. Because the endpoint is a normal Symfony route, standard access control, firewalls, or IP restrictions can be applied to it.
- Which metric types can I record with this bundle?
- It supports the three core Prometheus metric types provided by the underlying client: counters, gauges, and histograms. Counters are for monotonically increasing values such as request totals, gauges for values that go up and down such as queue depth, and histograms for distributions such as request durations. Metric collectors and the registry are registered as Symfony services, so you can inject them wherever you need to record values.
- Which storage adapters are supported for the metrics?
- The bundle supports Redis, APCu, and in-memory storage adapters, configured through the bundle configuration. The in-memory adapter is process-local, so metrics recorded in one request are not visible to the /metrics request handled by another worker; it is best suited to tests and CLI tooling. For PHP-FPM or multi-process setups you should use APCu (per server) or Redis (shared across servers) so that scraped values reflect all traffic.
- How do I set a namespace for the metric names?
- The bundle configuration lets you define a metric namespace, which is passed to the storage adapter and prefixed to every metric name. This is useful when several applications or services share one Redis instance or report to the same Prometheus server, because it keeps metric names from colliding. Choose a stable namespace up front, since renaming it later changes metric names and breaks existing dashboards and alerts.
- How do I instrument a service or controller with counters and histograms?
- Because the metric registry and collectors are registered as services, you can autowire them into the constructor of any service or controller and update metrics from normal application code. A typical pattern is a counter incremented at the start or end of an action and a histogram observing elapsed time in a finally block. Keep metric labels limited to low-cardinality values such as route names or status codes, and never use user IDs, emails, or raw URLs as labels.
- Which Symfony and PHP versions does this bundle support?
- Compatibility is defined by the require constraints in the package's composer.json, which pin the supported Symfony component versions and PHP version. Before upgrading Symfony or PHP, check those constraints and confirm the bundle has a release that matches your target, since it depends on Symfony bundle and dependency injection features. If your framework version is newer than the supported range, test on a staging branch or consider calling promphp/prometheus_client_php directly.
- How can I test Prometheus metrics without Redis or APCu?
- Configure the in-memory storage adapter in your test environment so metrics are held in the process and require no external services. Remember that in-memory storage is process-local, so metrics do not carry across requests or between test cases; reset or rebuild the registry between tests to avoid leaking state. You can then assert on recorded counter, gauge, and histogram values inside functional tests, and also exercise the metrics endpoint to confirm the exposition output renders.
- Is this bundle suitable for production, and is it actively maintained?
- The bundle is a thin integration layer over promphp/prometheus_client_php, so its runtime behaviour and reliability largely depend on the chosen storage adapter and on that client library. For production, prefer Redis when you run multiple servers, keep label cardinality low, and consider protecting the metrics endpoint. It is a small, focused package, so before adopting it check the repository's recent commit activity, open issues, and tagged releases against your Symfony and PHP versions. If the bundle lags behind your framework, using promphp/prometheus_client_php directly with your own service definitions is a reasonable alternative.