Sdk Php Laravel Package

Technical Evaluation

Architecture Fit

• Observability Integration: The package provides a drop-in observability solution for Laravel/PHP, aligning well with modern DevOps practices (APM, logging, tracing). It captures errors, logs, HTTP requests, DB queries, traces, and cron tasks—critical for debugging and performance monitoring.
• Laravel-Native: Auto-discovers Laravel service providers, reducing manual configuration. Leverages Laravel’s exception handler and request lifecycle for seamless integration.
• Modular Design: Collectors (e.g., exceptions, HTTP, DB) are toggleable via config/env vars, allowing granular control over telemetry overhead.
• Guzzle Support: Extends beyond Laravel to standalone PHP/Guzzle apps, useful for microservices or CLI tools.

Integration Feasibility

• Low Friction: Requires only composer require + API key for basic setup. Laravel auto-discovery eliminates boilerplate.
• Zero-Code Changes: Captures unhandled exceptions via Laravel’s exception handler (no middleware or custom logic needed).
• Config-Driven: Centralized toggles (config/allstak.php or env vars) simplify enabling/disabling features (e.g., disable DB telemetry for performance-sensitive routes).
• Guzzle Hooks: For HTTP clients, integrates via Guzzle middleware, requiring minimal setup if already using Guzzle.

Technical Risk

• Vendor Lock-in: Proprietary SDK (AllStak-specific). Migration to alternatives (e.g., Laravel Telescope, Sentry, Datadog) would require reconfiguring collectors.
• Data Privacy: Sends raw logs/errors to AllStak’s servers. Ensure compliance with GDPR/CCPA if handling PII (e.g., sanitize logs before capture).
• Performance Overhead: Telemetry collection adds network I/O and CPU (serialization, batching). Monitor latency impact in high-throughput apps.
• Laravel Version Compatibility: No explicit version constraints in README. Test with Laravel 10+ to confirm auto-discovery works.
• Cron Heartbeats: Useful for monitoring long-running tasks but may require custom logic for non-standard cron setups (e.g., Artisan commands).

Key Questions

1. Data Retention/Compliance: How does AllStak handle log retention and data deletion? Can we enforce custom retention policies?
2. Cost Structure: Is pricing usage-based (e.g., per log/error) or flat-rate? Are there cost spikes for high-volume apps?
3. Sampling: Does the SDK support sampling (e.g., 1% of requests) to reduce volume?
4. Custom Attributes: Can we add custom metadata (e.g., user IDs, request IDs) to traces/logs?
5. Offline Mode: How does the SDK behave when AllStak’s API is unreachable? Are events buffered?
6. Migration Path: What’s the effort to switch providers (e.g., to Sentry or OpenTelemetry) later?
7. Support: What’s the SLA for SDK issues? Is there a public roadmap for feature updates?

Integration Approach

Stack Fit

• Laravel: Ideal for auto-discovery and exception handling. Works out-of-the-box with Laravel’s request lifecycle and Artisan commands.
• PHP (Non-Laravel): Requires manual initialization (AllStak::init()) and may need custom middleware for HTTP/DB telemetry.
• Guzzle: Integrates via Guzzle middleware, useful for API clients or CLI tools.
• Monolithic vs. Microservices:
  • Monolith: Captures all layers (HTTP, DB, exceptions) in one place.
  • Microservices: May need per-service API keys and context propagation (e.g., trace IDs).

Migration Path

1. Pilot Phase:
   • Install in staging with ALLSTAK_CAPTURE_EXCEPTIONS=true only.
   • Validate error reporting and performance impact.
2. Gradual Rollout:
   • Enable collectors one by one (e.g., start with errors, then HTTP, then DB).
   • Use config/allstak.php to toggle features:

     'collectors' => [
         'exceptions' => env('ALLSTAK_CAPTURE_EXCEPTIONS', true),
         'http' => env('ALLSTAK_CAPTURE_HTTP', false),
         'pdo' => env('ALLSTAK_CAPTURE_PDO', false),
     ],
     

3. Laravel-Specific:
   • Confirm auto-discovery works (Laravel ≥8.x). If not, manually register AllStakServiceProvider.
   • Override exception handler if custom logic is needed:

     // app/Exceptions/Handler.php
     public function report(Throwable $exception) {
         AllStak\Facade::captureError($exception);
         parent::report($exception);
     }
     

4. Guzzle Integration:
   • For HTTP clients, add middleware:

     $client = new GuzzleHttp\Client([
         'middleware' => [
             new AllStak\Guzzle\Middleware(),
         ],
     ]);
     

Compatibility

• Laravel: Tested with Laravel 8+ (auto-discovery). For older versions, manual provider registration is needed.
• PHP Versions: Requires PHP 8.0+ (check composer.json constraints).
• Database: Supports PDO telemetry. For Eloquent, may need query logging enabled:

  DB_LOG_QUERIES=true
  

• Async Jobs: Captures Artisan commands and queued jobs (if using Laravel’s queue system).

Sequencing

1. Setup:
   • Add ALLSTAK_API_KEY to .env.
   • Install via Composer.
2. Validation:
   • Verify errors/logs appear in AllStak dashboard.
   • Check for performance regressions (e.g., 100ms latency spikes).
3. Expand:
   • Enable HTTP/DB collectors post-validation.
   • Configure sampling if volume is high.
4. Monitor:
   • Set up alerts for critical errors (e.g., 5xx responses).
   • Review false positives (e.g., expected exceptions).

Operational Impact

Maintenance

• Configuration: Centralized in config/allstak.php and .env. Easy to update collectors or API keys.
• Updates: Follow AllStak’s release cadence (last release: 2026-05-29). Minor updates are likely low-risk.
• Debugging: SDK provides facades (AllStak\Facade) for manual captures (e.g., captureLog(), captureError()), useful for custom telemetry.
• Backup: No local storage required (data flows to AllStak’s servers). Ensure API key rotation is documented.

Support

• Vendor Support: Rely on AllStak’s support channels (check README for contact details). Limited by package’s 0 stars/dependents.
• Community: No public issues or discussions (GitHub stars: 0). Risk of undiscovered bugs.
• Fallback: If AllStak’s API fails, events may be lost unless buffering is implemented (not mentioned in docs).
• Documentation: Basic README with setup and collector toggles. Lack of advanced use cases (e.g., custom attributes, sampling).

Scaling

• Performance:
  • Network Overhead: Each event adds HTTP requests to AllStak’s API. High-volume apps may hit rate limits.
  • Batching: Check if SDK batches events (not documented). Implement local buffering if needed:

    // Example: Queue events during outages
    AllStak::setQueue(new \Spatie\QueueableEntity\Queue());
    

  • Sampling: Critical for high-traffic apps. Request sampling config (e.g., ALLSTAK_SAMPLE_RATE=0.1).
• Cost:
  • Usage-Based: Likely scales with event volume. Monitor dashboard for spikes.
  • Reserved Capacity: Consider dedicated API keys for microservices to isolate costs.
• Horizontal Scaling: Works in multi-server setups (each instance sends its own telemetry). Ensure consistent service name in config.

Failure Modes