Monitoring PHP applications
When considering PHP applications monitoring, it’s essential to monitor not only the application itself but the services on which the application depends, as well as the infrastructure hosting the application. Detecting performance bottlenecks and debugging problems can otherwise be very tricky, and unexpected downtime may occur.
Infrastructure monitoring
Our advanced monitoring system is partially based on the TICK stack developed by InfluxData. TICK is an acronym for Telegraf, InfluxDB, Chronograf, and Kapacitor – components that make the complete monitoring and metrics collection stack.
We’ll leave deep dive into the TICK stack for another occasion, and this time we’ll focus only on the two most important components – Telegraf and InfluxDB.
Telegraf is a plugin-driven agent that’s installed on servers, and it’s used for collecting various operating system metrics (CPU, memory, disk IO utilization, etc.). Thanks to a vast number of available plugins, Telegraf can also collect metrics from various services, such as HAProxy, MySQL, PHP-FPM, Varnish, Kubernetes, you name it!
Once the metrics are collected, Telegraf can output them to a variety of data stores, services, and message queues, such as Amazon CloudWatch, Graphite, OpenTSDB, Datadog, Kafka and InfluxDB among many others.
Our datastore of choice is InfluxDB – an extremely performant time-series database that we’ve been using for many years now.
All those collected metrics are meaningless if we can’t visualize them. For this purpose, we use Grafana – the open-source analytics and monitoring platform.
Grafana is phenomenal because it allows us to share information-packed dashboards with our customers. With detailed insight into server health and performance of all services their applications use, our customers can quickly identify problems or performance degradations caused by a bad deploy, configure alerts based on certain conditions (e.g. error rate or page load time), annotate points on the graphs and much more.
The majority of our customers use web applications written in the PHP programming language, and they found our PHP monitoring dashboard very useful. Beside the PHP-FPM specific metrics, our monitoring system gathers other helpful information such as:
- PHP requests execution timings,
- CPU time spent for processing those requests,
- Distribution of application response codes
- Distribution of PHP errors, warnings, and notices.
Application profiling
While our advanced monitoring system gives excellent insight into how the services and infrastructure functions, to understand better what happens within the source code, application profiling is a must.
Profiling describes a method of measuring the application’s memory and CPU usage, frequency and duration of function calls.
When talking about PHP profilers, Xdebug and XHProf are one of the most popular. Xdebug has been around since 2002, and it’s very powerful, but it also has a steep learning curve. XHProf, on the other hand, requires modifications to the application, so it may not be suitable for less experienced developers.
There are several very good profilers offered as a service and usually come with easy to use web interfaces. Some of them even utilize Xdebug or XHProf under the hood.
Some of the most popular solutions are:
While profilers are great tools for debugging and optimizing applications, they are not cheap in terms of resource usage since they do a deep inspection of code execution. Unless you have enough spare resources, we advise that profilers are enabled only when necessary, as in some cases we observed up to 30% higher CPU usage on application servers where some kind of profiler was enabled.
Error reporting
After covering infrastructure monitoring and application profiling, we mustn’t forget about error reporting. While log files are a great source of information when debugging a particular problem that was spotted by a developer or reported by the user, today is crucial to get notified as soon as the error occurs. That way, debugging can begin before users even get the chance to report the problem.
From our experience, and many of our customers would agree, Sentry is probably the best open-source error tracking platform. It supports a large number of programming languages and frameworks, and it’s easily integrated with applications. Integration with 3rd-party services such as GitLab, Jira, and Slack boosts its usability to the next level.
Once integrated with an application, Sentry can catch errors as they happen and send a report to the Sentry server, where loads of useful information can help you understand how and why the problem occurs.
Depending on the programming language and framework, you’ll be presented with exception/backtrace, environment variables, server and visitor information, see the error’s history, etc. You will also have the ability to assign, comment and link the error with your issue tracker, GitHub or GitLab project and in general, collaborate on debugging with others.
Sentry is available both as a service and as a self-hosted solution. If you’d like to give self-hosted Sentry a go, get in touch with us, we can help you set it up and manage it for you.
What’s next?
As we mentioned at the beginning of this article, to properly monitor web applications, many factors have to be taken into consideration. Luckily, today we have a lot of powerful tools that make PHP applications monitoring as well as debugging them easier than ever.
And with that, we conclude our second article in the series. Our next article covers the migration process. As you might already suspect, migrating a large webshop is no easy task. With that in mind, we described our migration process and shared with you some tips on how to migrate your data as painlessly as possible. In the meantime, if you have any questions on this topic, leave us a comment below or get in touch and we’ll be happy to help.
