Weave Code
Octane Exporter Laravel Package
renoki-co/octane-exporter
Prometheus exporter for Laravel Octane that surfaces worker and server metrics such as memory usage, request counts, and worker health, so you can monitor Octane-powered Laravel apps with your existing Prometheus and Grafana setup.
Export Laravel Octane metrics using this Prometheus exporter.
Frequently asked questions about Octane Exporter
- How do I install renoki-co/octane-exporter in a Laravel Octane application?
- Install it with Composer using composer require renoki-co/octane-exporter, then publish the package config file so you can control the metrics route and middleware. Register the package service provider and expose the metrics route, optionally wrapping it in middleware for access control. There are no database migrations, queue workers, or external service dependencies, so the whole setup is measured in hours rather than sprints. The main decision is where the endpoint lives rather than how to wire it.
- Which Laravel and PHP versions does octane-exporter support?
- The package supports Laravel 8.x, and the 1.1.0 release adds Laravel 9 support alongside OpenSwoole support. Because Laravel 9 raises the minimum PHP version, confirm whether your services are on PHP 8.0.2 or newer before upgrading. Pin both the package version and your laravel/octane version, and record the combination in your compatibility matrix. Applications still on PHP 7.4 should stay on the older Laravel and package line.
- What metrics does the Laravel Octane Prometheus exporter expose?
- It serializes Octane in-process server metrics into Prometheus exposition format, covering worker state, request counts, memory usage, and uptime. It is deliberately narrow in scope: no dashboards, no metrics storage, and no alerting, so it composes with your existing Prometheus and Grafana stack instead of competing with it. Think of it as one more scrape target rather than an APM tool. The metric field availability can differ subtly between Swoole and OpenSwoole runtimes.
- Is the octane-exporter metrics endpoint safe to expose publicly?
- No. The endpoint returns internal worker memory and traffic data, which is reconnaissance-grade information if it is reachable from the internet. Treat restricting the route as a security control rather than a configuration detail, and serve it on a dedicated internal route or a separate host and port behind your load balancer. The package does not provide authentication out of the box, so gate it with middleware or network policy.
- Does renoki-co/octane-exporter work with OpenSwoole?
- Version 1.1.0 declares OpenSwoole support, but a declared support is not the same as validation against your pinned openswoole extension and laravel/octane versions. OpenSwoole is a fork of Swoole with a diverging extension API, so some metric fields may be missing or subtly different. Pilot the exporter on one non-critical Octane service first and confirm the actual metric surface before rolling it out. Also verify whether metric names and label sets are stable across the Swoole to OpenSwoole switch, since changes will break existing dashboards and alerts.
- How do I configure Prometheus to scrape the Laravel Octane exporter?
- Add a scrape job in your prometheus.yml under scrape_configs pointing at the metrics route exposed by the package, using the path from the published config file. If you isolate the endpoint on a dedicated host or port, target that listener rather than the public application port. Reload Prometheus and check the targets page to confirm the scrape is healthy and the Octane metrics appear. Set the scrape interval conservatively so you do not add unnecessary load to your Octane workers.
- Can I use octane-exporter if my app runs on php-fpm instead of Octane?
- No, or at least not usefully. The package exposes Octane-specific internals such as worker state, worker memory, and per-worker request counts, which do not exist under php-fpm. On a php-fpm deployment it has little to say about your application, and you should look at php-fpm exporter or standard Laravel instrumentation instead. It is designed for Laravel applications already running Octane on Swoole or OpenSwoole.
- Why do my Prometheus scrapes of Octane metrics time out under load?
- The metrics endpoint is served by the same Octane workers that handle user traffic, so under saturation scrapes can time out. That produces false service down alerts, because the exporter failure mode masquerades as an application outage. Consider isolating the metrics listener, adjusting scrape timeouts and intervals, or alerting on scrape staleness rather than a hard failure. Do not treat a metrics scrape failure as proof that the service itself is down.
- What is the difference between octane-exporter and OpenTelemetry or a full APM tool?
- octane-exporter is a pull-based Prometheus metrics source for Laravel Octane, not an APM platform. It provides no dashboards, no storage, no tracing, and no alerting, which is why it slots cleanly alongside an existing Prometheus and Grafana or OpenTelemetry collector stack. If your team has standardized on OpenTelemetry SDK instrumentation, adding this second parallel metrics path may increase cognitive overhead for marginal gain. It is the right fit when Prometheus already scrapes your estate and you want Octane internals without a separate exporter container or agent.
- Is renoki-co/octane-exporter actively maintained, and how should I pin it?
- The package has a small maintainer footprint, so confirm the release cadence and maintenance posture before adopting it broadly. Pin the exact Composer version and record the combination of Laravel version, PHP version, laravel/octane version, and swoole or openswoole extension that you validated. Keep the exporter adoption separate from any OpenSwoole runtime migration so you are not conflating two failure domains in a single change. Review release notes for each bump, since metric names and label sets are part of your dashboard and alert contract.
Weaver
How can I help you explore Laravel packages today?