Df Exporter Prometheus Laravel Package

Technical Evaluation

Architecture fit. Despite the "Laravel/PHP package" framing, this is not a general-purpose Laravel package — it is a DreamFactory platform module that happens to be built on Laravel (DreamFactory's API platform runs on Laravel). It hooks into the DreamFactory service-provider and routing layer to expose a Prometheus-scrapeable metrics endpoint (typically under /api/v2/...). It fits only if the target application is a DreamFactory instance. For a vanilla Laravel app, it is not directly consumable; the architectural value is the pattern (a metrics controller + registry) rather than the code.

Integration feasibility. Installation is a Composer require into the df-skeleton instance, followed by service-provider/route registration and .env configuration. Feasibility is medium-to-low as-is: the last release is 2019-10-08, which predates several DreamFactory major versions and Laravel 8/9/10/11. Expect dependency-constraint conflicts (laravel/framework, guzzlehttp/guzzle, PSR interfaces) and possible namespace/route-registration drift. Realistic path is fork-and-patch, not composer require.

Technical risk.

• Abandonment risk (high): 0 stars, 0 dependents, single 2019 release, repo link redirects to the skeleton — no active maintainer, no issue triage, no security response.
• Compatibility risk (high): pinned PHP/Laravel constraints against a modern DreamFactory runtime.
• Security surface (medium): metrics endpoints frequently leak hostnames, SQL, endpoint inventories, and request volumes; default auth posture must be verified.
• Licensing risk (low): Apache-2.0 with patent grant is permissive and safe for an internal fork and redistribution.
• Cardinality risk (medium): naive per-request/per-user labels can blow up Prometheus TSDB and exporter memory.

Key questions.

1. Which DreamFactory version (3.x vs 4.x) and PHP runtime are we on, and does the package's composer.json resolve against it?
2. What metric surface do we actually need (API latency, per-service request counts, DB pool, queue depth, error rates) versus what this exporter emits?
3. What is the scrape interval and expected series cardinality?
4. How is the metrics endpoint authenticated/network-restricted — internal-only listener, mTLS, or token?
5. Is the requirement "Prometheus metrics from DreamFactory" or "Prometheus metrics from our Laravel app"? These lead to different solutions.
6. Are we willing to own a fork (patch dependencies, security-review, maintain) for the platform's lifetime?

Integration Approach

Stack fit. Assumes a DreamFactory deployment on PHP 7.x/Laravel 5.6–6.x with Prometheus + Grafana as the observability backend. It is not a fit for Laravel 9+/PHP 8.2+ without code changes. If the application is plain Laravel rather than DreamFactory, prefer an actively maintained exporter (e.g., a promphp/prometheus_client_php-based Laravel package) and treat this repo as reference only.

Migration path. Three options, in order of preference:

1. Fork-and-modernize (recommended if staying on DreamFactory): vendor the package into a private repo, bump Composer constraints to the current DF/Laravel baseline, re-register the service provider in df-skeleton config, and add endpoint auth. Cost is bounded because the codebase is small.
2. Reimplement as a thin in-platform controller: a single route that reads DF's existing system/API stats and renders the Prometheus text exposition format. Often cheaper than reviving the fork, and gives full control over metric names and cardinality.
3. Sidecar exporter: scrape DreamFactory's REST admin API (or its backing MySQL/Redis) from a standalone Go/PHP exporter. Decouples metrics from the DF release cycle and avoids touching the runtime — best if the platform must not be modified.

Compatibility. Validate: Composer solve against the pinned DF version; service-provider auto-discovery vs manual registration in config/app.php; route prefix and middleware collisions; config merge behavior on php artisan config:cache; PHP extension requirements (APCu/Redis for the metrics store backend, if used).

Sequencing.

1. Confirm DreamFactory version, PHP version, deployment topology (containers vs VMs), and existing Prometheus scraping conventions.
2. Define the metric contract: names, labels, types (counter/gauge/histogram), cardinality budget, retention.
3. Stand up a staging DF instance; attempt unmodified install to measure breakage.
4. Fork and patch dependencies; add endpoint auth and network policy.
5. Wire Prometheus scrape job + relabeling; validate series counts and scrape duration.
6. Ship Grafana dashboards and baseline alerts (error rate, p99 latency, scrape-down).
7. Roll to production behind a feature flag; keep the sidecar variant as fallback.

Operational Impact

Maintenance. Effectively no upstream support. The team inherits the full maintenance burden: dependency upgrades on every DreamFactory/PHP bump, security review of the endpoint, and metric-schema ownership. Budget roughly 1–2 engineer-weeks to productionize the fork and ~2–5% of an engineer ongoing, spiking at each platform upgrade.

Support. Community-only; no vendor SLA. Apache-2.0 permits internal forking and redistribution, which mitigates the bus-factor problem but does not eliminate it. Document the fork's owner explicitly — an unowned fork becomes a silent outage risk.

Scaling. The exporter's cost scales with scrape frequency × metric collection cost, not with API traffic, unless instrumentation is per-request. Watch for: per-scrape database queries against DF's metadata store, unbounded label sets (user IDs, endpoint paths, tenant IDs), and lock contention if a file/APCu backend is used. Cap cardinality at the label-design stage; enforce scrape intervals of 15–60s; cache expensive aggregates for one scrape cycle.

Failure modes.

• Exporter unavailable → stale or absent metrics, silent alerting gaps; mitigate with a up == 0 alert and a fallback sidecar.
• DreamFactory upgrade → Composer conflict or class-not-found at boot, potentially taking the whole API platform down (a service-provider failure is not isolated). Test in staging; keep the module out of the critical boot path where possible.
• Cardinality explosion → Prometheus memory/TSDB pressure and exporter OOM; enforce label allowlists.
• Metrics endpoint exposure → information disclosure of internal topology and traffic patterns; bind to internal interface and/or require auth.
• Silent metric drift → renamed/removed series break dashboards and alerts without erroring; version the metric contract.

Ramp-up. Low for a PHP engineer comfortable with Laravel service providers, Composer, and Prometheus exposition format: ~1–2 days to read the code and stand up a staging instance, ~1–2 weeks to fork, patch, secure, and instrument. The steeper learning curve is DreamFactory platform internals (service wiring, config layering), not this package. Given the package's 2019 vintage, zero adoption, and 0.23 score, treat it as reference implementation rather than a dependency — the strongest TPM recommendation is to build a thin, owned exporter against the current DreamFactory runtime instead of adopting this artifact.