Prometheus Client Php Laravel Package

Product Decisions This Supports

• Observability roadmap / SLO work: Prometheus instrumentation is the substrate for RED (Rate, Errors, Duration) and USE (Utilization, Saturation, Errors) dashboards. This package is the PHP-side hook that makes PHP services first-class citizens in an existing Prometheus/Grafana stack, which unblocks committing to SLOs and error budgets for PHP-backed surfaces (checkout, API gateways, background crons).
• Feature-flag and rollout validation: Counters keyed by a label (e.g., variant=blue) let you measure canary vs. control cohorts with the same metric pipeline you already use for alerting — a cheap way to answer "did the release actually improve conversion/latency?" without building a separate analytics path.
• Build vs. buy: Strong "buy/adopt" signal on the instrumentation layer. Roll-your-own metrics (log parsing, ad-hoc tables) duplicates work, drifts in semantics, and rarely supports histograms/summaries correctly. This package gives you the Prometheus text exposition format, counters/gauges/histograms, and multi-process aggregation for free.
• Capacity and cost decisions: Histograms over request latency and queue/cron duration give the data needed to size PHP-FPM pools, Redis instances, and worker counts — turning capacity arguments into evidence rather than anecdote.
• Incident response quality: Metric-driven alerting (burn-rate alerts on histograms) reduces time-to-detect for PHP services currently only covered by log-based or synthetic checks.
• Architecture constraint: PHP's stateless process model. The core product-relevant insight here is the adapter choice (Redis / APCu / in-memory), which directly implies an infrastructure dependency. That is a roadmapping input: if you standardize on this, you are also committing to a local Redis sidecar or APCu everywhere PHP runs.
• Vendor/ecosystem risk register: The package is archived and redirects to a community fork. That is a procurement decision (support model, security patch cadence), not just an engineering detail.

When to Consider This Package

Consider it (preferably the maintained fork, endclothing/prometheus_client_php) when:

• Your platform already runs Prometheus + Grafana (or a compatible scraper such as VictoriaMetrics, Grafana Agent, or a managed Prometheus). Instrumentation only pays off as an extension of an existing query/alerting stack.
• You own PHP services where latency, throughput, and error rates matter to a business SLO — customer-facing APIs, payment paths, authentication, or high-volume crons.
• You need multi-process aggregation. Web requests under PHP-FPM do not share state, so the Redis or APCu adapter is what makes counters and histograms correct across workers. If your workload is a long-running daemon or one-shot script, the in-memory adapter is sufficient and the dependency disappears.
• You want low-ceremony, code-level instrumentation without a vendor agent or paid APM. This is a library, not an SDK for a commercial backend — no per-host licensing, no outbound data egress to a third party.
• You are already comfortable operating Redis. The recommended topology is a local Redis alongside PHP workers; adding a new stateful dependency purely for metrics is rarely justified.
• You need standard Prometheus exposition semantics (label sets, histogram buckets, _total/_bucket conventions) so dashboards and recording rules are portable and not reinvented per team.

Look elsewhere when:

• You have no Prometheus. If metrics land in Datadog, New Relic, or CloudWatch, use that vendor's PHP agent/SDK — it will be better supported and requires no adapter sidecar.
• You want long-term vendor support. The Jimdo repo is archived. Treat any adoption as an adoption of the fork, and evaluate that fork's release cadence, security posture, and maintainer count before building on it. If neither repo passes your dependency-health bar, instrument via OpenTelemetry's PHP SDK and export through the Prometheus exporter — a heavier setup, but a path with a governance story.
• You need tracing or profiling. This is metrics-only. Distributed tracing, span context propagation, and continuous profiling are out of scope; plan a separate decision (OpenTelemetry PHP is the natural candidate and could eventually subsume this dependency).
• Your team is small and time-constrained. Histograms have real design costs (bucket boundaries, label cardinality). Without someone who will own dashboards and alerts, instrumenting produces unused data and a Redis dependency you now must operate.
• Cardinality risk is unmanaged. Free-form labels (user IDs, request paths, raw error strings) will blow up the TSDB. This is a process control problem, not a library problem — but it is the most common way this adoption fails.

How to Pitch It (Stakeholders)

For executives (one paragraph): Our PHP services are currently a blind spot — we can see that they are slow only when customers tell us. Adopting Prometheus instrumentation lets those services report the same latency, error-rate, and volume metrics our other systems already report, so they appear on the same dashboards and fire the same alerts. It is an open-source library with no license cost, and it reuses our existing monitoring stack, so the incremental spend is engineering time plus a small Redis process per host. The catch is governance: the original repository is archived and the project has moved to a community-maintained fork, so I recommend we adopt the fork explicitly, pin the version, and record it in our dependency-risk review rather than treating it as a permanent, supported platform commitment.

For engineering leads (summary): It is a thin, well-understood Prometheus client: CollectorRegistry gives you counters, gauges, and histograms, and you pick an adapter — Redis or APCu for cross-worker aggregation, in-memory for long-running scripts. The hard part is not the code, it is the operating model: a local Redis (or APCu on every host), a /metrics endpoint you are willing to expose, and label discipline so we do not melt the TSDB with high-cardinality labels. Because PHP-FPM workers share no state, the adapter is the entire reason this library exists — do not plan an in-memory deployment for web traffic and expect correct numbers. Two decisions I need from you: (1) confirm the endclothing fork as our sanctioned source and pin it, and (2) confirm we own the histogram bucket and label conventions centrally, ideally via a thin internal wrapper, so ten teams do not invent ten metric schemas. If both hold, this is a low-risk, high-leverage addition; if we cannot commit to the wrapper and the dashboards, the data will go unread and we will have added a dependency for nothing.