The Amazon AWS blog has posted a tutorial helping you get started using Amazon CloudWatch logging from PHP. CloudWatch is a logging service offered by Amazon that comes with features making it easier to track metrics, set alarms and monitor log files.

Logging and information debugging can be approached from a multitude of different angles. Whether you use an application framework or coding from scratch it’s always comforting to have familiar components and tools across different projects. In our examples today, I am going to enable Amazon CloudWatch Logs logging with a PHP application. To accomplish this, I wanted to use an existing solution that is both already popular and well used, and that is standards compliant. For these reasons, we are going to use the open source log library, PHP Monolog.

They start the tutorial with a brief overview of both Monolog and the CloudWatch logging service. From there they help you get the AWS PHP SDK and Monolog installed and an add-on that lets Monolog talk to CouldWatch. The post then provides some example code showing how to set up the PHP-to-CloudWatch connection and what the logging result looks like. They also include instructions on setting up logging filters/metrics and, as a bonus, how to use CloudWatch logging in a Laravel application.

In this new tutorial from the TutsPlus.com site they introduce you to the exception handling that comes along with the Laravel framework and how you can work with it in your own applications.

In this article, we're going to explore one of the most important and least discussed features of the Laravel web framework—exception handling. Laravel comes with a built-in exception handler that allows you to report and render exceptions easily and in a friendly manner.

In the first half of the article, we'll explore the default settings provided by the exception handler. In fact, we'll go through the default Handler class in the first place to understand how Laravel handles exceptions. In the second half of the article, we'll go ahead and see how you could create a custom exception handler that allows you to catch custom exceptions.

You'll need to have a Laravel instance set up already to follow along (instructions not provided here). The tutorial starts with a change to the base configuration for the "APP_DEBUG" and "APP_LOG" settings to enable/disable the error handling and output. Next comes a look at the base exception class for the framework - code included - and a closer look at its report and render methods. Finally it gets into the creation of a custom exception class including the code required to create it and where it should be located in the application for use.

With the final release of PHP 7.2 coming on the horizon the Exakat blog wants to be sure you and your code are prepared for some of the changes. In this new post they share things to change and improvements to expect in this latest version of the PHP language.

PHP 7.2 is around the corner, and shall be out soon, thanks to the hard work of @RemiCollet), Sara Golemon (@saramg) and countless others that run tests and submit bug reports. PHP 7.2 is already RC6, and the documentation has even been updated : it is high time to get ready for PHP 7.2.

We have been hard at work, at @Exakat, to prepare the migration analysis. This is our take on this upcoming task.

He's broken the changes coming down into a few categories based on the actions required and what you can do to prepare: Know, Lint, Static (Analysis), Unit testing and Logging. A chart is then included showing each of the changes, which category they fall into and links to more information about them and what has been updated (or added).

On the Zend Framework blog there's a new post in their series highlighting components of the main framework. In this new tutorial they look a the Zend-log component and how it can be used for logging in your application.

Every PHP application generates errors, warnings, and notices and throws exceptions. If we do not log this information, we lose a way to identify and solve problems at runtime. Moreover, we may need to log specific actions such as a user login and logout attempts. All such information should be filtered and stored in an efficient way.

[...] Zend Framework offers a logging component, zend-log; the library can be used as a general purpose logging system. It supports multiple log backends, formatting messages sent to the log, and filtering messages from being logged.

The tutorial then walks you through the installation of the component and some basic usage of it to write directory to the 'php://output' stream. It then shows you how to set up custom formatting on the message and a few other examples of it in use:

• logging PHP events (errors/exceptions)
• using the built-in data (level) filtering functionality
• custom processors
• working with multiple backends for storage

The post ends with a look at using the Zend-log package in either a traditional MVC application or one based more on middleware (like an Expressive application).

On the Amazon Web Services blog there's a new post showing you how to use the Monolog logging library and a custom AWS extension to ship your logs to Amazon CloudWatch quickly and easily.

Logging and information debugging can be approached from a multitude of different angles. Whether you use an application framework or coding from scratch it’s always comforting to have familiar components and tools across different projects. In our examples today, I am going to enable Amazon CloudWatch Logs logging with a PHP application. To accomplish this, I wanted to use an existing solution that is both already popular and well used, and that is standards compliant. For these reasons, we are going to use the open source log library, PHP Monolog (https://github.com/Seldaek/monolog).

They start by introducing the Monolog library for those not familiar with it and how it relates to the PSR-3 standard. The ultimate goal with their implementation is to allow for the logs to be shipped to CloudWatch and implement some alerting around them. The tutorial then kicks in and they show you how to use Composer to install Monolog and an add-on to interface with CloudWatch. Code is provided to set up the initial logger and how to have it to log messages to different places. They then move over to CloudWatch and define a filter for the JSON data to find successful logins to your application. They also show how to use this same functionality in a Laravel application, contained in a test route.

On the DaedTech blog Erik Dietrich has written up a list of a few things he suggests avoiding when using logging functionality in your application. The suggestions range from the actual contents of the message out to some logging best practices.

It seems almost strange to talk about avoiding things while logging. After all, logging is your last line of defense or your salvation in many cases. [...] Well, it turns out that, while logging may be a highly inclusive activity in terms of what should be included, there are ways to create problems. You want to be liberal in terms of what you log, but judicious and wise in terms of how you log it. You don’t want to indulge in a feckless free-for-all when it comes to the calls you make to your application’s logger.

So what are these problems, and how to avoid them? Let’s take a look at some things that can come back to bite you.

He points out the following (common) bad practices he has seen during his time developing:

• Forgetting Context
• Cryptic Codes
• Spamming the Log File
• Unsafe Logging Calls
• Mixing Application Logic with Logging

He ends the post with a suggestion of "sensible logging" - capturing as much meaningful information as possible while not overdoing it. Logs can be a powerful ally when hunting down an issue or trying to provide documentation of a security issue. Log wisely, log on purpose.

On the SitePoint PHP blog there's a new tutorial posted by Younes Rafie looking at logging of mail handling in Laravel by extending the already included driver with your own updates.

One of the many goodies Laravel offers is mailing. You can easily configure and send emails through multiple popular services, and it even includes a logging helper for development.

[...] Laravel also provides a good starting point for sending mails during the development phase using the log driver, and in production using smtp, sparkpost, mailgun, etc. This seems fine in most cases, but it can’t cover all the available services! In this tutorial, we’re going to learn how to extend the existing mail driver system to add our own.

They start by helping you create the service provider used to log the mail information to a database table (the DBMailProvider). The extend the existing mail provider class and set it up to register the Swift Mailer provider if the configuration for the mailer is not set to "db". The the tutorial shows how to update the provider to override the swift.mailer instance in the application dependency injection container and include the code to override the "send" method. A migration is created to hold the mail data and a matching Emails model is used to save the mail results.

In a new post to his site Freek Van der Herten shares information about a logging package they've developed for Laravel-based applications to make activity logging simpler throughout the app: laravel-activitylog.

n your apps there’s probably a lot going on. Users log in and out, they create, update and delete content, mails get sent and so on. For an administrator of an app these events provide useful insights. In almost every project we make at Spatie we log these events and show them in the admin-section of our site. [...] We made a new package called laravel-activitylog that makes logging activities in a Laravel app a cinch. In this blogpost I’d like to walk you through it.

He then goes through the basics of using the library, complete with code examples:

• simple activity logging with messaging
• providing the "acted on" object information
• logging the information about who the actor was

There's also a section with details on automatic model logging, making it easier to see the changes on you data without having to log each one individually. He also shows you how to use multiple logs, providing a method to narrow down log records by type.

Loggly, the online logging management service, has posted a guide that aims to help you get up to speed with logging in PHP starting from the basics out to more recent changes in PHP 7.

This guide explores the basics of logging in PHP, where to find PHP logs, and how these logs help you more effectively troubleshoot problems and monitor your PHP application. There are a couple of different elements you’ll want to consider logging: errors emitted by the PHP engine itself when a core function fails or if code can’t be parsed, custom errors that your application triggers, usually caused by missing or incorrect user input and activities in your application that you may want to analyze at a later time, such as recording when a user account is updated or content in a CMS is updated

They start with a look at the configuration settings you can change to modify how and what your application logs. They also mention run-time configuration changes and the default error log locations (file-based). From there they get into some of the basic, built-in logging functions and the format of the logs they write. The next section talks about application error logs (logs based on failures in PHP itself) and an example of writing logs with JSON instead of plain text. The post ends with a look at exception handling and logging for base, custom and SPL exception types, pointing out the change in PHP 7 around the Throwable interface.

On the Coding.bmail.net blog they've posted a guide to what they've called an advanced logging system in PHP for careful developers - essentially a logging system that's as "error proof" as possible and that works with as little user exposure as possible.

Being aware of all the activity and problems under the hood is essential when running big websites with lots of users, many features and, as it is usual in such cases, weak spots that must not be left untracked.

In order to be the first in knowing when errors or other events of interest happen we need a well designed logs manager. My code will provide such a feature, for PHP based websites.

They briefly outline how the complete setup will work, failing back to email if the database connection isn' available and logging based on environment. It also includes error levels and, on development only, a method for showing the errors being logged. While a good bit of this functionality could be handled by something like Monolog they do include some additional features like the email fallback, output of the errors in development mode and custom error/exception handlers.