Kevin Schroeder has a post to his site sharing some helpful tips for monitoring Magento jobs and crons to help provide a bit more information about the job and its current state.

About a month ago a client of mine was lamenting the fact that they didn’t have insight into what was going on with their cron jobs. So I did what any idiot would do and built out a service that does just that. It works with any Magento version, 1 or 2, system crons, and you can use an API to integrate it with your own system with a very minimal amount of work. I call it the 10n Job Health Vault. With Magento 1 or 2 you can have it set up and running in under 5 minutes (minus DI compilation time, of course).

The tool tracks the execution of the job and notifies you if something's wrong and it hasn't finished. This also means it can track the execution time and report back if it's slower than usual. You can find out more information about this Magento monitoring tool on its website.

On the SitePoint PHP blog there's a new tutorial from Daniel Berman showing you how to use the ELK stack to monitor WordPress applications, a combination of Elastic Search, Logstash and Kibana. You can find out about setting this stack up in this previous tutorial.

When something does go wrong, one of the first things you’re going to want to look at are the log files. Not because you enjoy it — log files are not easy to decipher — but because they contain valuable information that can shed light on what exactly occurred.

While [you can use the WP Log Viewer], analyzing WordPress and PHP logs is simply not enough. There are also web server and database logs to sift through. To successfully query huge volumes of log messages coming in from various sources and identify correlations, a more solid solution is required.

Enter the ELK Stack.

He shows how to enable the logging features in your WordPress application (in the wp-config file) and ensure they're not output to the users of your site. He then shows you how to install Filebeat to ship the logs over to the ELK stack. He switches over to the ELK side and shows the configuration needed on Logstash to properly handle the WordPress log format. The remainder of the post helps you get started analyzing the log results and limit it down to only what you need via the Kibana query syntax.

The SitePoint blog has posted a new tutorial from author Daniel Berman about using the ELK stack to monitor PHP applications. The ELK stack is made up of Elasticsearch, Logstash and Kibana to make for effective log storage and searching.

A modern web application environment consists of multiple log sources, which collectively output thousands of log lines written in unintelligible machine language. If you, for example, have a LAMP stack set up, then you have PHP, Apache, and MySQL logs to go through. Add system and environment logs into the fray — together with framework-specific logs such as Laravel logs — and you end up with an endless pile of machine data.

Talk about a needle in a haystack. [...] The ELK Stack (Elasticsearch, Logstash, and Kibana) is quickly becoming the most popular way to handle this challenge. Already the most popular open-source log analysis platform — with 500,000 downloads a month, according to Elastic — ELK is a great way to centralize logs from multiple sources, identify correlations, and perform deep-data analysis.

They walk you through the full installation of all three tools starting with Java (they all require it) followed by instructions for each piece. Once they're all up and running (and playing nice together) they help you configure it to pull in Apache access logs and search on the results. They then populate it with quite a bit more sample data and share some basic tips on searching using the custom searching "language". Finally they talk about the visualizations Kibana offers complete with an example showing browser percentages from users of the site.

On the QaFoo blog there's a post sharing some of what they've learned about the common bottlenecks in performance testing and some things you can to do determine the issues in your own tests.

Most developers by now internalized that we should not invest time in optimizations before we know what happens exactly. [...] This is true for optimizations in your PHP code but also for optimizations regarding your infrastructure. We should measure before we try to optimize and waste time. When it comes to the assumed performance problems in your system architecture most people guess the root cause will be the database. This might be true but in most projects we put under load it proved to be false.

So, how can we figure out where the problems are located in our stack?

They talk about some common testing practices using basic tools (like ab and siege) and having them perform common operations on the application. They then talk about testing for high load, monitoring the stack for the impact and a few tools you can use to gather statistics. They end the post with a quick mention that, despite popular opinion, the issue isn't always the database's fault. Sometimes other technology that's in play - like file locking issues or processing for server-side includes - and other things that may only show up under high load.

7PHP.com has posted another interview with a PHP community member - this time it's Patrick Allaert, the creator of the Alternative PHP Monitor project (a monitoring extension for PHP, collects error events and store them in a local SQLite database).

In this edition I talked with [Patrick Allaert @patrick_allaert], the creator and lead developer of the Alternative PHP Monitor extension. Patrick is also an eZ Publish expert where he is currently a Third line support engineer prior to being their System developer back in 2010. He is an Open Source lover and is a prominent Board member at the famous and amazing PHP group named PHPBenelux.

Patrick answers questions about his history as a developer, what kind of environment he likes to work in, his opinions on PHP and some of the best resources he'd recommend for people learning the language. He also talks some about the APM project - what it does, how it can be used and what some of his future plans are for the tool.

Sébastien Thomas has a recent post to his blog shows how (with just a bit of code) you can monitor your APC cache usage on your local host.

I won't go deep into how OpCode caches work, you will find a lot of docs, just google for APC, Xcache, eAccelerator... What I can say is that APC (as other caches do) will save binary parts of your PHP code into memory and use it when you call for the same PHP function again. This way you save all the PHP file opening, parsing, etc. [...] One thing you won't come accross often on internet is How (the hell) do I know if APC is performing well ?

His answer comes in the form of code based on the APC-PHP-Monitor script. He changed it slightly to allow for use in other places, like with Nagios monitoring. A Nagois template is included to query the cache and report back a hit ratio. An example of the full cache results can be seen here complete with general cache info, hits, misses and file versus user caching stats.

Johannes Schlüter has a new post to his blog today mentioning the beta release of the mysqlnd_ms plugin (previously mentioned by Ulf Wendel and a new feature that can be plugged into the MySQL Enterprise Monitor to make the Query Analyzer directly use PHP instead.

When running a PHP-based application with MySQL it is often quite interesting to see what actually happens on the database sever. Besides monitoring of the system load etc. it is often interesting to see what queries are actually executed and which of them are expensive. A part of MySQL Enterprise Monitor is the MySQL Query Analyzer which helps answering these questions.

This was handled via a proxy that sat between the database and app server and ran through the queries looking for improvements. This new plugin keeps it closer to PHP itself without having to hit against the proxy. You can see the result in these two screenshots from inside the Manager application. You also have the side benefit of getting a stack trace of it running through the app to help you identify the spots most needing improvement in the code too.

Sometimes a little (external) testing of your website is in order and Gagan Chhatwal has posted his list of ten tools you can use to check everything from how much load the site can take to what can be done to optimize the load time.

When maintaining or running a website , Webmasters need to keep in mind that one of the pertinent issues they will need to focus on is :Website Testing, which is not only vital for the website itself but for the user as well and one should not overlook its importance. [We have] collected some vital and free website testing tools which will help Webmasters in testing their sites thus saving users to conduct time consuming needless searches in finding the best resources pertaining to Web related tools and info.

Among the tools on the list are services like:

• Load Impact
• Browser Mob
• Host Tracker
• Built With
• CSE HTML validator

Most of these resources are free services, if not then they have a trial where you can see if it's a good fit.

Brian Moon has a new post to his blog that pulls together some of his thoughts on monitoring PHP applications and how to handle the error that might be thrown.

PHP errors are just part of the language. Some internal functions throw warnings or notices and seem unavoidable. A good case is parse_url. The point of parse_url is to take apart a URL and tell me the parts. Until recently, the only way to validate a URL was a regex. You can now use filter_var with the FILTER_VALIDATE_URL filter. But, in the past, I would use parse_url to validate the URL. It worked as the function returns false if the value is not a URL. But, if you give parse_url something that is not a URL, it throws a PHP Warning error message. The result is I would use the evil @ to suppress errors from parse_url. Long story short, you get errors on PHP systems. And you don't need to ignore them.

He talks about the two-step process he's upgraded to to help monitor and handle the errors that pop up - an error handler that logs human-readable and json versions of the errors and something like Circonus to do metric tracking. He also mentions some external services recommended on twitter - HopToad and Loggly.

In a new post to the CatsWhoCode.com blog Jean-Babtiste Jung walks you through the creation of a simple monitoring script written using just PHP that can tell you if your web site is up and responsive.

In order to make sure that your website is always available to the public, you have to monitor it. In this tutorial, I’ll show you how you can easily create a monitoring script that will check your website availability and send an email or sms alert to you if it isn’t.

They have a snippet of code (about 15 lines long) with a function you can call to check a remote host's connection and check the returned data for a certain string. This can not only ensure that your site is responsive but also that it's not responding incorrectly. You could even use this to hit a certain monitoring page of your site to check for certain things (like database connection problems).