Df Exporter Prometheus Laravel Package

Getting Started

This is not a general-purpose Laravel package you'll composer require into an app. It's a DreamFactory platform component — a metrics exporter that serializes DreamFactory's internal metric collections into the Prometheus text exposition format so a Prometheus server can scrape them. It ships as part of a DreamFactory install (composer require dreamfactory/df-exporter-prometheus inside a DreamFactory codebase), registered via a Laravel service provider like every other df-* module.

First steps

1. Read the composer.json and the service provider first. The package is a subtree split of the df-skeleton monorepo, so the GitHub link points at the whole platform rather than a tight, self-documenting package. Find the provider class, see what it registers (a route? a console command? an exporter driver binding?), and check require constraints against your DreamFactory version — this is where the 2019 release date bites.
2. Find the exporter config. DreamFactory exposes exporters through its config layer (config/df.php / a package-local config/*.php) and the admin UI under System Config. Confirm the exporter key name from the provider — do not guess.
3. Verify the endpoint manually before touching Prometheus:

curl -s -H 'Accept: text/plain' \
  -H 'X-DreamFactory-Api-Key: <your-key>' \
  https://df.example.com/api/v2/system/metrics

You want lines like df_api_requests_total{service="mysql",method="GET"} 42. If you get JSON, you're hitting the generic metrics endpoint and not the Prometheus formatter — check the format/Accept handling in the exporter class.

4. First real use case: put DreamFactory API traffic on a Grafana dashboard. Scrape config:

scrape_configs:
  - job_name: dreamfactory
    scrape_interval: 30s
    scrape_timeout: 10s
    metrics_path: /api/v2/system/metrics
    static_configs:
      - targets: ['df.example.com']
        labels: { instance: df-prod-1, env: prod }

Implementation Patterns

Pull, don't push. Prometheus scrapes DreamFactory on an interval; the exporter is stateless formatting on top of whatever counters DreamFactory accumulated. Keep the exporter out of the hot request path — no per-request network calls, no synchronous flush on every API call. Let the scrape do the work.

Label design is your main design decision. DreamFactory can generate metrics per service, per API key, per endpoint, per role. The exporter may emit all of it, and that's a cardinality trap. Decide up front what's dashboard-worthy (service, method, status class) versus debugging-only. If the exporter emits raw path labels, aggregate/relabel at Prometheus:

metric_relabel_configs:
  - source_labels: [__name__]
    regex: 'df_api_requests_total.*'
    action: keep
  - source_labels: [path]
    target_label: path
    regex: '/api/v2/([^/]+)/.*'
    replacement: '/api/v2/$1/*'

Multi-instance / multi-tenant fleets. One scrape job per DreamFactory node, with instance and tenant/env labels set in static_configs or via file-SD/service discovery. Never let the exporter's own labels be the only identifier — restarting a node shouldn't look like a new timeseries.

Custom metrics and extension points. For app-specific numbers (records synced, queue depth behind a DreamFactory scripted service, custom business counters), don't fork the exporter. Two cleaner options:

• Register your own exporter driver if the package resolves exporters through a manager/binding — swap the class in config.
• Add a small custom system/metrics-adjacent endpoint or a scripted service that emits the exposition format yourself, and scrape it as a second job. Ten lines of sprintf beats fighting a 2019 codebase.

Auth in the scrape config. DreamFactory's system endpoints usually want an API key or admin session. Put credentials in a file, not in YAML:

    authorization:
      type: ApiKey
      credentials_file: /etc/prometheus/df_api_key

(Adjust the header name to whatever the exporter actually reads — verify against the provider's route middleware.)

Local dev loop. docker-compose with prom/prometheus + grafana/grafana, a scrape job pointed at your DreamFactory container, and promtool check metrics < sample.txt on a captured response. This is far faster than round-tripping through a shared staging Prometheus.

Alerting on the scraper itself. Always alert on up{job="dreamfactory"} == 0 and on scrape_duration_seconds approaching your timeout — the exporter is quiet when the platform is sick, which is exactly when you want to know.

Gotchas and Tips

• The repo link is misleading. github.com/dreamfactorysoftware/df-skeleton is the platform skeleton; this package is a read-only subtree split. Issues, PRs, and changelogs live in the monorepo. With zero stars, zero dependents, and a last release in October 2019, assume no upstream support and budget time to read the source yourself.
• PHP/Laravel version skew is the #1 risk. A 2019-era DreamFactory component was written against PHP 7.x and an older Laravel. If you're on DreamFactory 4.x / PHP 8.x, test the provider boot, config resolution, and any type-hinted signatures carefully. composer why-not after adding it will tell you fast.
• php artisan config:cache will eat your config changes. Classic Laravel trap, and it applies here: change the exporter settings, forget to re-cache, and you'll debug a "config ignored" problem for an hour. php artisan config:clear first.
• Metric name sanitization. Prometheus allows [a-zA-Z_:][a-zA-Z0-9_:]*. If DreamFactory service names contain dots, dashes, or slashes, check how the exporter maps them — collisions after sanitization (e.g. my-service and my.service both becoming my_service) silently merge series.
• Counters reset on process restart if backed by in-process storage, and diverge across nodes if backed by local cache. Prometheus handles resets with rate()/increase(), but only if you're not summing raw counters across instances — use sum(rate(...)), not sum(...).
• Don't put the metrics endpoint behind rate limiting or CSRF-heavy middleware. It's a machine endpoint; a 429 or a redirect will show up as a scrape failure and a gap in every dashboard.
• Debugging ladder: curl the endpoint raw → promtool check metrics on the body → Prometheus Status → Targets for the error string (context deadline exceeded, 401, unexpected content type) → Graph tab with {__name__=~"df_.*"} to see what actually landed.
• Timeouts on slow platforms. DreamFactory's metrics collection may hit the system database. If collection is slow, a 10s scrape timeout will intermittently fail. Raise scrape_timeout, lower scrape_interval frequency, or point the exporter at a cached snapshot.
• Extension point worth knowing: if the exporter is bound through a manager or a config/df.php driver key, that binding — not the class internals — is where you override behavior. Subclassing a 2019 exporter is usually more work than writing a 60-line replacement implementing the same interface.