What LaraBug records
An event is one thing your application reported. This section is one page per kind: what it is, what has to be switched on for it to arrive, and what it costs you.
The catalogue
| Event | What it is | What collects it |
|---|---|---|
| Requests | One trip through your application, with the work it did. | requests.track_requests |
| Exceptions | Something threw. | register_exception_handler |
| Queries | The SQL a request ran, and how long each statement took. | inside a request |
| Queue jobs | A job finished, or failed. | jobs.track_jobs |
| Scheduled tasks | A scheduled command ran, or did not. | schedule.track_scheduled_tasks |
| Commands | An Artisan command ran. | commands.track_commands |
| Logs | A log record, from the level you pick upwards. | the larabug-logs channel |
| Mail and notifications | What your application sent, and how far it got. | inside a request |
| Cache | Hits, misses, writes and forgets. | inside a request |
| Dependencies | A package in composer.lock, or in an npm lockfile, with a known CVE. |
cve.enabled |
Two switches, and both have to be on
Every kind passes two gates.
The client decides whether to collect it. That is the switch in the table above, in config/larabug.php, and it is the one that costs your application anything: with it off, nothing is registered, no listener is subscribed, and there is no work to skip.
The application in LaraBug decides whether to accept it. Open the application in the panel and its features are in the settings. A client sending a kind the application does not accept is refused, and backs off rather than retrying.
A new application accepts exceptions, queue jobs and dependency findings, because those are the three the client sends without being asked. Requests, logs, commands and scheduled tasks are off on both sides until you turn them on.
What a request carries
Queries, outgoing HTTP calls, mail, notifications, cache operations and Livewire updates are not events of their own. They are recorded against the request that caused them and travel with it.
Two things follow. With request tracking off, none of them arrive at all. And because requests are sampled, what you get is a representative tenth rather than the lot.
What the console does instead
Request tracking is HTTP only. A queue worker, an Artisan command and a scheduled task are not requests, so the queries they run are not collected. Each reports its own event instead: the job, the command, the task, with its duration and how it ended.
What it costs
Every request, job, command and task counts towards your monthly telemetry allowance, and every exception towards your issues allowance, repeats included. The three levers are the same everywhere, and each page says what its defaults are:
- Sampling. Requests are kept at one in ten. Jobs can be sampled the same way.
- Deduplication. The same exception, from the same place, is reported once a minute.
- Ignoring. Paths, queues, job classes, commands and exception classes can all be left out entirely.
What the telemetry raises on its own, a slow route or a failing job, is on What opens an issue. How LaraBug works covers what happens to an event once it arrives: issues, occurrences and retention.