Essay Nº 001 — laravel
Laravel Telescope and Pulse - right tool for the job
In the past I used telescope a lot: I even had it behind auth set up on prod and just maybe turned off most of the time. The release of pulse eventually made me look at this more sensibly, putting the Laravel "debug" tools into categories:
- Telescope is an actual debug tool that is meant to run in the local/dev environment. It collects a lot of data and could impact performance by having a lot of events inside the app (e.g. every DB query) leading to inserting into the DB.
- Pulse is actually meant for running in production and collecting data about slow queries, jobs, requests etc. and seeing the general health of the application.
Sensible (paranoid) setup for Pulse
As I've also had setups with telescopes that "blew up" in the sense of creating huge databases (specially when forgetting to schedule the pruning command) it made me go a bit more paranoid then maybe strictly needed with pulse.
- Run on a separate DB to make DB dumps for the main DB smaller.
- Pruning old data happens automatically.
- Use ingesting information via redis and a worker to speed it up.
What's the lesson then? Mainly to use the right tools for the right jobs:
- Capture errors and their context with an error tracking tool like sentry or flare.
- For performance monitoring an APM tool is best, sentry is again something to consider.
- And if you want something you run as part of your own app to get performance insights then pulse is a good choice.
❦