Zabbix Bundle Laravel Package

Technical Evaluation

Architecture fit: The core constraint is unchanged: this is a Symfony bundle (flowti/zabbix-bundle, repo thomas-sens/zabbix-bundle), not a Laravel package. It relies on Symfony's Bundle class, DependencyInjection/Extension, and YAML/XML service wiring, none of which Laravel's kernel bootstraps. There is still no auto-discovery, no publishable config, no facade. Only the underlying service classes are candidates for reuse, and the v0.0.1 notes make that reuse surface more legible — but do not change the fact that the bundle layer is dead weight in a Laravel application.

What the new release actually tells us: v0.0.1 documents seven implemented Zabbix JSON-RPC methods: user.login, user.logout, event.acknowledge, host.get, hostgroup.get, event.get, trigger.get. Three implications matter for scoping:

1. Direction is settled. This is a JSON-RPC API client (pull/manage), not a trapper/zabbix_sender implementation. The push-vs-pull question from the prior spike is now answered: there is no push capability here at all. If our requirement is metric emission, this package contributes nothing and we build a sender regardless.
2. Scope is read-plus-acknowledge, not provisioning. The method set is *.get for hosts, host groups, triggers, and events, plus event.acknowledge. There is no host.create, item.*, problem.get, or history.get. The prior assessment speculated the bundle might cover host/item/trigger provisioning — it does not. This shrinks the extraction surface and the effort estimate, but also means "adopt this to manage Zabbix configuration" is off the table entirely.
3. Auth model is legacy. user.login/user.logout is session-based credential auth, not the API-token model introduced in Zabbix 5.4/6.0. That is a direct confirmation of the version-drift risk: the client is targeting pre-token semantics and will need rework for modern Zabbix deployments.

Integration feasibility: Still feasible at small scale, still "extract and wrap," but the estimate is now more defensible because the method list bounds the work. Two caveats sharpen rather than soften the picture. First, v0.0.1 is pre-1.0 semver — it signals an immature, unstable public surface with no compatibility promise, and is a strange artifact given the prior metadata indicated a January 2022 release. Either this is a first tag of previously-untagged code or a version reset; both readings mean "expect breaking changes." Second, user.login/user.logout implies session lifecycle management (login, hold session, logout, handle expiry), which is exactly the class of stateful plumbing that goes wrong silently in queue workers.

Technical risk:

• Abandonment risk (high, unchanged): single maintainer, negligible dependent ecosystem, no visible security triage. A v0.0.1 release does not constitute a maintenance signal — it may be a single burst of activity.
• Pre-1.0 API instability (high, new): 0.0.x versioning means any method signature, return shape, or exception type can change without notice. Forking and pinning is not optional.
• Version drift (high, now confirmed): legacy user.login auth plus a fixed method list means the client is anchored to older Zabbix API semantics. Zabbix 5.0 → 6.0 → 6.4 → 7.0 changed auth handling and response envelopes materially.
• PHP/Symfony constraints (medium): Composer constraints remain unverified and likely Symfony 4/5 and PHP 7.x era; may conflict with Laravel 10/11's bundled Symfony components.
• Hidden coupling (medium): still unconfirmed whether services are constructor-injected and container-free, or pull from the container. user.login/user.logout suggests stored credentials and possibly shared session state.
• No test/CI signal: release notes list features, not test coverage. Treat as unverified.

Revised key questions for the spike (now 1–2 days, down from 2–3):

1. Push or pull? Answered: JSON-RPC pull/manage only. Confirm we actually need read/acknowledge — if our need is metric push, stop here.
2. Are the service classes container-free and constructor-injected, or do they depend on Symfony DI / ContainerAwareInterface?
3. Does the client expose API-token auth, or only user.login session auth? If session-only, what is the rework to support tokens (Zabbix 6.0+)?
4. What are the Composer require constraints for php, symfony/*, and the HTTP client?
5. Is there a maintained standalone PHP Zabbix API client we should prefer over a fork? The method set here is small enough that a clean-room adapter is credible.

Integration Approach

Stack fit: Partial, unchanged. Laravel 10/11 ships Symfony components so framework-agnostic HTTP logic will run; the bundle, DI extension, and configuration schema will not and should be excluded from the path.

Recommended migration path (in order):

1. Fork and audit. Fork to our namespace, run composer update --dry-run against our Laravel version, static-analyse the service classes. MIT license — permissive, forking and vendoring are clean; retain the copyright notice.
2. Extract the client only. Lift the JSON-RPC client/service classes into app/Services/Zabbix/ or a small internal package. Strip Symfony DI annotations, the Bundle class, and the extension. Because the method set is seven calls, a clean-room reimplementation is a genuine alternative to extraction — evaluate both, but do not assume the fork is cheaper.
3. Wrap in Laravel idioms. ZabbixServiceProvider with a bound singleton, config/zabbix.php driven by env vars (ZABBIX_URL, ZABBIX_API_TOKEN, ZABBIX_TIMEOUT), thin Facade. Prefer Laravel's Http client over the bundle's transport — you inherit retry(), timeout(), and middleware.
4. Replace session auth with token auth. Do not port user.login/user.logout into a queue-worker context. Zabbix 6.0+ API tokens are stateless, remove the reconnection logic, and eliminate a whole failure class. This is the one place where deviating from the upstream design is clearly correct.
5. Decide direction explicitly. For push-based metrics, ignore this package entirely and implement zabbix_sender — a length-prefixed wire format, low risk, high throughput.
6. Queue the writes. Never call Zabbix inline in a request cycle, including event.acknowledge.

Compatibility & sequencing: Do not block a release on this package. Sequence: (1) confirm our actual need is read/acknowledge rather than push — this is now the decisive gate and can be resolved in a day, (2) fork-and-audit or clean-room decision, (3) token-auth client wrapped in a Laravel service, (4) config and secret management, (5) queued dispatch with retry/backoff, (6) validation against a real Zabbix server of a known version. The package remains a pattern reference and possible starting point, not a milestone dependency.

Operational Impact

Maintenance: Zero upstream support; we own the code on adoption. The v0.0.1 tag marginally worsens this — pre-1.0 versioning plus a thin method set means upstream may renumber, restructure, or abandon without ceremony. Budget fork maintenance and Zabbix API version tracking as a small but permanent recurring line item. MIT keeps it legally clean; abandonment makes it operationally inevitable.

Support: No vendor, no community (2 stars, 0 dependents), no issue-triage history. Escalation is internal. Acceptable only because the domain is narrow and Zabbix documents its API well.

Scaling: The method set is read-heavy and low-frequency by nature — host/trigger/event polling and event acknowledgement, not per-request metric emission. That scales comfortably if queued and batched. The scaling concern shifts to polling cadence: event.get and trigger.get on a tight schedule will load the Zabbix server. Set poll intervals deliberately and cache host/group topology, which changes rarely. For high-volume metric push, zabbix_sender remains the correct path and is entirely outside this package.

Failure modes to design against:

• Silent metric loss / silent empty results — JSON-RPC returns HTTP 200 with an embedded error object. Parse the envelope explicitly; never trust the status code. This is especially relevant for *.get calls that return empty result sets on failure.
• Session lifecycle breakage — the user.login/user.logout model fails badly in long-lived queue workers: stale sessions, mid-job expiry, and logout races. Replacing it with token auth removes this failure mode outright.
• API version drift — response shapes and auth semantics differ across Zabbix 5/6/7. Pin and assert the server version at startup.
• Unstable upstream surface — v0.0.1 means a routine composer update could break the fork. Vendor or pin hard.
• Inline timeouts — aggressive timeouts plus circuit-break-to-no-op; a slow Zabbix server must never block user traffic.
• No retry semantics in the original — wrap in queued jobs with exponential backoff and dead-letter visibility; event.acknowledge in particular should be idempotent and observable.
• Secret leakage — API tokens in config reaching logs; route through Laravel's encrypted secret store.

Ramp-up: Low. The seven-method surface is learnable in hours, not days; the JSON-RPC envelope and auth parameter are simple. The real cost is the fork-and-audit-or-reimplement decision and the token-auth migration, which together are a 1–2 day spike rather than the 2–3 days previously estimated. Net assessment: the release narrows the case rather than strengthening it — this is a read/acknowledge client with legacy auth, not a provisioning or push capability. Do not adopt as a dependency; either fork the small client under a pinned version and migrate it to token auth, or build a ~200-line internal adapter and skip the inheritance entirely. For push-based metrics, build zabbix_sender and treat this package as irrelevant.