There comes a point where your website or web application starts to grow and it becomes increasingly busy. This makes it more and more important that it remains fast and available. Of course, you don’t want to be constantly refreshing your website, but you do want to go to bed with peace of mind, knowing that you will receive a notification if something does go wrong.
Observability is the solution for this, and it is more than just receiving an alert when something goes wrong. It gives you deep insight into your application: the current state and how certain problems have arisen or which areas you can optimize. This allows you to prevent or resolve incidents early, and reduce resolution time (lower MTTR) when something does go wrong.
The big problem with implementing Observability is that your data is often stored and processed decentrally. This causes you to miss the power of correlating events. In addition, Observability is not something you configure once. It must live within the developers and the administrators of the underlying platform, by continuously implementing improvements and adding additional insights.
Core concepts: logs, metrics, traces
If you want to gain insight into your application, you always come across the “three pillars of observability”: logs, metrics, and traces.
With logs, you want to find out what has happened. What kinds of requests have come into your application? Were there any error messages? Debug information helps to gain deeper insight into what your application does during a request.
With metrics, you take a snapshot of the current state of your application: how many requests are coming in, how much traffic is there, and are more errors occurring than usual? This is ideal for creating alerts and dashboards. It gives a good indication of the health of your application and can quickly signal when something goes wrong.
Traces are used to go deep into your application. They allow you to follow a request from the customer’s browser, through the application, all the way to the database. This way, you can find bottlenecks or determine exactly where something goes wrong. Traces are usually used after receiving an alert or a specific customer inquiry, to gather more information and determine a possible fix.
Laravel-own tooling
A good start is to use the tooling that Laravel itself offers: starting with Laravel/Monolog for logs, and then Telescope and Pulse.
Laravel uses Monolog as the default logging engine. With this, you can quickly create different channels to process your logs. Examples include writing to a log file, sending messages to Slack, or modifying specific types of log data (such as debug or tracing information) and automating log rotation.
To start debugging your Laravel environment, you can use the Laravel Debugbar. This is an accessible way to debug your development environment and quickly provides insight into queries, routes, and events, among other things. Note, however, that this plugin should not run in production, as it can leak information about stored requests.
Telescope is ideal for development environments, because Telescope records all requests, queries, cache calls, jobs, exceptions, mail, notifications, and more. This gives a good overview of what is happening at that moment, for example when heavy queries are running in the backend.
Laravel Pulse provides a lightweight form of APM. In it, you can (almost) in real-time find slow endpoints, long-running jobs, N+1 hits, and active users. This gives a good initial indication and is perfect for use in production environments.
