In this new post to his site Emir Karsiyakali shares a quick tip for the Laravel users out there to improve your logging output and make following requests easier.

Putting unique id to requests one of my silver bullet while designing RESTful APIs. It provides an extremely easy way to follow each request’s lifecycle while debugging. In this guide I’ll show you how you can add it to your log files on Laravel 5.6.

Under the hood, Laravel utilizes the Monolog library, which provides support for a variety of powerful log handlers. Laravel makes it a cinch to configure these handlers, allowing you to mix and match them to customize your application’s log handling.

He starts with adding the "tap" value to the logger configuration and pointing it to a newly created LocalLogger class. He shows the implementation of this logger class including a custom log formatter that will modify the log string to add the unique ID after the "datetime" value. He also includes some usage examples in your Laravel code, putting the Log::info line into a LogRequestResponse middleware to be executed on each request.

On his Medium.com site ?brahim Gündüz has posted a tutorial showing you how to send logs from Symfony to Graylog via RabbitMQ, making use of backend queues to handle moving log information into the Graylog instance.

Message Queues are indispensable tools of the systems which is under high load. You can split your systems to small pieces and provide communication between each other through message queue services.

If your system happens by many pieces it means you have so many log entries which is coming from multiple application instances in same time. So you should scale your logging system like how you scaled your application also. Otherwise, your application may go down because of your logging system might be bottleneck.

You can use message queue systems to avoid this trouble.

He starts by helping you install the Composer dependencies required for the RabbitMQ interface and defining the configuration in Symfony to make the connection to the queue. With this in place he moves over to the RabbitMQ side and sets up the queue and exchange to handle the incoming log information. He then creates a LoggingTestCommand command to test out sending the logs to the queue and shows the setup of Graylog to read from that queue and pull in the information automatically.

On TutsPlus.com they've continued their series showing the construction of a startup (a calendaring site) using PHP and the Yii2 framework. In this latest article they walk you through their construction of a notification system when others need to be informed/invited to meetings in the system.

This tutorial is part of the Building Your Startup With PHP series on Envato Tuts+. In this series, I'm guiding you through launching a startup from concept to reality using my Meeting Planner app as a real-life example. [...] In this two-part series, I'll describe how we built the notifications infrastructure and their delivery. Today, I'm going to focus on the MeetingLog to track changes that help us determine when to send updates.

They start with their vision of how the notification system should work (starting at the UI level) and the types of responses an invited user could reply with. The article then gets into how the notifications will work and the creation of the first step: a log to track all actions taken around notifications. They include the model to work with the logging table, adding a new log message, defining the logging command and finding specific log messages. With that in place, the tutorial switches to the frontend, showing what the notifications should look like using flash messages and a few updates to the views in the application.

In a new post to the Liip blog Karine Chor shares some helpful Drupal 8 debugging tips and things you can do to determine what you code is doing "under the covers".

It has been nearly 7 months since Drupal 8 first release and as a developer, I am still in the learning process. It can be hard sometimes to know what is going wrong with your code and how to solve it. I will tell you about few things to know on how to develop and debug Drupal 8 projects and continue learning, learning and learning !

Her tips cover topics like:

• Disabling cache
• Displaying errors
• Creating log messages
• Debugging Twig templates
• Profiling pages

The post ends with a section covering use of the the Drupal command line tool to provide even more real-time debugging functionality.

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.

In this post to his site Gonzalo Ayuso shows you how to create a logger for your POST requests and their information with a bit of helpful code and Websockets.

Last days I’ve been working with background geolocation with an ionic application. There’s a cool plugin to do that. [...] Basically this plugin performs a POST request to the server with the GPS data. [...] I can develop a simple Silex application with a POST route and log the request in a file or flush those request to the console. This’d have been easy but as far as I’m a big fan of WebSockets (yes I must admit that I want to use WebSockets everywhere :) I had one idea in my mind.

He shows the creation of a simple Silex-based application with just two endpoints (channel that handles both GET and POST) that uses the Guzzle HTTP library to listen on the Websockets port for incoming connections. He then shows how to add the code necessary on the frontend (using express) to send the POST data automatically to the waiting Silex application. He's provided the full working code for the example on his GitHub account as well so you can see it fully fleshed out.

On the Lakion blog there's a post showing you how to debug your application's Behat tests easily as a part of your continuous integration process. In thieir case, they were trying to figure out why builds were breaking on a Travis-CI build instance.

Debugging Behat scenarios while using Mink to simulate the user is not always an easy job. Especially, if they are run on Continuous Integration server. That is why I came up with an idea to make it easier. During repairing our javascript test suite on Sylius everything went as bad as it could go. There were many errors that happened on Travis, but I was not able to reproduce them locally. [...] MinkDebugExtension was written to speed up that boring and tiring part of debugging on CI server. It consists of two parts: Behat extension and useful scripts.

The extension fires after failed steps and makes a log of the issue with content needed to recreate the issue (including possible screenshots). He also describes the scripts that come with it to help you browse through the results, uploading the resulting logs and screenshots to a place for public consumption.

Rob Allen continues his posts looking at the use of the Slim PHP framework with this new post about logging errors.

Slim Framework 3 is being actively developed at the moment and has a number of changes in it, including the use of the Pimple DI container and an overhaul of pretty much everything else! In this post, I'm going to look at error handling. The default error handler in Slim 3 is SlimHandlersError. It's fairly simple and renders the error quite nicely, setting the HTTP status to 500. I want to log these errors via monolog.

He includes the code to first set up the Monolog logger and inject it into the dependency injection container. Then he creates a custom error handler that extends the Slim handler but overrides the __invoke method to log the message in addition to displaying it. Finally he registers the error handler into the DI container as the "errorHandler" instance so Pimple correctly knows how to throw errors.

Peter Petermann has an interesting post he's added to his site describing a lesser known feature of the Composer package manager: virtual package support.

A few days ago i stumbled over a “virtual package” on packagist – and found it to be a feature that i was actually missing in composer. Turns out, composer can do it, its just not so well documented. So what is this about? Virtual packages allow you to have a more loose dependency. Rather than depending on a specific package, you depend on a virtual one, which can be fulfilled by all packages that provide the virtual one.

He includes a few examples to help illustrate the point of using virtual packages. The first describes an application that wants to use the PSR-4 logger structure but depends on "log-implementation" (a virtual package) rather than the "psr/log" package. The key is in using the "provide" keyword in the Composer configuration. His other two examples expand on this a bit, one showing the use of the "provide" keyword to define the relationship and the other of an actual application making use of this package.

Gonzalo Ayuso as a new post today showing the results of some of his testing with the event dispatcher and Silex to send logs to a remote server.

Today I continue playing with event dispatcher and Silex. Now I want to send a detailed log of our Kernel events to a remote server. We can do it something similar with Monolog, but I want to implement one working example hacking a little bit the event dispatcher. Basically we’re going to create one Logger class (implementing PSR-3 of course).

He includes the sample code defining a "Logger" class that takes whatever message sent to it and pushes it into a given socket resource. He also creates a provider for the logger to implement it in the example and registers it with the event dispatcher. He hooks it into the request, get controller, terminate and exception events. On the other side he uses React to make a basic server to listen on port 4000 for the incoming log data.