Octane Exporter Laravel Package

Technical Evaluation

Architecture fit. renoki-co/octane-exporter is a thin observability sidecar for Laravel Octane: it registers a route/middleware that serializes Octane's in-process server metrics (worker state, request counts, memory, uptime) into Prometheus exposition format. Architecturally it is a pull-based metrics source, which fits cleanly alongside an existing Prometheus/Grafana or OpenTelemetry-collector stack without requiring a separate metrics daemon, exporter container, or agent. It is deliberately narrow-scope — no dashboards, no storage, no alerting — so it composes rather than competes. The correct mental model is "one more scrape target," not "an APM tool."

Integration feasibility. High. Installation is Composer-only; wiring is a service provider plus a route (and optionally middleware) with published config. There are no database migrations, no queue workers, no external service dependencies, and no persistent state. For a team already running Octane, effort is measured in hours, not sprints. The main decision is where the endpoint lives (dedicated internal route vs. host/port separation behind the load balancer) rather than how to integrate.

Technical risk. The 1.1.0 release is additive and non-breaking: Laravel 9.x and OpenSwoole support. Three risks remain, none severe:

• OpenSwoole parity. OpenSwoole is a fork of Swoole with a diverging extension API. Support being declared is not the same as validated against your pinned openswoole extension version and Laravel Octane version. Metric field availability can differ subtly between Swoole and OpenSwoole runtimes.
• Endpoint exposure. A metrics route that returns internal worker memory and traffic data is reconnaissance-grade information if publicly reachable. This must be network-restricted; treat it as a security control, not a config detail.
• Scrape contention. The endpoint is served by the same Octane workers handling user traffic. Under saturation, scrapes time out and produce false "service down" alerts — the exporter's failure mode masquerades as an outage.

Key questions for the maintainer / team.

1. Which exact openswoole extension and laravel/octane version combinations are tested in CI for 1.1.0?
2. Does the Laravel 9 bump imply a raised minimum PHP version (8.0.2+) that conflicts with any of our services still on PHP 7.4?
3. Are the exported metric names and label sets stable across the Swoole → OpenSwoole switch, or will existing dashboards/alerts need rewriting?
4. Is the endpoint intended to be exposed on the public app port, or does the package document a recommended isolated listener?
5. What is the release cadence and maintenance posture for this package given its small maintainer footprint?

Integration Approach

Stack fit. Best fit is a Laravel 8/9 application already running Octane on Swoole or OpenSwoole, with Prometheus (or a Prometheus-compatible collector) already scraping the estate. Poor fit if you are on php-fpm (the package exposes Octane-specific internals and has little to say), or if you have standardized on OpenTelemetry SDK instrumentation — in that case adding a second, parallel metrics path increases cognitive overhead for marginal gain.

Migration path. There is no migration in the destructive sense; this is greenfield instrumentation. The only genuine migration vector is the Swoole → OpenSwoole runtime switch, and 1.1.0 makes the exporter viable on the far side of it. Recommended path: (a) pilot the exporter on one non-critical Octane service on the runtime you already use, (b) confirm the metric surface, (c) only then treat OpenSwoole as an option for the wider fleet. Do not couple the OpenSwoole adoption and the exporter adoption into a single change — that conflates two failure domains.

Compatibility. Verify against your matrix explicitly: Laravel 8.x (prior support) vs. 9.x (new), PHP version implied by each, laravel/octane version, and the swoole vs. openswoole extension. Pin the package version and record the matrix in your service catalog. Note that adding Laravel 9 support in a minor release is acceptable under semver only if 8.x remains supported — confirm this rather than assuming it.

Sequencing.

1. Confirm internal-only network path for the scrape endpoint (security review gate — do this first).
2. Add package and config to one pilot service; deploy to staging.
3. Validate scrape success, metric names/labels, and cardinality against a real Prometheus instance.
4. Build dashboards and then alerts — alerts without a burned-in baseline produce noise.
5. Roll out to remaining Octane services.
6. Re-run steps 1–3 on OpenSwoole before treating that runtime as production-ready for the fleet.

Operational Impact

Maintenance. Low steady-state burden: no schema, no state, no background jobs. The maintenance cost is concentrated in version-matrix drift — the package must track Laravel, Octane, and the Swoole/OpenSwoole extension, three independently moving targets. Budget a recurring dependency-review line item rather than assuming it is "set and forget."

Support. The package is community-maintained with a small contributor base; the 1.1.0 change arrives via a single external PR (#18). That is fine for a metrics endpoint and unacceptable for anything on the request-critical path — which is a further argument for keeping the scrape route off the public listener. Establish an internal owner so the "who fixes this when it breaks" question has an answer before, not after, adoption.

Scaling. Scrape cost is constant per instance and independent of request volume — this scales well horizontally as instance count grows, since each pod/VM is an independent target. Cardinality risk is low because metrics are per-worker, not per-user or per-route. The real scaling constraint is Prometheus-side: target count and scrape interval, not the exporter. Watch worker-count-labelled series on large Octane worker pools.

Failure modes.

• Silent staleness: exporter returns last-known values after an Octane restart in some configurations, producing green dashboards over a dead service. Mitigate with a scrape-age / up alert.
• Scrape timeout under load: conflates saturation with outage. Mitigate by alerting on latency and error rate before scrape liveness.
• Information disclosure: publicly reachable metrics endpoint. Mitigate at the network layer.
• Runtime mismatch: exporter reports partial or missing fields on an untested Swoole/OpenSwoole version, yielding misleading zero-values rather than errors. Mitigate with a startup smoke check in CI.

Ramp-up. Genuinely small: a mid-level Laravel engineer can integrate and validate in under a day. The non-obvious onboarding cost is interpretation — the team must learn what Octane worker memory and request-count series actually mean before the numbers drive decisions. Pair the rollout with a short internal write-up and one worked example dashboard, or the metrics will be collected and ignored.