Product Decisions This Supports
- Observability buy-vs-build: If we already run Zabbix, this package answers "how do we get application-level metrics into the monitoring we already pay for?" without standing up a second observability vendor (Datadog, Grafana Cloud, etc.). It's a thin protocol client for the Zabbix sender/trapper interface, so the integration cost is a few hours, not a sprint.
- Roadmap: business-KPI alerting. Zabbix is usually wired to infrastructure (CPU, disk, uptime). This package lets us push product signals — signup conversion rate, queue backlog depth, failed payment counts, cron job success — into the same alerting pipeline. That unlocks SLO-style dashboards and on-call alerts on business metrics without new tooling.
- Feature decisions: background job and scheduler visibility. Laravel apps lean on queues and the scheduler; silent failures are a classic support-ticket source. A push-based metric ("last successful nightly import: 14h ago") is a cheap, high-value reliability feature to prioritize.
- Deployment and release markers. Pushing a "deployed v1.2.3 at T" value lets ops correlate incident spikes with releases — useful for post-mortems and for deciding whether to invest in canary/rollback tooling.
- Build-vs-buy for the integration layer itself: The package is small and unopinionated (sender + agent config), so we can adopt it, wrap it in our own
MetricsService, and keep the option to swap it later. That's a low-lock-in call, which is easier to defend than committing to a proprietary agent.
When to Consider This Package
Adopt when:
- Zabbix is already the organization's source of truth for monitoring and on-call alerting.
- We need to push custom values from PHP (Laravel or otherwise) to Zabbix trapper items — app health, queue depth, business KPIs, batch job outcomes.
- We want a small, framework-agnostic library rather than pulling in a full Zabbix API SDK.
- We're comfortable wrapping a low-activity dependency in our own adapter class and pinning it.
Look elsewhere when:
- The stack is Prometheus/OpenTelemetry/Datadog-first — use the native exporter/SDK instead; Zabbix sender is the wrong protocol.
- We need to manage Zabbix (create hosts, items, templates, provision) — this only covers sending data and agent config, not the configuration API.
- We expect a maintained, first-class Laravel package (service provider, publishable config, facade). This is a protocol client; the Laravel glue is ours to write.
- Maintenance risk is unacceptable: 36 stars and zero dependents means effectively a single-maintainer project with a small user base. No community safety net, no fast CVE response. If we adopt, plan to vendor/fork it or budget a day to reimplement the sender protocol ourselves — it's a simple, documented line protocol, so that fallback is realistic.
How to Pitch It (Stakeholders)
To executives: We already pay for Zabbix. Today it only sees servers, not our product. This small library lets our application report business and reliability metrics — failed payments, queue backlog, nightly job health — into the monitoring and alerting we already own. Cost is roughly a day of engineering, no new vendor contract, and it lets us catch revenue-affecting failures before customers report them.
To engineering: It's a minimal client for the Zabbix sender protocol plus agent config, with no framework coupling and no heavy dependencies. We'll wrap it behind our own MetricsService interface, add config and tests, and pin the version. Because the protocol is trivial and the package has low maintenance activity, the wrapper also gives us a clean exit: if the dependency stalls, we replace the internals without touching call sites.
Risk framing to include up front: low adoption (36 stars, 0 dependents) and single-maintainer risk are the real concerns — not technical complexity. Mitigate by wrapping, pinning, and keeping the swap path open; treat it as a stopgap integration, not a platform bet.