Logging Laravel Package

Product Decisions This Supports

• Standardized Logging Across Microservices: Enables consistent JSON-formatted logs (with timestamp, level, message, context, service, trace, version) across PHP/Symfony services, simplifying observability and debugging in distributed systems.
• Observability Roadmap: Accelerates adoption of OpenTelemetry integration (via otel_trace) for distributed tracing, aligning with modern observability stacks (e.g., Jaeger, Zipkin).
• Build vs. Buy: Avoids reinventing Monolog/Symfony logging infrastructure, reducing technical debt while allowing customization via processors/trace providers.
• Use Cases:
  • Debugging: Unified log structure (e.g., service.name, trace_id) for cross-service correlation.
  • Compliance/Audit: Structured logs for regulatory requirements (e.g., timestamp, level standardization).
  • Performance: logging:scan identifies underutilized loggers or missing severity levels (e.g., --severity-min=error).
  • Cloud-Native: Enrichment with cf-ray headers for Cloudflare users, or OpenTelemetry context for Kubernetes/containerized apps.

When to Consider This Package

• Adopt if:
  • Your PHP/Symfony project uses Monolog 2.3+ and needs structured JSON logs for observability tools (e.g., ELK, Datadog, Loki).
  • You require distributed tracing (OpenTelemetry) or Cloudflare-specific headers (cf-ray) in logs.
  • Your team lacks a centralized logging standard but needs auditability (e.g., service.version, timestamp).
  • You want to scan for logging gaps (e.g., missing error logs) via logging:scan without manual code reviews.
• Look elsewhere if:
  • You’re not using Symfony/Monolog (though core components can be used standalone).
  • Your logging needs are simple (e.g., basic file/appender setups without JSON structure).
  • You’re already using a mature logging solution (e.g., AWS CloudWatch Logs PHP agent, Sentry SDK).
  • Your team lacks PHP 8.2+ or Symfony 5.4+/6.4+/7.0 compatibility.

How to Pitch It (Stakeholders)

For Executives: "This package standardizes how our PHP services log data—turning unstructured text into machine-readable JSON with timestamps, service names, and trace IDs. It’s like giving our observability tools (e.g., Datadog, ELK) a ‘Rosetta Stone’ for logs, so debugging cross-service issues becomes 10x faster. For example, if a payment fails in orders-api, we’ll instantly see the trace_id linking it to the billing-api logs. It’s a low-code, high-impact way to reduce MTTR (mean time to resolve) without hiring more SREs."

For Engineering: *"This is a drop-in Monolog/Symfony bundle that:

1. Forces consistency: All logs get the same schema (JSON, service.name, trace_id).
2. Saves time: logging:scan finds unused loggers or missing severity levels in seconds.
3. Future-proofs observability: OpenTelemetry integration (otel_trace) lets us correlate logs with traces without rewriting instrumentation.
4. Flexible: Need custom log processing? Extend it via YAML aliases—no forks required. Tradeoff: Minimal upfront config (e.g., logging.yaml), but payoff is debuggable, auditable logs out of the box."*

For DevOps/SRE: *"This ensures logs from auth-service and inventory-service play nicely with our centralized logging pipeline (e.g., Fluentd → Elasticsearch). Key wins:

• Structured data: No more parsing INFO: User logged in [{"id":123}]—just query service.name:auth-service AND level:ERROR.
• Trace context: cf-ray headers or OpenTelemetry IDs auto-injected, so you can follow requests across services.
• Compliance: Standardized timestamp and level fields for audit trails. Downside: Requires a cache:clear after config changes, but that’s a one-time cost."*